DPDK patches and discussions
 help / color / mirror / Atom feed
From: SwamZ <swamssrk@gmail.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Rx_missed_errors drops with larger packet size
Date: Tue, 31 May 2016 11:50:08 -0700	[thread overview]
Message-ID: <CAMh0sieUnp71dgjBV_Yd6ENqu9gT_y63CAa=gRa3cScyQm66MA@mail.gmail.com> (raw)
In-Reply-To: <CAMh0sife+jPJqDyLSH8K5FTk--tcHmFEJ-UxgLEo0WoKh5n8qw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3618 bytes --]

Hi Alex et al.,
 I am seeing another case of rx_missed_error. In this case,
rx_missed_errors are seen only when I send multiple flows. Rx_missed_errors
are NOT seen if I send single flow. Following are the test details:

Packet type: Unicast/Mulitcast
Packet size : 512Bytes
Number of flows:  1000
Rate            : 24K PPS (98.3Mb) bidirectional traffic.
CPU Speed  : 2.6 GHz
NIC            : 82599ES 10-Gigabit
IO Virtualization: SR-IOV

Packet drops are seen for every 20-30 seconds once. Around 2K packets are
getting dropped in each instance. Please let me know if anybody has seen
this kind of issue in past and any pointers to debug this is really useful.

This is Gen2.0 x8 PCI. Attached the lspci -vvv output for reference.

Thanks for the help,
Swamy SRK


On Fri, May 20, 2016 at 2:47 PM, SwamZ <swamssrk@gmail.com> wrote:

> Hi Alex and Bruce,
>  Thanks for the reply.
>
> Alex,
>  Just saw your email. You are right, this issue was happening for
> multicast packets only.  On 82599 NIC, multicast and broadcast packet
> replication (IXGBE_VT_CTL_REPLEN) was enabled even for single VF case,
> hence NIC was dropping the packets as rx_missed_errors. After disabling the
> replication, we are not seeing any drops.
>
> Regards,
> Swamy SRK
>
> On Fri, May 20, 2016 at 9:45 AM, Alexander Duyck <
> alexander.duyck@gmail.com> wrote:
>
>> 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
>>
>
>
>
> --
> Swamz
>



-- 
Swamz

[-- Attachment #2: lspci_vvv.txt --]
[-- Type: text/plain, Size: 4863 bytes --]

88:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
Network Connection (rev 01)
    Subsystem: Hewlett-Packard Company Ethernet 10Gb 2-port 560SFP+ Adapter
    Physical Slot: 4
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR+ FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
    Latency: 0, Cache Line Size: 64 bytes
    Interrupt: pin B routed to IRQ 17
    Region 0: Memory at c8100000 (32-bit, non-prefetchable) [size=1M]
    Region 2: I/O ports at a020 [size=32]
    Region 3: Memory at c8204000 (32-bit, non-prefetchable) [size=16K]
    [virtual] Expansion ROM at c8280000 [disabled] [size=512K]
    Capabilities: [40] Power Management version 3
        Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
        Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Address: 0000000000000000  Data: 0000
        Masking: 00000000  Pending: 00000000
    Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
        Vector table: BAR=3 offset=00000000
        PBA: BAR=3 offset=00002000
    Capabilities: [a0] Express (v2) Endpoint, MSI 00
        DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
        DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
            RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
            MaxPayload 256 bytes, MaxReadReq 4096 bytes
        DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
        LnkCap: Port #0, Speed 5GT/s, Width x8, ASPM L0s, Exit Latency L0s
unlimited, L1 <8us
            ClockPM- Surprise- LLActRep- BwNot-
        LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
        LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt-
ABWMgmt-
        DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not
Supported
        DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF
Disabled
        LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
             Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
             Compliance De-emphasis: -6dB
        LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
             EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
    Capabilities: [e0] Vital Product Data
        Product Name: HP Ethernet 10Gb 2-port 560SFP+ Adapter
        Read-only fields:
            [PN] Part number: 665247-001
            [EC] Engineering changes: D-5514
            [SN] Serial number: MYI52608QY
            [V0] Vendor specific: 11W/8W PCIeG2x8 2p 10Gb SFP+ Intel 82599
            [V2] Vendor specific: 5526
            [V4] Vendor specific: 00110A6786D8
            [V5] Vendor specific: 0D
            [RV] Reserved: checksum good, 0 byte(s) reserved
        Read/write fields:
            [V1] Vendor specific: 4.5.19
            [V3] Vendor specific: 3.0.24
            [V6] Vendor specific: 2.3.20
            [YA] Asset tag: N/A
            [YB] System specific: xxxxxxxxxxxxxxxx
            [YC] System specific: xxxxxxxxxxxxxxxx
        End
    Capabilities: [100 v1] Advanced Error Reporting
        UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
        UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
        UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
        CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
        CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
        AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
    Capabilities: [140 v1] Device Serial Number 00-11-0a-ff-ff-67-86-d8
    Capabilities: [150 v1] Alternative Routing-ID Interpretation (ARI)
        ARICap: MFVC- ACS-, Next Function: 1
        ARICtl: MFVC- ACS-, Function Group: 0
    Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
        IOVCap: Migration-, Interrupt Message Number: 000
        IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy+
        IOVSta: Migration-
        Initial VFs: 64, Total VFs: 64, Number of VFs: 4, Function Dependency
Link: 00
        VF offset: 128, stride: 2, Device ID: 10ed
        Supported Page Size: 00000553, System Page Size: 00000001
        Region 0: Memory at 000003bfffe00000 (64-bit, prefetchable)
        Region 3: Memory at 000003bfffd00000 (64-bit, prefetchable)
        VF Migration: offset: 00000000, BIR: 0
    Kernel driver in use: ixgbe

      reply	other threads:[~2016-05-31 18:50 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
2016-05-20 21:47   ` SwamZ
2016-05-31 18:50     ` SwamZ [this message]

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='CAMh0sieUnp71dgjBV_Yd6ENqu9gT_y63CAa=gRa3cScyQm66MA@mail.gmail.com' \
    --to=swamssrk@gmail.com \
    --cc=alexander.duyck@gmail.com \
    --cc=dev@dpdk.org \
    /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).