netdev - Re: [PATCH net-next 2/2] net_sched: sch_fq: add the ability to offload pacing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <66fae0f1f12f1_187400294c0@willemb.c.googlers.com.notmuch>
Date: Mon, 30 Sep 2024 13:33:37 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Eric Dumazet <edumazet@...gle.com>, 
 "David S . Miller" <davem@...emloft.net>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>
Cc: Willem de Bruijn <willemb@...gle.com>, 
 Jeffrey Ji <jeffreyji@...gle.com>, 
 netdev@...r.kernel.org, 
 eric.dumazet@...il.com, 
 Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next 2/2] net_sched: sch_fq: add the ability to
 offload pacing

Eric Dumazet wrote:
> From: Jeffrey Ji <jeffreyji@...gle.com>
> 
> Some network devices have the ability to offload EDT (Earliest
> Departure Time) which is the model used for TCP pacing and FQ packet
> scheduler.
> 
> Some of them implement the timing wheel mechanism described in
> https://saeed.github.io/files/carousel-sigcomm17.pdf
> with an associated 'timing wheel horizon'.
> 
> This patchs adds to FQ packet scheduler TCA_FQ_OFFLOAD_HORIZON
> attribute.
> 
> Its value is capped by the device max_pacing_offload_horizon,
> added in the prior patch.
> 
> It allows FQ to let packets within pacing offload horizon
> to be delivered to the device, which will handle the needed
> delay without host involvement.
> 
> Signed-off-by: Jeffrey Ji <jeffreyji@...gle.com>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>

> @@ -1100,6 +1105,17 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt,
>  		WRITE_ONCE(q->horizon_drop,
>  			   nla_get_u8(tb[TCA_FQ_HORIZON_DROP]));
>  
> +	if (tb[TCA_FQ_OFFLOAD_HORIZON]) {
> +		u64 offload_horizon = (u64)NSEC_PER_USEC *
> +				      nla_get_u32(tb[TCA_FQ_OFFLOAD_HORIZON]);
> +
> +		if (offload_horizon <= qdisc_dev(sch)->max_pacing_offload_horizon) {
> +			WRITE_ONCE(q->offload_horizon, offload_horizon);

Do we expect that that an administrator will ever set the offload
horizon different from the device horizon?

It might be useful to have a wildcard value that means "match
hardware ability"?

Both here and in the device, realistic values will likely always be
MSEC scale?

> +		} else {
> +			NL_SET_ERR_MSG_MOD(extack, "invalid offload_horizon");
> +			err = -EINVAL;
> +		}
> +	}
>  	if (!err) {
>  
>  		sch_tree_unlock(sch);