[ovs-dev] [DPDK Upcalls 07/11] xlate: Handle VLAN splinters in xlate_actions().

[Ben Pfaff]

I'd be happy with that solution.

It would actually be really awesome if we could somehow encapsulate
*all* of the splinters behavior right inside dpif-linux, but I'm not
sure that's practical.

On Tue, Aug 05, 2014 at 02:35:55PM -0700, Ethan Jackson wrote:
> Basically I want the packet passed into the upcall callback to be
> "const" so I have some guarantee that it's not modified in a way that
> will confuse the datapath.  Unlike in the standard linux datapath,
> we're dealing with the actual packet, not a copy, so modifications
> could have some rather surprising results.
> 
> Perhaps a compromise solution would be to pull the VLAN splinters
> handling out of xlate_recieve(), and only call it in the dpif-linux
> case, not in the dpif-netdev callback case.
> 
> Thoughts?
> Ethan
> 
> On Tue, Aug 5, 2014 at 1:31 PM, Ben Pfaff <blp at nicira.com> wrote:
> > On Fri, Aug 01, 2014 at 06:39:18PM -0700, Ethan Jackson wrote:
> >> I find this quite a bit simpler to reason about.  Also, future patches
> >> require xlate_actions() not to modify the packet.
> >>
> >> Signed-off-by: Ethan Jackson <ethan at nicira.com>
> >
> > This actually make xlate_actions() modify the packet more than before,
> > although it does change it back.  Did you mean that future patches
> > require xlate_receive() not to modify the packet?
> >
> > The reason that we do this in xlate_receive() is basically the
> > end-to-end principle: if we add the VLAN header as early as possible,
> > then it means that nothing else in userspace has to know that the
> > packet and the flow aren't really correct.  If we do it later on, we
> > have to audit everything between xlate_receive() and xlate_actions()
> > to make sure that it doesn't depend on vlan_tci or whether there's a
> > VLAN header in the packet.  That's hard to do (did you do it?), and if
> > you get it wrong in a corner case we probably won't find out for a
> > long time because very few installations need the VLAN splinters
> > feature.