Date:   Tue, 25 Aug 2020 09:31:36 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Carolyn Wyborny <carolyn.wyborny@...el.com>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org, jesse.brandeburg@...el.com,
        tom.herbert@...el.com
Subject: Re: [RFC PATCH net-next 0/2] Granular VF Trust Flags for SR-IOV



On 8/20/20 6:16 PM, Carolyn Wyborny wrote:
> Proposal for Granular VF Trust Flags for SR-IOV
>
> I would like to propose extending the concept of VF trust in a more
> granular way by creating VF trust flags. VF Trust Flags would allow more
> flexibility in assigning privileges to VF's administratively in SR-IOV.
> Users are asking for more configuration to be available in the VF.
> Features for one use case like a firewall are not always wanted in a
> different type of privilegd VF.  If a base set of generic privileges could be
> configured in a more granular way, they can be combined in a more flexible
> way by the user.
>
> The implementation would do this by by adding a new iflattribute for trust
> flags which defines the flags in an nla_bitfield32.  The changes `would
> also include changes to .ndo_set_vf_trust parameters, different or converted
> settings in .ndo_get_vf_config, kernel validation of the trust flags and
> driver changes for those that implement .ndo_set_vf_trust. There will also
> be changes proposed for ip link in the iproute2 toolset.
>
> This patchset provides an example implementation that is not complete.
> It does not include the full validation of the feature flags in the kernel,
> all the helper macros likely needed for the trust flags nor all the driver
> changes needed. It also needs a method for advertising supported privileges
> and validation to ensure unsupported privileges are not being set.
> It does have a simple example driver implementation in igb.  The full
> patchset will include all these things.
>
> I'd like to start the discussion about the general idea and then begin the
> dicussion about a base set of VF privleges that would be generic across the
> device vendors.
>
> ---

Hi Carolyn, thanks for sending this out, and for your presentation at 
NetDev last week.  Here are some initial thoughts and questions I had to 
get the discussion going.

Would this ever need to be extended to the sub-function devices (sf) 
that some devlink threads are discussing?

What would the user-land side of this look like?  Would this be an 
extension of the existing ip link set dev <pf> vf <vfid> <attr> 
<value>?  How would these attributes be named?

Will enabling the legacy trust include trusting all current and future 
trust items, or should it be limited to the current set?  If limited, 
then you might add a macro for VF_TRUST_F_ALL_LEGACY.  Not sure whether 
or not this would be a good thing.

Instead of SPFCHK_DIS or "spoofchk_disable" - can we get replace the 
reverse logic and rename these?

Permission bits might be needed for allowing RSS configuration and 
bandwidth limits.

Will there need to be more granularity around the Advanced Flow 
configuration abilities?

Should there be permission bits for changing settings found in 
ethtool-based settings like link-ksettings, coalesce, pause, speed, etc?

How can we guide/manage this to be sure we don't end up with vendors 
pushing device specific permission bits or feature enabling bits rather 
than generic permissions?

Do we really need a typedef for vf_trust_flags_t, or can we keep with a 
simple type?

Cheers,
sln

Powered by blists - more mailing lists