All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	Zvi Effron <zeffron@riotgames.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Lorenzo Bianconi <lorenzo@kernel.org>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Shay Agroskin <shayagr@amazon.com>,
	john fastabend <john.fastabend@gmail.com>,
	David Ahern <dsahern@kernel.org>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Eelco Chaudron <echaudro@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	Saeed Mahameed <saeed@kernel.org>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Magnus Karlsson <magnus.karlsson@intel.com>,
	tirthendu.sarkar@intel.com
Subject: Re: [PATCH v21 bpf-next 18/23] libbpf: Add SEC name for xdp_mb programs
Date: Wed, 12 Jan 2022 23:04:55 +0100	[thread overview]
Message-ID: <8735lshapk.fsf@toke.dk> (raw)
In-Reply-To: <Yd82J8vxSAR9tvQt@lore-desk>

Lorenzo Bianconi <lorenzo.bianconi@redhat.com> writes:

>> On Wed, Jan 12, 2022 at 11:47 AM Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>> >
>> > On Wed, Jan 12, 2022 at 11:21 AM Andrii Nakryiko
>> > <andrii.nakryiko@gmail.com> wrote:
>> > >
>> > > On Wed, Jan 12, 2022 at 11:17 AM Alexei Starovoitov
>> > > <alexei.starovoitov@gmail.com> wrote:
>> > > >
>> > > > On Wed, Jan 12, 2022 at 10:24 AM Andrii Nakryiko
>> > > > <andrii.nakryiko@gmail.com> wrote:
>> > > > >
>> > > > > On Wed, Jan 12, 2022 at 10:18 AM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>> > > > > >
>> > > > > > > On Sun, Jan 9, 2022 at 7:05 AM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>> > > > > > > >
>> > > > > > > > Introduce support for the following SEC entries for XDP multi-buff
>> > > > > > > > property:
>> > > > > > > > - SEC("xdp_mb/")
>> > > > > > > > - SEC("xdp_devmap_mb/")
>> > > > > > > > - SEC("xdp_cpumap_mb/")
>> > > > > > >
>> > > > > > > Libbpf seemed to went with .<suffix> rule (e.g., fentry.s for
>> > > > > > > sleepable, seems like we'll have kprobe.multi or  something along
>> > > > > > > those lines as well), so let's stay consistent and call this "xdp_mb",
>> > > > > > > "xdp_devmap.mb", "xdp_cpumap.mb" (btw, is "mb" really all that
>> > > > > > > recognizable? would ".multibuf" be too verbose?). Also, why the "/"
>> > > > > > > part? Also it shouldn't be "sloppy" either. Neither expected attach
>> > > > > > > type should be optional.  Also not sure SEC_ATTACHABLE is needed. So
>> > > > > > > at most it should be SEC_XDP_MB, probably.
>> > > > > >
>> > > > > > ack, I fine with it. Something like:
>> > > > > >
>> > > > > >         SEC_DEF("lsm.s/",               LSM, BPF_LSM_MAC, SEC_ATTACH_BTF | SEC_SLEEPABLE, attach_lsm),
>> > > > > >         SEC_DEF("iter/",                TRACING, BPF_TRACE_ITER, SEC_ATTACH_BTF, attach_iter),
>> > > > > >         SEC_DEF("syscall",              SYSCALL, 0, SEC_SLEEPABLE),
>> > > > > > +       SEC_DEF("xdp_devmap.multibuf",  XDP, BPF_XDP_DEVMAP, 0),
>> > > > > >         SEC_DEF("xdp_devmap/",          XDP, BPF_XDP_DEVMAP, SEC_ATTACHABLE),
>> > > > > > +       SEC_DEF("xdp_cpumap.multibuf",  XDP, BPF_XDP_CPUMAP, 0),
>> > > > > >         SEC_DEF("xdp_cpumap/",          XDP, BPF_XDP_CPUMAP, SEC_ATTACHABLE),
>> > > > > > +       SEC_DEF("xdp.multibuf",         XDP, BPF_XDP, 0),
>> > > > >
>> > > > > yep, but please use SEC_NONE instead of zero
>> > > > >
>> > > > > >         SEC_DEF("xdp",                  XDP, BPF_XDP, SEC_ATTACHABLE_OPT | SEC_SLOPPY_PFX),
>> > > > > >         SEC_DEF("perf_event",           PERF_EVENT, 0, SEC_NONE | SEC_SLOPPY_PFX),
>> > > > > >         SEC_DEF("lwt_in",               LWT_IN, 0, SEC_NONE | SEC_SLOPPY_PFX),
>> > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > Acked-by: Toke Hoiland-Jorgensen <toke@redhat.com>
>> > > > > > > > Acked-by: John Fastabend <john.fastabend@gmail.com>
>> > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> > > > > > > > ---
>> > > > > > > >  tools/lib/bpf/libbpf.c | 8 ++++++++
>> > > > > > > >  1 file changed, 8 insertions(+)
>> > > > > > > >
>> > > > > > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> > > > > > > > index 7f10dd501a52..c93f6afef96c 100644
>> > > > > > > > --- a/tools/lib/bpf/libbpf.c
>> > > > > > > > +++ b/tools/lib/bpf/libbpf.c
>> > > > > > > > @@ -235,6 +235,8 @@ enum sec_def_flags {
>> > > > > > > >         SEC_SLEEPABLE = 8,
>> > > > > > > >         /* allow non-strict prefix matching */
>> > > > > > > >         SEC_SLOPPY_PFX = 16,
>> > > > > > > > +       /* BPF program support XDP multi-buff */
>> > > > > > > > +       SEC_XDP_MB = 32,
>> > > > > > > >  };
>> > > > > > > >
>> > > > > > > >  struct bpf_sec_def {
>> > > > > > > > @@ -6562,6 +6564,9 @@ static int libbpf_preload_prog(struct bpf_program *prog,
>> > > > > > > >         if (def & SEC_SLEEPABLE)
>> > > > > > > >                 opts->prog_flags |= BPF_F_SLEEPABLE;
>> > > > > > > >
>> > > > > > > > +       if (prog->type == BPF_PROG_TYPE_XDP && (def & SEC_XDP_MB))
>> > > > > > > > +               opts->prog_flags |= BPF_F_XDP_MB;
>> > > > > > >
>> > > > > > > I'd say you don't even need SEC_XDP_MB flag at all, you can just check
>> > > > > > > that prog->sec_name is one of "xdp.mb", "xdp_devmap.mb" or
>> > > > > > > "xdp_cpumap.mb" and add the flag. SEC_XDP_MB doesn't seem generic
>> > > > > > > enough to warrant a flag.
>> > > > > >
>> > > > > > ack, something like:
>> > > > > >
>> > > > > > +       if (prog->type == BPF_PROG_TYPE_XDP &&
>> > > > > > +           (!strcmp(prog->sec_name, "xdp_devmap.multibuf") ||
>> > > > > > +            !strcmp(prog->sec_name, "xdp_cpumap.multibuf") ||
>> > > > > > +            !strcmp(prog->sec_name, "xdp.multibuf")))
>> > > > > > +               opts->prog_flags |= BPF_F_XDP_MB;
>> > > > >
>> > > > > yep, can also simplify it a bit with strstr(prog->sec_name,
>> > > > > ".multibuf") instead of three strcmp
>> > > >
>> > > > Maybe ".mb" ?
>> > > > ".multibuf" is too verbose.
>> > > > We're fine with ".s" for sleepable :)
>> > >
>> > >
>> > > I had reservations about "mb" because the first and strong association
>> > > is "megabyte", not "multibuf". And it's not like anyone would have
>> > > tens of those programs in a single file so that ".multibuf" becomes
>> > > way too verbose. But I don't feel too strongly about this, if the
>> > > consensus is on ".mb".
>> >
>> > The rest of the patches are using _mb everywhere.
>> > I would keep libbpf consistent.
>> 
>> Should the rest of the patches maybe use "multibuf" instead of "mb"? I've been
>> following this patch series closely and excitedly, and I keep having to remind
>> myself that "mb" is "multibuff" and not "megabyte". If I'm having to correct
>> myself while following the patch series, I'm wondering if future confusion is
>> inevitable?
>> 
>> But, is it enough confusion to be worth updating many other patches? I'm not
>> sure.
>> 
>> I agree consistency is more important than the specific term we're consistent
>> on.
>
> I would prefer to keep the "_mb" postfix, but naming is hard and I am
> polarized :)

I would lean towards keeping _mb as well, but if it does have to be
changed why not _mbuf? At least that's not quite as verbose :)

-Toke


  reply	other threads:[~2022-01-12 22:05 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-08 11:53 [PATCH v21 bpf-next 00/23] mvneta: introduce XDP multi-buffer support Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 01/23] net: skbuff: add size metadata to skb_shared_info for xdp Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 02/23] xdp: introduce flags field in xdp_buff/xdp_frame Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 03/23] net: mvneta: update mb bit before passing the xdp buffer to eBPF layer Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 04/23] net: mvneta: simplify mvneta_swbm_add_rx_fragment management Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 05/23] net: xdp: add xdp_update_skb_shared_info utility routine Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 06/23] net: marvell: rely on " Lorenzo Bianconi
2022-01-10 16:37   ` Andy Gospodarek
2022-01-11 13:05     ` Lorenzo Bianconi
2022-01-11 14:29       ` Andy Gospodarek
2022-01-08 11:53 ` [PATCH v21 bpf-next 07/23] xdp: add multi-buff support to xdp_return_{buff/frame} Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 08/23] net: mvneta: add multi buffer support to XDP_TX Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 09/23] bpf: introduce BPF_F_XDP_MB flag in prog_flags loading the ebpf program Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 10/23] net: mvneta: enable jumbo frames if the loaded XDP program support mb Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 11/23] bpf: introduce bpf_xdp_get_buff_len helper Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 12/23] bpf: add multi-buff support to the bpf_xdp_adjust_tail() API Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 13/23] bpf: add multi-buffer support to xdp copy helpers Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 14/23] bpf: move user_size out of bpf_test_init Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 15/23] bpf: introduce multibuff support to bpf_prog_test_run_xdp() Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 16/23] bpf: test_run: add xdp_shared_info pointer in bpf_test_finish signature Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 17/23] bpf: selftests: update xdp_adjust_tail selftest to include multi-buffer Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 18/23] libbpf: Add SEC name for xdp_mb programs Lorenzo Bianconi
2022-01-10  2:16   ` Andrii Nakryiko
2022-01-12 18:17     ` Lorenzo Bianconi
2022-01-12 18:24       ` Andrii Nakryiko
2022-01-12 18:35         ` Lorenzo Bianconi
2022-01-12 19:16         ` Alexei Starovoitov
2022-01-12 19:20           ` Andrii Nakryiko
2022-01-12 19:47             ` Alexei Starovoitov
2022-01-12 20:04               ` Zvi Effron
2022-01-12 20:12                 ` Lorenzo Bianconi
2022-01-12 22:04                   ` Toke Høiland-Jørgensen [this message]
2022-01-13  9:38                     ` Jesper Dangaard Brouer
2022-01-13 10:22                       ` Lorenzo Bianconi
2022-01-13 20:19                         ` Alexei Starovoitov
2022-01-13 23:58                           ` Lorenzo Bianconi
2022-01-14  2:09                             ` Alexei Starovoitov
2022-01-14 16:50                               ` Jesper Dangaard Brouer
2022-01-14 18:55                                 ` Zvi Effron
2022-01-14 19:36                                   ` Andrii Nakryiko
2022-01-26 16:11                                     ` Lorenzo Bianconi
2022-01-26 20:12                                       ` Andrii Nakryiko
2022-01-14 16:35                           ` Lorenzo Bianconi
2022-01-14 19:35                             ` Andrii Nakryiko
2022-01-08 11:53 ` [PATCH v21 bpf-next 19/23] bpf: generalise tail call map compatibility check Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 20/23] net: xdp: introduce bpf_xdp_pointer utility routine Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 21/23] bpf: selftests: introduce bpf_xdp_{load,store}_bytes selftest Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 22/23] bpf: selftests: add CPUMAP/DEVMAP selftests for xdp multi-buff Lorenzo Bianconi
2022-01-08 11:53 ` [PATCH v21 bpf-next 23/23] xdp: disable XDP_REDIRECT " Lorenzo Bianconi
2022-01-12 18:55 ` [PATCH v21 bpf-next 00/23] mvneta: introduce XDP multi-buffer support Lorenzo Bianconi

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=8735lshapk.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=echaudro@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=lorenzo@kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeed@kernel.org \
    --cc=shayagr@amazon.com \
    --cc=tirthendu.sarkar@intel.com \
    --cc=zeffron@riotgames.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.