[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] possible find_arp_entry() issue?
From: |
Ed Sutter |
Subject: |
[lwip-users] possible find_arp_entry() issue? |
Date: |
Fri, 17 Jan 2003 18:49:07 -0500 |
Hello,
I've been tracking down a performance issue in my system and
I think I stumbled onto something...
I have my target on a network with several machines (a lot
of traffic), and I also have ETHARP_ALWAYS_INSERT set to 1.
That being said, here's what I found...
If all entries in the arp_table[] array are stamped AND the
find_arp_entry() function is called within the same
ARP_TMR_INTERVAL window, the value of global ctime and
all of the arp_table[].ctime entries will be the same.
In that case, the function find_arp_entry() will return
ARP_TABLE_SIZE, erroneously indicating that there are
no arp_table[] slots available. This will occur because
in every case 'ctime - arp_table[i].ctime' will be zero;
hence, j will remain set to ARP_TABLE_SIZE.
If someone else can take a look at this and it is agreed
that this is a bug, I have a fix for it, so please let
me know.
Also, a minor note...
Under some extreme cases it is valid for find_arp_entry()
to return ARP_TABLE_SIZE, and in that case, the DEBUGF()
statement at the bottom of the function will attempt to
dump the content of arp_table[ARP_TABLE_SIZE].state, which
is outside the boundary of the table. This should be
qualified with a test for the value of 'i'.
Ed Sutter
els.vcf
Description: Card for Ed Sutter
- [lwip-users] possible find_arp_entry() issue?,
Ed Sutter <=