Date: Wed, 30 Oct 2013 23:31:45 +0100 From: Andre Oppermann <andre@freebsd.org> To: grenville armitage <garmitage@swin.edu.au>, freebsd-net@freebsd.org Subject: Re: [long] Network stack -> NIC flow (was Re: MQ Patch.) Message-ID: <527188D1.2070905@freebsd.org> In-Reply-To: <527181C8.3040502@swin.edu.au> References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <CA%2BhQ2%2BgTc87M0f5pvFeW_GCZDogrLkT_1S2bKHngNcDEBUeZYQ@mail.gmail.com> <52701D8B.8050907@freebsd.org> <527022AC.4030502@FreeBSD.org> <527027CE.5040806@freebsd.org> <5270309E.5090403@FreeBSD.org> <5270462B.8050305@freebsd.org> <CAJ-Vmo=6thETmTDrPYRjwNTEQaTWkSTKdRYN3eRw5xVhsvr5RQ@mail.gmail.com> <20131030050056.GA84368@onelab2.iet.unipi.it> <527181C8.3040502@swin.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?527188D1.2070905>