[RFC PATCH 4/6] ethdev: extend VMDq/DCB configuration with queue mapping

[Ivan Malov]

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;
- VLAN UP (priority) selects an entry in the 'pool' (gives 'base', 'nb_queue);
- 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'?

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.

Thank you.