From owner-freebsd-net@FreeBSD.ORG Mon Jul 31 10:00:29 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02BBC16A4ED; Mon, 31 Jul 2006 10:00:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 921A843D5E; Mon, 31 Jul 2006 10:00:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2083D46B0D; Mon, 31 Jul 2006 06:00:27 -0400 (EDT) Date: Mon, 31 Jul 2006 11:00:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sam Leffler In-Reply-To: <44CD56BB.6080405@errno.com> Message-ID: <20060731105438.D16341@fledge.watson.org> References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> <44CD56BB.6080405@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, net@FreeBSD.org Subject: Re: Changes in the network interface queueing handoff model X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 10:00:29 -0000 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