[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM0EoMmGxQGA8LXWvRvgPHZd80r2mv6SB8P79v47tkbWhx7SXg@mail.gmail.com>
Date: Fri, 5 Apr 2024 13:14:31 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Network Development <netdev@...r.kernel.org>, deb.chatterjee@...el.com,
Anjali Singhai Jain <anjali.singhai@...el.com>, namrata.limaye@...el.com, tom@...anda.io,
Marcelo Ricardo Leitner <mleitner@...hat.com>, Mahesh.Shirshyad@....com, Vipin.Jain@....com,
tomasz.osinski@...el.com, Jiri Pirko <jiri@...nulli.us>,
Cong Wang <xiyou.wangcong@...il.com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Vlad Buslov <vladbu@...dia.com>, Simon Horman <horms@...nel.org>, khalidm@...dia.com,
Toke Høiland-Jørgensen <toke@...hat.com>,
Martin KaFai Lau <martin.lau@...ux.dev>, victor@...atatu.com,
Pedro Tammela <pctammela@...atatu.com>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH net-next v14 14/15] p4tc: add set of P4TC table kfuncs
On Fri, Apr 5, 2024 at 11:51 AM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> On 4/5/24 1:16 AM, Jamal Hadi Salim wrote:
> > On Thu, Apr 4, 2024 at 7:05 PM Alexei Starovoitov
> > <alexei.starovoitov@...il.com> wrote:
> >> On Thu, Apr 4, 2024 at 3:59 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >>>
> >>> We will use ebpf/xdp/kfuncs whenever they make sense to us.
> >>
> >> In such case my Nack stands even if you drop this patch.
> >
> > We are not changing any ebpf code. I must have missed the memo that
> > stated you can control how people write or use ebpf.
> > The situation is this: Anybody can write kfuncs today. They can put
> > them in kernel modules - i am sure you designed it with that intent.
> > So what exactly are you objecting to that is ebpf related here?
>
> To be honest, this entire patchset is questionable from a design pov for
> the many reasons stated by various folks (including tc co-maintainers) in
> all the earlier discussions, but related to the BPF bits if someone else
> were trying to propose an interface on kfuncs which replicate to a larger
> extend BPF map APIs, the feedback would be similarly in that this should
> be attempted to generalize instead so that this is useful as a building
> block, esp given the goal is on SW datapath and not offloads, and the
> context specific pieces would reside in the p4tc code.
"questionable from a design pov" is the crux of the back and forth.
You have to live in a world where other people have different design
Povs, different use cases. You are imposing on us how it should be
done and according to you guys just because it runs in tc it is
inferior. In open source you work on your itches - many use cases and
many designs. Given history on how far we bent over to try and reach a
compromise i have concluded we'll never satisfy you.
100% of the code is in the tc domain. It is touching zero of the ebpf code.
We are using kfuncs the way they are intended. You are not going to
stop people using kfuncs the way we did. Giving us advice on how to
better kfuncs is reasonable. Martin did that and we fixed those
issues. Trying to dictate whether we can use kfuncs or not is crossing
the line in particular given that you have said many times that kfuncs
dont even have to be even posted on the bpf mailing list. And i am not
going to relitigate some of the statements you made above that we have
rehashed many times. Read the cover letter.
cheers,
jamal
Powered by blists - more mailing lists