Re: [PATCH v2.56] datapath: Add basic MPLS support to kernel

[yamamoto-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org (YAMAMOTO Takashi)]

> On Fri, Apr 25, 2014 at 1:06 AM, YAMAMOTO Takashi
> <yamamoto-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org> wrote:
>>> On Thu, Apr 24, 2014 at 05:57:29PM +0900, YAMAMOTO Takashi wrote:
>>>> hi,
>>>>
>>>> > + * Due to the sample action there may be multiple possible eth types.
>>>> > + * In order to correctly validate actions all possible types are tracked
>>>> > + * and verified. This is done using struct eth_types.
>>>>
>>>> is there any real-world use cases of these actions inside a sample?
>>>> otherwise, how about just rejecting such combinations?
>>>> it doesn't seem to worth the code complexity to me.
>>>> (sorry if it has been already discussed.  it's the first time for me
>>>> to seriously read this long-lived patch.)
>>>
>>> Good point, the code is rather complex.
>>>
>>> My understanding is that it comes into effect in the case
>>> of sflow or ipfix being configured on the bridge. I tend
>>> to think these are real-world use-cases, though that thinking
>>> is by no means fixed.
>>>
>>> My reading of the code is that in the case of sflow and ipfix a single
>>> sample rule appears at the beginning of the flow. And that it may be
>>> possible to replace the code that you are referring to with something
>>> simpler to handle these cases.
>>
>> it seems that they put only a userland action inside a sample.
>> it's what i expected from its name "sample".
> 
> Yes, that's the only current use case. In theory, this could be used
> more generally although nothing has come up yet.
> 
> In retrospect, I regret the design of the sample action - not the part
> that allows it to handle different actions but the fact that the
> results can affect things outside of the sample action list. I think
> that if we had made it more like a subroutine then that would have
> retained all of the functionality but none of the complexity here.
> Perhaps if we can find a clean way to restructure it without breaking
> compatibility then that would simplify the validation here.

how about

a. just disallow packet-modifying actions in a sample

or

b. unconditionally restore the packet at the end of sample

or, if you prefer to retain compatibility more,
c. disallow push/pop actions in a sample

given the known use cases, i guess a. is good enough.

YAMAMOTO Takashi

> 
>>>
>>> My understanding is that the code you are referring to also comes into
>>> effect when a sample action (a Nicira extension) is used directly in a
>>> rule.  I am less sure that this is a real-world case but the complex logic
>>> you are referring to should to handle this use-case.
>>
>> probably nicira folks can clarify?
> 
> It's the same set of use cases, just extending it to OpenFlow to
> enable building sampling into different situations.
> _______________________________________________
> dev mailing list
> dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
> http://openvswitch.org/mailman/listinfo/dev