From: Declan Doherty <declan.doherty@intel.com>
To: Stefan Binna <stefan.binna@salzburgresearch.at>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Thomas Pfeiffenberger"
<thomas.pfeiffenberger@salzburgresearch.at>,
"Ferdinand Tüllenburg"
<ferdinand.tuellenburg@salzburgresearch.at>
Subject: Re: [dpdk-dev] Fast Failover Test Results
Date: Tue, 1 Sep 2015 17:03:31 +0100 [thread overview]
Message-ID: <55E5CC53.90708@intel.com> (raw)
In-Reply-To: <55E5A8A5.7000502@salzburgresearch.at>
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
next prev parent reply other threads:[~2015-09-01 15:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <55E5A7A5.3080202@salzburgresearch.at>
[not found] ` <55E5A80F.70508@salzburgresearch.at>
2015-09-01 13:31 ` Stefan Binna
2015-09-01 16:03 ` Declan Doherty [this message]
2015-09-02 7:23 ` Stefan Binna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55E5CC53.90708@intel.com \
--to=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=ferdinand.tuellenburg@salzburgresearch.at \
--cc=stefan.binna@salzburgresearch.at \
--cc=thomas.pfeiffenberger@salzburgresearch.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).