[ovs-dev] [PATCH 3/3] datapath: Add basic MPLS support to kernel

[Rajahalme, Jarno (NSN - FI/Espoo)]

On Mar 9, 2013, at 16:54 , ext Simon Horman wrote:

> On Thu, Mar 07, 2013 at 11:12:31AM -0800, Ben Pfaff wrote:
>> On Thu, Mar 07, 2013 at 04:12:22AM +0100, Simon Horman wrote:
>>> Perhaps Ben has some ideas, but it seems to me that the
>>> way that execute_* and compose_* interact needs to be changed
>>> around in order to preserve the order of actions.
>> 
>> This seems likely to be necessary.
> 
> Hi,
> 
> I have taken a look into changing things around to preserve the order
> of actions, however, I think there is a problem.
> 
> My reading of compose_output_action__() is that if a flow outputs to more
> than one port, is for an IP frame and get_priority() calls return different
> values for different ports then set_ipv4 or set_ipv6 action may be added
> between output actions.
> 
> The behaviour above seems problematic as the motivation for preserving the
> order of actions was to avoid the case where an action that needs l3+ data
> occurs after a push_mpls action. This would allow an skb's network header
> to be used to track the top of the MPLS stack in the kernel datapath.
> 
> It is not obvious to me how the behaviour relating to get_priority() as
> described above can sensibly be reconciled with a desire to preserve the
> order of actions. Or even reconciled with a looser constraint that actions
> that need l3+ data occur before push_mpls actions.

Simon,

Maybe not a solution yet, but a thought at least:

Kernel datapath clones the skb for each but the last output action. This, as such, does not help your problem, but hints at a potential solution, as each skb has its own set of layer pointers.  The current semantics is that all actions accumulate on the packet, and are hence performed on the original skb (the new clone is given to the do_output()). However, it might be possible to clone the skb earlier, and then perform the L2.5 (and L2 ?) actions on the cloned skb, keeping the original skb for the forthcoming actions after the output. This would be a change to the current action semantics, and would require repeating all L2.5 and L2 actions for each of the multiple outputs, but this change in semantics would remove the need for any L3 actions on an skb after MPLS actions.

To be efficient on the kernel datapath, this may require additional support from the userspace to avoid unnecessary cloning for the last output action. This could perhaps be accomplished with an explicit CLONE action with the semantics that all forthcoming actions, up to the next output action, are to performed on the clone, which is then consumed by the output action, and the rest of the actions would then be performed on the original skb. Userspace would then emit such a CLONE action in a suitable place (e.g. after all L3 actions are done) for all but the last output action.

What is nice about this is that the userspace would be in total command of the semantics of action accumulation on the packet (steered by the placement of CLONEs) actions; the current semantics would be accomplished without any CLONE actions, which would be backwards compatible.

Alternatively, the kernel datapath could itself analyze the actions (e.g., at the time of validation) and then decide ahead of time when and where it needs to clone the skb to maintain intended semantics, but here the semantics needs to be set in stone and backwards compatibility might be an issue.

  Jarno