> +static void netc_ipv_to_buffer_pool_mapping(struct netc_switch *priv)
> +{
> + int bp_per_port = priv->num_bp / priv->info->num_ports;
> + int q = NETC_IPV_NUM / bp_per_port;
> + int r = NETC_IPV_NUM % bp_per_port;
> + int num = q + r;
> +
> + /* IPV-to–buffer-pool mapping per port:
> + * Each port is allocated 'bp_per_port' buffer pools and supports 8
> + * IPVs, where a higher IPV indicates a higher frame priority. Each
> + * IPV can be mapped to only one buffer pool.
> + *
> + * The mapping rule is as follows:
> + * - The first 'num' IPVs share the port's first buffer pool (index
> + * 'base_id').
> + * - After that, every 'q' IPVs share one buffer pool, with pool
> + * indices increasing sequentially.
> + */
> + for (int i = 0; i < priv->info->num_ports; i++) {
> + u32 base_id = i * bp_per_port;
> + u32 bp_id = base_id;
> + u64 mapping = 0;
> +
> + for (int ipv = 0; ipv < NETC_IPV_NUM; ipv++) {
> + /* Update the buffer pool index */
> + if (ipv >= num)
> + bp_id = base_id + ((ipv - num) / q) + 1;
> +
> + mapping |= (u64)bp_id << (ipv * 8);
Sashiko says:
If hardware ever provides more than 8 buffer pools per port (for example,
bp_per_port = 10), will this logic fail to utilize the extra pools?
With bp_per_port > 8, q evaluates to 0, r evaluates to 8, and num becomes 8.
The condition if (ipv >= num) then evaluates to if (ipv >= 8), which
is never met since the loop terminates at ipv < 8.
This would leave bp_id at base_id for all priorities, mapping them all to a
single buffer pool and leaving the rest unused. Should bp_per_port be capped
to NETC_IPV_NUM before calculating q to prevent this silent fallback?
From hardware perspective, each port has 8 IPVs, each IPV can only be
mapped to one buffer pool, it is impossible that the hardware provides
more than 8 buffer pools per port. So this is a false positive.
