On 3/12/2026 6:36 PM, Talluri Chaitanyababu wrote:
> Update forwarding TC mask based on configured traffic classes to properly
> handle both 4 TC and 8 TC modes. The bitmask calculation (1u << nb_tcs) - 1
> correctly creates masks for all available traffic classes (0xF for 4 TCs,
> 0xFF for 8 TCs).
>
> When the mask is not updated after a TC configuration change, it stays at
> the default 0xFF, which causes dcb_fwd_tc_update_dcb_info() to skip the
> compress logic entirely (early return when mask ==
> DEFAULT_DCB_FWD_TC_MASK).
> This can lead to inconsistent queue allocations.
Sorry, I cannot understand your question. Could you please provide some steps
to reproduce the issue and the problem phenomenon?
>
> Additionally, the existing VMDQ pool guard in dcb_fwd_config_setup() only
> checks RX queue counts, missing the case where the TX port has zero queues
> for a given pool/TC combination. When nb_tx_queue is 0, the expression
> "j % nb_tx_queue" triggers a SIGFPE (integer division by zero).
The dcb_fwd_check_cores_per_tc() check this case. So please provide the steps.
>
> Fix this by:
> 1. Updating dcb_fwd_tc_mask after port DCB reconfiguration using the
> user requested num_tcs value, so fwd_config_setup() sees the correct
> mask.
> 2. Extending the existing pool guard to also check TX queue counts.
> 3. Adding a defensive break after the division by dcb_fwd_tc_cores to
> catch integer truncation to zero.
>
> Fixes: 0ecbf93f5001 ("app/testpmd: add command to disable DCB")
> Cc: [email protected]
>
> Signed-off-by: Talluri Chaitanyababu <[email protected]>
> Signed-off-by: Shaiq Wani <[email protected]>
> ---
