sorry, but how to contribute to this thread:
http://openvswitch.org/pipermail/discuss/2015-May/017687.html
It seems I can only reply this thread
http://openvswitch.org/pipermail/discuss/2015-July/018324.html
for this QoS question, here is some of my ideas:
1. add ingress type for QOS just like egress qdisc.
but I don't think it is a good idea.
first, it needs lots of code modifcation;
second, ingress qdisc have only one queue, if we add another type for
ingress qdisc, it seems incompatible with linux tc.
2. do some query with kernel before del/add ingress qdisc in OVS.
The main problem is OVS does't know whether users have already configured
ingress qdisc without OVS command.
so if we query kernel first, and compare the kernel rate with OVS ingress
rate.
but still I think it is not a good way.
this method needs communication with kernel every time ports updated, and may
consume lots of resource.
3. use flag to mark ingress qdisc
there is already a flag VALID_POLICING to mark OVS ingress qdisc.
but I don't know why VALID_POLICING is still set when
iface->cfg->ingress_policing_rate=0
I have read the ovs qos code, and it seems when we use command
ovs-vsctl set interface tapxxx ingress_policing_rate=0 is just like
ovs-vsctl clear interface tapxxx ingress_policing_rate
so I think we can just use the already existing flag VALID_POLICING
when VALID_POLICING is unset, and when update port qos function is called
with parameter kbits_rate equal to netdev->kbits_rate
then we do nothing for this port.
I have tested QOS feature with method 3, and when ovs restart, add-port to
qos. del-port from qos, update port's atrributes,
tc ingress qdisc can be reserved.
At 2015-07-22 23:34:15, "Ben Pfaff" <b...@nicira.com> wrote:
>On Wed, Jul 22, 2015 at 10:04:20AM +0800, ychen wrote:
>> I found that when delete one port from ovs bridge, then another port's tc
>> ingress qdisc automatically disappeared, but egress qdisc is still existed.
>> I have tried version 2.3.2 and master branch of ovs, the bug still exists in
>> these 2 branch.
>> we can reproduce this phenomenon following the step:
>> 1. create 2 tap device
>> ip tuntap add dev tap111 mode tap
>> ip tuntap add dev tap222 mode tap
>>
>>
>> 2. add port to ovs bridge
>> ovs-vsctl add-br br0
>> ovs-vsctl add-port br0 tap111
>> ovs-vsctl add-port br0 tap222
>>
>>
>> 3. add ingress qdisc for these 2 ports
>> tc qdisc add dev tap111 ingress
>> tc qdisc add dev tap222 ingress
>>
>>
>> 4.delete port tap111
>> ovs-vsctl del-port br0 tap111
>> ////// then we can see tc ingress qdisc of tap222 disappear//////////
>
>OVS assumes it's in charge of QoS currently for ports in its bridges.
>
>If you want to change that assumption then you should contribute to this
>thread:
>http://openvswitch.org/pipermail/discuss/2015-May/017687.html
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
