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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
