On Fri, Sep 30, 2016 at 02:33:21PM +0200, Wolfgang Bumiller wrote:
> I've noticed openvswitch apparently blindly deletes the ingress qdisc
> of bridge ports even if no ingress policing is configured.
> This also prevents the use of this qdisc for purposes other than the
> in OVS implemented ingress policing (eg. handling fw-marks, bpf based
> filters, or early port/address/mac filtering can be convenient at this
> stage). Reading the source code didn't reveal any option to prevent
> the qdisc from staying completely unmanaged, which would be the
> simplest solution here.
>
> What are your thoughts on this?
This is analogous to the situation OVS had for egress qdiscs, which I
summarized in this email:
http://openvswitch.org/pipermail/discuss/2015-May/017687.html
We solved this in OVS 2.6 with commit 6cf888b821c:
https://github.com/openvswitch/ovs/commit/6cf888b821cffb75c5723ee76b7103e54b8fa2b5
Probably, some similar scheme would work for ingress qdiscs. Your
thoughts?
> Much of the configuration variable handling code seems auto generated
> and I'm unsure whether there's a good/simple way to distinguish
> explicitly defined values from defaults. And considering all OVS does
> for ingress policing is setting up 'tc' it seems it would make sense
> to allow users to handle tc themselves, too.
There's generated code but it's not really relevant for this particular
issue. The question is really the interpretation of the database
contents rather than what code does that interpretation.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
