[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-netdev
Subject:    Re: [PATCH net-next RFC 00/20] Introducing P4TC
From:       Jamal Hadi Salim <jhs () mojatatu ! com>
Date:       2023-01-31 23:31:00
Message-ID: CAM0EoM=qeA1zO-FZNjppzc9V7i3dScCT5rFXbqL=ERcnCuZxfA () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jan 31, 2023 at 5:54 PM Toke H=C3=B8iland-J=C3=B8rgensen <toke@redh=
at.com> wrote:
>
> 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.

There is  built-in metadata chain id/prio/protocol (stored in cls
common struct) passed when the policy is installed. The hardware may
be able to handle received (probably packet encapsulated, but i
believe that is vendor specific) metadata and transform it into the
appropriate continuation point. Maybe a simpler example is to look at
the patch from Paul (since that is the most recent change, so it is
sticking in my brain); if you can follow the example,  you'll see
there's some state that is transferred for the action with a cookie
from/to the driver.

> > 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 :)

Should have mentioned this earlier as requirement:
Speed of update is _extremely_ important, i.e how fast you can update
could make or break things; see talk from Marcelo/Vlad[1]. My gut
feeling is dealing with feedback from some vendor firmware/driver
interface that the entry is really offloaded may cause challenges for
ebpf by stalling the program. We have seen upto several ms delays on
occasions.

cheers,
jamal
[1] https://netdevconf.info/0x15/session.html?Where-turbo-boosting-TC-flowe=
r-control-path-had-led-us-to
[prev in list] [next in list] [prev in thread] [next in thread]