From: Edward Cree <ecree.xilinx@gmail.com>
To: "Íñigo Huguet" <ihuguet@redhat.com>,
habetsm.xilinx@gmail.com, davem@davemloft.net, kuba@kernel.org,
ivan@cloudflare.com
Cc: ast@kernel.org, daniel@iogearbox.net, hawk@kernel.org,
john.fastabend@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] sfc: revert "reduce the number of requested xdp ev queues"
Date: Wed, 7 Jul 2021 12:23:08 +0100 [thread overview]
Message-ID: <0e6a7c74-96f6-686f-5cf5-cd30e6ca25f8@gmail.com> (raw)
In-Reply-To: <20210707081642.95365-1-ihuguet@redhat.com>
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
next prev parent reply other threads:[~2021-07-07 11:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 8:16 [PATCH 1/3] sfc: revert "reduce the number of requested xdp ev queues" Íñigo Huguet
2021-07-07 8:16 ` [PATCH 2/3] sfc: revert "adjust efx->xdp_tx_queue_count with the real number of initialized queues" Íñigo Huguet
2021-07-07 8:16 ` [PATCH 3/3] sfc: add logs explaining XDP_TX/REDIRECT is not available Íñigo Huguet
2021-07-07 11:23 ` Edward Cree [this message]
2021-07-07 11:49 ` [PATCH 1/3] sfc: revert "reduce the number of requested xdp ev queues" Íñigo Huguet
2021-07-07 13:01 ` Martin Habets
2021-07-08 12:14 ` Íñigo Huguet
2021-07-09 14:07 ` Edward Cree
2021-07-09 15:06 ` Jesper Dangaard Brouer
2021-07-12 13:40 ` Íñigo Huguet
2021-07-12 14:52 ` Edward Cree
2021-07-13 6:20 ` Íñigo Huguet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e6a7c74-96f6-686f-5cf5-cd30e6ca25f8@gmail.com \
--to=ecree.xilinx@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=habetsm.xilinx@gmail.com \
--cc=hawk@kernel.org \
--cc=ihuguet@redhat.com \
--cc=ivan@cloudflare.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).