On 10/27/19 9:21 AM, Toke Høiland-Jørgensen wrote: > Rather, what we should be doing is exposing the functionality through > helpers so XDP can hook into the data structures already present in the > kernel and make decisions based on what is contained there. We already > have that for routing; L2 bridging, and some kind of connection > tracking, are obvious contenders for similar additions. The way OVS is coded and expected to flow (ovs_vport_receive -> ovs_dp_process_packet -> ovs_execute_actions -> do_execute_actions) I do not see any way to refactor it to expose a hook to XDP. But, if the use case is not doing anything big with OVS (e.g., just ACLs and forwarding) that is easy to replicate in XDP - but then that means duplicate data and code. Linux bridge on the other hand seems fairly straightforward to refactor. One helper is needed to convert ingress <port,mac,vlan> to an L2 device (and needs to consider stacked devices) and then a second one to access the fdb for that device. Either way, bypassing the bridge has mixed results: latency improves but throughput takes a hit (no GRO).
