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
