Date: Mon, 15 Oct 2012 10:27:12 -0700 From: Jack Vogel <jfvogel@gmail.com> To: Gleb Smirnoff <glebius@freebsd.org> Cc: "Alexander V. Chernikov" <melifaro@freebsd.org>, net@freebsd.org Subject: Re: ixgbe & if_igb RX ring locking Message-ID: <CAFOYbcm20CcA1Lxs6KhG%2Bmyu4-%2Ba7vt5h%2BBSD4FF03ZsqbnhKA@mail.gmail.com> In-Reply-To: <20121015165828.GX89655@glebius.int.ru> References: <5079A9A1.4070403@FreeBSD.org> <20121015162926.GV89655@FreeBSD.org> <CAFOYbcmkt%2B3-f7BzfaStUHBFEO0TzJXhYES=42ovkencPoKHJA@mail.gmail.com> <20121015165828.GX89655@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 15, 2012 at 9:58 AM, Gleb Smirnoff <glebius@freebsd.org> wrote: > On Mon, Oct 15, 2012 at 09:39:24AM -0700, Jack Vogel wrote: > J> > To me this unlock/lock looks like a legacy from times, when the driver > J> > had a single mutex for both TX and RX parts. > J> > > J> > And removing this re-locking in foo_rxeof() was one of the aims for > J> > separate > J> > TX/RX locking. > J> > > J> > Really, lurking through history shows that once driver had split its > J> > locking > J> > to separate RX and TX part, these unlock/lock was removed. However, > later > J> > this unlock/lock was added back: > J> > > J> > > J> > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_igb.c?revision=209068&view=markup > J> > > J> > , without any comments for the reason it is added back. > J> > > J> > I did not want to add it back, there were problems that constrained > me to > J> do so, although its > J> been some time, I'd be happy to do some testing again without and see. > > Can you please dig through mail archives to identify these problems? I > can't imagine any. > > It may not be in email, there were tests going on internally here that I often was working with... At this point it doesn't matter, Alexander says its running without, I will have some more testing on current code and go from there. Jack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFOYbcm20CcA1Lxs6KhG%2Bmyu4-%2Ba7vt5h%2BBSD4FF03ZsqbnhKA>