netdev - Re: [PATCH RFC net-next 0/2] net:sched: Introduce tc flower2 classifier based on PANDA parser in kernel

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] [day] [month] [year] [list]

Message-ID: <1268af91-11c9-2fad-b04e-bf1fb220468b@mojatatu.com>
Date:   Sun, 26 Sep 2021 11:54:38 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     John Fastabend <john.fastabend@...il.com>,
        Tom Herbert <tom@...anda.io>
Cc:     Simon Horman <simon.horman@...igine.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Felipe Magno de Almeida <felipe@...anda.io>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Boris Sukholitko <boris.sukholitko@...adcom.com>,
        Vadym Kochan <vadym.kochan@...ision.eu>,
        Ilya Lifshits <ilya.lifshits@...adcom.com>,
        Vlad Buslov <vladbu@...dia.com>,
        Ido Schimmel <idosch@...sch.org>, paulb@...dia.com,
        Davide Caratti <dcaratti@...hat.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Amritha Nambiar <amritha.nambiar@...el.com>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        Pedro Tammela <pctammela@...atatu.com>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH RFC net-next 0/2] net:sched: Introduce tc flower2
 classifier based on PANDA parser in kernel

On 2021-09-23 11:55 p.m., John Fastabend wrote:
> Jamal Hadi Salim wrote:

[..]

> 
>> Generally:
>> BPF is good for specific smaller parsing tasks; the ebpf flow dissector
>> hook should be trivial to add to PANDA. And despite PANDA being able
>> to generate EBPF - I would still say it depends on the depth of the
>> parse tree to be sensible to use eBPF.
> 
> Going to disagree. I'm fairly confident we could write a BPF
> program to do the flow disection. Anyways we can always improve
> the verifier as needed and this helps lots of things not
> just this bit. Also flow dissector will be loaded once at early
> boot most likely so we can allow it to take a bit longer or
> pre-verify it. Just ideas.
> 

With current status quo, it is challenging to achieve that
goal. Challenge is complexity and not so much instruction count.
In particular: If you include the parser as part of your eBPF
program you will reduce the amount of what the rest of your program
can do; depending how big the parse tree is, you may have no space
left at all for extra logic (even with tailcalls etc).

Changes to the eBPF core + verifier will certainly help - but
that remains to be seen. Hopefully the next patch set Felipe posts
would also have PANDA output for eBPF - then lets see what magic
you say can be added on top ;->

Note: I am not against ebpf, just where the fit is needs discussion.
For h/w interfacing, thats a totally different ballgame altogether
(tc is a good fit).

cheers,
jamal