Re: [PATCH net-next] net_sched: red: split red_parms into parms and vars

Le jeudi 05 janvier 2012 à 14:03 +0100, Dave Taht a écrit :

On Thu, Jan 5, 2012 at 1:25 PM, Eric Dumazet [off-list ref] wrote:

quoted

This patch splits the red_parms structure into two components.

One holding the RED 'constant' parameters, and one containing the
variables.

This permits a size reduction of GRED qdisc, and is a preliminary step
to add an optional RED unit to SFQ.

ah. I see where you are going with this. You are trying also to get your
'time in red' adaptation idea done, aren't you, or at least lay the groundwork
for that?

RED algo is agnostic : The quantity you want to average can be :

1) queue length in bytes
2) queue length in packets
3) time of residence in queue
...

Adding 3) is very easy.

Are you trying to make the 3.3 merge window for all this?

Its up to David ;)

I don't want to discourage you in any way, but byte oriented RED
with or without TSO doesn't work in your typical asymmetric
environment. If you set an appropriate byte limit for
stuff going one way, you end up with acks going out of
control - and vice versa.

TSO has little impact if you use "average queue length in bytes"

My main concern about adding RED is to be able to perform ecn marking
instead of mere packet drops.

In the case of your router, TSO is a non issue, since a router should
handle MTU sized skbs. (disable GRO at ingress side)

and/or packet oriented RED has some hope, but in either
case you have to do something intelligent with a giant TSO
stream if you are going to use it on a server or host.

Again, a flow is a flow, and TSO is just a big packet.

Once you separate flows (using SFQ or QFQ), adding a RED unit permits
early drops only on flows that want to be unfair.

And the basic red still has two flaws that may or may
not go away with your adaptation, or combination with
SFQ - (I do retain hope, though)

I only want to 'activate' red on selected backlogged flows.

tc qdisc add dev eth0 root sfq[red] \
	limit 3000 headdrop flows 512 divisor 16384 \
	redflowlimit 200000b ecn

Problems of RED are :

1) the 'average' on highly variable trafic : It means nothing
interesting at all.

2) the idle time management requires to specify the link bandwidth, as a
fixed value. This is a problem.

In case of SFQRED, flow bandwidth is unknown, or very dynamic.

This is why I plan to reset qavg to 0 each time a flow becomes 'active',
and not care of idle time at all.