I'm a student at Umeå University and I am currently using an Intel® 82599EB 10 Gigabit Ethernet Controller to send and receive network packets. I'm using the Flow Director filter to direct the packets into different rx queues, and I want to use the queue statistic registers (QPRC and QPRDC) to count the number of received packets at each queue.
However, the numbers are not correct! The GPRC register gives one number for the total amount of received packets (which is correct, it's the same as the amount of sent packets), while summing the queue statistics gives another number, lower than the GPRC. Shouldn't these be the same? It works at low speeds, <5 Gbit/s, but not for speeds higher than that. All packets should be matching the filters. Where/why are packets lost after being received and counted at the GPRC register, but before being placed in a queue and counted at the queue statistics?
Any other suggestions for ways to count packets divided into different groups/queues are also very appreciated if the solution with the Flow Director filter and queue statistics is not working!
Thank you for contacting Intel.
In order to further investigate your concerns, we would like to request for additional details:
1. Network Adapter Model:
2. Operating System:
3. Where you see the wrong counts.
We look forward to your reply.
Thanks for the fast reply!
Some additional info:
1. I think it is an "Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection". (Not 82599EB as I wrote in my first post)
2. I'm using Ubuntu 14.4.
3. I'm reading the statistic registers on the NIC. The register for Good Packets Received Count, GPRC, (at 0x04074) gives the total amount of received packets at the interface. This number is the same as the amount of packets that I'm sending, so it looks like it's correct! I'm then dividing these packets into different queues using Flow Director filters and I'm then reading the registers for Queue Packets Received Count, QPRC, (at 0x01030 + 0x40*n, n=0...15) and Queue Packets Received Drop Count, QPRDC, (at 0x01430 + 0x40*n, n=0...15) to see how many packets that have been put in each queue.
All packets should be put in a queue, right? The problem is that the amount of packets received at the queues (i.e. by summing all QPRC and QPRDC registers) are less than the amount of packets received at the interface in total (i.e. according to the GPRC register)! Shouldn't these numbers be the same? Or are packets lost somewhere after being received at the NIC, without this being registered in a statistic register (for example, without being registered at the QPRDC registers)?
The problem seems to be when the packets are matching more than around 2-3 filters, and hence are put into more than 2-3 queues, when sending/receiving at 10 Gbit/s. With packets matching less than four filters, the statistic registers are showing the correct numbers. However, with packets matching more filters than that, packets start getting "lost" somewhere and are not counted for in the queue statistic registers.
Any progress regarding this yet?
I have a few other, hopefully easier, questions now as well. The Flow Director filter is working well for IPv4 packets (except for the problem mentioned in my previous posts), but when I'm trying to add filters for IPv6 packets, then these packets never matches any filter. So my question is: should it be possible to have filters active for both IPv4 and IPv6 packets at the same time?
The problem might of course be that I may be adding the filters in an incorrect way. Is there any guide (or something similar) available somewhere that describes how to add Flow Director filters? Or can you provide a short step-by-step description here?
Sorry for the delay.
We are seeing this issue on older drivers. Updating the driver should resolve this missed count error. This is why the Flow Director is reporting missed counts. Please refer to website below for more information:
Errata 7: GPRC and GORCL/H Also Count Missed Packets
You may contact our https://kaveri.intel.com/ibl/help/support.htm Intel Business Link Support for further assistance on DPDK.