Re: Basic PCP/DEI-based queue classification

[Allan Nielsen - M31684 <Allan.Nielsen@microchip.com>]

Hi Vladimir, Daniel,

On 07.09.2022 19:57, Daniel Machon - M70577 wrote:
>> On Wed, Sep 07, 2022 at 10:41:10AM +0000, Daniel.Machon@microchip.com wrote:
>> > > Regarding the topic at hand, and the apparent lack of PCP-based
>> > > prioritization in the software data path. VLAN devices have an
>> > > ingress-qos-map and an egress-qos-map. How would prioritization done via
>> > > dcbnl interact with those (who would take precedence)?
>> >
>> > Hi Vladimir,
>> >
>> > They shouldn't interact (at least this is my understanding).
>> >
>> > The ingress and egress maps are for vlan interfaces, and dcb operates
>> > on physical interfaces (dcbx too). You cannot use dcbnl to do
>> > prioritization for vlan interfaces.
>> >
>> > Anyway, I think much of the stuff in DCB is for hw offload only, incl. the
>> > topic at hand. Is the APP table even consulted by the sw stack at all - I
>> > dont think so (apart from drivers).
>>
>> Not directly, but at least ocelot (or in fact felix) does set
>> skb->priority based on the QoS class from the Extraction Frame Header.
>> So the stack does end up consulting and meaningfully using something
>> that was set based on the dcbnl APP table.
>>
>> In this sense, for ocelot, there is a real overlap between skb->priority
>> being initially set based on ocelot_xfh_get_qos_class(), and later being
>> overwritten based on the QoS maps of a VLAN interface.
I do not think this is an overlap.

The mappings Daniel is proposing will cause the QoS class from the
extraction header to be mapped (actually they are mapped today, the
mapping is just a 1:1). If the frame is extracted by the CPU, the
classified QoS class will (and shall) be used to set the skb->priority.

As long as the frame is considered to belong to the physical interface,
this is correct.

If this frame then at a later point is being processed by a VLAN
interface, then the mapping will be updated in the context if the VLAN
interface.

>Right, so VLAN QoS maps currently takes precedence, if somebody would choose
>to add a tagged vlan interface on-top of a physical interface with existing
>PCP prioritization - is this a real problem, or just a question of configuration?
It is not like VLAN QoS maps takes precedence. The mapping is just
updated if the frame goes through a (SW) VLAN interface.

>> The problem with the ingress-qos-map and egress-qos-map from 802.1Q that
>> I see is that they allow for per-VID prioritization, which is way more
>> fine grained than what we need. This, plus the fact that bridge VLANs
>> don't have this setting, only termination (8021q) VLANs do. How about an
>> ingress-qos-map and an egress-qos-map per port rather than per VID,
>> potentially even a bridge_slave netlink attribute, offloadable through
>> switchdev? We could make the bridge input fast path alter skb->priority
>> for the VLAN-tagged code paths, and this could give us superior
>> semantics compared to putting this non-standardized knob in the hardware
>> only dcbnl.
>
>This is a valid alternative solution to dcbnl, although this seems to be a
>much more complex solution, to something that is easily solved in dcbnl,
>and actually is in-line with what dcbnl already does. On-top of this, the
>notion of 'trust' has also been raised by this topic. It makes a lot of sense
>to me to add APP selector trust and trust order to dcbnl.
I agree that this mapping could be done by allowing to set the
ingress-qos-map/egress-qos-map maps on physical interfaces (and to
handle the trust aspect, we would have to introduce a anoter flag which
does not make sense on VLAN interfaces, but only on physical
interfaces).

Still I think it is better to do it in the dcb-app (and skip the
sw-fallback) for the following reasons:
- This mapping is important to supprot meaning use-cases with PFC
   (Priority Flow Control) Buffer handling and in furture maybe
   FramePreemption. These are all features which cannot be done in a
   meaningfull way in SW. Therefore the SW-path will not bennefit from
   this (but rahter will be be slowed down by supporting more features).
- This is closely related to others features found DCB, and as a user I
   just think it make sense to collect related features in the same
   tool and man-page.

>This is the solution that I have been implementing lately, and is ready
>for posting very soon.
Given that this is mostly implemented in accordance with the initial
discussion with Petr, I think we should see it and evaluate it. If we
think it is better to move the ingress-qos-map/egress-qos-map then we
need to try out that.

/Allan