[ovs-discuss] ovs and tc's ingress qdisc

[Ben Pfaff]

On Wed, Oct 12, 2016 at 03:51:33PM +0200, Wolfgang Bumiller wrote:
> On October 5, 2016 at 6:55 PM Ben Pfaff <blp at ovn.org> wrote:
> > I don't know what you're trying to deal with.  The autogenerated code
> > provides a C view of all of the features that the underlying database
> > does.  If you need something else, then it probably means extending the
> > database schema, at which point the autogenerated code will give a view
> > of whatever you add to the schema.
> 
> I was just worried that the schema would be involved in interface/rpc
> code which could potentially break tools built with the old schema.
> (Considering it comes with a checksum)
> But I don't see another option.
> 
> Would you generally prefer an additional boolean flag for a change like
> this or perhaps add -1 special value for the ingress_policing_rate.
> A quick glance at the existing schema didn't point out many existing
> special values other than a semi intuitive active_timeout where 0 means
> default and -1 means disabled. In the case of ingress_policing_rate 0
> would mean disabled and -1 would mean untouched.

Yes, we're very concerned about schema backward compatibility.  Adding
special interpretations, or adding columns, doesn't break this kind of
backward compatibility.

I have two thoughts here.

One would be to use -1, as you say.  These columns currently have a
constraint "minInteger": 0, which prevents -1 from being used.  That
could prevent downgrading from a newer to an older schema if the -1
value were actually in use.  That is probably a minor concern.

The other possibility I'm thinking of is to add an ingress_qos column
to the Port table, which would resemble the qos column except that it
would be used on ingress.  Then we could define a collection of ingress
qdiscs like those used for egress, one of which would be a "noop"
qdisc.  This is more future proof and does not have downgrade issues,
although it is a little more work.