Re: [RFC PATCH 0/6] ethdev: refactor and extend DCB configuration API

[Vladimir Medvedkin <medvedkinv@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

Hi Ivan,

Thanks for your comments, please see my comments inline below.

сб, 30 авг. 2025 г. в 22:14, Ivan Malov <ivan.malov@arknetworks.am>:

> Hi Vladimir,
>
> On Sat, 30 Aug 2025, Vladimir Medvedkin wrote:
>
> > Hi all,
> >
> > This series reworks the ethdev API related to advanced queueing
> configuration,
> > specifically Data Center Bridging (DCB) and Virtual Machine Device Queues
> > (VMDq). The existing API was designed years ago around ixgbe hardware
> > assumptions, which makes it difficult to properly support modern NICs
> and their
> > more flexible capabilities.
> >
>
> I like this overall.
>
> The series seems to be a good rework, but the PMD changes are going to be
> vast.
> Also, given the fact it targets the same release cycle as some new drivers
> do,
> it can be problematic to apply 'rx_adv_conf.mq_mode' to, say, [1] on the
> go.
>
> [1] https://mails.dpdk.org/archives/dev/2025-August/323562.html


Yes, I see, some patches in the series may be postponed for later, if
necessary.


>
>
>
> Also, now we've touched on the topic of traffic classes and priorities, if
> I may
> be so bold as to ask an unrelated question about [2]. Does the priority
> value
> have to come specifically from VLAN header? Or can it come, say, from ToS
> of
> IPv4, or Traffic Class of IPv6, or from some vendor-specific header?
>
> [2]
> https://doc.dpdk.org/api-25.07/structrte__eth__pfc__conf.html#a0ad043071ccc7a261d79a759dc9c6f0c
>
>
That's a good question. The short answer is yes, at the moment, but it won't
be 100% true in the future.
For example, Intel E800 Series network adapters can operate in two modes,
depending on how HW classifies incoming packets into their respective
traffic classes. One of the modes uses a 3-bit PCP VLAN field, and this is
the default mode. Another mode is to use the 6-bit DSCP, which is supported
by E800 NICs, but is not currently enabled. In DSCP mode, HW maintains one
additional DSCP-to-UP mapping table to translate incoming packets to
intermediate UP, and then uses a usual UP-to-TC mapping table (ref. to the
E810 datasheet 8.2.1.3.1.2 Packet CoS Classification Flow in “DSCP PFC” Mode).
Also please note that the PFC PAUSE frames carry per-priority pause quanta
for 8 priorities, and those priorities usually correspond to VLAN PCP.
Regarding vendor-specific headers, I'm not aware of any vendor that supports
this. Although this is theoretically possible, keep in mind that the HW
block responsible for TC classification should usually be located somewhere
at the very beginning of the Rx pipeline, there are strict performance
limitations for it, so most likely its implementation will be as simple as
possible.



> Thank you.
>


-- 
Regards,
Vladimir

[-- Attachment #2: Type: text/html, Size: 16902 bytes --]