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
