Date: Wed, 26 Sep 2012 09:55:14 -0400 From: John Baldwin <jhb@freebsd.org> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-net@freebsd.org, Vijay Singh <vijju.singh@gmail.com> Subject: Re: ixgbe rx & tx locks Message-ID: <201209260955.14417.jhb@freebsd.org> In-Reply-To: <CAFOYbcmuxBmOfC6P0UBG5RR7xJy_i5mTr2NGMRcTJEJrQmjQ_Q@mail.gmail.com> References: <CALCNsJSSQSWV7vNVR-Sn8CPDKbUBBLpSH0b-HYMJo3SXvkOY=w@mail.gmail.com> <CALCNsJQ740ceDzpd5n7QAALn-uJ-GdWxPTkQJuMJUMTUGJjOUg@mail.gmail.com> <CAFOYbcmuxBmOfC6P0UBG5RR7xJy_i5mTr2NGMRcTJEJrQmjQ_Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, September 25, 2012 4:40:58 pm Jack Vogel wrote: > Ah yes, at one time I was keeping the RX side lock when calling the stack, > but then as I recall that had problems, so the code now releases and > reaquires > as you can see. It results in some contention but I'm not sure that's > avoidable. > > I've seen some LRO related panics on the 1G driver that may be related to > this lock release, or that's one theory I have.. > > Thanks for the testing Vijay! 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). If WITNESS complains, the fix is to only use the MTX_NETWORK_LOCK "lock type name" for your transmit ring locks, not for RX. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209260955.14417.jhb>