Date: Thu, 9 Nov 2000 11:55:36 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Kenjiro Cho <kjc@csl.sony.co.jp> Cc: jlemon@flugsvamp.com, smp@freebsd.org Subject: Re: SMP safe interface queues Message-ID: <20001109115536.E72943@prism.flugsvamp.com> In-Reply-To: <20001110023223E.kjc@csl.sony.co.jp> References: <20001108131343.A72943@prism.flugsvamp.com> <20001109121743Q.kjc@csl.sony.co.jp> <20001109092117.C72943@prism.flugsvamp.com> <20001110023223E.kjc@csl.sony.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 10, 2000 at 02:32:23AM +0900, Kenjiro Cho 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. I'll grant you that this may be a problem. However, at the moment I can't find any drivers that do this, so we can deal with them if they ever come up. Some drivers may call IF_DRAIN() from their ioctl() routine, but this case should already be protected from conflict by the driver lock. Recall the ifq lock only applies to queue manipulations outside of the driver itself, and I doubt that there is any manipulation done by the upper layers *currently* which is not a simple HANDOFF. -- 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?20001109115536.E72943>