On 2019-06-15 18:42, Jakub Kicinski wrote:
> On Wed, 12 Jun 2019 15:57:09 +0000, Maxim Mikityanskiy wrote:
>> @@ -390,6 +391,12 @@ void mlx5e_ethtool_get_channels(struct mlx5e_priv *priv,
>> {
>> ch->max_combined = mlx5e_get_netdev_max_channels(priv->netdev);
>> ch->combined_count = priv->channels.params.num_channels;
>> +
>> + /* XSK RQs */
>> + ch->max_rx = ch->max_combined;
>> + /* rx_count shows the number of XSK RQs up to the highest active one. */
>> + ch->rx_count = mlx5e_xsk_first_unused_channel(&priv->channels.params,
>> + &priv->xsk);
>> }
>
> Ah, Maciej pointed out to me this is why you want the patch 7 to do
> what it does
You seem to be confusing cause and effect. The libbpf patch is good
regardless of mlx5e's needs, because the current formula is incorrect,
and I'm fixing it. Then I do the cited change in mlx5e, which perfectly
fits the fixed formula. So, I'm not inserting some hack in libbpf just
to make mlx5e work, I'm fixing an existing bug, and it allows me to do
this stuff in mlx5e. It's not about "I need to use ethtool.rx in mlx5e,
so I'm adapting libbpf to it", it's about "I see an issue in libbpf, so
I'm fixing it, then I'm adapting mlx5e to fit the formula".
> This count is for stack's queues.
Second, I disagree with this statement. XSK RX queues are not stack
queues, but in i40e they are still registered as stack queues. Various
boundary checks in the kernel use the "amount of stack queues" to check
XSK QIDs. All the existing usage of this count in XSK code shows it's
not for stack queues only, my usage is no different from that, so I
don't see any issue in exposing XSK RX queues via ethtool.rx.
Anyway, I'm respinning without patch 7 and ethtool.rx.
> Nacked-by: Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx>
>
