[ovs-discuss] mf_value and mf_subvalue size restrictions

Madhu Challa challa at noironetworks.com
Fri Nov 7 23:12:02 UTC 2014


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 <jesse at 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 <challa at 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 <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.
>>>
>>> Thanks.



More information about the discuss mailing list