[ovs-dev] [PACKET_OUT v2] ofproto-dpif: treat non-datapath ports as local port for OFPT_PACKET_OUT

Ben Pfaff blp at nicira.com
Thu May 1 14:46:21 UTC 2014


On Thu, May 01, 2014 at 02:03:05AM -0700, Andy Zhou wrote:
> On Thu, May 1, 2014 at 1:20 AM, Simon Horman <simon at horms.net> wrote:
> > On Thu, May 01, 2014 at 03:59:20PM +0900, YAMAMOTO Takashi wrote:
> >> >> Something like this (I have not tested either scenario):
> >> >>
> >> >>   I think this will fail to match but that may not be obvious to users:
> >> >>   packet_out: in_port=CONTROLLER actions=goto_table:1
> >> >>   table 1: match=in_port=CONTROLLER actions=normal
> >> >>
> >> >>   I think this will match but that may not be obvious to users:
> >> >>   packet_out: in_port=CONTROLLER actions=goto_table:1
> >> >>   table 1: match=in_port=LOCAL actions=normal
> >> >>
> >> >>   Where CONTROLLER could be any port covered by this patch.
> >> >>
> >> > Only ODP ports are changed to LOCAL, so simple rule matches as
> >> > outlined should work.
> >> > However, this scenario is valid when recirculation is involved.
> >
> > I completely agree with that analysis.
> >
> >> > I am
> >> > not sure what we should
> >> > do about this edge case either.
> >>
> >> how about having a userspace-only special variant of RECIRC action,
> >> which can specify in_port as (ofproto, ofp port) and thus can be
> >> used even when odp port is not available?
> >>
> >> if a translation detects the condition (ie. recirculation is necessary
> >> but in_port does not have the corresponding odp port), it can use
> >> the userspace variant with SLOW_ACTION instead of normal RECIRC.
> >
> > FWIW I am happy with either that approach (assuming it works)
> > or Andy's approach. But I lean towards the simplicity of Andy's approach.
> 
> It seems we are missing some infrastructure to handle those edge case properly:
> 
> 1. Datapath, currently, requires a valid datapath in_port to packets.
> 2. Patch ports and CONTROLLER do not have corresponding datapath ports.
> 
> With those limitations, when datapath makes an upcall, user space can
> not recover the original ofport.
> This limitation actually goes beyond PACKET_OUT.
> 
> To properly solve it, we will need some infrastructure to allow user
> space to recover the
> original ofport, either by passing it to the datapath, or by some other means to
> re-associate them within the user space.
> 
> This infrastructure change is more complex and general than the
> problem at hand. I think we should
> improve the packet_out handling for now, assuming Simon's work can
> benefit from such improvement.
> If we decide to go down this road, we should note the limitations so
> that we can revisit them when
> proper infrastructure are in place. Make sense?

This seems reasonable to me as a stopgap measure until we can get in the
more sophisticated mechanisms.



More information about the dev mailing list