UDP packet loss calculation

_NOTE: The iperf3 issue tracker is for registering bugs, enhancement
requests, or submissions of code. It is not a means for asking
questions about building or using iperf3. Those are best directed
towards the iperf3 mailing list at iperf-dev@googlegroups.com or
question sites such as Stack Overflow
(http://www.stackoverflow.com/). A list of frequently-asked questions
regarding iperf3 can be found at http://software.es.net/iperf/faq.html._

# Context

* Version of iperf3:

* Hardware:

* Operating system (and distribution, if any):

_Please note: iperf3 is supported on Linux, FreeBSD, and macOS.
Support may be provided on a best-effort basis to other UNIX-like
platforms. We cannot provide support for building and/or running
iperf3 on Windows, iOS, or Android._

* Other relevant information (for example, non-default compilers,
libraries, cross-compiling, etc.):

_Please fill out one of the "Bug Report" or "Enhancement Request"
sections, as appropriate._

# Bug Report

When I use iperf for UDP packet, I saw packet loss.
I wonder how packet loss is calculated. The code below says out-of-order packets are considered as packet loss.
Is it true?

src/iperf_udp.c
* Try to handle out of order packets. The way we do this
* uses a constant amount of storage but might not be
* correct in all cases. In particular we seem to have the
* assumption that packets can't be duplicated in the network,
* because duplicate packets will possibly cause some problems here.
*
* First figure out if the sequence numbers are going forward.
* Note that pcount is the sequence number read from the packet,
* and sp->packet_count is the highest sequence number seen so
* far (so we're expecting to see the packet with sequence number
* sp->packet_count + 1 arrive next).
*/
if (pcount >= sp->packet_count + 1) {

/* Forward, but is there a gap in sequence numbers? */
if (pcount > sp->packet_count + 1) {
/* There's a gap so count that as a loss. */
sp->cnt_error += (pcount - 1) - sp->packet_count;
}

But most of system has multiple queues in NIC and packets are evenly distributed over the queues so out-of-order packets are normal.

* Expected Behavior

* Actual Behavior

* Steps to Reproduce

* Possible Solution

_Please submit patches or code changes as a pull request._

# Enhancement Request

* Current behavior

* Desired behavior

* Implementation notes

_If submitting a proposed implementation of an enhancement request,
please use the pull request mechanism._