On Tue, Jan 7, 2014 at 1:40 PM, Ben Pfaff <[email protected]> wrote: > On Tue, Jan 07, 2014 at 11:31:43AM -0800, Andy Zhou wrote: > > When vlan-splinter is enabled, ovs receives non-vlan flows from the > > kernel vlan ports, vlan tag is then added to the incoming flow before > > xlating, so that they look like those received from a trunk port. > > > > In case megaflow is enabled, xlating may set vlan masks during rule > > processing as usual. If those vlan masks were serialized and downloaded > > to the kernel (this bug), those mega flows will be rejected due to > > unexpected vlan mask encapsulation, since the original kernel flows do > > not have vlan tags. This bug does not break connectivity, but impacts > > performance since all traffic received on vlan splinter ports will now > > be handled by vswitchd, as no datapath flows can be successfully > > installed. > > > > This fix is to make sure no vlan mask encapsulation is generated for > > the datapath flow if its in_port was re-written by vlan-splinter > > receiving logic. > > > > Bug fixed: 22567 > > > > Signed-off-by: Andy Zhou <[email protected]> > > In the loop that this modifies in handle_upcalls(), multiple 'upcall's > can share the same 'upcall->flow_miss' (if they are in the same > microflow). If the flow is slow-pathed, then I believe that following > this patch the packets after the first one will have the wrong > miss->flow.vlan_tci value (since the code now zeros it). I guess that > we will need to restore the value or to use a copy of it? >
Good catch, will send out v3 to address this.
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
