[En-Nut-Discussion] ARP cache again

[Dusan Ferbas]

Hi Harald,

for server side it is only theoretical. But e.g. 2 threads doing UDP send, 
both originating on Nut/OS side.

Then waiting forever is in worst case 7,5 seconds (0,5 + 1 + 2 + 4).

If 1st thread is trying to do ARP resolve and is doing e.g. 3rd attempt, 
then it exits and releases ARP entry. If 2nd thread starts ARP resolving 
before 1st one finishes then it waits on NutEventWait(&entry->ae_tq, tmo); 
current tmo period. If during that wait 1st one finishes and in application 
layer another packet is queued (e.g. after a second), thread proceeds to 
resolve new ARP request. If this occures before 2nd thread finishes 
waiting, then 2nd thread think that 1st one is still waiting.

Situation is that Nut/OS device has ethernet cable unplugged. If you plug 
cable in, it can happen that you will have 1st packet after 7,5 second. 
Time is wasted because of ARP resolving mechanism.

And just a simple line of waking up all threads waiting on an ARP entry 
when entry is released solve this. But it is only my idea so I am posting 
it here for further discussion.


> >- if 2nd thread is waiting for an ARP entry completion and 1st thread
> >removes that entry, then 2nd thread is locked forever
> >
> >I suggest to announce such an ARP entry release in ArpCacheFlush():
> >
> >             *aep = ae->ae_next;
> >             free(ae);
> >             NutEventBroadcast(&ae->ae_tq);      //<< added to release
> > other possibly waiting thread(s)
>
>I do not understand your point here. Where is it locked forever?


Thank you for chewing our contributions.


Dusan