Date: Mon, 31 Jul 2006 11:00:26 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Sam Leffler <sam@errno.com> Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model Message-ID: <20060731105438.D16341@fledge.watson.org> In-Reply-To: <44CD56BB.6080405@errno.com> References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> <44CD56BB.6080405@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Jul 2006, Sam Leffler wrote: >> I'm a little uncomfortable with our current m_tag model, as it requires >> significant numbers of additional allocations and frees for each packet, as >> well as walking link lists. It's fine for occasional discretionary use >> (i.e., MAC labels), but I worry about cases where it is used with every >> packet, and we start seeing moderately non-zero numbers of tags on every >> packet. I think I would be more comfortable with an explicit queue >> identifier argument to if_start, where the link layer and driver layer >> agree on how to identify queues. >> >> As a straw man, how would the following strike you: >> >> int if_startmbuf(struct ifnet *ifp, struct mbuf *m, int ifqid); >> >> where for most link layers, the value would be zero, but for some link >> layer/driver combinations, it would identify a specific queue which the >> link layer believes the mbuf should be assigned, if implemented? > > mbuf tags are not a solution; too expensive. I think we need something in > the mbuf header. Agreed. I'm also quite unhappy that we have to use m_tags for VLAN tagging for identical reasons: it basically guarantees at least one extra memory allocation and free, possibly two, for each frame with encapsulation. This is one of the reasons I have been interested in reworking the ethernet link layer parts to increase integration of VLANs into the normal ethernet code, in order to avoid having to unnecessarily use expensive mbuf meta-data. What size field is needed in the mbuf pkthdr to capture all the necessary priority information between driver and link layer? An int? Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060731105438.D16341>