lwIP - A Lightweight TCP/IP stack - Patches: patch #7135, Significant etharp optimization...
You are not allowed to post comments on this tracker with your current authentication level.
patch #7135: Significant etharp optimization for TX speed improvement
Submitter: | Bill Auerbach <billauerbach> | ||
Submitted: | Fri 26 Mar 2010 04:59:33 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | goldsimon | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Mon 29 Mar 2010 02:17:32 PM UTC, comment #7: |
Simon Goldschmidt <goldsimon> |
Mon 29 Mar 2010 12:48:44 PM UTC, comment #6: This is good - sorry for a half-baked patch. What does bother me is why should the ARP table be involved at all if there are opened connections to the IP address? Because in this case the ARP entry cannot change. At this time it seems unnecessary to me. I'll brush up on the RFC.
|
Bill Auerbach <billauerbach> |
Mon 29 Mar 2010 09:00:41 AM UTC, comment #5: I much prefer Simon's version of this: having a copy of ARP data that doesn't time out or change when the ARP data changes would cause some users problems.
|
Kieran Mansley <kieranm> |
Sat 27 Mar 2010 04:55:51 PM UTC, comment #4: I just moved the code that handles "etharp_cached_entry" (or netif->addr_hint) from find_entry() to etharp_output() and etharp_query(). For LWIP_NETIF_HWADDRHINT==0 and with one netif only, this is exactly the same as the original patch only it is in sync with the arp_table. With LWIP_NETIF_HWADDRHINT==1, this is slightly slower for one connection, but faster for multiple concurrent connections.
|
Simon Goldschmidt <goldsimon> |
Sat 27 Mar 2010 09:38:56 AM UTC, comment #3: The current LWIP_NETIF_HWADDRHINT==1 code also avoids searching the cache, it merely test if the hwaddr is really OK (it's still marked as stable in the cache). This test would be omitted with your code and an entry would never time out with only one active connection and no other packets being sent.
|
Simon Goldschmidt <goldsimon> |
Fri 26 Mar 2010 09:56:27 PM UTC, comment #2: This avoids searching that cache (if you mean the ARP table). If you mean something else, then I think it's not as good as this. If it's done at the pbuf level, didn't already pass the ARP tests?
|
Bill Auerbach <billauerbach> |
Fri 26 Mar 2010 09:35:40 PM UTC, comment #1: We already have such a cache, but per pcb (which is better than per netif when having more than one simultaneous connection). Maybe we can minimize the code flow when LWIP_NETIF_HWADDRHINT==1 so that we can prevent find_entry getting called instead of adding yet another option/cache? |
Simon Goldschmidt <goldsimon> |
Fri 26 Mar 2010 04:59:33 PM UTC, original submission:
This is a significant optimization as it avoids ARP lookups on every packet sent through a netif to the same IP address:
|
Bill Auerbach <billauerbach> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-04-14 | goldsimon | Status | Ready For Test | Done | |
Open/Closed | Open | Closed | |||
2010-03-27 | goldsimon | Status | None | Ready For Test | |
Assigned to | None | goldsimon |
Powered by Savane 3.13-02a9.
Corresponding source code
That might not be a common case, but it's still valid. Suppose an administrator exchanged network interfaces for a PC. If our ARP table wouldn't be updated when we see a corresponding packet, we would never be able to reach that PC unless the open connections are dropped (which can be a long time for TCP).
The current implementation has the downside that (if ETHARP_TRUS_IP==0) the timer is not reset when receiving packets (which, at the ARP layer, would be the only detection of having an open connection), so an ARP entry will always time out after the max-time (which is quite long though).