netdev - Re: [RFC bpf-next 0/7] bpf: netdev TX metadata

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKH8qBuLG=k0dF+3X0fM-1vmJ318B-UCzYOpcCYseWW14_w2NA@mail.gmail.com>
Date: Thu, 15 Jun 2023 09:31:19 -0700
From: Stanislav Fomichev <sdf@...gle.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Toke Høiland-Jørgensen <toke@...nel.org>, 
	bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>, 
	John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, 
	Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	Willem de Bruijn <willemb@...gle.com>, David Ahern <dsahern@...nel.org>, 
	"Karlsson, Magnus" <magnus.karlsson@...el.com>, Björn Töpel <bjorn@...nel.org>, 
	"Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>, Network Development <netdev@...r.kernel.org>
Subject: Re: [RFC bpf-next 0/7] bpf: netdev TX metadata

On Thu, Jun 15, 2023 at 9:10 AM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Thu, Jun 15, 2023 at 5:36 AM Toke Høiland-Jørgensen <toke@...nel.org> wrote:
> >
> > Alexei Starovoitov <alexei.starovoitov@...il.com> writes:
> >
> > > On Wed, Jun 14, 2023 at 5:00 AM Toke Høiland-Jørgensen <toke@...nel.org> wrote:
> > >>
> > >> >>
> > >> >> It's probably going to work if each driver has a separate set of tx
> > >> >> fentry points, something like:
> > >> >>   {veth,mlx5,etc}_devtx_submit()
> > >> >>   {veth,mlx5,etc}_devtx_complete()
> > >>
> > >> I really don't get the opposition to exposing proper APIs; as a
> > >> dataplane developer I want to attach a program to an interface. The
> > >> kernel's role is to provide a consistent interface for this, not to
> > >> require users to become driver developers just to get at the required
> > >> details.
> > >
> > > Consistent interface can appear only when there is a consistency
> > > across nic manufacturers.
> > > I'm suggesting to experiment in the most unstable way and
> > > if/when the consistency is discovered then generalize.
> >
> > That would be fine for new experimental HW features, but we're talking
> > about timestamps here: a feature that is already supported by multiple
> > drivers and for which the stack has a working abstraction. There's no
> > reason why we can't have that for the XDP path as well.
>
> ... has an abstraction to receive, but has no mechanism to set it
> selectively per packet and read it on completion.

Timestamp might be a bit of an outlier here where it's just setting
some bit in some existing descriptor.
For some features, the drivers might have to reserve extra descriptors
and I'm not sure how safe it would be to let the programs arbitrarily
mess with the descriptor queues like that.
I'll probably keep this kfunc approach for v2 rfc for now (will try to
get rid of the complicated attachment at least), but let's keep
discussing.