[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200325180638.el22n4ms6aau42r4@ast-mbp>
Date: Wed, 25 Mar 2020 11:06:38 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: John Fastabend <john.fastabend@...il.com>,
Toke Høiland-Jørgensen <toke@...hat.com>,
Andrii Nakryiko <andrii.nakryiko@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Andrii Nakryiko <andriin@...com>,
"David S. Miller" <davem@...emloft.net>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Lorenz Bauer <lmb@...udflare.com>,
Andrey Ignatov <rdna@...com>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing
program when attaching XDP
On Tue, Mar 24, 2020 at 07:15:54PM -0700, Jakub Kicinski wrote:
>
> It is the way to configure XDP today, so it's only natural to
> scrutinize the attempts to replace it.
No one is replacing it.
> Also I personally don't think you'd see this much push back trying to
> add bpf_link-based stuff to cls_bpf, that's an add-on. XDP is
> integrated very fundamentally with the networking stack at this point.
>
> > Details are important and every case is different. So imo:
> > converting ethtool to netlink - great stuff.
> > converting netdev irq/queue management to netlink - great stuff too.
> > adding more netlink api for xdp - really bad idea.
>
> Why is it a bad idea?
I explained in three other emails. tldr: lack of ownership.
> There are plenty things which will only be available over netlink.
> Configuring the interface so installing the XDP program is possible
> (disabling features, configuring queues etc.). Chances are user gets
> the ifindex of the interface to attach to over netlink in the first
> place. The queue configuration (which you agree belongs in netlink)
> will definitely get more complex to allow REDIRECTs to work more
> smoothly. AF_XDP needs all sort of netlink stuff.
sure. that has nothing to do with ownership of attachment.
> Netlink gives us the notification mechanism which is how we solve
> coordination across daemons (something that BPF subsystem is only
> now trying to solve).
I don't care about notifications on attachment and no one is trying to
solve that as far as I can see. It's not a problem to solve in the first place.
Powered by blists - more mailing lists