From owner-freebsd-net@FreeBSD.ORG Wed Oct 30 22:02:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B23FD5CF for ; Wed, 30 Oct 2013 22:02:17 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 470F02749 for ; Wed, 30 Oct 2013 22:02:16 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r9UM1isa021721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Oct 2013 09:02:04 +1100 Message-ID: <527181C8.3040502@swin.edu.au> Date: Thu, 31 Oct 2013 09:01:44 +1100 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: [long] Network stack -> NIC flow (was Re: MQ Patch.) References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <52701D8B.8050907@freebsd.org> <527022AC.4030502@FreeBSD.org> <527027CE.5040806@freebsd.org> <5270309E.5090403@FreeBSD.org> <5270462B.8050305@freebsd.org> <20131030050056.GA84368@onelab2.iet.unipi.it> In-Reply-To: <20131030050056.GA84368@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 22:02:17 -0000 On 10/30/2013 16:00, Luigi Rizzo wrote: [..] > Just to set the terminology: > QUEUE MANAGEMENT POLICY refers to decisions that we make when we INSERT > or EXTRACT packets from a queue WITHOUT LOOKING AT OTHER QUEUES . > This is what implements DROPTAIL (also improperly called FIFO), > RED, CODEL. Note that for CODEL you need to intercept extractions > from the queue, whereas DROPTAIL and RED only act on > insertions. > > SCHEDULER is the entity which decides which queue to serve among > the many possible ones. It is called on INSERTIONS and > EXTRACTIONS from a queue, and passes packets to the NIC's queue. > > The decision on which queue and ring (Q_i and R_j) to use should be made > by a classifier at the beginning of step 2 (or once per iteration, > if using a hierarchical scheduler). Of course they can be precomputed > (e.g. with annotations in the mbuf coming from the socket). I'd like to give a big +1 to the above. Crucial additional points about the per-hop processing for QoS: - Classification is any decision of the form "to what class does this frame belong", where the answer is intended to drive the frame into the appropriate queue. (Which implies the notion of 'class' is very much context-dependent, and classification is something that may occur on L3 tuples, MPLS headers, other L2 fields, other local in-kernel context,etc.) - Queuing and schedule must happen where bottlenecks form, and are irrelevant at points in the data path where no bottleneck exists. cheers, gja