When we were previously doing just exact match, 'no-port' still
existed and it obviously wasn't a wildcard so I don't think that it
inherently means one now.
When the in port value is omitted, we currently allow you to omit the
mask or have either an all zeros or all ones mask so userspace should
still have control.
On Mon, Jul 29, 2013 at 12:17 PM, Andy Zhou <az...@nicira.com> wrote:
> Should 'no-port' be treated as wildcarded match on in_port?
>
>
> On Mon, Jul 29, 2013 at 11:31 AM, Jesse Gross <je...@nicira.com> wrote:
>>
>> On Mon, Jul 29, 2013 at 10:32 AM, Jesse Gross <je...@nicira.com> wrote:
>> > On Sat, Jul 27, 2013 at 10:27 PM, Andy Zhou <az...@nicira.com> wrote:
>> >> @@ -1317,6 +1326,7 @@ static int metadata_from_nlattrs(struct
>> >> sw_flow_match *match, u64 *attrs,
>> >> *attrs &= ~(1ULL << OVS_KEY_ATTR_IN_PORT);
>> >> } else if (!is_mask) {
>> >> SW_FLOW_KEY_PUT(match, phy.in_port, DP_MAX_PORTS,
>> >> is_mask);
>> >> + SW_FLOW_KEY_PUT(match, phy.in_port, 0xffff, !is_mask);
>> >
>> > Can you put this in a separate patch? All of these
>> > attribute-not-present corner cases are getting really nasty and I
>> > think that the vlan issues are actually somewhat separate.
>>
>> Actually, I don't think that this part is right anyways. The fact that
>> someone implicitly used a 'no-port' input port doesn't inherently mean
>> that they want to match on it - it could just be part of the packet
>> that's causing the flow to be set up.
>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
