From: "Maciej Fijałkowski" <maciejromanfijalkowski@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: ast@kernel.org, netdev@vger.kernel.org,
jakub.kicinski@netronome.com, brouer@redhat.com,
john.fastabend@gmail.com
Subject: Re: [PATCH bpf-next v5 0/8] xdp: Avoid unloading xdp prog not attached by sample
Date: Fri, 1 Feb 2019 22:47:20 +0100 [thread overview]
Message-ID: <20190201224720.3b4a1b5a@maciek-lenovo> (raw)
In-Reply-To: <1221854d-a2ad-cc03-8e72-985a265c49c9@iogearbox.net>
On Fri, 1 Feb 2019 22:23:45 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 02/01/2019 01:19 AM, Maciej Fijalkowski wrote:
> > Hi!
> > This patchset tries to address the situation where:
> > * user loads a particular xdp sample application that does stats polling
> > * user loads another sample application on the same interface
> > * then, user sends SIGINT/SIGTERM to the app that was attached as a first
> > one
> > * second application ends up with an unloaded xdp program
> >
> > 1st patch contains a helper libbpf function for getting the map fd by a
> > given map name.
> > In patch 2 Jesper removes the read_trace_pipe usage from xdp_redirect_cpu
> > which was a blocker for converting this sample to libbpf usage.
> > 3rd patch updates a bunch of xdp samples to make the use of libbpf.
> > Patch 4 adjusts RLIMIT_MEMLOCK for two samples touched in this patchset.
> > In patch 5 extack messages are added for cases where dev_change_xdp_fd
> > returns with an error so user has an idea what was the reason for not
> > attaching the xdp program onto interface.
> > Patch 6 makes the samples behavior similar to what iproute2 does when
> > loading xdp prog - the "force" flag is introduced.
> > Patch 7 introduces the libbpf function that will query the driver from
> > userspace about the currently attached xdp prog id.
> >
> > Use it in samples that do polling by checking the prog id in signal handler
> > and comparing it with previously stored one which is the scope of patch 8.
> >
> > Thanks!
> >
> > v1->v2:
> > * add a libbpf helper for getting a prog via relative index
> > * include xdp_redirect_cpu into conversion
> >
> > v2->v3: mostly addressing Daniel's/Jesper's comments
> > * get rid of the helper from v1->v2
> > * feed the xdp_redirect_cpu with program name instead of number
> >
> > v3->v4:
> > * fix help message in xdp_sample_pkts
> >
> > v4->v5:
> > * in get_link_xdp_fd, assign prog_id only when libbpf_nl_get_link returned
> > with 0
> > * add extack messages in dev_change_xdp_fd
> > * check the return value of bpf_get_link_xdp_id when exiting from sample
> > progs
>
> Series looks good to me, but doesn't apply cleanly, please rebase.
>
> Thanks,
> Daniel
Sure, sending v6 in a minute.
prev parent reply other threads:[~2019-02-01 21:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 0:19 [PATCH bpf-next v5 0/8] xdp: Avoid unloading xdp prog not attached by sample Maciej Fijalkowski
2019-02-01 0:19 ` [PATCH bpf-next v5 1/8] libbpf: Add a helper for retrieving a map fd for a given name Maciej Fijalkowski
2019-02-01 0:19 ` [PATCH bpf-next v5 2/8] samples/bpf: xdp_redirect_cpu have not need for read_trace_pipe Maciej Fijalkowski
2019-02-01 0:19 ` [PATCH bpf-next v5 3/8] samples/bpf: Convert XDP samples to libbpf usage Maciej Fijalkowski
2019-02-01 0:19 ` [PATCH bpf-next v5 4/8] samples/bpf: Extend RLIMIT_MEMLOCK for xdp_{sample_pkts, router_ipv4} Maciej Fijalkowski
2019-02-01 0:19 ` [PATCH bpf-next v5 5/8] xdp: Provide extack messages when prog attachment failed Maciej Fijalkowski
2019-02-01 0:32 ` Jakub Kicinski
2019-02-01 3:11 ` Jakub Kicinski
2019-02-01 7:02 ` Co-existing XDP generic and native mode? (Re: [PATCH bpf-next v5 5/8] xdp: Provide extack messages when prog attachment failed) Jesper Dangaard Brouer
2019-02-01 18:47 ` Jakub Kicinski
2019-02-01 21:33 ` Daniel Borkmann
2019-02-01 21:44 ` Jakub Kicinski
2019-02-01 23:14 ` Daniel Borkmann
2019-02-01 7:04 ` [PATCH bpf-next v5 5/8] xdp: Provide extack messages when prog attachment failed Jesper Dangaard Brouer
2019-02-01 0:19 ` [PATCH bpf-next v5 6/8] samples/bpf: Add a "force" flag to XDP samples Maciej Fijalkowski
2019-02-01 0:19 ` [PATCH bpf-next v5 7/8] libbpf: Add a support for getting xdp prog id on ifindex Maciej Fijalkowski
2019-02-01 21:43 ` Daniel Borkmann
2019-02-01 21:47 ` Jakub Kicinski
2019-02-01 23:00 ` Daniel Borkmann
2019-02-01 0:19 ` [PATCH bpf-next v5 8/8] samples/bpf: Check the prog id before exiting Maciej Fijalkowski
2019-02-01 21:23 ` [PATCH bpf-next v5 0/8] xdp: Avoid unloading xdp prog not attached by sample Daniel Borkmann
2019-02-01 21:47 ` Maciej Fijałkowski [this message]
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=20190201224720.3b4a1b5a@maciek-lenovo \
--to=maciejromanfijalkowski@gmail.com \
--cc=ast@kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=jakub.kicinski@netronome.com \
--cc=john.fastabend@gmail.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 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).