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
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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
--
WBR, Alexander
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
