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 =E0 19:55, Alexander V. Chernikov a =E9crit : > On 09.11.2012 20:51, Fabien Thomas wrote: >>=20 >> Le 9 nov. 2012 =E0 17:43, Ingo Flaschberger a =E9crit : >>=20 >>> 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. >>>=20 >>> what about this: >>=20 >> 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 >>=20 >> is now a lot more unclear and from my point of view dangerous. >=20 > 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. >>=20 >> 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). >=20 > .. and it seems flags handling (LLE_VALID) should be done with more = care. >>=20 >> Fabien >>>=20 >>> _______________________________________________ >>> 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" >>=20 >> _______________________________________________ >> 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" >>=20 >=20 >=20 >=20 > --=20 > WBR, Alexander >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC90EF90-F232-4855-9430-F7AAB803B265>