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 ? Thanks. On Fri, Nov 7, 2014 at 2:43 PM, Jesse Gross <je...@nicira.com> wrote: > I'm not sure I understand what you are referring to. Can you elaborate? > > On Thu, Nov 6, 2014 at 3:58 PM, Madhu Challa <cha...@noironetworks.com> wrote: >> Since we are on this topic I had one more question. This could still >> be an issue if we want to be able to support a mask on the entire >> length of the geneve options data since we would run out of space. Do >> you have any thoughts on how I could handle this ? >> >> Thanks. >> >> On Thu, Nov 6, 2014 at 3:43 PM, Madhu Challa <cha...@noironetworks.com> >> wrote: >>> On Thu, Nov 6, 2014 at 2:37 PM, Jesse Gross <je...@nicira.com> wrote: >>>> >>>> On Thu, Nov 6, 2014 at 10:08 AM, Madhu Challa <cha...@noironetworks.com> >>>> wrote: >>>> > Jesse, >>>> > >>>> > Thanks for sharing your thoughts on this. >>>> > >>>> > On Thu, Nov 6, 2014 at 7:47 AM, Jesse Gross <je...@nicira.com> wrote: >>>> >> >>>> >> On Wed, Nov 5, 2014 at 10:03 AM, Madhu Challa <cha...@noironetworks.com> >>>> >> wrote: >>>> >> > Thanks Ben. I will debug and get back to you. I will check with Jesse >>>> >> > in >>>> >> > the >>>> >> > upcoming ovs conference if he has other thoughts on implementing this. >>>> >> >>>> >> I haven't had too much time to make progress on this so I don't have >>>> >> much in the way of additional thoughts at this point. The main one is >>>> >> that my goal is to not implement support for specific TLVs in OVS but >>>> >> to expose the full flexibility outwards so that anyone can introduce >>>> >> new metadata without having to modify OVS (the only possible exception >>>> >> being things that have to happen autonomously or on a per-packet basis >>>> >> in OVS). >>>> > >>>> > >>>> > I was thinking along same lines. I was planning on having a new >>>> > MFF_TUN_METADATA that is basically parsed as a raw OXM of length >>>> > between 4 >>>> > and 128 bytes. The match logic would parse multiple of these OXMs from a >>>> > FlowMod. >>>> > >>>> > From the struct match perspective we need to extend struct flow_tnl to >>>> > carry >>>> > this metadata. This is the difficult part because struct flow is already >>>> > 200 >>>> > bytes and the sparse representation only allows an addition of 52 bytes. >>>> > I >>>> > feel we could instead have a reference to tnl metadata from flow_tnl. I >>>> > have >>>> > not scoped out all the changes to do this, however if you have any >>>> > thoughts >>>> > or an alternative that would be great. >>>> >>>> I agree that we will need to extend some infrastructure here. I >>>> haven't thought too much about this yet. >>>> >>>> >> >>>> >> One issue that comes up when doing this is that the TLVs in both >>>> >> Geneve and OXM are exactly the same size so mapping them directly >>>> >> would consume the entire OXM space just for Geneve. There was a >>>> >> suggestion to use experimenter OXMs since they are larger but I >>>> >> haven't had a chance to look into this yet. >>>> > >>>> > >>>> > Yep I am using experimenter OXMs. >>>> >>>> I'm curious how you ended up laying this out. The OpenFlow spec says >>>> that the extra space should be used as an vendor ID in the form of an >>>> OUI. How did you reconcile this? >>> >>> >>> Good that you brought this up. I had different thoughts in mind. One >>> was to use the Nicira vendor id 0x002320 and a unique oxm_field to >>> represent MFF_TUN_METADATA. I was thinking we could overlay the Geneve >>> tunnel options header right after the oxm header, so it looks >>> something like this. >>> >>> 3 2 1 0 >>> 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | oxm_class | oxm_field |M| oxm_length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Vendor id | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Option Class | Type |R|R|R| Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Variable Option Data | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> oxm_class = 0xffff >>> vendor_id = 0x002320 >>> >>> I was also thinking if it would be possible to reserve a separate >>> class for tunnel encap metadata. >>> >>> I just read Bens email and I guess I can ignore the OUI if I follow >>> that approach. >>> >>> Thanks. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
