Re: [RFC PATCH bpf-next 00/14] xdp_flow: Flow offload to XDP

[Toshiaki Makita]

On 2019/08/16 0:46, William Tu wrote:

On Tue, Aug 13, 2019 at 5:07 AM Toshiaki Makita
<toshiaki.maki...@gmail.com> wrote:

This is a rough PoC for an idea to offload TC flower to XDP.


* Motivation

The purpose is to speed up software TC flower by using XDP.

I chose TC flower because my current interest is in OVS. OVS uses TC to
offload flow tables to hardware, so if TC can offload flows to XDP, OVS
also can be offloaded to XDP.

When TC flower filter is offloaded to XDP, the received packets are
handled by XDP first, and if their protocol or something is not
supported by the eBPF program, the program returns XDP_PASS and packets
are passed to upper layer TC.

The packet processing flow will be like this when this mechanism,
xdp_flow, is used with OVS.

  +-------------+
  | openvswitch |
  |    kmod     |
  +-------------+
         ^
         | if not match in filters (flow key or action not supported by TC)
  +-------------+
  |  TC flower  |
  +-------------+
         ^
         | if not match in flow tables (flow key or action not supported by XDP)
  +-------------+
  |  XDP prog   |
  +-------------+
         ^
         | incoming packets

I like this idea, some comments about the OVS AF_XDP work.

Another way when using OVS AF_XDP is to serve as slow path of TC flow
HW offload.
For example:

  Userspace OVS datapath (The one used by OVS-DPDK)
      ^
       |
   +------------------------------+
   |  OVS AF_XDP netdev |
   +------------------------------+
          ^
          | if not supported or not match in flow tables
   +---------------------+
   |  TC HW flower  |
   +---------------------+
          ^
          | incoming packets

So in this case it's either TC HW flower offload, or the userspace PMD OVS.
Both cases should be pretty fast.

I think xdp_flow can also be used by OVS AF_XDP netdev, sitting between
TC HW flower and OVS AF_XDP netdev.
Before the XDP program sending packet to AF_XDP socket, the
xdp_flow can execute first, and if not match, then send to AF_XDP.
So in your patch set, implement s.t like
   bpf_redirect_map(&xsks_map, index, 0);

Thanks, the concept sounds good but this is probably difficult as long as
this is a TC offload, which is emulating TC.
If I changed the direction and implement offload in ovs-vswitchd, it would
be possible. I'll remember this optimization.

Another thing is that at each layer we are doing its own packet parsing.
 From your graph, first parse at XDP program, then at TC flow, then at
openvswitch kmod.
I wonder if we can reuse some parsing result.

That would be nice if possible...
Currently I don't have any ideas to do that. Someday XDP may support more
metadata for this or HW-offload like checksum. Then we can store the information
and upper layers may be able to use that.

Toshiaki Makita