netdev - Re: [PATCH iwl-next v4 0/5] iavf: Add devlink and devlink rate support'

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: <f586e275750b33feb347e2ba8484a338bc5a8585.camel@redhat.com>
Date: Wed, 18 Oct 2023 11:05:37 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Jakub Kicinski <kuba@...nel.org>, Wenjun Wu <wenjun1.wu@...el.com>, 
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org, 
	madhu.chittim@...el.com, qi.z.zhang@...el.com, anthony.l.nguyen@...el.com, 
	"Zhang, Xuejun" <xuejun.zhang@...el.com>
Subject: Re: [PATCH iwl-next v4 0/5] iavf: Add devlink and devlink rate
 support'

Hi,

please allow me to revive this old thread...

On Thu, 2023-08-24 at 09:04 +0200, Jiri Pirko wrote:
> > Wed, Aug 23, 2023 at 09:13:34PM CEST, xuejun.zhang@...el.com wrote:
> > > > 
> > > > On 8/22/2023 8:34 AM, Jiri Pirko wrote:
> > > > > > Tue, Aug 22, 2023 at 05:12:55PM CEST,kuba@...nel.org  wrote:
> > > > > > > > On Tue, 22 Aug 2023 08:12:28 +0200 Jiri Pirko wrote:
> > > > > > > > > > NACK! Port function is there to configure the VF/SF from the eswitch
> > > > > > > > > > side. Yet you use it for the configureation of the actual VF, which is
> > > > > > > > > > clear misuse. Please don't
> > > > > > > > Stating where they are supposed to configure the rate would be helpful.
> > > > > > TC?
> > > > 
> > > > Our implementation is an extension to this commit 42c2eb6b1f43 ice: Implement
> > > > devlink-rate API).
> > > > 
> > > > We are setting the Tx max & share rates of individual queues in a VF using
> > > > the devlink rate API.
> > > > 
> > > > Here we are using DEVLINK_PORT_FLAVOUR_VIRTUAL as the attribute for the port
> > > > to distinguish it from being eswitch.
> > 
> > I understand, that is a wrong object. So again, you should use
> > "function" subobject of devlink port to configure "the other side of the
> > wire", that means the function related to a eswitch port. Here, you are
> > doing it for the VF directly, which is wrong. If you need some rate
> > limiting to be configured on an actual VF, use what you use for any
> > other nic. Offload TC.

I have a doubt WRT the above. Don't we need something more/different
here? I mean: a possible intent is limiting the amount of resources (BW
in the VF -> esw direction) that the application owing the VF could
use.

If that is enforced via TC on the VF side (say, a different namespace
or VM), the VF user could circumvent such limit - changing the tc
configuration - either by mistake or malicious action. 

Looking at the thing from a different perspective, the TX B/W on the VF
side is the RX B/W on the eswitch side, so the same effect could be
obtained with a (new/different) API formally touching only eswitch side
object. WDYT?

Thanks,

Paolo