On Tue, Apr 09, 2019 at 03:36:10PM +0100, John Hurley wrote: > Common use-cases in OvS can produce datapath rules that match on OvS > internal ports. For example, when the endpoint IP address of a VXLAN > tunnel is on the OvS bridge itself, datapath rules may take the form: > > 1. in_port(eth1),actions:set(tunnel(...)),vxlan_sys_4789 > 2. in_port(br0),eth(src=...,dst=...),actions:eth2 > > Here, the first rule outputs to the vxlan port which determines the next > hop to be the OvS bridge. The user-space NORMAL rule can then be used > to form rule 2 that forwards the tunnelled packet to a physical port. > > Similarly, OvS can add rules that redirect to an internal port, e.g.: > > 1. in_port(eth2),eth(src=...,dst=...),actions:br0 > 2. in_port(vxlan_sys_4789),tunnel(...),actions:eth1 > > In this case, tunnelled packets arriving on eth2 are matched on their MAC > addresses and forwarded to internal port br0. As the tunnel endpoint IP > exists here, the packet can be decapped and match on rule 2. > > Currently, rules applied to internal ports are not offloaded to the TC > datapath. This patchset proposes changes to addresses that. > > The implimentation of OvS internal ports in Linux means that if a packet > is sent to them (via a datapath rule) then the packet is redirected > through the network stack as if it had been received on that port. If a > packet egresses an internal port (via its xmit ndo) then packet is passed > back into the OvS datapath with an ingress port set to that of the > internal port. > > To offload rules sending to internal ports as TC filters, the OvS-TC API > is modified to make use of the ingress mirred action. This allows us to > direct packets through the network stack from TC. > > For packets egressing internal ports, OvS-TC is modified to apply and use > egress filters. The start xmit ndo in OvS internal ports pushes packets > into the OvS kernel datapath with ingress set to the given internal port. > This is essentially what happens when packets RX on other ports that have > an OvS bridge as their master. Therefore, applying flower filters to the > egress path of an internal port is akin to the current practice of adding > the filters to the ingress path of non internal ports. > > Once such filters exist in TC, it enables drivers to interpret OvS > internal ports with the potential to offload a representation of them to > harware devices.
Thanks John, I have applied this series to the master branch. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
