[ovs-discuss] mf_value and mf_subvalue size restrictions
challa at noironetworks.com
Thu Nov 6 23:58:16 UTC 2014
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 ?
On Thu, Nov 6, 2014 at 3:43 PM, Madhu Challa <challa at noironetworks.com> wrote:
> On Thu, Nov 6, 2014 at 2:37 PM, Jesse Gross <jesse at nicira.com> wrote:
>> On Thu, Nov 6, 2014 at 10:08 AM, Madhu Challa <challa at noironetworks.com> wrote:
>> > Jesse,
>> > Thanks for sharing your thoughts on this.
>> > On Thu, Nov 6, 2014 at 7:47 AM, Jesse Gross <jesse at nicira.com> wrote:
>> >> On Wed, Nov 5, 2014 at 10:03 AM, Madhu Challa <challa at 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.
More information about the discuss