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

Andy Zhou azhou at nicira.com
Thu May 1 09:03:05 UTC 2014


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?



More information about the dev mailing list