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

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Jamal Hadi Salim <jhs@mojatatu.com> writes:

> So while going through this thought process, things to consider:
> 1) The autonomy of the tc infra, essentially the skip_sw/hw  controls
> and their packet driven iteration. Perhaps (the patch i pointed to
> from Paul Blakey) where part of the action graph runs in sw.

Yeah, I agree that mixed-mode operation is an important consideration,
and presumably attaching metadata directly to a packet on the hardware
side, and accessing that in sw, is in scope as well? We seem to have
landed on exposing that sort of thing via kfuncs in XDP, so expanding on
that seems reasonable at a first glance.

> 2) The dynamicity of being able to trigger table offloads and/or
> kernel table updates which are packet driven (consider scenario where
> they have iterated the hardware and ingressed into the kernel).

That could be done by either interface, though: the kernel can propagate
a bpf_map_update() from a BPF program to the hardware version of the
table as well. I suspect a map-based API at least on the BPF side would
be more natural, but I don't really have a strong opinion on this :)

-Toke