On Wed, Apr 17, 2024 at 10:35 AM Simon Horman wrote:
>
> + Toke Høiland-Jørgensen
> cake@lists.bufferbloat.net
>
> On Mon, Apr 15, 2024 at 01:20:42PM +0000, Eric Dumazet wrote:
> > Instead of relying on RTNL, cake_dump() can use READ_ONCE()
> > annotations, pa
On Mon, Oct 17, 2022 at 8:39 PM Zhengchao Shao wrote:
>
> When the default qdisc is fq_codel, if the qdisc of dev_queue fails to be
> inited during mqprio_init(), fq_codel_reset() is invoked to clear
> resources. In this case, the flow is NULL, and it will cause gpf issue.
>
> The process is as
On Wed, Aug 31, 2022 at 2:25 AM Toke Høiland-Jørgensen wrote:
>
> When the GSO splitting feature of sch_cake is enabled, GSO superpackets
> will be broken up and the resulting segments enqueued in place of the
> original skb. In this case, CAKE calls consume_skb() on the original skb,
> but still
(5%)
> 10=10:0:0:0:0:0:0:0 0
> [ 1] 6.0002-6.0511 sec 40.0 KBytes 6.44 Mbits/sec 50.895 ms (5.1%)
> 10=10:0:0:0:0:0:0:0 0
> [ 1] 7.0002-7.0501 sec 40.0 KBytes 6.57 Mbits/sec 49.889 ms (5%)
> 10=10:0:0:0:0:0:0:0 0
> [ 1] 8.0002-8.0481 sec 40.0 KBytes 6.84 M
/0) (6.396
>> ms/1635289683.794338)
>> [ 1] 8.00-9.00 sec 40.0 KBytes 328 Kbits/sec 10/0 0
>> 14K/5329 us 8
>> [ 1] 8.00-9.00 sec S8-PDF:
>> bin(w=100us):cnt(10)=1:2,38:1,45:2,49:1,50:3,63:1
>> (5.00/95.00/99.7%=1/63/63,Outliers=0,obl/obu=0/0) (6.292
On 10/25/21 8:11 PM, Stuart Cheshire via Bloat wrote:
> On 21 Oct 2021, at 17:51, Bob McMahon via Make-wifi-fast
> wrote:
>
>> Hi All,
>>
>> Sorry for the spam. I'm trying to support a meaningful TCP message latency
>> w/iperf 2 from the sender side w/o requiring e2e clock synchronization. I
On 01/07/2019 11:47 AM, Toke Høiland-Jørgensen wrote:
> From: Toke Høiland-Jørgensen
>
> With GSO splitting in sch_cake, we can decrease as well as increase the
> qlen. To make it possible to signal this up the qdisc tree, change
> qdisc_tree_reduce_backlog() to accept signed integer values as
er the help I gave on this problem.
Reviewed-by: Eric Dumazet
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
On 09/10/2018 11:52 AM, Eric Dumazet wrote:
>
>
> On 09/10/2018 09:04 AM, Toke Høiland-Jørgensen wrote:
>> Hi everyone
>>
>> While investigating a bug report on CAKE[0], I've run into the following
>> behaviour:
>>
>> When running CAKE as an i
On 09/10/2018 09:04 AM, Toke Høiland-Jørgensen wrote:
> Hi everyone
>
> While investigating a bug report on CAKE[0], I've run into the following
> behaviour:
>
> When running CAKE as an ingress shaper on an IFB interface, if the GSO
> splitting feature is turned on, TCP throughput will drop
On 05/21/2018 01:35 PM, Toke Høiland-Jørgensen wrote:
> +
> + /* 3 reserved flags must be unset to avoid future breakage
> + * ECE/CWR/NS can be safely ignored
> + * ACK must be set
> + * All other flags URG/PSH/RST/SYN/FIN must be unset
> + * 0x0FFF = all TCP flags
On 05/21/2018 11:08 AM, Eric Dumazet wrote:
>
>
> On 05/21/2018 10:35 AM, Toke Høiland-Jørgensen wrote:
>
>> Ah yes, sequence number wrapping. I was thinking I needed to deal with
>> that, and then got sidetracked and forgot about it. Will fix.
>>
&g
On 05/21/2018 10:35 AM, Toke Høiland-Jørgensen wrote:
> Ah yes, sequence number wrapping. I was thinking I needed to deal with
> that, and then got sidetracked and forgot about it. Will fix.
>
> Other than that, do you agree that this approach to SACK and header
> handling can work?
On 05/21/2018 09:24 AM, Toke Høiland-Jørgensen wrote:
> + while (oplen_tmp >= 8) {
> + u32 right_b = get_unaligned_be32(sack_tmp + 4);
> + u32 left_b = get_unaligned_be32(sack_tmp);
> +
> + if (left_b >= right_b)
> +
On 05/17/2018 07:36 PM, Ryan Mounce wrote:
> On 17 May 2018 at 22:41, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>> Eric Dumazet <eric.duma...@gmail.com> writes:
>>
>>> On 05/17/2018 04:23 AM, Toke Høiland-Jørgensen wrote:
>>>
>>>>
&
On 05/17/2018 04:23 AM, Toke Høiland-Jørgensen wrote:
>
> We don't do full parsing of SACKs, no; we were trying to keep things
> simple... We do detect the presence of SACK options, though, and the
> presence of SACK options on an ACK will make previous ACKs be considered
> redundant.
>
But
On 05/16/2018 01:29 PM, Toke Høiland-Jørgensen wrote:
> The ACK filter is an optional feature of CAKE which is designed to improve
> performance on links with very asymmetrical rate limits. On such links
> (which are unfortunately quite prevalent, especially for DSL and cable
> subscribers), the
On 05/01/2018 12:31 PM, Toke Høiland-Jørgensen wrote:
> Could you comment on specifically what you believe is broken in this,
> please, so I can fix it in the same iteration?
>
Apart from the various pskb_may_pull() this helper should not change skb layout.
Ideally, the skb should be const
On 04/30/2018 02:27 PM, Dave Taht wrote:
> I actually have a tc - bpf based ack filter, during the development of
> cake's ack-thinner, that I should submit one of these days. It
> proved to be of limited use.
>
> Probably the biggest mistake we made is by calling this cake feature a
> filter.
On 04/27/2018 06:38 AM, Toke Høiland-Jørgensen wrote:
>
> Ah, right. Will fix.
>
> Is it safe to dereference the iph pointer before calling
> pskb_may_pull()?
No, please take a look at ip_rcv() for a typical use case.
___
Cake mailing list
On 04/27/2018 05:17 AM, Toke Høiland-Jørgensen wrote:
...
> +
> +static struct sk_buff *cake_ack_filter(struct cake_sched_data *q,
> +struct cake_flow *flow)
> +{
> + int seglen;
> + struct sk_buff *skb = flow->tail, *skb_check, *skb_check_prev;
> +
On 04/25/2018 11:34 AM, Toke Høiland-Jørgensen wrote:
> Eric Dumazet <eric.duma...@gmail.com> writes:
>
>> On 04/25/2018 09:52 AM, Jonathan Morton wrote:
>>>> We can see here the high cost of forcing software GSO :/
>>>>
>>>> Really, this s
On 04/25/2018 09:17 AM, Toke Høiland-Jørgensen wrote:
> 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)?
No strong NACK, as long as the current code is fixed.
Right now, a malicious packet will kill the box or something bad
On 04/25/2018 09:55 AM, Toke Høiland-Jørgensen wrote:
> Well, as I said, 10Gbit+ links are not really the target audience ;)
Well, 640KB of memory is all we need.
>
> We did actually have a threshold at some point, but it was removed
> because it didn't work well (I'm not sure of the
On 04/25/2018 09:52 AM, Jonathan Morton wrote:
>> We can see here the high cost of forcing software GSO :/
>>
>> Really, this should be done only :
>> 1) If requested by the admin ( tc gso )
>>
>> 2) If packet size is above a threshold.
>> The threshold could be set by the admin,
On 04/25/2018 08:22 AM, Toke Høiland-Jørgensen wrote:
> Eric Dumazet <eric.duma...@gmail.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 befo
On 04/25/2018 08:22 AM, Toke Høiland-Jørgensen wrote:
> Eric Dumazet <eric.duma...@gmail.com> writes:
>> What performance number do you get on a 10Gbit NIC for example ?
>
> Single-flow throughput through 2 hops on a 40Gbit connection (with CAKE
> in unlimited mode vs
On 04/25/2018 08:22 AM, Toke Høiland-Jørgensen wrote:
> Hmm, because pure ACKs are not generally aggregated (sorry, I'm not
> quite clear on when exactly GSO will kick in)?
A GSO packet must contain payload in each of its segment.
There is no way some ack aggregation logic could build a GSO
On 04/25/2018 06:42 AM, Toke Høiland-Jørgensen wrote:
> sch_cake targets the home router use case and is intended to squeeze the
> most bandwidth and latency out of even the slowest ISP links and routers,
> while presenting an API simple enough that even an ISP can configure it.
>
* Support
On Sun, 2016-06-12 at 20:51 +0300, Jonathan Morton wrote:
> > On 12 Jun, 2016, at 20:48, Eric Dumazet <eric.duma...@gmail.com> wrote:
> >
> >> A) In my failing to make sense of all the dialog around these patches
> >> ( https://lwn.net/Articles/6876
On Sat, 2016-06-04 at 22:55 +0300, Jonathan Morton wrote:
> > On 4 Jun, 2016, at 20:49, Eric Dumazet <eric.duma...@gmail.com> wrote:
> >
> > ECN (as in RFC 3168) is well known to be trivially exploited by peers
> > pretending to be ECN ready, but not reac
On Sat, 2016-06-04 at 13:10 -0400, Noah Causin wrote:
> I notice that issue with Steam. Steam uses lots of ECN, which can be
> nice for saving bandwidth with large games. The issue I notice is that
> Steam is the one application that can cause me to have ping spikes of
> over 100ms, even
32 matches
Mail list logo
