XDP seeking input from NIC hardware vendors

Jesper Dangaard Brouer via iovisor-dev
2016-07-07T10:42:45Z

Would it make sense from a hardware point of view, to split the XDP
eBPF program into two stages.

Stage-1: Filter (restricted eBPF / no-helper calls)
Stage-2: Program

Then the HW can choose to offload stage-1 "filter", and keep the
likely more advanced stage-2 on the kernel side. Do HW vendors see a
benefit of this approach?

The generic problem I'm trying to solve is parsing. E.g. that the
first step in every XDP program will be to parse the packet-data,
in-order to determine if this is a packet the XDP program should
process.

Actions from stage-1 "filter" program:
- DROP (like XDP_DROP, early drop)
- PASS (like XDP_PASS, normal netstack)
- MATCH (call stage-2, likely carry-over opaque return code)

The MATCH action should likely carry-over an opaque return code, that
makes sense for the stage-2 program. E.g. proto id and/or data offset.

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer