From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "John Fastabend" <john.fastabend@gmail.com>,
"Björn Töpel" <bjorn.topel@gmail.com>,
"John Fastabend" <john.fastabend@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Björn Töpel" <bjorn.topel@intel.com>, bpf <bpf@vger.kernel.org>,
"David Miller" <davem@davemloft.net>,
"Jakub Kicinski" <jakub.kicinski@netronome.com>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>,
"Jonathan Lemon" <jonathan.lemon@gmail.com>
Subject: Re: [PATCH bpf-next v2 4/8] xsk: make xskmap flush_list common for all map instances
Date: Wed, 08 Jan 2020 17:01:08 +0100 [thread overview]
Message-ID: <87lfqigcor.fsf@toke.dk> (raw)
In-Reply-To: <5e15faaac42e7_67ea2afd262665bc44@john-XPS-13-9370.notmuch>
John Fastabend <john.fastabend@gmail.com> writes:
> Björn Töpel wrote:
>> On Tue, 7 Jan 2020 at 18:54, John Fastabend <john.fastabend@gmail.com> wrote:
>> >
>> > Björn Töpel wrote:
>> > > From: Björn Töpel <bjorn.topel@intel.com>
>> > >
>> > > The xskmap flush list is used to track entries that need to flushed
>> > > from via the xdp_do_flush_map() function. This list used to be
>> > > per-map, but there is really no reason for that. Instead make the
>> > > flush list global for all xskmaps, which simplifies __xsk_map_flush()
>> > > and xsk_map_alloc().
>> > >
>> > > Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> > > Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
>> > > ---
>> >
>> > Just to check. The reason this is OK is because xdp_do_flush_map()
>> > is called from NAPI context and is per CPU so the only entries on
>> > the list will be from the current cpu napi context?
>>
>> Correct!
>>
>> > Even in the case
>> > where multiple xskmaps exist we can't have entries from more than
>> > a single map on any list at the same time by my reading.
>> >
>>
>> No, there can be entries from different (XSK) maps. Instead of
>> focusing on maps to flush, focus on *entries* to flush. At the end of
>> the poll function, all entries (regardless of map origin) will be
>> flushed. Makes sense?
>
> Ah OK. This would mean that a single program used multiple maps
> though correct? Because we can only run a single BPF program per
> NAPI context.
Yeah, there's nothing limiting each program to a single map (of any
type)...
-Toke
next prev parent reply other threads:[~2020-01-08 16:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 6:09 [PATCH bpf-next v2 0/8] Simplify xdp_do_redirect_map()/xdp_do_flush_map() and XDP maps Björn Töpel
2019-12-19 6:09 ` [PATCH bpf-next v2 1/8] xdp: simplify devmap cleanup Björn Töpel
2020-01-07 17:32 ` John Fastabend
2020-01-08 10:08 ` Björn Töpel
2019-12-19 6:10 ` [PATCH bpf-next v2 2/8] xdp: simplify cpumap cleanup Björn Töpel
2019-12-19 6:10 ` [PATCH bpf-next v2 3/8] xdp: fix graze->grace type-o in cpumap comments Björn Töpel
2020-01-07 17:33 ` John Fastabend
2019-12-19 6:10 ` [PATCH bpf-next v2 4/8] xsk: make xskmap flush_list common for all map instances Björn Töpel
2020-01-07 17:54 ` John Fastabend
2020-01-08 10:13 ` Björn Töpel
2020-01-08 15:52 ` John Fastabend
2020-01-08 16:01 ` Toke Høiland-Jørgensen [this message]
2019-12-19 6:10 ` [PATCH bpf-next v2 5/8] xdp: make devmap " Björn Töpel
2020-01-07 17:58 ` John Fastabend
2020-01-08 10:16 ` Björn Töpel
2020-01-08 10:23 ` Toke Høiland-Jørgensen
2020-01-08 10:25 ` Björn Töpel
2019-12-19 6:10 ` [PATCH bpf-next v2 6/8] xdp: make cpumap " Björn Töpel
2020-01-07 17:59 ` John Fastabend
2019-12-19 6:10 ` [PATCH bpf-next v2 7/8] xdp: remove map_to_flush and map swap detection Björn Töpel
2020-01-07 18:15 ` John Fastabend
2020-01-07 21:07 ` Toke Høiland-Jørgensen
2020-01-08 3:45 ` John Fastabend
2020-01-08 10:24 ` Björn Töpel
2019-12-19 6:10 ` [PATCH bpf-next v2 8/8] xdp: simplify __bpf_tx_xdp_map() Björn Töpel
2019-12-19 7:18 ` [PATCH bpf-next v2 0/8] Simplify xdp_do_redirect_map()/xdp_do_flush_map() and XDP maps Jesper Dangaard Brouer
2019-12-20 5:21 ` Alexei Starovoitov
2019-12-20 7:46 ` Jesper Dangaard Brouer
2019-12-20 9:26 ` Jesper Dangaard Brouer
2019-12-20 10:29 ` Toke Høiland-Jørgensen
2020-01-07 11:10 ` Björn Töpel
2020-01-07 11:25 ` Toke Høiland-Jørgensen
2020-01-07 13:05 ` Jesper Dangaard Brouer
2020-01-07 13:27 ` Toke Høiland-Jørgensen
2020-01-07 13:52 ` Jesper Dangaard Brouer
2020-01-07 14:18 ` Toke Høiland-Jørgensen
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=87lfqigcor.fsf@toke.dk \
--to=toke@redhat.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@gmail.com \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=hawk@kernel.org \
--cc=jakub.kicinski@netronome.com \
--cc=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=magnus.karlsson@intel.com \
--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 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.