[Top][All Lists]

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

[lwip-devel] [task #6827] etharp could need some tuning

From: Simon Goldschmidt
Subject: [lwip-devel] [task #6827] etharp could need some tuning
Date: Wed, 30 May 2007 07:40:06 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20070309 Firefox/

Follow-up Comment #9, task #6827 (project lwip):

> Except that, replace "arp_table[i]" by a pointer should have a high cost.
But like each change, do some measures can help to decide if the patch is
good or no...

I can't really measure that. In my disassembly, accessing arp_table[i] is
done loading the address of arp_table into a register, adding
i*sizeof(arp_entry) to it and then accessing the members of the struct with a
'load addr+offset' instruction. In that case, a pointer is better because
adding of i*sizeof(arp_entry) is not needed and 'load addr+offset' for the
struct members is the same. So now I could do some measurement comparing
arp_table[i] to arp_entry* but that would only tell me what's better on my
target. That's why I wanted to hear some other opinions...

Can you give me more details why you think the pointer has a higher cost?

> The problem is more to know if it's need to improve that or not.

You mean adding a hash table? That's dependent on how you use lwIP. The
current implementation is really slow (unless you have a table with only 10
entries, but that way, you easily end up throwing away entries you would need
later...). The recently added one-entry-cache speeds up things if you talk to
one host only. Including a hash-table is much too big for some embedded
targets, of course. But it's the way most switches to that work, so it can't
hurt for lwIP. It depends on the table size. If you have a table with 100
entries, calculating the hash is faster. And I still would add the linked
list which is automatically sorted each time it is accessed (moving the
wanted entry one step forward, that way entries that are used often are at
the beginning of the list).

All that requires that we can use the arp_entries without accessing it like


Reply to this item at:


  Nachricht geschickt von/durch Savannah

reply via email to

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