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

Ethan Jackson ethan at nicira.com
Tue Aug 5 21:35:55 UTC 2014

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.


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.

More information about the dev mailing list