From owner-freebsd-smp Thu Nov 9 10:37:19 2000 Delivered-To: freebsd-smp@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 6438937B479; Thu, 9 Nov 2000 10:37:16 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eA9IXwc65958; Thu, 9 Nov 2000 12:33:58 -0600 (CST) (envelope-from jlemon) Date: Thu, 9 Nov 2000 12:33:57 -0600 From: Jonathan Lemon To: "Justin T. Gibbs" Cc: Kenjiro Cho , 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> References: <20001110023223E.kjc@csl.sony.co.jp> <200011091808.eA9I83a89553@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200011091808.eA9I83a89553@aslan.scsiguy.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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