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 <[email protected]> wrote: > Should 'no-port' be treated as wildcarded match on in_port? > > > On Mon, Jul 29, 2013 at 11:31 AM, Jesse Gross <[email protected]> wrote: >> >> On Mon, Jul 29, 2013 at 10:32 AM, Jesse Gross <[email protected]> wrote: >> > On Sat, Jul 27, 2013 at 10:27 PM, Andy Zhou <[email protected]> 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 [email protected] http://openvswitch.org/mailman/listinfo/dev
