[RFC] Remove calls to etharp_ip_input(). (Was: Re: [lwip-devel] more slow code)

[Leon Woestenberg]

Hello Christiaan,

Christiaan Simons wrote:
> It's etharp_ip_input(), which in turn calls
> update_arp_entry() and find_entry() for
> each incomping IP packet.
> ...
> I guess lot off subsequent (burst) IP packets can come from the same
> source,
> without much use for updating the table.
>   
Good find.

I upgraded etharp.c to the full RFC 826 specification, along with the 
"related issue" on the back about timeouts and cache refreshes, and 
removing this call *altogether* was still on my roadmap.

There is no longer a need for the call to etharp_ip_input() from the 
ingress traffic handling code (the network driver in our case).

It also makes the stack more BSD compliant (AFAIK), as most stacks *do 
not update their ARP cache from IP packets*.

So I suggest to remove the call to etharp_ip_input() altogether.

 switch (htons(ethhdr->type)) {
 /* IP packet? */
 case ETHTYPE_IP:
   /* update ARP table */
   etharp_ip_input(netif, p);
   /* skip Ethernet header */

From then on, ARP resolution depends solely on the proper workings of 
etharp.c on outgoing traffic only. I.e. if a local network recipient's 
hardware address is not in the cache when a packet is transmitted, 
etharp will (optionally cache the outgoing packet and) perform an ARP 
request.

Of course, I would like to see some people testing this, as this typical 
simple case will become more involved:

A = some host
B = lwIP host

old:

Application on A knows address of B.
Host A sends IP packet F to B (B=lwip)
lwIP in B caches IP address of A.
Host B sends packet P to A.
lwIP in B does not know about adress of A, caches

new:

Application on A knows address of B.
Host A sends IP packet F to B (B=lwip)
Application B sends packet P back to A.
lwIP in B does not know about adress of A, caches P, broadcasts ARP 
request R for address A.
Host A responds with ARP response R to B.
lwIP in B caches IP address of A.
Host B sends cached packet P back to A.

From this point on, the ARP cache is OK, and kept up to date by the ARP 
timer, and everything would proceed as usual in both the old and new 
situation.

Regards,

Leon Woestenberg.