On Sat, Nov 8, 2014 at 11:28 AM, Madhu Challa <cha...@noironetworks.com> wrote: > On Fri, Nov 7, 2014 at 8:13 PM, Jesse Gross <je...@nicira.com> wrote: >> On Fri, Nov 7, 2014 at 3:12 PM, Madhu Challa <cha...@noironetworks.com> >> wrote: >>> I was referring to the bit mask present in the spec: >>> >>> A.2.3.5 Flow Match Field Masking >>> When oxm_hasmask is 1, the OXM TLV contains a bitmask and its length >>> is effectively doubled, so >>> oxm_length is always even. The bitmask follows the field value and is >>> encoded in the same way. The masks >>> are defined such that a 0 in a given bit position indicates a “don’t >>> care” match for the same bit in the >>> corresponding field, whereas a 1 means match the bit exactly >>> >>> So if a mask is present with a Geneve option the max oxm_length could >>> be 256 bytes which will not fit a single oxm ? >> >> This may be a reason to find a different way to do the encoding of the >> Geneve type. The payload of a single option maxes out at 124 bytes so >> that will always fit in an OXM. However, eating away at that some for >> the experimenter ID and option header would push us over the edge so >> maybe that calls for the mapping table approach or some other way to >> avoid having the header there. > > I agree with you Jesse. I have couple more thoughts one going back to > what Ben mentioned. > > 1. With the experimenter oxm approach Ben mentioned we have (255 - > 1)/2 = 127 bytes for payload (worst case with mask). If we derive the > geneve option length using oxm_length and ignore the reserve fields we > are left with a max geneve option of 127 bytes that would fit the oxm. > We will support one option per oxm. > > 2. I do not know whats involved in using a new oxm_class, but if we > could map the geneve option class to an oxm_class we would save 2 more > bytes. The geneve type field is 8 bits whereas the oxm_field is only 7 > bits, otherwise we could have easily mapped those.
I agree it's unfortunate about the mismatch in type fields. I also was originally hoping that we could map them directly. This is about the extent that I've thought about this so far, so I don't have a specific idea yet. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
