Re: [RFC PATCH net-next 2/2] net: dcb: add new apptrust attribute

Den Fri, Sep 09, 2022 at 12:29:50PM +0000 skrev Vladimir Oltean:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi Daniel,

On Thu, Sep 08, 2022 at 02:04:42PM +0200, Daniel Machon wrote:

quoted

Add a new apptrust extension attribute to the 8021Qaz APP managed
object.

The new attribute is meant to allow drivers, whose hw supports the
notion of trust, to be able to set whether a particular app selector is
to be trusted - and also the order of precedence of selectors.

A new structure ieee_apptrust has been created, which contains an array
of selectors, where lower indexes has higher precedence.

Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
---

Let's say I have a switch which only looks at VLAN PCP/DEI if the bridge
vlan_filtering setting is enabled (otherwise, the switch is completely
VLAN unaware, including for QoS purposes).

Would it be ok to report through ieee_getapptrust() that the PCP
selector is trusted when under a vlan_filtering bridge, not trusted when
not under a vlan_filtering bridge, and deny changes to ieee_setapptrust()
for the PCP selector? I see the return value is not cached anywhere
within the kernel, just passed to the user.

There *might* be a distinction between enabled and trusted, disabled and not-trusted.
For instance, sparx5 switch has this distinction (at least for dscp) - but really that is 
hw dependent. Therefore, in your particular case, with the vlan_filtering on/off, 
yes that would be OK IMO. Any concerns?

This patch merely provides the means for drivers to implement a user-specified trust
order and report it back to the user, just like with many of the other dcb attributes 
(maxrate, buffer etc.).