netdev - Re: [RFC PATCH] net: introduce HW Rate Limiting Driver API

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 for Android: free password hash cracker in your pocket

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

Message-ID: <abe35bb09ff1449eafaa6b78a1bce2110dee52e7.camel@nvidia.com>
Date: Wed, 5 Jun 2024 15:04:18 +0000
From: Cosmin Ratiu <cratiu@...dia.com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "pabeni@...hat.com"
	<pabeni@...hat.com>
CC: "jhs@...atatu.com" <jhs@...atatu.com>, "sridhar.samudrala@...el.com"
	<sridhar.samudrala@...el.com>, "john.fastabend@...il.com"
	<john.fastabend@...il.com>, "madhu.chittim@...el.com"
	<madhu.chittim@...el.com>, "jiri@...nulli.us" <jiri@...nulli.us>,
	"horms@...nel.org" <horms@...nel.org>, "sgoutham@...vell.com"
	<sgoutham@...vell.com>, "kuba@...nel.org" <kuba@...nel.org>
Subject: Re: [RFC PATCH] net: introduce HW Rate Limiting Driver API

On Wed, 2024-05-08 at 22:20 +0200, Paolo Abeni wrote:

> +/**
> + * struct net_shaper_info - represents a shaping node on the NIC H/W
> + * @metric: Specify if the bw limits refers to PPS or BPS
> + * @bw_min: Minimum guaranteed rate for this shaper
> + * @bw_max: Maximum peak bw allowed for this shaper
> + * @burst: Maximum burst for the peek rate of this shaper
> + * @priority: Scheduling priority for this shaper
> + * @weight: Scheduling weight for this shaper
> + */
> +struct net_shaper_info {
> +	enum net_shaper_metric metric;
> +	u64 bw_min;	/* minimum guaranteed bandwidth, according to metric */
> +	u64 bw_max;	/* maximum allowed bandwidth */
> +	u32 burst;	/* maximum burst in bytes for bw_max */

'burst' really should be u64 if it can deal with bytes. In a 400Gbps
link, u32 really is peanuts.

> +/**
> + * enum net_shaper_scope - the different scopes where a shaper could be attached
> + * @NET_SHAPER_SCOPE_PORT:   The root shaper for the whole H/W.
> + * @NET_SHAPER_SCOPE_NETDEV: The main shaper for the given network device.
> + * @NET_SHAPER_SCOPE_VF:     The shaper is attached to the given virtual
> + * function.
> + * @NET_SHAPER_SCOPE_QUEUE_GROUP: The shaper groups multiple queues under the
> + * same device.
> + * @NET_SHAPER_SCOPE_QUEUE:  The shaper is attached to the given device queue.
> + *
> + * NET_SHAPER_SCOPE_PORT and NET_SHAPER_SCOPE_VF are only available on
> + * PF devices, usually inside the host/hypervisor.
> + * NET_SHAPER_SCOPE_NETDEV, NET_SHAPER_SCOPE_QUEUE_GROUP and
> + * NET_SHAPER_SCOPE_QUEUE are available on both PFs and VFs devices.
> + */
> +enum net_shaper_scope {
> +	NET_SHAPER_SCOPE_PORT,
> +	NET_SHAPER_SCOPE_NETDEV,
> +	NET_SHAPER_SCOPE_VF,
> +	NET_SHAPER_SCOPE_QUEUE_GROUP,
> +	NET_SHAPER_SCOPE_QUEUE,
> +};

How would modelling groups of VFs (as implemented in [1]) look like
with this proposal?
I could imagine a NET_SHAPER_SCOPE_VF_GROUP scope, with a shared shaper
across multiple VFs. How would managing membership of VFs in a group
look like? Will the devlink API continue to be used for that? Or will
something else be introduced?

Looking a bit into the future now...
I am nowadays thinking about extending the mlx5 VF group rate limit
feature to support VFs from multiple PFs from the same NIC (the
hardware can be configured to use a shared shaper across multiple
ports), how could that feature be represented in this API, given that
ops relate to a netdevice? Which netdevice should be used for this
scenario?
In that world, there would be multiple 'root'-level nodes in this
hierarchy, each corresponding to a group of VFs from potentially
multiple PFs.

[1]
https://lore.kernel.org/netdev/1622636251-29892-1-git-send-email-dlinkin@nvidia.com/T/#u

Cosmin.