On Thu, Mar 30, 2017 at 02:09:28PM +0000, Ionut Chiriac wrote: > Open vSwitch version: 2.5.0, 2.5.2, 2.7.0 > > Kernel Version: Linux version 3.10.70 > > OS: Openwrt Barrier Breaker > > > > > > ________________________________________________________________ > > | > DUT > | > > ______ | _______________ > ____________________________ | > ___________ > > | | | | | > | Ovs bridge_1 > | | | > | > > | | | | | > veth | > | | > | | > > | PC1 |-----------------| | lxc-container | > ------------------------------| Port [lan_0] Port [ > eth1] | |----------------------------------------------| PC2 | > > |_____ | | | | > |____________________________| | > |___________| > > | |_______________| > > | > > > |________________________________________________________________| > > > > Scenario: > > On PC1 we start to send burst traffic: > > 300 packets at 185 Mbps; wait 2 seconds; > > 300 packets at 105 Mbps; wait 2 seconds > > 300 packets at 65 Mbps; wait 2 seconds > > 300 packets at 125 Mbps > > > We are experiencing packet reordering on PC2. After some testing we were able > to pinpoint the problem in Ovs bridge_1. > > A flow is added and we can see it with: > > ovs-appctl dpif/dump-flows bridge_1 > > > It seems that the packets that are reordered are those that go to userspace > before the flow is added. When the flow becomes active in kernel space the > next packets are forwarded directly without going to userspace. > > > Can you please tell us if this is a bug or an expected behavior?
It's expected behavior. Traffic doesn't normally burst like this outside of artificial test scenarios. We don't care much about artificial test scenarios. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
