Thanks, Ben. I figured out that even without apply any QoS or queueing, UDP traffic observes throughout of around 175Mbps. I guess the issue is not with QoS or queueing.
On Sat, Dec 15, 2018, 1:08 AM Ben Pfaff <[email protected] wrote: > On Fri, Dec 14, 2018 at 05:53:05PM +0500, Ramzah Rehman wrote: > > I have two servers connected via 1Gbps cable. I have installed OVS 2.8 > on > > server one. I have a switch named OVS_BR_LEAF_1 on it. I experimented > with > > QoS traffic shaping. I have connected eth3 of server one to ovs-switch on > > port 2. I want traffic going from server one to server two to observer > QoS > > traffic rate that I specify. > > > > I added following configuration: > > > > #ovs-vsctl -- set port eth3 qos=@newqos -- --id=@newqos create qos > > type=linux-hfsc other-config:max-rate=1000000000 queues:1=@q1 -- --id=@q1 > > create queue other-config:min-rate=x other-config:max-rate=x > > > > I have following flow entries in my switch: > > #vs-ofctl add-flow OVS_BR_LEAF_1 > > priority=6000,in_port=LOCAL,actions=set_queue:1,normal > > #ovs-ofctl add-flow OVS_BR_LEAF_1 priority=6000,in_port=2,actions=normal > > > > Then I checked throughput for TCP traffic (from server one to two) via > > iperf and got following results: > > > > got 846 Mbps for x=900 Mbps > > got 757 Mbps for x=800 Mbps > > got 653 Mbps for x=700 Mbps > > got 428 Mbps for x=450 Mbps > > got 381 Mbps for x=400 Mbps > > got 287 Mbps for x=300 Mbps > > got 239 Mbps for x=250 Mbps > > got 192 Mbps for x=200 Mbps > > > > Seems like traffic shaping is working fine for TCP traffic. However, for > > UDP, I got these results: > > > > 148 Mbps for x=800 Mbps > > 185 Mbps for x=300 Mbps > > 131 Mbps for x=200 Mbps > > 93 Mbps for x=100 Mbps > > 77 Mbps for x=80 Mbps > > 28.9 Mbps for x=30 Mbps > > 19.3 Mbps for x=20 Mbps > > > > For UDP, traffic shaping works fine till x=100Mpbs, but for higher values > > is shows unexpected behavior. Is there an explanation? > > This FAQ entry probably applies. > > Q: I configured QoS, correctly, but my measurements show that it isn't > working > as well as I expect. > > A: With the Linux kernel, the Open vSwitch implementation of QoS has > two > aspects: > > - Open vSwitch configures a subset of Linux kernel QoS features, > according > to what is in OVSDB. It is possible that this code has bugs. If you > believe that this is so, then you can configure the Linux traffic > control > (QoS) stack directly with the "tc" program. If you get better > results > that way, you can send a detailed bug report to [email protected] > . > > It is certain that Open vSwitch cannot configure every Linux kernel > QoS > feature. If you need some feature that OVS cannot configure, then > you > can also use "tc" directly (or add that feature to OVS). > > - The Open vSwitch implementation of OpenFlow allows flows to be > directed > to particular queues. This is pretty simple and unlikely to have > serious > bugs at this point. > > However, most problems with QoS on Linux are not bugs in Open vSwitch > at > all. They tend to be either configuration errors (please see the > earlier > questions in this section) or issues with the traffic control (QoS) > stack > in Linux. The Open vSwitch developers are not experts on Linux traffic > control. We suggest that, if you believe you are encountering a > problem > with Linux traffic control, that you consult the tc manpages (e.g. > tc(8), > tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or > mailing > lists (e.g. http://vger.kernel.org/vger-lists.html#netdev). >
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
