[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 14 Oct 2014 06:54:47 +0200
From: Simon Horman <horms@...ge.net.au>
To: Ben Pfaff <blp@...ira.com>
Cc: Simon Horman <simon.horman@...ronome.com>, dev@...nvswitch.org,
netdev@...r.kernel.org
Subject: Re: [ovs-dev] [PATCH/RFC repost 7/8] ofproto: translate datapath
select group action
On Mon, Oct 13, 2014 at 01:46:24PM -0700, Ben Pfaff wrote:
> On Thu, Oct 09, 2014 at 10:14:36AM +0900, Simon Horman wrote:
> > On Fri, Sep 26, 2014 at 04:57:25PM -0700, Ben Pfaff wrote:
> > > On Thu, Sep 18, 2014 at 10:55:10AM +0900, Simon Horman wrote:
> > > > This patch is a prototype and has several limitations:
> > > >
> > > > * It assumes that no actions follow a select group action
> > > > because the resulting packet after a select group action may
> > > > differ depending on the bucket used. It may be possible
> > > > to address this problem using recirculation. Or to not use
> > > > the datapath select group in such situations. In any case
> > > > this patch does not solve this problem or even prevent it
> > > > from occurring.
> > >
> > > It seems like this limitation in particular is a pretty big one. Do
> > > you have a good plan in mind for how to resolve it?
> >
> > Hi Ben,
> >
> > it seems to me that this would be somewhat difficult to resolve in the
> > datapath so I propose not doing so. And I have two ideas on how to
> > resolve this problem outside of the datapath.
> >
> > 1. Recirculation
> >
> > It seems to me that it ought to be possible to handle this by
> > recirculating if actions occur after an ODP select group action.
> >
> > This could be made slightly more selective by only recirculating
> > if the execution different buckets may result in different packet
> > contents and the actions after the ODP select group action rely on
> > the packet contents (e.g. set actions do but output actions do not).
> >
> > My feeling is that this could be implemented by adding a small amount
> > of extra state to action translation in ovs-vswitchd.
> >
> > 2. Fall back to selecting buckets in ovs-vswtichd
> >
> > The idea here is to detect cases where there would be a problem
> > executing actions after an ODP select group action and in that
> > case to select buckets in ovs-vswtichd: that is use the existing bucket
> > translation code in ovs-vswtichd.
> >
> > Though this seems conceptually simpler than recirculation it
> > seems to me that it would be somewhat more difficult to implement
> > as it implies a two stage translation process: e.g. one stage to
> > determine if an ODP select group may be used; and one to perform
> > the translation.
> >
> > I seem to recall trying various two stage translation processes
> > as part some earlier unrelated work. And my recollection is that
> > the result of my previous efforts were not pretty.
> >
> > Both of the above more or less negate any benefits of ODP select group
> > action. In particular lowering flow setup cost and potentially allowing
> > complete offload of select groups from the datapath to hardware. However I
> > think that this case is not a common one as it requires both of the
> > following. And I think they are both not usual use cases.
> >
> > * Different buckets modifying packets in different ways
> > - My expectation is that it is common for buckets to be homogeneous in
> > regards to packet modifications. But perhaps this is na??ve in the
> > context of VLANs, MPLS, and similar tags that can be pushed and popped.
> > * Actions that rely on packet contents after
> > - My expectation is that it is common to use a select group to output
> > packets and that is the final action performed.
>
> I am glad that you have thought about it. Your ideas seem like a good
> start to me. Personally, approach #2, of falling back to selecting
> buckets in ovs-vswitchd, seems like a clean solution to me, although
> if it really takes multiple stages in translation then that is
> undesirable, so I hope that some clean and simple approach works out.
Thanks. I'll focus on #2 and see how far I can get.
> I think that we probably need a solution before we can apply the patch
> series, because otherwise we end up with half-working code.
Yes, I agree. It needs to be solved before it can be merged.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists