DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
To: Ivan Malov <ivan.malov@arknetworks.am>
Cc: <dev@dpdk.org>, <bruce.richardson@intel.com>,
	<anatoly.burakov@intel.com>,  <thomas@monjalon.net>,
	<andrew.rybchenko@oktetlabs.ru>, <stephen@networkplumber.org>
Subject: Re: [RFC PATCH 4/6] ethdev: extend VMDq/DCB configuration with queue mapping
Date: Tue, 7 Oct 2025 16:21:02 +0100	[thread overview]
Message-ID: <1313fa61-4141-4840-913a-38221f1c2c0c@intel.com> (raw)
In-Reply-To: <4c1c74c5-5d03-7a00-9dc3-c837a2ec47d2@arknetworks.am>

Hi Ivan,

On 9/25/2025 6:59 PM, Ivan Malov wrote:
> Hi Vladimir,
>
> On Sat, 30 Aug 2025, Vladimir Medvedkin wrote:
>
>> Currently DCB Traffic Class queue mapping is only used when calling get
>> DCB info API, while setting up queue mappings is up to each individual
>> driver. Use the tc queue mapping structure to enable setting up custom
>> mapping explicitly.
>>
>
> snip
>
>> -/**
>> - * A structure used to get the information of queue and
>> - * TC mapping on both Tx and Rx paths.
>> - */
>> -struct rte_eth_dcb_tc_queue_mapping {
>> -    /** Rx queues assigned to tc per Pool */
>> -    struct {
>> -        uint16_t base;
>> -        uint16_t nb_queue;
>> -    } tc_rxq[RTE_ETH_MAX_VMDQ_POOL][RTE_ETH_DCB_NUM_TCS];
>> -    /** Rx queues assigned to tc per Pool */
>> -    struct {
>> -        uint16_t base;
>> -        uint16_t nb_queue;
>> -    } tc_txq[RTE_ETH_MAX_VMDQ_POOL][RTE_ETH_DCB_NUM_TCS];
>> -};
>
> May I clarify: is 'tc_rxq' structure supposed to facilitate the use 
> case where:
> - VLAN ID (VID) of the packet selects a 'pool' containing some entries;

I think it could be VLAN ID and/or dst MAC address

> - VLAN UP (priority) selects an entry in the 'pool' (gives 'base', 
> 'nb_queue);
VLAN UP selects TC (could be many to one mapping). And then TC selects 
an entry
> - if 'nb_queue' is 1, we send the packet to a specific queue ('base');
> - if 'nb_queue > 1', we perform RSS across 'nb_queue' relative to 'base'?
yes
>
> I'm slightly confused, as [3/6] seems to remove 
> 'rte_eth_vmdq_dcb_conf' and
> the 'pool_map' (with 'vlan_id') and I'm not sure where it should 
> resurface.

Correct, I think we should separate DCB from VMDQ configuration. 
Currently rte_eth_vmdq_dcb_conf combines two different technologies 
because of how old NICs were working wit respect to queue assignment.

But now I think it would be better to get rid of `struct 
rte_eth_dcb_tc_queue_mapping`, at least inside the configuration block, 
and replace it with a somehow similar struct, but with one-dimensional 
array indexed only by TC (i.e. remove `[RTE_ETH_MAX_VMDQ_POOL]`), 
implying similar per-TC queue assignment for each pool.

>
> Thank you.

-- 
Regards,
Vladimir


  reply	other threads:[~2025-10-07 15:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-30 17:17 [RFC PATCH 0/6] ethdev: refactor and extend DCB configuration API Vladimir Medvedkin
2025-08-30 17:17 ` [RFC PATCH 1/6] ethdev: extend and refactor DCB configuration Vladimir Medvedkin
2025-08-30 19:52   ` Ivan Malov
2025-08-31 15:00     ` Vladimir Medvedkin
2025-08-30 19:57   ` Ivan Malov
2025-08-31 15:01     ` Vladimir Medvedkin
2025-08-30 17:17 ` [RFC PATCH 2/6] ethdev: remove nb_tcs from rte_eth_dcb_conf structure Vladimir Medvedkin
2025-08-30 17:17 ` [RFC PATCH 3/6] ethdev: decouple VMDq and DCB cofiguration Vladimir Medvedkin
2025-08-30 17:17 ` [RFC PATCH 4/6] ethdev: extend VMDq/DCB configuration with queue mapping Vladimir Medvedkin
2025-08-30 20:36   ` Ivan Malov
2025-08-31 15:09     ` Vladimir Medvedkin
2025-08-31 15:57       ` Ivan Malov
2025-09-25 17:59   ` Ivan Malov
2025-10-07 15:21     ` Medvedkin, Vladimir [this message]
2025-08-30 17:17 ` [RFC PATCH 5/6] ethdev: remove dcb_capability_en from rte_eth_conf Vladimir Medvedkin
2025-08-30 20:46   ` Ivan Malov
2025-08-30 20:49   ` Ivan Malov
2025-08-30 17:17 ` [RFC PATCH 6/6] ethdev: move mq_mode to [r,t]x_adv_conf Vladimir Medvedkin
2025-08-30 21:13 ` [RFC PATCH 0/6] ethdev: refactor and extend DCB configuration API Ivan Malov
2025-08-31 14:55   ` Vladimir Medvedkin
2025-09-01  8:51 ` Thomas Monjalon
2025-09-01 18:09   ` Medvedkin, Vladimir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1313fa61-4141-4840-913a-38221f1c2c0c@intel.com \
    --to=vladimir.medvedkin@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ivan.malov@arknetworks.am \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).