[ovs-discuss] Packet reodering Open vSwitch multiple versions
Ben Pfaff
blp at ovn.org
Thu Mar 30 15:23:29 UTC 2017
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.
More information about the discuss
mailing list