[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240605124011.69809be6@kernel.org>
Date: Wed, 5 Jun 2024 12:40:11 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Cosmin Ratiu <cratiu@...dia.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "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>
Subject: Re: [RFC PATCH] net: introduce HW Rate Limiting Driver API
On Wed, 05 Jun 2024 17:52:32 +0200 Paolo Abeni wrote:
> > 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?
>
> I must admit we[1] haven't thought yet about the scenario you describe
> above. I guess we could encode the PF number and the VF number in the
> handle major/minor and operate on any PF device belonging to the same
> silicon, WDYT?
Just a minor clarification. _Internally_ we can support expressing VF /
PF shaping. uAPI for that continues to be devlink, right?
Powered by blists - more mailing lists