I would like to confirm that Thomas's use case is key also for the BGP/MPLS VPN implementation in Open Daylight. In our case OVS is forwarding MPLSoGRE encapsulated L3 VPN traffic from physical ports as IP packets to VMs on vhost-user ports.
Even without the additional recirculation after pop_mpls, the throughput of the DPDK datapath in OVS 2.5 for incoming traffic from the GRE tunnel is less than half of the performance for outgoing traffic to the GRE tunnel. The additional, unnecessary recirculation will shift that imbalance further. We would be very happy to help finding a satisfactory way of implementing a logic to insert recirculation only when needed. /Jan > 2016-02-26, Thomas Morin: > > > > mpls,in_port=1,mpls_label=200,mpls_bos=1 > > actions=pop_mpls:0x0800,mod_dl_src:5a:19:2a:49:c1:ee,mod_dl_dst:fa:16: > > 3e:2f:82:b0,output:220 > > > > 220 being a patchport, a veth or a tap interface. > > For the sake of illustrating that this is a use case to consider, this kind > of action > (with a physical port) is very typical of what a router implementing BGP/MPLS > VPNSs (RFC4364) will do to send traffic to a customer site. > > Implementations of BGP/MPLS VPNs that implement that in the vswitch (e.g. > OpenContrail, bagpipe-bgp, to name opensource ones) may want to do that as > well. > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
