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 <b...@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 <et...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
