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
next prev parent 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).