Date: Mon, 12 Nov 2012 09:35:25 +0100 From: Fabien Thomas <fabien.thomas@netasq.com> To: "Alexander V. Chernikov" <melifaro@FreeBSD.org> Cc: freebsd-net@freebsd.org, Ingo Flaschberger <if@xip.at> Subject: Re: [patch] reducing arp locking Message-ID: <BC90EF90-F232-4855-9430-F7AAB803B265@netasq.com> In-Reply-To: <509D518A.9000803@FreeBSD.org> References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> <509CC776.9010200@FreeBSD.org> <37E1F76F-D951-4B36-AF00-039DA1CC5CF3@netasq.com> <509CE6A2.2040200@FreeBSD.org> <8169CD67-E444-46FC-A7C8-DD6FB59091E1@netasq.com> <509D32CC.6000201@xip.at> <AA0D6054-D300-409E-918C-98B206D11F55@netasq.com> <509D518A.9000803@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > WBR, Alexander >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC90EF90-F232-4855-9430-F7AAB803B265>