[dpdk-dev] Fast Failover Test Results

[dpdk-dev] Fast Failover Test Results

[Stefan Binna]

Hi @all,

I've conducted some fast failover tests on a SDN infrastructure, whereby
following three configurations were used for the device under test (DUT):

- Intel 82574L with default driver e1000e
- Intel 82574L with DPDK
- Realtek RTL8111/8168/8411 PCI Express with default driver r8169

There were two paths connected to the DUT, e.g. Path 1 and Path 2.
So by default Path 1 had been used. When Path 1 was disconnected, the
time it took to switch to Path 2 had been measured by counting the lost
packets.
Several tests have been conducted and the median calculated.

Terminology:

Median FF: Median fast failover time / ms
Median LP: Median lost packets / packet(s)

                       Median FF   Median LP

DPDK            1700            3363
Intel              350              690
Realtek         350              695

Anyone an idea why DPDK is so "slow"?

Best regards,
     Stefan.

Re: [dpdk-dev] Fast Failover Test Results

[Declan Doherty]

On 01/09/15 14:31, Stefan Binna wrote:
> Hi @all,
>
> I've conducted some fast failover tests on a SDN infrastructure, whereby
> following three configurations were used for the device under test (DUT):
>
> - Intel 82574L with default driver e1000e
> - Intel 82574L with DPDK
> - Realtek RTL8111/8168/8411 PCI Express with default driver r8169
>
> There were two paths connected to the DUT, e.g. Path 1 and Path 2.
> So by default Path 1 had been used. When Path 1 was disconnected, the
> time it took to switch to Path 2 had been measured by counting the lost
> packets.
> Several tests have been conducted and the median calculated.
>
> Terminology:
>
> Median FF: Median fast failover time / ms
> Median LP: Median lost packets / packet(s)
>
>                       Median FF   Median LP
>
> DPDK            1700            3363
> Intel              350              690
> Realtek         350              695
>
> Anyone an idea why DPDK is so "slow"?
>
> Best regards,
>     Stefan.

Hey Stefan,

A couple of questions regarding your setup which will hopefully help me 
figure out what the issue is.

- Are you just running in active backup mode or are you using  one of 
the other bonding modes.
- What is down stream of the DUT, is it a switch or are you just 
directly connected to another system?

I'm not sure if the 82574L has LSC interrupt support in DPDK, I'll check 
that out, but if it doesn't the PMD need will be polling the link status 
which could be slowing down detection of the link going down and the 
fail over to the over port.

Declan

Re: [dpdk-dev] Fast Failover Test Results

[Stefan Binna]

Am 01.09.2015 um 18:03 schrieb Declan Doherty:
>
>
> On 01/09/15 14:31, Stefan Binna wrote:
>> Hi @all,
>>
>> I've conducted some fast failover tests on a SDN infrastructure, whereby
>> following three configurations were used for the device under test 
>> (DUT):
>>
>> - Intel 82574L with default driver e1000e
>> - Intel 82574L with DPDK
>> - Realtek RTL8111/8168/8411 PCI Express with default driver r8169
>>
>> There were two paths connected to the DUT, e.g. Path 1 and Path 2.
>> So by default Path 1 had been used. When Path 1 was disconnected, the
>> time it took to switch to Path 2 had been measured by counting the lost
>> packets.
>> Several tests have been conducted and the median calculated.
>>
>> Terminology:
>>
>> Median FF: Median fast failover time / ms
>> Median LP: Median lost packets / packet(s)
>>
>>                       Median FF   Median LP
>>
>> DPDK            1700            3363
>> Intel              350              690
>> Realtek         350              695
>>
>> Anyone an idea why DPDK is so "slow"?
>>
>> Best regards,
>>     Stefan.
>
> Hey Stefan,
>
> A couple of questions regarding your setup which will hopefully help 
> me figure out what the issue is.
>
> - Are you just running in active backup mode or are you using  one of 
> the other bonding modes.
> - What is down stream of the DUT, is it a switch or are you just 
> directly connected to another system?
>
> I'm not sure if the 82574L has LSC interrupt support in DPDK, I'll 
> check that out, but if it doesn't the PMD need will be polling the 
> link status which could be slowing down detection of the link going 
> down and the fail over to the over port.
>
> Declan
>
>

Hi Declan,

regarding your first question I think that I use the active backup mode, 
but I didn't define anything special.

What I did was starting OpenvSwitch with DPDK using following command(s):

# Start OVS with DPDK portion using 2GB of node 0 memory
./ovs/vswitchd/ovs-vswitchd --dpdk -c 0xf -n 4 --socket-mem 2048,0 -- unix:/usr/local/var/run/openvswitch/db.sock --pidfile --detach

Afterwards I added the interfaces which have been bound to the igb_uio 
driver as "dpdk interfaces":

./ovs/utilities/ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
sleep 0.5
./ovs/utilities/ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk
sleep 0.5
./ovs/utilities/ovs-vsctl add-port br0 dpdk2 -- set Interface dpdk2 type=dpdk
sleep 0.5

The downstream of the DUT is connected to another switch.
Here is a network diagram: http://abload.de/img/ff_testbed_dpdk28sah.png
whereby al40-118 is the DUT, al40-115 the sender and al40-111 the receiver.

Thanks very much.

Stefan.