Thanks for the additional information. I did some more experiments with your example. I posted a v2 of my patch: http://openvswitch.org/pipermail/dev/2015-March/052394.html
You'll need to implement the tc_load callback now since otherwise you'll get a segfault when tc_query_qdisc() tries to call the NULl pointer. On Wed, Mar 11, 2015 at 04:39:05PM +0100, Jonathan Vestin wrote: > Thank you for your fast reply and fix. I applied it and it still doesn't fix > my problem. Some investigation and my problem seems to be that in > tc_query_qdisc, the call to tc_transact returns error 2 (No such file or > directory). > > I try to trigger tc_load with the following script: > > tc qdisc del dev tun0 root > tc qdisc add dev tun0 root sfq perturb 20 > ovs-vsctl add-br br0 > ovs-vsctl add-port br0 tun0 > > > On 03/10/2015 11:04 PM, Ben Pfaff wrote: > > On Tue, Mar 10, 2015 at 10:07:31PM +0100, Jonathan Vestin wrote: > >> Ok, quite some things to do, I will fix the things you mentioned after > >> sorting out the tc_load problem. > >> > >> Regarding tc_load: > >> See the comment in: tc_parse_qdisc at 4414 to 4420: > >> * To avoid the OOPS, we must not make a request that would attempt to dump > >> * a "built-in" qdisc, that is, the default pfifo_fast qdisc or one of a > >> * few others. There are a few ways that I can see to do this, but most of > >> * them seem to be racy (and if you lose the race the kernel OOPSes). The > >> * technique chosen here is to assume that any non-default qdisc that we > >> * create will have a class with handle 1:0. The built-in qdiscs only have > >> * a class with handle 0:0. > >> > >> I presume this means that in order for tc_load to be called, the qdisc > >> *must* have one class, which classless qdiscs cannot have. Please correct > >> me > >> if I'm wrong. > > That's a good point, thanks for pointing it out. > > > > I sent out a possible fix. Would you mind reviewing it and making > > sure that it actually fixes the problem for you? The patch is at: > > http://openvswitch.org/pipermail/dev/2015-March/052268.html > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev