<div dir="ltr"><div dir="ltr"><div>Hi Ivan,</div><div> </div><div>Thanks for your comments, please see my comments inline below.</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 30 авг. 2025 г. в 22:14, Ivan Malov <<a href="mailto:ivan.malov@arknetworks.am" target="_blank">ivan.malov@arknetworks.am</a>>: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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] <a href="https://mails.dpdk.org/archives/dev/2025-August/323562.html" rel="noreferrer" target="_blank">https://mails.dpdk.org/archives/dev/2025-August/323562.html</a></blockquote><div> </div><div>Yes, I see, some patches in the series may be postponed for later, if necessary.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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] <a href="https://doc.dpdk.org/api-25.07/structrte__eth__pfc__conf.html#a0ad043071ccc7a261d79a759dc9c6f0c" rel="noreferrer" target="_blank">https://doc.dpdk.org/api-25.07/structrte__eth__pfc__conf.html#a0ad043071ccc7a261d79a759dc9c6f0c</a> </blockquote><div> </div>That's a good question. The short answer is yes, at the moment, but it won't be 100% true in the future.<div>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.</div><div>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.</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Thank you. </blockquote></div></div><div> </div> -- <div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards, </div>Vladimir </div></div>