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 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 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