On Thu, Jul 19, 2012 at 08:26:53PM -0700, Ben Pfaff wrote: > OK, there seem to be only two remaining points of disagreement. Let's > try to settle them. > > On Fri, Jul 20, 2012 at 08:22:27AM +0900, Simon Horman wrote: > > On Thu, Jul 19, 2012 at 10:44:18AM -0700, Ben Pfaff wrote: > > > On Thu, Jul 19, 2012 at 05:56:01PM +0900, Simon Horman wrote: > > > > On Thu, Jul 19, 2012 at 12:24:13AM -0700, Ben Pfaff wrote: > > > > > + Match NXM OF1.0 OF1.1 OF1.2 > > > > > + ----- --------- ----------- ----------- ------------ > > > > > + [9] 1001/1001 <none> <none> 1001/1001,-- > > > > > > With regards ti [9], I think its validity depends on how the CFI bit > > is treated, which I believe is still a point of debate. > > [...] > > > > > > + [6] Matches packets with no 802.1Q header or with an 802.1Q header > > > > > + with a VID of 0. Only possible with NXM. > > > > > + > > > > > + [7] Matches packets with no 802.1Q header or with an 802.1Q header > > > > > + with a PCP of 0. Only possible with NXM. > > > > > + > > > > > + [8] Matches packets with no 802.1Q header or with an 802.1Q header > > > > > + with both VID and PCP of 0. Only possible with NXM. > > > > > + > > > > > + [9] Matches only packets that have an 802.1Q header with an > > > > > + odd-numbered VID (and any PCP). Only possible with NXM and > > > > > + OF1.2. (This is just an example; one can match on any desired > > > > > + VID bit pattern.) > > > > > > > > For OF1.2 my feeling is that as all of these > > > > have OFPVID_NONE as the VID that they are all equivalent to [2]. > > > > > > > > Either that or all masks should be rejected if > > > > the VID is OFPVID_NONE. > > > > > > My interpretation is different: Table 10 in the spec talks about > > > oxm_value, not about the VID, and in fact if you just look at the VID > > > you've only got 12 bits but OFPVID_PRESENT requires at least 13 bits. > > > > Sure, my trouble is what to do with the 13th bit as in reality it is always > > present as the oxm_value is encoded using 16 bits. > > > > The OFPVID_PRESENT and OFPVID_NONE cases are clear to me. The others are > > not. > > First, of [6], [7], [8], [9], I'm only claiming that [9] can be matched > with OXM. So if by "all of these" you mean [6], [8], [8], [9], then we > can limit the discussion to [9], because that's the only one where we > seem to disagree. > > Here's the definition of OXM_OF_VLAN_VID from OF1.2: > > /* 802.1Q VID. > * > * For a packet with an 802.1Q header, this is the VLAN-ID (VID) from the > * outermost tag, with the CFI bit forced to 1. For a packet with no 802.1Q > * header, this has value OFPVID_NONE. > * > * Prereqs: None. > * > * Format: 16-bit integer in network byte order with bit 13 indicating > * presence of VLAN header and 3 most-significant bits forced to 0. > * Only the lower 13 bits have meaning. > * > * Masking: Arbitrary masks. > * > * This field can be used in various ways: > * > * - If it is not constrained at all, the nx_match matches packets without > * an 802.1Q header or with an 802.1Q header that has any VID value. > * > * - Testing for an exact match with 0x0 matches only packets without > * an 802.1Q header. > * > * - Testing for an exact match with a VID value with CFI=1 matches packets > * that have an 802.1Q header with a specified VID. > * > * - Testing for an exact match with a nonzero VID value with CFI=0 does > * not make sense. The switch may reject this combination. > * > * - Testing with nxm_value=0, nxm_mask=0x0fff matches packets with no > 802.1Q > * header or with an 802.1Q header with a VID of 0. > * > * - Testing with nxm_value=0x1000, nxm_mask=0x1000 matches packets with > * an 802.1Q header that has any VID value. > */ > #define OXM_OF_VLAN_VID OXM_HEADER (0x8000, OFPXMT_OFB_VLAN_VID, 2) > #define OXM_OF_VLAN_VID_W OXM_HEADER_W(0x8000, OFPXMT_OFB_VLAN_VID, 2) > > To me, the "Format" and "Masking" sections seem pretty clear that you > can mask any bits you want and rely on the behavior in the table. > > What do you think?
Thanks, that helps a lot. I will see about implementing the OF1.2 version of these tests and fix my implementation as needed. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
