From owner-freebsd-net@FreeBSD.ORG Wed Jul 9 17:17:33 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 408BF106564A; Wed, 9 Jul 2008 17:17:33 +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 13ABB8FC0A; Wed, 9 Jul 2008 17:17:32 +0000 (UTC) (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 7929146C66; Wed, 9 Jul 2008 13:17:32 -0400 (EDT) Date: Wed, 9 Jul 2008 18:17:32 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Evans In-Reply-To: <20080710002759.Q27395@delplex.bde.org> Message-ID: <20080709181531.Q8639@fledge.watson.org> References: <200807041748.m64HmZur018637@svn.freebsd.org> <20080705161831.F13262@delplex.bde.org> <20080709131101.S8639@fledge.watson.org> <20080710002759.Q27395@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: John Baldwin , net@FreeBSD.org Subject: Re: svn commit: r180256 - head/sys/dev/arl 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: Wed, 09 Jul 2008 17:17:33 -0000 On Thu, 10 Jul 2008, Bruce Evans wrote: >> possibility I've been considering is making the whole ifq subsystem a >> library to device drivers, rather than a required interface to transmit. >> This would allow the device driver to instantiate more than one if there >> are multiple hardware queues that need to be represented, or, for example, >> allow synthetic encapsulation interfaces (such as vlan) to avoid queueing >> entirely and directly dispatch to the lower layer interface without >> requiring a mandatory enqueue/dequeue step. I've started hacking on this >> every now and then, but it requires a lot of code to be touched -- it's >> something we do need to address before 8.0, however. > > Could this be more efficient? > > I think direct dispatch wouldn't work well. It didn't help as much as hoped > for rx, and tx is predictable so perfect scheduling of it is possible (only > dispatch in bulk in order to be more efficient). Also, the current > implementation gives necessary watermark stuff almost automatically -- the > queue split gives a virtual low watermark at the split point, and this > reduces the chance of the combined queue running dry. In most cases, what I have in mind would simply be a rearrangement rather than a functional change. However, for vlans, I think it would significantly lower overhead without really modifying queueing behavior: notice that we enqueue it at the VLAN layer just to dequeue it a few instructions later so that we can enqueue it a layer lower. Robert N M Watson Computer Laboratory University of Cambridge