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
