[ovs-discuss] tc ingress qdisc of tapB disappeared when del-port tapA from bridge

[ychen]

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" <blp at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150723/141c8c74/attachment-0002.html>