[ovs-discuss] OVS 2.5.0 patch ports bug?
Ben Pfaff
blp at ovn.org
Sun Aug 21 15:10:54 UTC 2016
On Sun, Aug 21, 2016 at 04:31:17PM +0200, Levente Csikor wrote:
> Hi all,
> we've been experiencing with OVS and its patch ports, and we set up a
> the following case:
>
> One OVS bridge instance (created via add-br) is connected to two
> physical interfaces (our two-port Intel X710 NIC), and with an arbitrary
> number of patch ports (we used 12,24,36,48, etc.) this OVS bridge
> instance is connected to another bridge instance (created via add-br as
> well).
> For a simple setup, we installed the following rules into the flow tables:
> The first OVS (having the physical ports) is receiving traffic from one
> of the NIC ports (0), and forwards them to one of the patch ports
> (differentiated via VLAN tags). The second OVS bridge instance
> immediately loops the packets back on the same patch port where it
> received them. Finally, the first OVS bridge instance put these
> loop-backed traffic to the other NIC port (1) (see below - hopefully,
> ASCII art did not fall into pieces).
>
> +----------+ +---------+
> 0 | OVS 1 |<---->|0 OVS 2 |
> --->| |<---->|1 |
> 1 | | .... | |
> <---| |<---->|12 |
> +----------+ +---------+
>
> In this case, where the patch ports are basically "full-duplex" ones,
> i.e., OVS 1 sends traffic on each of them, while OVS 2 also passes back
> the packets on each of them, we deterministically experienced approx.
> 10% packet drop (number of patch ports has no impact on this).
>
> However, if we doubled the number of patch ports, and set up OVS 2 to
> loop-back the packets on the next patch ports instead, i.e., patch ports
> were considered as "simplex" (see below), then the packet loss was not
> observed.
>
>
> +----------+ +---------+
> 0 | OVS 1 |----->|0 OVS 2 |
> --->| |<-----|1 |
> 1 | | .... | |
> <---| |----->|23 |
> | |<-----|24 |
> +----------+ +---------+
>
> We used the openvswitch kernel module, and DPDK, and the observation
> applies to both cases, while we also 'played' with the sending rate as
> well to avoid 'overloading'.
>
>
> Could someone help us to understand this phenomenon?
It doesn't make sense to me. Patch ports are implemented as just
function calls. I think you'll have to look it into closer yourselves.
More information about the discuss
mailing list