On Wed, Aug 28, 2013 at 05:45:28PM +0900, Simon Horman wrote:
> Hi Ethan,
> 
> On Wed, Aug 28, 2013 at 12:25:31AM -0700, Ethan Jackson wrote:
> > > In short, it would make my life much easier if facets could be looked up
> > > execute_flow_miss(). And I am interested to know if you have any plans in
> > > that regards.
> > 
> > This actually is in the exact opposite of the direction I'm planning
> > to move.  Facets don't scale to tens of thousands of datapath flows,
> > are confusing, and are difficult to maintain, so I'm in the process of
> > cleaning up patches I've written which do away with them entirely.  I
> > don't have a lot of context on this recirculation stuff, but it sounds
> > like you'll need some thread-safe global state, completely independent
> > of facets, which can be used for your purposes.  A giant global hash
> > table of some sort perhaps.
> 
> I had assumed that it was the opposite of your planned direction which
> is why I didn't jump in and start accessing the facets.
> 
> > 
> > Comments inline.
> > 
> > >    However, my understanding is that with your recent changes facets 
> > > aren't
> > >    available in the thread where misses are executed which seems to be 
> > > when
> > >    action translation occurs and the rule is required.
> > 
> > Correct, and indeed facets are going away.
> > 
> > >    I had planned to get around this by creating a new recirculator
> > >    structure which would hold a recirculation id and flow. The flow
> > >    holds the parent recirculation id and it should be possible to
> > >    use this to find the top-most recirculator. This would provide
> > >    the thus the top-most flow which could be use for rule lookup.
> > 
> > Sounds like the right approach, but again I don't have much context.
> > 
> > >    However I see two problems with this scheme:
> > >
> > >    i.  If multiple misses are in-flight but handled in different
> > >        flow_miss_batches then multiple recirculators would be created for
> > >        what is in fact the same flow. This doesn't map comfortably to the
> > >        idea associate a recirculator with a facet. Though in a pinch it
> > >        ought to be possible to associate multiple recirculators with a
> > >        facet.
> > 
> > When facets go away flow miss batches will go away to.  A miss handler
> > will forward the packet and then be done with it, a new thread called
> > a "revalidator" will later clean up unused flows in the datapath
> > created by the miss handlers.
> 
> Ok, so the "revalidator" will know which flows to expire from the datapath
> without the need for facets in ovs-vswitchd?
> 
> > 
> > >        Another solution would be to allow recirculators to be looked up be
> > >        classifier. But it seems this would require re-working or 
> > > augmenting
> > >        the thread-safety of classifiers as in the scheme I propose
> > >        recirculators are created when translation occurs and this is not 
> > > in
> > >        the main thread where write-access to classifiers is thread-safe.
> > 
> > Perhaps they could be given they're own classifier?  The classifier
> > itself is thread safe if used within the context of a rwlock.
> 
> Thanks, that that sounds like it could work.
> 
> > >    ii.  A more acute problem seems to that it seems that revalidation
> > >         should occur when rule lookup for a recirculated packet occurs.
> > >         This is because the scheme described above involves using offsets,
> > >         calculated during previous action translations, to determine which
> > >         part of a rules ofpacts should be used when translating actions
> > >         for a recirculated packet.
> > 
> > Revalidation is also going away.  There will only be the equivalent of
> > the "expire" function.  If the datapath actions happen to be wrong, of
> > course we'll fix them, but this won't have any special machinery.
> > 
> > If you'd like I could send you a prototype version of what I have in
> > the works so you could start planning.  It's a couple of weeks away
> > from being ready for an official posting on the dev list, but you can
> > get a sense of the jist.
> 
> Thanks, a prototype would be very helpful in conjunction with your
> comments to come up with a plan for recirculation.

Hi Ethan,

I'm wondering if you have a prototype that you could post at this time.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to