From mboxrd@z Thu Jan 1 00:00:00 1970 From: yamamoto-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org (YAMAMOTO Takashi) Subject: Re: [PATCH v2.56] datapath: Add basic MPLS support to kernel Date: Mon, 28 Apr 2014 11:04:14 +0900 (JST) Message-ID: <20140428020414.F1F7971E58@kuma.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, rkerur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org To: jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org Return-path: In-Reply-To: Your message of "Fri, 25 Apr 2014 12:57:20 -0700" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-yBygre7rU0TnMu66kgdUjQ@public.gmane.org Sender: "dev" List-Id: netdev.vger.kernel.org > On Fri, Apr 25, 2014 at 1:06 AM, YAMAMOTO Takashi > 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