From: Jakub Kicinski <kuba@kernel.org>
To: Andy Gospodarek <andrew.gospodarek@broadcom.com>
Cc: Michael Chan <michael.chan@broadcom.com>,
davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, bpf@vger.kernel.org, hawk@kernel.org,
ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
Somnath Kotur <somnath.kotur@broadcom.com>
Subject: Re: [PATCH net] bnxt_en: do not map packet buffers twice
Date: Fri, 15 Dec 2023 09:21:12 -0800 [thread overview]
Message-ID: <20231215092112.3f0fee3d@kernel.org> (raw)
In-Reply-To: <ZXyFW0lIGluM8ipj@C02YVCJELVCG.dhcp.broadcom.net>
On Fri, 15 Dec 2023 11:57:14 -0500 Andy Gospodarek wrote:
> > This patch is all good, but I'm confused by the handling of head.
> > Do you recycle it immediately and hope that the Tx happens before
> > the Rx gets around to using the recycled page again? Am I misreading?
>
> Your description is correct, but we use a better strategy that just
> hoping it works out. :)
>
> The design is that we do not update the rx ring with the producer value
> that was present when the packet was received until after getting the tx
> completion indicating that the packet sent via XDP_TX action has been
> sent.
Ah, I see it, interesting! In that case - next question.. :)
Are the XDP_REDIRECT (target) and XDP_TX going to the same rings?
The locking seems to be missing, and bnxt_tx_int_xdp() does not
seem to be able to handle the optimization you described if
a ring contains a mix of XDP_REDIRECT and XDP_TX.
If I'm reading the assignment in bnxt_alloc_mem() and indexing
right - XDP_REDIRECT and XDP_TX do seem to go to the same rings.
next prev parent reply other threads:[~2023-12-15 17:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 21:31 [PATCH net] bnxt_en: do not map packet buffers twice Michael Chan
2023-12-14 23:18 ` David Wei
2023-12-15 0:27 ` Michael Chan
2023-12-15 5:54 ` David Wei
2023-12-15 16:37 ` Jakub Kicinski
2023-12-15 16:57 ` Andy Gospodarek
2023-12-15 17:21 ` Jakub Kicinski [this message]
2023-12-15 20:45 ` Michael Chan
2023-12-15 18:20 ` patchwork-bot+netdevbpf
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=20231215092112.3f0fee3d@kernel.org \
--to=kuba@kernel.org \
--cc=andrew.gospodarek@broadcom.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=somnath.kotur@broadcom.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.