"Yang, Yi" <yi.y.y...@intel.com> writes: > On Tue, Sep 05, 2017 at 09:12:09PM +0800, Hannes Frederic Sowa wrote: >> "Yang, Yi" <yi.y.y...@intel.com> writes: >> >> > We can change this later if we really find a better way to handle this >> > because it isn't defined in include/uapi/linux/openvswitch.h, so I still >> > have backdoor to do this if needed :-) >> >> Sorry, I can't follow you. >> >> It doesn't matter if something is defined in uapi headers, the >> observable behavior matters. If you allow users to configure flows with >> specific fields, it should not stop working at a future point in time. > > Anyway this can be changed if it is really needed, so far current way is > the best one we can come up with, we would like to use it if you can > have better proposal. We have explained repeatedly context headers must > be matched and set, this is bottom line.
I understand that in the way you use those context fields you will have to match on those. I understand that there is no way around that. >> > For our sfc use case in Opendaylight, we use context[0] for tunnel ID, >> > context[1] for destination IP for reverse RSP, they are used to match >> > and set in OpenFlow table, you can't limit users to use them in such >> > ways. >> >> So in your specific case you expect the masks to be completely stable >> because you defined a protocol on top of NSH, understood. And that is >> stable accross all possible paths. Understood as well. >> >> > If you check GENEVE implementation, tun_metadata* can be set or matched >> > as any other match field. >> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata >> is not in tun_metadata as well? > > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a > lot of rework on tun_metadata to make it shared between GENEVE and NSH, > I don't think this can happen in near term. So tun_metadata isn't option > for this now. Sorry, I couldn't follow you. Why can't you store the context headers in tun_metadata exactly? [...] Bye, Hannes
