Date: Thu, 16 Apr 2009 16:08:52 -0700 From: Kip Macy <kmacy@freebsd.org> To: Robert Watson <rwatson@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: <3c1674c90904161608m290938e9oe973ac2202d4a834@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.0904162342010.19879@fledge.watson.org> References: <200904140317.n3E3HigF092519@svn.freebsd.org> <alpine.BSF.2.00.0904141018530.19879@fledge.watson.org> <3c1674c90904141545tc2aa075l512cb76c1f334069@mail.gmail.com> <alpine.BSF.2.00.0904162342010.19879@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
see 191161 - I think it addresses everything
-Kip
On Thu, Apr 16, 2009 at 3:51 PM, Robert Watson <rwatson@freebsd.org> wrote:
> 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
--
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c1674c90904161608m290938e9oe973ac2202d4a834>