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? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
