From owner-freebsd-net@FreeBSD.ORG Thu Nov 8 10:48:28 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 2AC47CD5 for ; Thu, 8 Nov 2012 10:48:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 83DF38FC0C for ; Thu, 8 Nov 2012 10:48:27 +0000 (UTC) Received: (qmail 64365 invoked from network); 8 Nov 2012 12:23:34 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2012 12:23:34 -0000 Message-ID: <509B8DF5.5010101@freebsd.org> Date: Thu, 08 Nov 2012 11:48:21 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: [patch] reducing arp locking References: <509AEDAC.10002@FreeBSD.org> <509B884F.7040106@networx.ch> <509B88B1.3070905@FreeBSD.org> In-Reply-To: <509B88B1.3070905@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-hackers@FreeBSD.org 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: Thu, 08 Nov 2012 10:48:28 -0000 On 08.11.2012 11:25, Alexander V. Chernikov wrote: > 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. Right. Sorry. I didn't immediately get that the IF_AFDATA_LOCK is the table lock. -- Andre >> 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. >> > >