Re: [PATCH] sch_sfq: revert dont put new flow at the end of flows

On Wed, Mar 14, 2012 at 2:04 PM, Eric Dumazet [off-list ref] wrote:

Le mercredi 14 mars 2012 à 12:32 +0100, Jesper Dangaard Brouer a écrit :

quoted

ons, 14 03 2012 kl. 04:52 +0000, skrev Dave Taht:

quoted

On Wed, Mar 14, 2012 at 4:04 AM, Eric Dumazet [off-list ref] wrote:

quoted

quoted

As the depth of the sfq queue increases it gets increasingly hard to
trigger the problem. I've been using values in the 200-300 range, and
in combination with red, haven't seen it happen.

I don't think you should adjust the "depth", but instead "limit" or
"flows".

Sorry, I'd meant 'limit' above, with limiting the per flow depth (at
4Mbit depths of 12-24 are good + red doing byte limiting starting at
3000), and having lots of flows in the hash....

Anyway, as this change to sfq currently has pathological edge cases, I suggest:

1) reverting this patch (the new features of sfq - hugely increased
number of flows, and increased limit, head drop/marking support, red,
ecn, etc, can stay - and are rather nice in and of themselves)

2) trying again, but not in the context of sfq - starting with sfq as
a base, with a copy and rename, getting the iproute infrastructure
around it working, more thorough tests going. I'll note that while
flow management is needed, it needent be red-based.

nsfq? efq?

quoted

The problem can be solved by SFQ parameter tuning.  Perhaps, we could
just change the default parameters?

I can't think of a way to make existing users of sfq not hit this problem
if they are overriding the default params in the first place. thus my
suggestion we start again in a new namespace.

quoted

The problem occurs when all flows have ONE packet, then sfq_drop()
cannot find a good flow to drop packets from...

This situation can occur because the default setting is "limit=127"
packets and "flows=127".  If we just make sure that "limit" > "flows",
then one flow with >=2 packets should exist, which is then chosen for
drop.
My practical experiments show that "limit" should be between 10-20
packets larger than "flows" (I'm not completely sure why this is
needed).

flows and/or depth?

if flows, then we could drop the flows parameter entirely and just use limit
to calculate flows. But I think that it's more subtle than just this.

more thorough tests exploring the pathological cases are needed. I'm on it.

quoted

There are many ways to starve SFQ if we dont revert the patch or add new
logic in linux-3.4

Even if we change default settings, we can have following situation :

SFQ in a state with several regular flows in queue, correctly behaving
because they are nice.

loop repeat_as_many_times_you_can_think
 enqueue : packet comes for a new flow X.
          OK lets favor this new flow against 'old' ones.
 dequeue : takes the packet for flow X.
          forget about flow X since dequeue all its packets.
endloop

All other flows are in a frozen state.

some thoughts

1) Keeping more history around during the next X packet deliveries would help.
2) in case of being close up against various limits randomly enqueue on tail

I note that htb introduces a window for new flows to win
pathologically by holding onto a packet
which perhaps it should be peeking (or so I understand it)

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net