From: "Toke Høiland-Jørgensen" <toke@redhat•com>
To: "Loftus, Ciara" <ciara.loftus@intel•com>,
Jesper Dangaard Brouer <jbrouer@redhat•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"bpf@vger•kernel.org" <bpf@vger•kernel.org>
Cc: "brouer@redhat•com" <brouer@redhat•com>,
"ast@kernel•org" <ast@kernel•org>,
"daniel@iogearbox•net" <daniel@iogearbox•net>,
"davem@davemloft•net" <davem@davemloft•net>,
"kuba@kernel•org" <kuba@kernel•org>,
"hawk@kernel•org" <hawk@kernel•org>,
"john.fastabend@gmail•com" <john.fastabend@gmail•com>,
"bjorn@kernel•org" <bjorn@kernel•org>,
"Karlsson, Magnus" <magnus.karlsson@intel•com>,
"jonathan.lemon@gmail•com" <jonathan.lemon@gmail•com>,
"Fijalkowski, Maciej" <maciej.fijalkowski@intel•com>
Subject: RE: [RFC PATCH bpf-next 0/8] XDP_REDIRECT_XSK and Batched AF_XDP Rx
Date: Wed, 17 Nov 2021 15:24:42 +0100 [thread overview]
Message-ID: <87mtm2g8r9.fsf@toke.dk> (raw)
In-Reply-To: <PH0PR11MB4791D63AFE9595CAA9A6EC378E999@PH0PR11MB4791.namprd11.prod.outlook.com>
"Loftus, Ciara" <ciara.loftus@intel•com> writes:
>> I'm fine with adding a new helper, but I don't like introducing a new
>> XDP_REDIRECT_XSK action, which requires updating ALL the drivers.
>>
>> With XDP_REDIRECT infra we beleived we didn't need to add more
>> XDP-action code to drivers, as we multiplex/add new features by
>> extending the bpf_redirect_info.
>> In this extreme performance case, it seems the this_cpu_ptr "lookup" of
>> bpf_redirect_info is the performance issue itself.
>>
>> Could you experiement with different approaches that modify
>> xdp_do_redirect() to handle if new helper bpf_redirect_xsk was called,
>> prior to this_cpu_ptr() call.
>> (Thus, avoiding to introduce a new XDP-action).
>
> Thanks for your feedback Jesper.
> I understand the hesitation of adding a new action. If we can achieve the same improvement without
> introducing a new action I would be very happy!
> Without new the action we'll need a new way to indicate that the bpf_redirect_xsk helper was
> called. Maybe another new field in the netdev alongside the xsk_refcnt. Or else extend
> bpf_redirect_info - if we find a new home for it that it's too costly to access.
> Thanks for your suggestions. I'll experiment as you suggested and
> report back.
I'll add a +1 to the "let's try to solve this without a new return code" :)
Also, I don't think we need a new helper either; the bpf_redirect()
helper takes a flags argument, so we could just use ifindex=0,
flags=DEV_XSK or something like that.
Also, I think the batching in the driver idea can be generalised: we
just need to generalise the idea of "are all these packets going to the
same place" and have a batched version of xdp_do_redirect(), no? The
other map types do batching internally already, though, so I'm wondering
why batching in the driver helps XSK?
-Toke
next prev parent reply other threads:[~2021-11-17 14:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 7:37 [RFC PATCH bpf-next 0/8] XDP_REDIRECT_XSK and Batched AF_XDP Rx Ciara Loftus
2021-11-16 7:37 ` [RFC PATCH bpf-next 1/8] xsk: add struct xdp_sock to netdev_rx_queue Ciara Loftus
2021-11-16 7:37 ` [RFC PATCH bpf-next 2/8] bpf: add bpf_redirect_xsk helper and XDP_REDIRECT_XSK action Ciara Loftus
2021-11-16 7:37 ` [RFC PATCH bpf-next 3/8] xsk: handle XDP_REDIRECT_XSK and expose xsk_rcv/flush Ciara Loftus
2021-11-16 7:37 ` [RFC PATCH bpf-next 4/8] i40e: handle the XDP_REDIRECT_XSK action Ciara Loftus
2021-11-16 7:37 ` [RFC PATCH bpf-next 5/8] xsk: implement a batched version of xsk_rcv Ciara Loftus
2021-11-16 7:37 ` [RFC PATCH bpf-next 6/8] i40e: isolate descriptor processing in separate function Ciara Loftus
2021-11-16 7:37 ` [RFC PATCH bpf-next 7/8] i40e: introduce batched XDP rx descriptor processing Ciara Loftus
2021-11-16 7:37 ` [RFC PATCH bpf-next 8/8] libbpf: use bpf_redirect_xsk in the default program Ciara Loftus
2021-11-16 9:43 ` [RFC PATCH bpf-next 0/8] XDP_REDIRECT_XSK and Batched AF_XDP Rx Jesper Dangaard Brouer
2021-11-16 16:29 ` Loftus, Ciara
2021-11-17 14:24 ` Toke Høiland-Jørgensen [this message]
2021-11-19 15:48 ` Loftus, Ciara
2021-11-22 14:38 ` Toke Høiland-Jørgensen
2021-11-18 2:54 ` Alexei Starovoitov
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=87mtm2g8r9.fsf@toke.dk \
--to=toke@redhat$(echo .)com \
--cc=ast@kernel$(echo .)org \
--cc=bjorn@kernel$(echo .)org \
--cc=bpf@vger$(echo .)kernel.org \
--cc=brouer@redhat$(echo .)com \
--cc=ciara.loftus@intel$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=hawk@kernel$(echo .)org \
--cc=jbrouer@redhat$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=jonathan.lemon@gmail$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=maciej.fijalkowski@intel$(echo .)com \
--cc=magnus.karlsson@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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