From owner-freebsd-net@FreeBSD.ORG Fri Nov 9 18:57:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9D6C7DD for ; Fri, 9 Nov 2012 18:57:15 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 78CD98FC16 for ; Fri, 9 Nov 2012 18:57:15 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TWton-000IMf-8T; Fri, 09 Nov 2012 23:00:41 +0400 Message-ID: <509D518A.9000803@FreeBSD.org> Date: Fri, 09 Nov 2012 22:55:06 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fabien Thomas Subject: Re: [patch] reducing arp locking 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Ingo Flaschberger X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:57:16 -0000 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-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