From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 48FDE46E34; Sun, 31 Aug 2025 16:55:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D628640262; Sun, 31 Aug 2025 16:55:58 +0200 (CEST) Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by mails.dpdk.org (Postfix) with ESMTP id 8292C4021E for ; Sun, 31 Aug 2025 16:55:57 +0200 (CEST) Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-b03fa5c5a89so137456866b.2 for ; Sun, 31 Aug 2025 07:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756652157; x=1757256957; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6hfQ9T/uxspIa8/YYY1s43dmzDHZYcv4uIUkMxfyRGQ=; b=PkOLLw9EkUL2cQEFgWHwMenOp5eypvWvd37eBQjvjQM/ybYv49wVBqGH4CpoGQ3EjU EySrl+QePBEsU5xG1JfVS55xwI2wi5AYCtdEpXVk1akOoyVWGmW2XhftyH3LHV7gvUaj wZYAUxV4Svn8ccFmm7YRvpEjyE4AGD24KU5Gv4kTTC+PxS0DhNFDIWLS+PURWIKGYRXl bm24lVphGybJtu157CI2mMkmGVSpLSbX5J4wSY7RHTtt30AQ4ziC22Qv5VNoqukTEa8J rkDVaT7EhQ20Yp2bBPemxuzefFL/uP8HPNPDhzlSqIQLqUl0gRQl83F9jDHnPyI/6zGh vT3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756652157; x=1757256957; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6hfQ9T/uxspIa8/YYY1s43dmzDHZYcv4uIUkMxfyRGQ=; b=YRL6WYhEtqKShXZ73TSzPwE2lbcygUpfN9nZtoYLeXRDnW1504hb02It8gdeTZHINB MSdA2nHQjkghaq78JXtmZjlYHR78Bje+bgHq22n/k4B9d11zy1m8mOluVJsZD2NMwVGU fMxWI5Bm/JTJfCas1O9HMVQauAHrr1ozWBIK2NKXU7Xa+wCokGSDgCuK+2/lFhfFBBwG +wKz8Cxh559I84F19ILRH7yFLWP/uwqYR9zH3uOD8B5VvzgqK2xHTDi6vFFgSht0H19g h/5VuzWi2H2+qdu6gRkNvcFhcmRhJGhgCo/hqUMIiBsQb9q/KrHBU6Me9gsYavhSwgrb 10vw== X-Forwarded-Encrypted: i=1; AJvYcCX7/e4aHpZx9pnCnNXU+g6zEMa+ErTLGvgUf5gNToZ1YllMeoX0M8j8J5a0SFI/zW0Fr7M=@dpdk.org X-Gm-Message-State: AOJu0YxALObZGEy126Hrc0Y3vzLcbunNLuSm++VmyNhoZGfkPIrNqIi0 w/Y5r8EAIbOOP1tDZq35Touvx9mkjcjfskQc/3KMeKtJQnbwnsr1UVvmMyI7XoSJMYoMEYHZKbT v3CupQcmC9DvsZz57G2P0fwNVNCjVPrQ= X-Gm-Gg: ASbGncv8Y7NFn387FfRd34Z4R40HlVWNTsl4rl1Ji8i4zM4cnOJ6Rs+VnOs/NdvX9W0 aICbAdTGF4tLIHe36Y5lCGD8rvoIR/JnESeOzB0rczWFwnMajGTrgIC2UpXVwVQFWDpRGYaVmEk ssectlnzwW4GuCMtVSTtM+nhsbynudpxXvMP5BKiF9527c7zV4MAXsvzgjtLmdrvhIzxRn3kh+A BEI X-Google-Smtp-Source: AGHT+IGtlXoHBMZtrtMd2bEfEMtumsXETEPJmSfsAAZLndMfkgbek6WDlaWUqdB+6LWF/jNod23QVSAINBVOrvPFUkg= X-Received: by 2002:a17:907:9287:b0:afe:f980:99cf with SMTP id a640c23a62f3a-b01d8c74bdbmr513779766b.23.1756652156608; Sun, 31 Aug 2025 07:55:56 -0700 (PDT) MIME-Version: 1.0 References: <20250830171706.428977-1-vladimir.medvedkin@intel.com> <609e89f7-4bbc-3535-b924-832afed6d006@arknetworks.am> In-Reply-To: <609e89f7-4bbc-3535-b924-832afed6d006@arknetworks.am> From: Vladimir Medvedkin Date: Sun, 31 Aug 2025 15:55:45 +0100 X-Gm-Features: Ac12FXytSf8kOm3n-FisZkw1QJPiisvs47_TH1Cuj6TADfk00Szu4L58EcKXQ-0 Message-ID: Subject: Re: [RFC PATCH 0/6] ethdev: refactor and extend DCB configuration API To: Ivan Malov Cc: Vladimir Medvedkin , dev@dpdk.org, bruce.richardson@intel.com, anatoly.burakov@intel.com, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, stephen@networkplumber.org Content-Type: multipart/alternative; boundary="000000000000c9e47a063daa7366" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000c9e47a063daa7366 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ivan, Thanks for your comments, please see my comments inline below. =D1=81=D0=B1, 30 =D0=B0=D0=B2=D0=B3. 2025=E2=80=AF=D0=B3. =D0=B2 22:14, Iva= n Malov : > 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 Queu= es > > (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 driver= s > 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, i= f > 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#a0ad043071c= cc7a261d79a759dc9c6f0c > > 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 =E2=80=9CDSCP = PFC=E2=80=9D 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 support= s 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. > --=20 Regards, Vladimir --000000000000c9e47a063daa7366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ivan,

Th= anks for your comments,=C2=A0please see my comments inline below.

=D1=81=D0=B1, 30 =D0=B0=D0=B2=D0=B3. 2025=E2=80=AF=D0= =B3. =D0=B2 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 config= uration,
> specifically Data Center Bridging (DCB) and Virtual Machine Device Que= ues
> (VMDq). The existing API was designed years ago around ixgbe hardware<= br> > 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 v= ast.
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] o= n the go.

[1] https://mails.dpdk.org/archives/dev/2= 025-August/323562.html

Yes, I see, some= patches=C2=A0in the seri= es may be postponed for= later, if necessary.
=C2=A0



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 val= ue
have to come specifically from VLAN header? Or can it come, say, from ToS o= f
IPv4, or Traffic Class of IPv6, or from some vendor-specific header?

[2] h= ttps://doc.dpdk.org/api-25.07/structrte__eth__pfc__conf.html#a0ad043071ccc7= a261d79a759dc9c6f0c


That's a good question. The short answer is= yes, at the moment, but i= t won't be 1= 00% true in the future.
For example, Intel <= span style=3D"white-space:pre-wrap">E800 Series n= etwork adapters can operate in two modes, depending<= span style=3D"white-space:pre-wrap"> on how HW classifies incoming packets into their respective= traffic classes. One <= span style=3D"white-space:pre-wrap">of the modes = uses a 3-bit PCP VLAN= field, and this is the= default mode. Another = mode is to = use the 6-bi= t DSCP, which is supported by E800 NICs,= but is not= currently enabled. In<= span style=3D"white-space:pre-wrap"> DSCP mode,= HW maintains one additional DSCP-to-UP mapping table to= translate incoming packets to= intermediate UP, and t= hen uses a = usual UP-to<= /span>-TC mapping table (ref. to the E810 datasheet 8.2.1.3.1.2 Pa= cket CoS Classification Flow in =E2=80=9CDSCP PFC=E2=80=9D Mode). Also please note that the PFC PAUSE frames car= ry 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 pos= sible, keep= in mind that the HW block responsible for TC<= span style=3D"white-space:pre-wrap"> 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 i= mplementation will= be as simple as possible.

=C2=A0
Thank you.


--
Regards,
Vladimir
--000000000000c9e47a063daa7366--