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
