Date: Thu, 16 Apr 2009 23:51:16 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Kip Macy <kmacy@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r191037 - head/sys/net Message-ID: <alpine.BSF.2.00.0904162342010.19879@fledge.watson.org> In-Reply-To: <3c1674c90904141545tc2aa075l512cb76c1f334069@mail.gmail.com> References: <200904140317.n3E3HigF092519@svn.freebsd.org> <alpine.BSF.2.00.0904141018530.19879@fledge.watson.org> <3c1674c90904141545tc2aa075l512cb76c1f334069@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--621616949-9378164-1239922276=:19879
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Tue, 14 Apr 2009, Kip Macy wrote:
>> The commit message should perhaps read:
>>
>> Call default if_qflush on ifq if there are still packets left in the
>> default queue after calling the driver's flush method.
>>
>> However, this seems a bit odd: what if the driver uses if_snd as its queue
>> but implements other differences in the transmit routine? In that case, we
>> might impose default queue properties on if_snd even though the driver
>> doesn't use them. Could you talk a bit about the circumstances under which
>> the driver provides an if_qflush that doesn't drain its queues properly?
>
> I'm afraid I don't understand the question. If a driver only uses if_snd for
> its transmit routine then there is no reason for it to override the default
> if_qflush implementation.
In the past (and possibly still) device driver and link layers have used
if_snd plus their own queues for differentiated traffic. For example, if_slip
used an additional "fast" queue for interactive traffic, and if_snd for "slow"
traffic. It would still need to implement a flush method itself since it
maintains additional queues.
What I'd like to see is two modes of operation:
(1) Historic mode: the ifnet framework provides all queueing support,
enqueuing using the standard macros to if_snd, and the default
implementation of if_qflush in place to flush the queue. This means
implementing neither if_transmit nor if_qflush methods on the ifnet.
(2) Modern mode: the driver provides all queueing support, possibly by
invoking "library" routines from the stack, and the ifnet queue stays
entirely out of the way. This means implementing both if_transmit and
if_qflush methods on the ifnet.
To support the (1) scenario above, simply calling ifp->if_qflush() does the
trick fine, since it's pre-initialized to if_qflush(). For the (2) scenario,
the driver might choose to call if_qflush() to perform some or all flushing,
but it shouldn't happen by itself unless the device driver author wants that.
Robert N M Watson
Computer Laboratory
University of Cambridge
--621616949-9378164-1239922276=:19879--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904162342010.19879>