Date: Thu, 9 Nov 2000 12:33:57 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Kenjiro Cho <kjc@csl.sony.co.jp>, jasone@freebsd.org, cp@freebsd.org, dg@freebsd.org, jlemon@flugsvamp.com, smp@freebsd.org Subject: Re: SMP safe interface queues Message-ID: <20001109123357.F72943@prism.flugsvamp.com> In-Reply-To: <200011091808.eA9I83a89553@aslan.scsiguy.com> References: <20001110023223E.kjc@csl.sony.co.jp> <200011091808.eA9I83a89553@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 09, 2000 at 11:08:03AM -0700, Justin T. Gibbs wrote: > > > >Jonathan Lemon wrote: > >> I understand that this is a problem for ALTQ. However, for my > >> purposes, making the interface queues SMP safe, it is not a problem. > >> The queueing discipline remains FIFO at this time, and each driver > >> instance has its own ifq. So the driver can safely peek at the > >> front of the queue, and place packets back using PREPEND() without > >> a problem. (assuming, of course, that the rx or tx routine of the > >> driver is single-threaded). > >> > >> I agree that moving forward it probably will be beneficial to hide > >> the internal queueing details, but it is not needed initially. > > > >How about calling IF_DRAIN() or IF_PREPEND() outside of the interrupt > >context? > >Although it might be unlikely in practice, the point is that a locking > >system needs the design of a self-contained operation model. > >(defined operations should work when the lock is properly held.) > >I doubt that it can be done without modifying the existing drivers. > > There was some discussion about this very issue at USENIX. I > believe the outcome was that all mutex operations should be > made explicit in each driver. Chuck, David, and Jason were > more involved in this discussion than I was, so perhaps they > can chime in here. Hmm. I regrettably missed that, something to do with me not having a watch. :-( However, I'm not sure that this is needed; while each driver still has the option of explicitly performing a locking operation, it would seem to be a better fit for most of the locking to be implicit, since that is the way most operations are performed. The macros I have are not the same as the BSD/OS ones, so there is no confusion of the lock/unlock operation being split across different macro calls, which might be what was discussed at the meeting. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001109123357.F72943>