Re: [PATCH v21 bpf-next 18/23] libbpf: Add SEC name for xdp_mb programs

From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
	"Jesper Dangaard Brouer" <jbrouer@redhat.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Lorenzo Bianconi" <lorenzo.bianconi@redhat.com>,
	"Zvi Effron" <zeffron@riotgames.com>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	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>,
	"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: Fri, 14 Jan 2022 11:35:05 -0800	[thread overview]
Message-ID: <CAEf4BzZFu-5FChGhQrHcu-2kJe-qO6xXCdmGO-L6cViMMmtbYg@mail.gmail.com> (raw)
In-Reply-To: <YeGmZDI6etoB0hKx@lore-desk>

On Fri, Jan 14, 2022 at 8:35 AM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> > On Thu, Jan 13, 2022 at 2:22 AM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > > > > >
> > > > > > 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 :)
> > > >
> > > > I dislike the "mb" abbreviation as I forget it stands for multi-buffer.
> > > > I like the "mbuf" suggestion, even-though it conflicts with (Free)BSD mbufs
> > > > (which is their SKB).
> > >
> > > If we all agree, I can go over the series and substitute mb postfix with mbuf.
> > > Any objections?
> >
> > mbuf has too much bsd taste.
> >
> > How about ".frags" instead?
> > Then xdp_buff_is_mb() will be xdp_buff_has_frags().
> >
> > I agree that it's not obvious what "mb" suffix stands for,
> > but I don't buy at all that it can be confused with "megabyte".
> > It's the context that matters.
> > In "100mb" it's obvious that "mb" is likely "megabyte",
> > but in "xdp.mb" it's certainly not "xdp megabyte".
> > Such a sentence has no meaning.
> > Imagine we used that suffix for "tc"...
> > it would be "tc.mb"... "Traffic Control Megabyte" ??
> >
> > Anyway "xdp.frags" ?
> >
> > Btw "xdp_cpumap" should be cleaned up.
> > xdp_cpumap is an attach type. It's not prog type.
> > Probably it should be "xdp/cpumap" to align with "cgroup/bind[46]" ?
>
> If we change xdp_devmap/ in xdp/devmap (and xdp_cpumap/ in xdp/cpumap),
> are we going to break backward compatibility?
> Maybe there are programs already deployed using it.
> This is not a xdp multi-buff problem since we are not breaking backward
> compatibility there, we can just use:
>
> xdp.frags/devmap
> xdp.frags/cpumap
>
> Moreover in samples/bpf we have something like:
>
> SEC("xdp_devmap/egress")
>
> It seems to me the egress postfix is not really used, right? Can we just drop
> it?

Yeah, by current rules it should be just SEC("xdp_devmap"). This will
break in libbpf 1.0 mode. For anyone who knows how to actually test
BPF samples, it would be great to add
libbpf_set_strict_mode(LIBBPF_STRICT_ALL); in every sample and make
sure everything is still working. We've cleaned up selftests and all
other places I knew about, but missed samples (and I can't test them
properly).

>
> Regards,
> Lorenzo
>
> >
> > In patch 22 there is a comment:
> > /* try to attach BPF_XDP_DEVMAP multi-buff program"
> >
> > It creates further confusion. There is no XDP_DEVMAP program type.
> > It should probably read
> > "Attach BPF_XDP program with frags to devmap"
> >
> > Patch 21 still has "CHECK". Pls replace it with ASSERT.