From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Heng Qi <hengqi@linux.alibaba.com>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [PATCH net] veth: Avoid drop packets when xdp_redirect performs
Date: Thu, 20 Oct 2022 18:34:12 +0200 [thread overview]
Message-ID: <87bkq6v4hn.fsf@toke.dk> (raw)
In-Reply-To: <c128d468-0c87-8759-e7de-b482abf8aab6@linux.alibaba.com>
Heng Qi <hengqi@linux.alibaba.com> writes:
> maybe we should consider a simpler method: when loading xdp in veth,
> we can automatically enable the napi ring of peer veth, which seems to
> have no performance impact and functional impact on the veth pair, and
> no longer requires users to do more things for peer veth (after all,
> they may be unaware of more requirements for peer veth). Do you think
> this is feasible?
It could be, perhaps? One issue is what to do once the XDP program is
then unloaded? We should probably disable NAPI on the peer in this case,
but then we'd need to track whether it was enabled by loading an XDP
program; we don't want to disable GRO/NAPI if the user requested it
explicitly. This kind of state tracking gets icky fast, so I guess it'll
depend on the patch...
-Toke
next prev parent reply other threads:[~2022-10-20 16:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 8:30 [PATCH net] veth: Avoid drop packets when xdp_redirect performs Heng Qi
2022-09-27 12:20 ` Toke Høiland-Jørgensen
2022-09-28 11:57 ` Heng Qi
2022-09-28 14:58 ` Toke Høiland-Jørgensen
2022-09-29 2:50 ` Heng Qi
2022-09-29 6:57 ` Paolo Abeni
2022-09-29 7:33 ` Heng Qi
2022-09-29 12:08 ` Toke Høiland-Jørgensen
2022-10-20 2:23 ` Heng Qi
2022-10-20 16:34 ` Toke Høiland-Jørgensen [this message]
2022-10-21 6:31 ` Heng Qi
2022-10-24 11:20 ` Heng Qi
2022-10-24 13:34 ` Toke Høiland-Jørgensen
2022-10-24 13:39 ` Heng Qi
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=87bkq6v4hn.fsf@toke.dk \
--to=toke@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hengqi@linux.alibaba.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=xuanzhuo@linux.alibaba.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 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).