| Message ID | 20220908120442.3069771-2-daniel.machon@microchip.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Add PCP selector and new APPTRUST attribute | expand |
Daniel Machon <daniel.machon@microchip.com> writes: > Add new PCP selector for the 8021Qaz APP managed object. > > The purpose of adding the PCP selector, is to be able to offload > PCP-based queue classification to the 8021Q Priority Code Point table, > see 6.9.3 of IEEE Std 802.1Q-2018. > > PCP and DEI is encoded in the protocol field as 8*dei+pcp, so that a > mapping of PCP 2 and DEI 1 to priority 3 is encoded as {255, 10, 3}. > > While PCP is not a standard 8021Qaz selector, it seems very convenient > to add it to the APP object, as this is where similar priority mapping > is handled, and it perfectly fits the {selector, protocol, priority} > triplet. > > Signed-off-by: Daniel Machon <daniel.machon@microchip.com> > --- > include/uapi/linux/dcbnl.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/linux/dcbnl.h b/include/uapi/linux/dcbnl.h > index a791a94013a6..8eab16e5bc13 100644 > --- a/include/uapi/linux/dcbnl.h > +++ b/include/uapi/linux/dcbnl.h > @@ -217,6 +217,7 @@ struct cee_pfc { > #define IEEE_8021QAZ_APP_SEL_DGRAM 3 > #define IEEE_8021QAZ_APP_SEL_ANY 4 > #define IEEE_8021QAZ_APP_SEL_DSCP 5 > +#define IEEE_8021QAZ_APP_SEL_PCP 255 > > /* This structure contains the IEEE 802.1Qaz APP managed object. This > * object is also used for the CEE std as well. I'm thinking how to further isolate this from the IEEE standard values. I think it would be better to pass the non-standard APP contributions in a different attribute. IIUIC, this is how the APP table is passed: DCB_ATTR_IEEE_APP_TABLE { DCB_ATTR_IEEE_APP { struct dcb_app { ... }; } DCB_ATTR_IEEE_APP { struct dcb_app { ... }; } } Well, instead, the non-standard stuff could be passed in a different attribute: DCB_ATTR_IEEE_APP_TABLE { DCB_ATTR_IEEE_APP { struct dcb_app { ... }; // standard contribution to APP table } DCB_ATTR_DCB_APP { struct dcb_app { ... }; // non-standard contribution } } The new selector could still stay as 255. This will allow us to keep the internal bookkeeping simple for the likely case that 255 never becomes a valid IEEE selector. But if it ever does, the UAPI can stay the same, just the internals will need to be updated.
> > The purpose of adding the PCP selector, is to be able to offload > > PCP-based queue classification to the 8021Q Priority Code Point table, > > see 6.9.3 of IEEE Std 802.1Q-2018. > > > > PCP and DEI is encoded in the protocol field as 8*dei+pcp, so that a > > mapping of PCP 2 and DEI 1 to priority 3 is encoded as {255, 10, 3}. > > > > While PCP is not a standard 8021Qaz selector, it seems very convenient > > to add it to the APP object, as this is where similar priority mapping > > is handled, and it perfectly fits the {selector, protocol, priority} > > triplet. > > > > Signed-off-by: Daniel Machon <daniel.machon@microchip.com> > > --- > > include/uapi/linux/dcbnl.h | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/include/uapi/linux/dcbnl.h b/include/uapi/linux/dcbnl.h > > index a791a94013a6..8eab16e5bc13 100644 > > --- a/include/uapi/linux/dcbnl.h > > +++ b/include/uapi/linux/dcbnl.h > > @@ -217,6 +217,7 @@ struct cee_pfc { > > #define IEEE_8021QAZ_APP_SEL_DGRAM 3 > > #define IEEE_8021QAZ_APP_SEL_ANY 4 > > #define IEEE_8021QAZ_APP_SEL_DSCP 5 > > +#define IEEE_8021QAZ_APP_SEL_PCP 255 > > > > /* This structure contains the IEEE 802.1Qaz APP managed object. This > > * object is also used for the CEE std as well. > > I'm thinking how to further isolate this from the IEEE standard values. > I think it would be better to pass the non-standard APP contributions in > a different attribute. IIUIC, this is how the APP table is passed: > > DCB_ATTR_IEEE_APP_TABLE { > DCB_ATTR_IEEE_APP { > struct dcb_app { ... }; > } > DCB_ATTR_IEEE_APP { > struct dcb_app { ... }; > } > } > > Well, instead, the non-standard stuff could be passed in a different > attribute: > > DCB_ATTR_IEEE_APP_TABLE { > DCB_ATTR_IEEE_APP { > struct dcb_app { ... }; // standard contribution to APP table > } > DCB_ATTR_DCB_APP { > struct dcb_app { ... }; // non-standard contribution > } > } > > The new selector could still stay as 255. This will allow us to keep the > internal bookkeeping simple for the likely case that 255 never becomes a > valid IEEE selector. But if it ever does, the UAPI can stay the same, > just the internals will need to be updated. I get your sentiment, but it seems a little far-fetched to me. The trade-off will be extra code, in trade for something that IMO very likely will not happen. Like you said earlier - how many selectors could one possibly prioritize on?
diff --git a/include/uapi/linux/dcbnl.h b/include/uapi/linux/dcbnl.h index a791a94013a6..8eab16e5bc13 100644 --- a/include/uapi/linux/dcbnl.h +++ b/include/uapi/linux/dcbnl.h @@ -217,6 +217,7 @@ struct cee_pfc { #define IEEE_8021QAZ_APP_SEL_DGRAM 3 #define IEEE_8021QAZ_APP_SEL_ANY 4 #define IEEE_8021QAZ_APP_SEL_DSCP 5 +#define IEEE_8021QAZ_APP_SEL_PCP 255 /* This structure contains the IEEE 802.1Qaz APP managed object. This * object is also used for the CEE std as well.
Add new PCP selector for the 8021Qaz APP managed object. The purpose of adding the PCP selector, is to be able to offload PCP-based queue classification to the 8021Q Priority Code Point table, see 6.9.3 of IEEE Std 802.1Q-2018. PCP and DEI is encoded in the protocol field as 8*dei+pcp, so that a mapping of PCP 2 and DEI 1 to priority 3 is encoded as {255, 10, 3}. While PCP is not a standard 8021Qaz selector, it seems very convenient to add it to the APP object, as this is where similar priority mapping is handled, and it perfectly fits the {selector, protocol, priority} triplet. Signed-off-by: Daniel Machon <daniel.machon@microchip.com> --- include/uapi/linux/dcbnl.h | 1 + 1 file changed, 1 insertion(+)