[RFC,v2,net-next,0/2] Add PCP selector and new APPTRUST attribute

Message

Daniel Machon Sept. 15, 2022, 9:57 a.m. UTC

This patch series adds support for offloading PCP-based queue
classification and introduces a new APPTRUST extension attribute to the
8021Qaz APP managed object.  Prior to implemenation, it has been
discussed on the netdev mailing list here:

https://lore.kernel.org/netdev/Yv9VO1DYAxNduw6A@DEN-LT-70577/

In summary: there currently exist no conveinent way to offload per-port
PCP-based queue classification to hardware. Similarly, there is no way
to indicate the notion of trust for APP table selectors. This patch
series addresses both topics.

PCP based queue classification:

	8021Q standardizes the Priority Code Point table (see 6.9.3 of
	IEEE Std 802.1Q-2018).  This patch series makes it possible, to
	offload the PCP classification to said table.  The new PCP
	selector is not a standard part of the APP managed object,
	therefore it has been assigned a value of 255 to avoid any
	clashes with future DCB standard extensions.

Selector trust:

	ASIC's often has the notion of trust DSCP and trust PCP. This
	new object makes it possible to specify a trust order of app
	selectors, which drivers can then react on.

Patch #1 introduces a new PCP selector to the APP object, which makes it
possible to encode PCP and DEI in the app triplet and offload it to the
PCP table of the ASIC.

Patch #2 Introduces the new extension attributes
DCB_ATTR_DCB_APP_TRUST_TABLE and DCB_ATTR_DCB_APP_TRUST. Trusted
selectors are passed in the nested DCB_ATTR_DCB_APP_TRUST_TABLE
attribute, and assembled into an array of selectors:

  u8 selectors[256];

where lower indexes has higher precedence.  In the array, selectors are
stored consecutively, starting from index zero. With a maximum number of
256 unique selectors, the list has the same maximum size.

The userspace part of this will be posted in a separate patch series.

================================================================================

RFC v1:
https://lore.kernel.org/netdev/[e-mail]/

RFC v1 -> RFC v2:
  - Added new nested attribute type DCB_ATTR_DCB_APP_TRUST_TABLE.
  - Renamed attributes from DCB_ATTR_IEEE_* to DCB_ATTR_DCB_*
  - Renamed ieee_set/getapptrust to dcbnl_set/getapptrust
  - Added -EOPNOTSUPP if dcbnl_setapptrust is not set.
  - Added sanitization of selector array, before passing to driver.


Daniel Machon (2):
  net: dcb: add new pcp selector to app object
  net: dcb: add new apptrust attribute

 include/net/dcbnl.h        |  5 +++
 include/uapi/linux/dcbnl.h |  5 +++
 net/dcb/dcbnl.c            | 66 ++++++++++++++++++++++++++++++++++++--
 3 files changed, 73 insertions(+), 3 deletions(-)

--
2.34.1

Comments

Petr Machata Sept. 19, 2022, 7:54 a.m. UTC | #1

Thanks, this looks good to me overall, despite the several points
Vladimir and I raised. I think it would be good to send this as non-RFC.

Note that for the non-RFC version, an actual user of the interface needs
to be present as well. So one of the offloading drivers should be
adapted to make use of the APP_TRUST and the new PCP selector.
mlxsw would like to make use of both, but I don't know when I will have
time to implement that.

Daniel Machon Sept. 19, 2022, 8:13 a.m. UTC | #2

Den Mon, Sep 19, 2022 at 09:54:23AM +0200 skrev Petr Machata:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Thanks, this looks good to me overall, despite the several points
> Vladimir and I raised. I think it would be good to send this as non-RFC.
> 
> Note that for the non-RFC version, an actual user of the interface needs
> to be present as well. So one of the offloading drivers should be
> adapted to make use of the APP_TRUST and the new PCP selector.
> mlxsw would like to make use of both, but I don't know when I will have
> time to implement that.

Sounds good, and thanks for reviewing to you both.
I will go ahead and add support for this in the sparx5 driver - most of it
is already implemented during the tests anyway.

Should the driver support be posted together with said non-RFC patch
series?

/ Daniel

Petr Machata Sept. 19, 2022, 3:11 p.m. UTC | #3

<[e-mail]> writes:

> Den Mon, Sep 19, 2022 at 09:54:23AM +0200 skrev Petr Machata:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> 
>> Thanks, this looks good to me overall, despite the several points
>> Vladimir and I raised. I think it would be good to send this as non-RFC.
>> 
>> Note that for the non-RFC version, an actual user of the interface needs
>> to be present as well. So one of the offloading drivers should be
>> adapted to make use of the APP_TRUST and the new PCP selector.
>> mlxsw would like to make use of both, but I don't know when I will have
>> time to implement that.
>
> Sounds good, and thanks for reviewing to you both.
> I will go ahead and add support for this in the sparx5 driver - most of it
> is already implemented during the tests anyway.
>
> Should the driver support be posted together with said non-RFC patch
> series?

Yes.