[lwip-devel] RE: more slow code

[Bob Grice]

I added a quick patch to the code by adding a wrapper around the existing 
find_entry (which I renamed to search_entry). There is an improvement my tcp 
throughput increased about 2 %, but my arp cache is not really populated very 
much as I am only doing a couple of concurrent ftp sockets - maybe someone 
doing web server could re-measure.

Patch code
==========

/**
 * Search the ARP table for a matching or new entry.
 *
 * cache locally the last seach_entry result, if the same address
 * is requested again, return the cached copy of the index, otherwise
 * perform a full search.
 * 
 * Update the local cache after a successfull search
 * 
 *  
 * @return The ARP entry index that matched or is created, ERR_MEM if no
 * entry is found or could be recycled.
 */
static s8_t find_entry(struct ip_addr *ipaddr, u8_t flags)
{
        static  s8_t    last = 0;
                        s8_t    result;
        

        if ( ( (arp_table[last].state == ETHARP_STATE_PENDING) || 
                   (arp_table[last].state == ETHARP_STATE_STABLE) ) && 
                 (ipaddr && ip_addr_cmp(ipaddr, &arp_table[last].ipaddr) ) )
        {
                result = last;  
        }
        else
        {
                result = search_entry(ipaddr,flags);
                if (ERR_MEM != result)
                {
                        last = result;                                  /* 
remember for next call       */
                }       
        }
        
        return(result);
}

 

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of address@hidden
Sent: 04 April 2006 17:06
To: address@hidden
Subject: lwip-devel Digest, Vol 22, Issue 1

Send lwip-devel mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.nongnu.org/mailman/listinfo/lwip-devel
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lwip-devel digest..."


Today's Topics:

   1. more slow code (Christiaan Simons)
   2. Re: more slow code (Atte Kojo)
   3. Re: more slow code (Kieran Mansley)


----------------------------------------------------------------------

Message: 1
Date: Tue, 4 Apr 2006 10:42:34 +0200
From: "Christiaan Simons" <address@hidden>
Subject: [lwip-devel] more slow code
To: address@hidden
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=US-ASCII


Hi,

I've found some more cycle consuming code
(besides pbuf_alloc()/_free()).

It's etharp_ip_input(), which in turn calls
update_arp_entry() and find_entry() for
each incomping IP packet.

I think the linear search in find_entry()
over the ARP table is the culprit.

I guess lot off subsequent (burst) IP packets can come from the same
source,
without much use for updating the table.
So update_arp_entry() should return as quickly as possible for that case.

Christiaan Simons

Hardware Designer
Axon Digital Design

http://www.axon.tv





------------------------------

Message: 2
Date: Tue, 4 Apr 2006 11:57:45 +0300
From: Atte Kojo <address@hidden>
Subject: Re: [lwip-devel] more slow code
To: lwip-devel <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain;  charset="iso-8859-1"

On Tuesday 04 April 2006 11:42, Christiaan Simons wrote:
> I think the linear search in find_entry()
> over the ARP table is the culprit.
>
> I guess lot off subsequent (burst) IP packets can come from the same
> source,
> without much use for updating the table.
> So update_arp_entry() should return as quickly as possible for that case.

One solution that comes to my mind is to keep a one-entry cache in 
find_entry(). This should at least speed up the case when the stack is 
communicating with a small number of hosts and when receiving bursts of IP 
packets.

-- 
Atte Kojo
Software Development Engineer
Elekta Neuromag Oy
Street address: Elimäenkatu 22, Helsinki, Finland
Mailing address: P.O. Box 68, FIN-00511 HELSINKI, Finland
Tel: +358 9 756 24084 (direct), +358 9 756 2400 (operator)
Fax: +358 9 756 24011
E-mail: address@hidden
www.elekta.com




------------------------------

Message: 3
Date: Tue, 4 Apr 2006 10:37:18 +0100
From: Kieran Mansley <address@hidden>
Subject: Re: [lwip-devel] more slow code
To: lwip-devel <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

On Tue, Apr 04, 2006 at 11:57:45AM +0300, Atte Kojo wrote:
> On Tuesday 04 April 2006 11:42, Christiaan Simons wrote:
> > I think the linear search in find_entry()
> > over the ARP table is the culprit.
> >
> > I guess lot off subsequent (burst) IP packets can come from the same
> > source,
> > without much use for updating the table.
> > So update_arp_entry() should return as quickly as possible for that case.
> 
> One solution that comes to my mind is to keep a one-entry cache in 
> find_entry(). This should at least speed up the case when the stack is 
> communicating with a small number of hosts and when receiving bursts of IP 
> packets.

Agreed.  That would be both simple to implement and catch many of the
cases that lwIP is likely to encounter.

Kieran




------------------------------

_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel


End of lwip-devel Digest, Vol 22, Issue 1
*****************************************