Date: Thu, 09 Nov 2000 12:17:43 +0900 From: Kenjiro Cho <kjc@csl.sony.co.jp> To: jlemon@flugsvamp.com Cc: smp@freebsd.org Subject: Re: SMP safe interface queues Message-ID: <20001109121743Q.kjc@csl.sony.co.jp> In-Reply-To: <20001108131343.A72943@prism.flugsvamp.com> References: <20001108131343.A72943@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Lemon wrote: > I've converted the ifqueue structure and the IF* macros to be SMP > safe. The conversion was done with an eye towards modifying the > ethernet drivers as little as possible. An explanation of the > changes is below, and at the end is a design question of what to > do with "misbehaved" drivers. I also looked into the issue of restructuring "struct ifqueue" to support packet scheduling (for ALTQ), and proposed a new design back in July. (available from http://www.csl.sony.co.jp/~kjc/software/altq-new-design.txt) 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. > 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. -Kenjiro 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?20001109121743Q.kjc>