Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Jul 2008 18:17:32 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        John Baldwin <jhb@FreeBSD.org>, net@FreeBSD.org
Subject:   Re: svn commit: r180256 - head/sys/dev/arl
Message-ID:  <20080709181531.Q8639@fledge.watson.org>
In-Reply-To: <20080710002759.Q27395@delplex.bde.org>
References:  <200807041748.m64HmZur018637@svn.freebsd.org> <20080705161831.F13262@delplex.bde.org> <20080709131101.S8639@fledge.watson.org> <20080710002759.Q27395@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080709181531.Q8639>