Date: Fri, 09 Nov 2012 13:05:58 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: Fabien Thomas <fabien.thomas@netasq.com> Cc: freebsd-net@FreeBSD.org, Andre Oppermann <oppermann@networx.ch>, freebsd-hackers@FreeBSD.org Subject: Re: [patch] reducing arp locking Message-ID: <509CC776.9010200@FreeBSD.org> In-Reply-To: <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com> References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> <49EE4F42-6162-40F4-9DE0-1ACA1289B225@netasq.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09.11.2012 12:51, Fabien Thomas wrote: > > Le 8 nov. 2012 à 11:25, Alexander V. Chernikov a écrit : > >> On 08.11.2012 14:24, Andre Oppermann wrote: >>> On 08.11.2012 00:24, Alexander V. Chernikov wrote: >>>> Hello list! >>>> >>>> Currently we need to acquire 2 read locks to perform simple 6-byte >>>> copying from arp record to packet >>>> ethernet header. >>>> >>>> It seems that acquiring lle lock for fast path (main traffic flow) is >>>> not necessary even with >>>> current code. >>>> >>>> My tests shows ~10% improvement with this patch applied. >>>> >>>> If nobody objects I plan to commit this change at the end of next week. >>> >>> This is risky and prone to race conditions. The copy of the MAC address >>> should be done while the table read lock is held to protect against the >> It is done exactly as you say: table read lock is held. > > How do you protect from entry update if i've a ref to the entry ? > You can end up doing bcopy of a partial mac address. I see no problems in copying incorrect mac address in that case: if host mac address id updated, this is, most likely, another host, and several packets being lost changes nothing. However, there can be some realistic scenario where this can be the case (L2 load balancing/failover). I'll update in_arpinput() to do lle removal/insertion in that case. > la_preempt modification is also write access to an unlocked structure. This one changes nothing: current code does this under _read_ lock. > > >> >>> entry going away. You can either return with table lock held and drop >>> it after the copy, or you could a modified lookup function that takes a >>> pointer for the copy destination, do the copy with the read lock, and then >>> return. If no entry is found an error is returned and obviously no copy >>> is done. >>> >> >> >> -- >> WBR, Alexander >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?509CC776.9010200>