lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leon Woestenberg
Subject: [RFC] Remove calls to etharp_ip_input(). (Was: Re: [lwip-devel] more slow code)
Date: Sat, 22 Apr 2006 18:38:39 +0200
User-agent: Thunderbird 1.5.0.2 (Windows/20060308)

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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]