[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zi1r5kgx.fsf@toke.dk>
Date: Wed, 25 Apr 2018 18:17:34 +0200
From: Toke Høiland-Jørgensen <toke@...e.dk>
To: Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Cc: cake@...ts.bufferbloat.net, Dave Taht <dave.taht@...il.com>
Subject: Re: [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc
Eric Dumazet <eric.dumazet@...il.com> writes:
> On 04/25/2018 08:22 AM, Toke Høiland-Jørgensen wrote:
>> Eric Dumazet <eric.dumazet@...il.com> writes:
>
>>> Lack of any pskb_may_pull() is really concerning.
>>
>> By this you mean "check that the packet is long enough to contain the
>> header we are looking for before trying to do ACK filtering", right?
>
>
> skb->len is not enough, you also have skb->data_len that matters.
>
> A qdisc can be fed with skbs that are not linear, or pretend to be
> TCP, but they be truncated by malicious sender.
>
> skb might have headers or payload in the page fragments, thus we
> generally have to call pskb_may_pull() to bring headers in skb->head
Right, gotcha; was just making sure I understood you correctly.
> Quite frankly , an ack-filter does not belong to a packet scheduler.
>
> It might be added to tcp conntrack module _if_ someone really cares.
Well, integrating it with the queue does have the advantage of only
filtering ACKs if the flow is actually bottlenecked...
That being said, I'm not personally hugely attached to the ACK filter;
let's see if someone one the cake list speaks up in favour of keeping
it.
Or am I to interpret that as a hard NAK on having this feature in CAKE
(even if we fix the issues you pointed out)?
-Toke
Powered by blists - more mailing lists