On 19/10/23 (水) 23:11:25, Jamal Hadi Salim wrote:

Sorry - didnt read every detail of this thread so i may
be missing something.

On 2019-10-22 12:54 p.m., John Fastabend wrote:

quoted

Toshiaki Makita wrote:

quoted

On 2019/10/19 0:22, John Fastabend wrote:

quoted

Toshiaki Makita wrote:

quoted

This is a PoC for an idea to offload flow, i.e. TC flower and 
nftables,
to XDP.

quoted

I don't know who this "someone" is that wants to use XDP through TC
flower or nftables transparently. TC at least is not known for a
great uapi. 

The uapi is netlink. You may be talking about lack of a friendly
application library that abstracts out concepts?

quoted

It seems to me that it would be a relatively small project
to write a uapi that ran on top of a canned XDP program to add
flow rules. This could match tc cli if you wanted but why not take
the opportunity to write a UAPI that does flow management well.

Disagreement:
Unfortunately legacy utilities and apps cant just be magically wished
away. There's a lot of value in transparently making them work with
new infrastructure. My usual exaggerated pitch: 1000 books have been
written on this stuff, 100K people have RH certificates which entitle
them to be "experts"; dinasour kernels exist in data centres and
(/giggle) "enteprise". You cant just ignore all that.

Summary: there is value in what Toshiaki is doing.

I am disappointed that given a flexible canvas like XDP, we are still
going after something like flower... if someone was using u32 as the
abstraction it will justify it a lot more in my mind.
Tying it to OVS as well is not doing it justice.

Flexibility is good for the time when very complicated or unusual flow 
handling is needed. OTOH, good flexibility often sacrifices good 
usability IMO. Configuration tends to be difficult.

What I want to do here is to make XDP easy for sysadmins for typical 
use-cases. u32 is good for flexibility, but to me flower is easier to 
use. Using flower fits better in my intention.

Agreement:
Having said that I dont think that flower/OVS should be the interface
that XDP should be aware of. Neither do i agree that kernel "real
estate" should belong to Oneway(TM) of doing things (we are still stuck
with netfilter planting the columbus flag on all networking hooks).
Let 1000 flowers bloom.
So: couldnt Toshiaki's requirement be met with writting a user space
daemon that trampolines flower to "XDP format" flow transforms? That way
in the future someone could add a u32->XDP format flow definition and we
are not doomed to forever just use flower.

Userspace daemon is possible. Do you mean adding notification points in 
TC and listen filter modification events from userspace? If so, I'm not 
so positive about this, as it seems difficult to emulate TC/kernel 
behavior from userspace.
Note that I think u32 offload can be added in the future even with 
current xdp_flow implementation.

Toshiaki Makita