From owner-freebsd-net@FreeBSD.ORG Wed Oct 30 22:32:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4AA0316F for ; Wed, 30 Oct 2013 22:32:09 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92D152910 for ; Wed, 30 Oct 2013 22:32:08 +0000 (UTC) Received: (qmail 64443 invoked from network); 30 Oct 2013 23:02:26 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Oct 2013 23:02:26 -0000 Message-ID: <527188D1.2070905@freebsd.org> Date: Wed, 30 Oct 2013 23:31:45 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: grenville armitage , 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> <527181C8.3040502@swin.edu.au> In-Reply-To: <527181C8.3040502@swin.edu.au> 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:32:09 -0000 On 30.10.2013 23:01, grenville armitage wrote: > 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.) Full ack. When the class information is present (and trusted) on ingress packets in the vlan header, IP tos and other such well-defined fields we can map it directly to the mbuf header qoscos field. Everything more complex has to be done in a packet filter that has access to and can parse L3 and higher layers in the packet. On egress only the mbuf header is looked at to determine the class and queue it should be put into. > - Queuing and schedule must happen where bottlenecks form, and > are irrelevant at points in the data path where no bottleneck exists. Very well put and *the* one crucial thing to understand to make any kind of QoS work in practice. -- Andre