[ovs-discuss] mf_value and mf_subvalue size restrictions
challa at noironetworks.com
Thu Nov 6 18:08:00 UTC 2014
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>
> > Thanks Ben. I will debug and get back to you. I will check with Jesse in
> > 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
>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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss