From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <moeller0@gmx.de>
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20])
	by huchra.bufferbloat.net (Postfix) with ESMTP id 0F99C21F1B1
	for <codel@lists.bufferbloat.net>; Fri, 12 Jul 2013 09:36:11 -0700 (PDT)
Received: from hms-beagle.home.lan ([79.229.236.119]) by mail.gmx.com
	(mrgmx001) with ESMTPSA (Nemesis) id 0Lx8vJ-1U57mi0PyD-016eeB;
	Fri, 12 Jul 2013 18:36:09 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <1373642001.10804.18.camel@edumazet-glaptop>
Date: Fri, 12 Jul 2013 18:36:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAD20AE2-21C2-43E2-8DDD-B695BA6FE6E2@gmx.de>
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>
To: Eric Dumazet <eric.dumazet@gmail.com>
X-Mailer: Apple Mail (2.1508)
X-Provags-ID: V03:K0:ZqImFQPOnydbdwovJxasl1aS1bui1o2Bc9WI03Kq7APjdYcRH1q
	acfnk4OVdC2GHMo1zpPDwOzW3OahLy+1Hx+GzV37lngretLlk8O9OZ7ZncQpw3gc4vYQUj2
	dYYcey7mDokMz4Vx7Cg4gfz+j9AuzB5F8JuTfg3UWssEs6skS1rYEiNdIKgylOYFj7GkezP
	73vu+4cYuTKiEItVKou+w==
Cc: codel@lists.bufferbloat.net, Jesper Dangaard Brouer <jbrouer@redhat.com>
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: Fri, 12 Jul 2013 16:36:12 -0000

Hi there,


On Jul 12, 2013, at 17:13 , Eric Dumazet <eric.dumazet@gmail.com> wrote:

> On Fri, 2013-07-12 at 11:34 +0200, Jesper Dangaard Brouer wrote:
>=20
>> I also think of "fq_codel" as a good replacement for pfifo_fast.  As
>> the 3-PRIO bands in pfifo_fast is replaced with something smarter in
>> "fq_codel". (IMHO please don't try to add a prio_fq_codel, just be =
because
>> pfifo_fast had prio bands, people can just enable a prio qdisc if =
they
>> really need it).
>=20
> Nope. Its really easy for an attacker to flood your fq_codel with say
> UDP messages on all available hash slots.

	Question, what stops the same attacker to also fudge the TOS =
bits (say to land in priority band 0)? Just asking...

>=20
> Some people really want the high prio packets to be sent before any
> med/low prio packets. Not everybody uses a separate ethernet port for
> management and heartbeats.
>=20
> If we want to replace pfifo_fast as the default qdisc, we want some
> integrated qdisc with 3 bands.
>=20
> I presume something really simple like :
>=20
> a fifo for band 0 messages
> a fq_codel for band 1 messages
> a fifo for band 2 messages
>=20
> Would be more than enough, and this also should use device txqueue len
> as the (dynamic) limit, because some existing scripts expect to =
control
> qdisc limit using "ifconfig eth0 txqueuelen 100", not a tc script.
>=20
>=20
>=20
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel


Best
	Sebastian=