[ovs-dev] [vlan-splinter megaflow fix v2] ofproto-dpif: Fix vlan-splinter megaflow bug

Andy Zhou azhou at nicira.com
Tue Jan 7 22:55:25 UTC 2014


On Tue, Jan 7, 2014 at 1:40 PM, Ben Pfaff <blp at nicira.com> 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 <azhou at nicira.com>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140107/e2cea72f/attachment-0003.html>


More information about the dev mailing list