From owner-svn-src-all@FreeBSD.ORG Thu Apr 16 22:51:17 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C24A1065696; Thu, 16 Apr 2009 22:51:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3C3B18FC20; Thu, 16 Apr 2009 22:51:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D82E146B45; Thu, 16 Apr 2009 18:51:16 -0400 (EDT) Date: Thu, 16 Apr 2009 23:51:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: <3c1674c90904141545tc2aa075l512cb76c1f334069@mail.gmail.com> Message-ID: References: <200904140317.n3E3HigF092519@svn.freebsd.org> <3c1674c90904141545tc2aa075l512cb76c1f334069@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-9378164-1239922276=:19879" Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r191037 - head/sys/net X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:51:18 -0000 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--