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 will think more on it. Thanks. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
