[patch] reducing arp locking

[Fabien Thomas]

Le 9 nov. 2012 à 19:55, Alexander V. Chernikov a écrit :

> On 09.11.2012 20:51, Fabien Thomas wrote:
>> 
>> Le 9 nov. 2012 à 17:43, Ingo Flaschberger a écrit :
>> 
>>> Am 09.11.2012 15:03, schrieb Fabien Thomas:
>>>> In in_arpinput only exclusive access to the entry is taken during the update no IF_AFDATA_LOCK that's why i was surprised.
> I'll update patch to reflect changes discussed in previous e-mails.
>>> 
>>> what about this:
>> 
>> I'm not against optimizing but an API that seems clear (correct this if i'm wrong):
>> - one lock for list modification
>> - one RW lock for lle entry access
>> - one refcount for ptr unref
>> 
>> is now a lot more unclear and from my point of view dangerous.
> 
> This can be changed/documented as the following:
> - table rW lock for list modification
> - table rW lock lle_addr, la_expire change
> - per-lle rw lock for refcount and other fields not used by 'main path' code

Yes that's fine if documented and if every access to lle_addr + la_expire is under the table lock.

>> 
>> My next question is why do we need a per entry lock if we use the table lock to protect entry access?
> Because there are other cases, like sending traffic to unresolved rte (arp request send, but reply is not received, and we have to maintain packets queue to that destination).
> 
> .. and it seems flags handling (LLE_VALID) should be done with more care.
>> 
>> Fabien
>>> 
>>> _______________________________________________
>>> freebsd-net at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>> 
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>> 
> 
> 
> 
> -- 
> WBR, Alexander
>