From owner-freebsd-net@FreeBSD.ORG Sun Jul 30 20:40:11 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 9008316A4DF; Sun, 30 Jul 2006 20:40:11 +0000 (UTC) (envelope-from prvs=julian=3594eb8d2@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4A9C43D55; Sun, 30 Jul 2006 20:40:10 +0000 (GMT) (envelope-from prvs=julian=3594eb8d2@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.32]) by a50.ironport.com with ESMTP; 30 Jul 2006 13:40:09 -0700 Message-ID: <44CD1928.6000004@elischer.org> Date: Sun, 30 Jul 2006 13:40:08 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> In-Reply-To: <20060730200929.J16341@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org, arch@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: Sun, 30 Jul 2006 20:40:11 -0000 Robert Watson wrote: > On Sun, 30 Jul 2006, Sam Leffler wrote: > >> I have a fair amount of experience with the linux model and it works >> ok. The main complication I've seen is when a driver needs to process >> multiple queues of packets things get more involved. This is seen in >> 802.11 drivers where there are two q's, one for data frames and one >> for management frames. With the current scheme you have two separate >> queues and the start method handles prioritization by polling the mgt >> q before the data q. If instead the packet is passed to the start >> method then it needs to be tagged in some way so the it's prioritized >> properly. Otherwise you end up with multiple start methods; one per >> type of packet. I suspect this will be ok but the end result will be >> that we'll need to add a priority field to mbufs (unless we pass it >> as an arge to the start method). >> We have a priority tag in netgraph that we use to keep management frames on time in the frame relay code it seems to work ok. >> All this is certainly doable but I think just replacing one mechanism >> with the other (as you specified) is insufficient. > Linux did a big analysis of what was needed at the time they did most of their networking and their buffer scheme (last I looked) had all sorts of fields for this and that. I wonder how it has held up over time? > > Hmm. This is something that I had overlooked. I was loosely aware > that the if_sl code made use of multiple queues, but was under the > impression that the classification to queues occured purely in the > SLIP code. Indeed, it does, but structurally, SLIP is split over the > link layer (if_output) and driver layer (if_start), which I had > forgotten. I take it from your comments that 802.11 also does this, > which I was not aware of. > > 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. It would certainly be possible to (for example) have 2 tags preallocated on each mbuf or something but it is hard to know in advance what will be needed.