From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 19:38:34 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 D3D741065672 for ; Wed, 26 Sep 2012 19:38:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A78798FC14 for ; Wed, 26 Sep 2012 19:38:34 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 17131B922; Wed, 26 Sep 2012 15:38:34 -0400 (EDT) From: John Baldwin To: Ryan Stone Date: Wed, 26 Sep 2012 15:38:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201209260955.14417.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209261538.11588.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 26 Sep 2012 15:38:34 -0400 (EDT) Cc: freebsd-net@freebsd.org, Jack Vogel , Vijay Singh Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 19:38:34 -0000 On Wednesday, September 26, 2012 3:08:22 pm Ryan Stone wrote: > On Wed, Sep 26, 2012 at 9:55 AM, John Baldwin wrote: > > You only have to drop the RX lock around if_input() if you use the same lock > > for both TX and RX (as if_transmit() / if_start() can be invoked while locks > > in the network stack are held). > > Last time I checked(FreeBSD 8.2), this is not true. The problematic > (and convoluted) ordering is: > > ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx Hmm, I'm not sure where the 'in_multi_mtx -> ix:core' bit comes from. I think that is the broken part of this. The SIOCADDMULTI and SIOCDELMULTI ioctls are invoked without any stack locks held, so it shouldn't come from there. -- John Baldwin