lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] [lwip] RE:[lwip-members] improved Ethernet ARP on my web s


From: leon . woestenberg
Subject: [lwip-users] [lwip] RE:[lwip-members] improved Ethernet ARP on my web site, seeking testers
Date: Thu, 09 Jan 2003 00:11:15 -0000

Hello all,

Paul Sheer had some remarks on the (new) etharp.c design which allows me
to explain the changes more in detail:

> > > - update (i.e. time-stamp) existing entries on foreign ARP traffic.
> isn't the code doing this already for all traffic?
> since update_arp_entry is called for any IP packet
>
IP yes, but not for any ARP packet.

For example, of any ARP request to us, the source IP would not enter the
cache. Furthermore, foreign ARP traffic (between two other hosts) was
ignored as well.

> > - ARP now uses link level output function, so both an ARP reply and a
> > queued IP packet can be sent at the same time.
> i think it is very rare to have to send both
>
This situation occurs when an ARP entry is going from PENDING to STABLE
by means of an incoming ARP request to us. If this occurs, we must both
reply with ARP, as well as send the queued packet.

The current implementation could NOT do both, and the packet would still
be on the queue. Furthermore, the code did not cater for queued packets
in STABLE entries. I have not examined whether this caused memory leaks
in the old implementation but my guess is it does.

> > - ARP is now more persistent on queries (and can do requests more
often).
> the biggest problem with the previous ARP code was that it
> did not create new entries for arbitrary IP packets. Hence
>
I understand what you mean. However, the ARP cache is referenced for
outgoing
IP packets only, and should be optimized towards that usage.

Updating on arbitrary IP packets would indeed keep more entries more
up-to-date, but we must not destructively overwrite heavily used
ARP entries.

> if you'd ping a LwIP host, you never got an immediate
> reply. Instead you got an ARP request back, and then a
> ping reply later.
>
>This ARP request is theoretically unnecessary because the
>ping request contains the ethernet hardware address. I think
>most IP stacks work this way.
>
This behaviour is now correct, like you described.

> The second problem is that the ARP table could grow
> large: I have set mine to 120. Now all arp entries must
> be searched with each packet. This is unnecessary CPU
> cost. My own ARP table grows and shrinks as required.
>
Dynamic vs. static resource allocation is always a delicate
topic in embedded design. I think static works best for
most of us. In case of many hosts, a dynamically resizing
cache might indeed be beneficial.

ARP cache sorting is in the plans, but not high-priority.
Reserving entry #0 for the default gateway can be easily
implemented, and might be worthwhile.

Regards,

Leon Woestenberg.

[This message was sent through the lwip discussion list.]




reply via email to

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