Thread (7 messages) flat view 7 messages, 3 authors, 2021-09-26

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

From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: 2021-09-26 15:54:44

On 2021-09-23 11:55 p.m., John Fastabend wrote:
Jamal Hadi Salim wrote:
[..]
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help