linux-kernel - Re: [PATCH 1/3] sfc: revert "reduce the number of requested xdp ev queues"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Jul 2021 12:23:08 +0100
From:   Edward Cree <ecree.xilinx@...il.com>
To:     Íñigo Huguet <ihuguet@...hat.com>,
        habetsm.xilinx@...il.com, davem@...emloft.net, kuba@...nel.org,
        ivan@...udflare.com
Cc:     ast@...nel.org, daniel@...earbox.net, hawk@...nel.org,
        john.fastabend@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] sfc: revert "reduce the number of requested xdp ev
 queues"

On 07/07/2021 09:16, Íñigo Huguet wrote:
> The problem is that the TX queues are also contained inside the channel
> structs, and there are only 4 queues per channel. Reducing the number of
> channels means also reducing the number of queues, resulting in not
> having the desired number of 1 queue per CPU.
> 
> This leads to getting errors on XDP_TX and XDP_REDIRECT if they're
> executed from a high numbered CPU, because there only exist queues for
> the low half of CPUs, actually.

Should we then be using min(tx_per_ev, EFX_MAX_TXQ_PER_CHANNEL) in the
 DIV_ROUND_UP?
And on line 184 probably we need to set efx->xdp_tx_per_channel to the
 same thing, rather than blindly to EFX_MAX_TXQ_PER_CHANNEL as at
 present — I suspect the issue you mention in patch #2 stemmed from
 that.
Note that if we are in fact hitting this limitation (i.e. if
 tx_per_ev > EFX_MAX_TXQ_PER_CHANNEL), we could readily increase
 EFX_MAX_TXQ_PER_CHANNEL at the cost of a little host memory, enabling
 us to make more efficient use of our EVQs and thus retain XDP TX
 support up to a higher number of CPUs.

-ed