Date: Thu, 9 Nov 2000 09:21:17 -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: <20001109092117.C72943@prism.flugsvamp.com> In-Reply-To: <20001109121743Q.kjc@csl.sony.co.jp> References: <20001108131343.A72943@prism.flugsvamp.com> <20001109121743Q.kjc@csl.sony.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 09, 2000 at 12:17:43PM +0900, Kenjiro Cho wrote:
> >From this experience, I believe we cannot avoid modifying network
> drivers if we are going to have per-ifq locking,
> For example, many ethernet drivers does the following:
>
> while ((m = ifp->if_snd.ifq_head) != NULL) {
>
> /* use m to get resources */
> if (something goes wrong)
> return;
>
> IF_DEQUEUE(&ifp->if_snd, m);
>
> /* kick the hardware */
> }
>
> There is a race where the queue could get emptied before IF_DEQUEUE()
> is called.
> It would be better to eliminate all direct references to the ifqueue
> internal fields from all the drivers. (IF_POLL() is used in my
> proposal.)
> At least, the drivers should check (m != NULL) after IF_DEQUEUE()
> even when the driver doesn't use m to get resources.
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.
> > The only warts in this particular model are certain drivers which
> > abuse the ifqueue structure as a convenient way of retaining mbufs
> > that the chip is transmitting. In this case, the ifq is completely
> > private to one driver, and thus does not need to be locked, as it
> > is not an interface queue at all. The question then is should the
> > driver be converted to use the "mutex-free" versions of the macros
> > above, or should it be forced to perform locking/unlocking even though
> > it is unncessary?
>
> There are not only drivers but also userland programs which use struct
> ifqueue. It is better to rename "struct ifqueue" and the related
> macros for backward compatibility if they need to be changed.
In this case, I would argue that the userland programs are broken.
This same argument would apply to a program which decided to examine
the internal layout of an mbuf; this should not prevent us from
changing the structure of the mbuf to better fit the kernel's requirements.
Also, any component in the kernel (or 3rd party driver) which is using
an ifqueue as an actual interface queue will have to be updated to use
mutexes, changing the name of the structure will not help here.
--
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?20001109092117.C72943>