From: Alexander Duyck <alexander.duyck@gmail.com>
To: SwamZ <swamssrk@gmail.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Rx_missed_errors drops with larger packet size
Date: Fri, 20 May 2016 09:45:47 -0700 [thread overview]
Message-ID: <CAKgT0UfnF-1JTdpWv73hhD87PZL=WYEMJoMdYSzyNdKs_+zKuQ@mail.gmail.com> (raw)
In-Reply-To: <CAMh0sidbgTz=q90Q9jTbn7RVP5m8WqjSD1wyK+nT-w9iGAq3sA@mail.gmail.com>
On Fri, May 20, 2016 at 2:09 AM, SwamZ <swamssrk@gmail.com> wrote:
> Hi,
>
>
> While doing performance testing with larger packet size (like 4000 bytes),
> we are seeing rx_missed_errors on the interface. This issue is not seen
> with packet size less than 2000. There were questions asked in this forum
> on rx_missed_error, but there was not any conclusion. Please let me know
> what could be the reason for these drops.
>
>
> I tried the following without any luck:
>
> 1) Tried different burst size like 16, 32 an 64
>
> 2) Tried different number of the rx descriptors like 512, 1024, 2048 and
> 4096.
I've seen issues like this occur on the 82599 using the Linux kernel
diver in the past, but it was usually related to CPU C states. I'm
assuming that shouldn't apply since you are using the poll mode driver
right so there are no interrupts and the CPUs are busy polling.
Another thing to check is that you have sufficient PCIe bandwidth.
Take a look at an lspci -vvv for the device and make certain it is
connected at x8 Gen2.
> Setup and testing details:
>
> CPU Speed : 2.6 GHz
>
> NIC : 82599ES 10-Gigabit
>
> IO Virtualization: SR-IOV
>
> IO and packet processing cores are in the same NUMA.
If you are running SR-IOV then the SRRCTL_DROP_EN bit should be set in
all the SRRCTL registers if I am not mistaken. As such if you are
triggering Rx missed errors it may not be related to the driver
directly but could point to some sort of PCIe but utilization issue.
How many VFs are you using and is any of this traffic multicast or
broadcast? Multicast or broadcast traffic can potentially saturate
the PCIe bus if there is enough of it on the wire as each packet is
normally replicated for each active VF. So 1 packet on the wire (4K)
can become 8 on the PCIe bus (32K) if you have 7 active VFs.
> Packet size : 4000 bytes
>
> Traffic rate: 80 % line rate. If the traffic rate is < ~80% then drops are
> not seen.
>
> Application: This is a sample application developed using L3fwd example app.
>
> DPDK version: 1.7
> Thanks,
> Swamy
next prev parent reply other threads:[~2016-05-20 16:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 9:09 SwamZ
2016-05-20 10:44 ` Bruce Richardson
2016-05-20 16:45 ` Alexander Duyck [this message]
2016-05-20 21:47 ` SwamZ
2016-05-31 18:50 ` SwamZ
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='CAKgT0UfnF-1JTdpWv73hhD87PZL=WYEMJoMdYSzyNdKs_+zKuQ@mail.gmail.com' \
--to=alexander.duyck@gmail.com \
--cc=dev@dpdk.org \
--cc=swamssrk@gmail.com \
/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).