From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jbrouer@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
	by huchra.bufferbloat.net (Postfix) with ESMTP id B6A4C21F199
	for <codel@lists.bufferbloat.net>; Mon, 15 Jul 2013 06:40:22 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6FDeFYp000372
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Jul 2013 09:40:18 -0400
Received: from localhost (ovpn-116-55.ams2.redhat.com [10.36.116.55])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r6FDeCC4029738; Mon, 15 Jul 2013 09:40:14 -0400
Date: Mon, 15 Jul 2013 15:40:09 +0200
From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <20130715154009.4c0d4531@redhat.com>
In-Reply-To: <1373648057.10804.29.camel@edumazet-glaptop>
References: <CAA93jw5SBtsz3=L9M7mhASg9oAVyvysFL9VNwc-52mOk4HWg8A@mail.gmail.com>
	<1373564673.4600.55.camel@edumazet-glaptop>
	<CAA93jw6rd1G2Q4pmfAB5GPuwfqCbVPDw6njCaceszD9q5Avz_A@mail.gmail.com>
	<1373568848.4600.66.camel@edumazet-glaptop>
	<CAA93jw4+TcWOBH8mMpsk6EAO-EVzemHvx1FjPbrevEzqTJmr_A@mail.gmail.com>
	<20130712113413.4b601800@redhat.com>
	<1373642001.10804.18.camel@edumazet-glaptop>
	<FAD20AE2-21C2-43E2-8DDD-B695BA6FE6E2@gmx.de>
	<1373648057.10804.29.camel@edumazet-glaptop>
Organization: Red Hat Inc.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] hardware multiqueue in fq_codel?
X-BeenThere: codel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: CoDel AQM discussions <codel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/codel>
List-Post: <mailto:codel@lists.bufferbloat.net>
List-Help: <mailto:codel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 13:40:23 -0000

On Fri, 12 Jul 2013 09:54:17 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> On Fri, 2013-07-12 at 18:36 +0200, Sebastian Moeller wrote:
> 
> > 
> > 	Question, what stops the same attacker to also fudge the
> > TOS bits (say to land in priority band 0)? Just asking...
> 
> This kind of thing is filtered before those packets arrive to the tx
> queue where pfifo_fast is plugged ;)
> 
> TOS is properly checked/rewritten when alien packets enter your
> network.
> 
> People caring with this do their own classification using iptables or
> tc filter rules.

Then they should also be smart enough to change their default fq_codel
qdisc, to be a prio band based qdisc... shouldn't they ;-)

Something as "easy" like:

ETH=eth66
NQUEUES=16  # or more, check how many tx queues your NIC supports
tc qdisc del dev $ETH root 2>/dev/null
tc qdisc add dev $ETH root handle 100: mq
for i in `seq 1 $NQUEUES`; do
  tc qdisc add dev $ETH parent 100:$i handle $i: prio bands 3
     tc qdisc add dev $ETH parent $i:1 pfifo limit 10
     tc qdisc add dev $ETH parent $i:2 fq_codel
     tc qdisc add dev $ETH parent $i:3 fq_codel
done

(p.s. sorry, I'm in a troll mood today ;-))
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer