netdev - Re: [PATCH net-next RFC 00/20] Introducing P4TC

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAM0EoMkR0+5YHwnrJ_TnW53MAfTC2Y9Wq0WFcEWTq3V=P0OzAg@mail.gmail.com>
Date:   Tue, 31 Jan 2023 05:27:53 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     John Fastabend <john.fastabend@...il.com>,
        "Singhai, Anjali" <anjali.singhai@...el.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Jamal Hadi Salim <hadi@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Willem de Bruijn <willemb@...gle.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "kernel@...atatu.com" <kernel@...atatu.com>,
        "Chatterjee, Deb" <deb.chatterjee@...el.com>,
        "Limaye, Namrata" <namrata.limaye@...el.com>,
        "khalidm@...dia.com" <khalidm@...dia.com>,
        "tom@...anda.io" <tom@...anda.io>,
        "pratyush@...anda.io" <pratyush@...anda.io>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "vladbu@...dia.com" <vladbu@...dia.com>,
        "simon.horman@...igine.com" <simon.horman@...igine.com>,
        "stefanc@...vell.com" <stefanc@...vell.com>,
        "seong.kim@....com" <seong.kim@....com>,
        "mattyk@...dia.com" <mattyk@...dia.com>,
        "Daly, Dan" <dan.daly@...el.com>,
        "Fingerhut, John Andy" <john.andy.fingerhut@...el.com>
Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC

On Mon, Jan 30, 2023 at 11:12 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Mon, 30 Jan 2023 19:26:05 -0500 Jamal Hadi Salim wrote:
> > > Didn't see this as it was top posted but, the answer is you don't program
> > > hardware the ebpf when your underlying target is a MAT.
> > >
> > > Use devlink for the runtime programming as well, its there to program
> > > hardware. This "Devlink is NOT for the runtime programming" is
> > > just an artificate of the design here which I disagree with and it feels
> > > like many other folks also disagree.
> >
> > We are going to need strong justification to use devlink for
> > programming the binary interface to begin with
>
> We may disagree on direction, but we should agree status quo / reality.
>
> What John described is what we suggested to Intel to do (2+ years ago),
> and what is already implemented upstream. Grep for DDP.
>

I went back and looked at the email threads - I hope i got the right
one from 2020.

Note, there are two paths in P4TC:
DDP loading via devlink is equivalent to loading the P4 binary for the hardware.
That is one of the 3 (and currently most popular) driver interfaces
suggested. Some of that drew
Second is runtime which is via standard TC. John's proposal is
equivalent to suggesting moving the flower interface Devlink. That is
not the same as loading the config.

> IIRC my opinion back then was that unless kernel has any use for
> whatever the configuration exposes - we should stay out of it.

It does for runtime and the tc infra already takes care of that. The
cover letter says:

"...one can be more explicit and specify "skip_sw" or "skip_hw" to either
offload the entry (if a NIC or switch driver is capable) or make it purely run
entirely in the kernel or in a cooperative mode between kernel and user space."

cheers,
jamal