DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: <dev@dpdk.org>
Subject: Re: Intel i40e rx burst API non-conformance?
Date: Wed, 9 Jul 2025 16:28:26 +0100	[thread overview]
Message-ID: <aG6Kmun_ibhZsL3K@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9FDAB@smartserver.smartshare.dk>

On Wed, Jul 09, 2025 at 04:59:51PM +0200, Morten Brørup wrote:
> Looking at the i40e driver source code, I think it doesn't conform to the API when requesting small bursts.
> 
> Let's say the hardware has received 31 packets.
> rte_eth_rx_burst(...,16) will return 16 packets and leave 15 in the driver's staging buffer (which has capacity for 32 packets).
> 
> Time passes, and more packets are received.
> 
> Now, rte_eth_rx_burst(...,16) will only return the 15 packets from the staging buffer, and not proceed to check for more [1].
> It thereby (according to my interpretation of the API description) informs the application that no more packets are ready to be received, which is incorrect.
> 

Again, the spec is not entirely clear. I would partially agree with you and
partially disagree, but overall, it's probably not the best behaviour here.

Rather than informing the app that there are no more packets, I would say
instead that it incorrectly informs the app that the descriptor ring is not
potentially overloaded. The reason for the difference is that, even in the
case of a driver correctly returning any number of packets, by the time the
function returns there could always be more in the ring. Where the real
risk, IMHO, is that you could miss out on a ring filling up without being
aware of it, because a full burst is a warning sign of overload.

/Bruce

> [1]: https://elixir.bootlin.com/dpdk/v25.07-rc2/source/drivers/net/intel/i40e/i40e_rxtx.c#L640
> 
> PS: I stumbled across this while reviewing how the very old 32 packet limit bugs (where it truncated large rx/tx requests to 32 packets) had been fixed.
> 

  reply	other threads:[~2025-07-09 15:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-09 14:59 Morten Brørup
2025-07-09 15:28 ` Bruce Richardson [this message]
2025-07-09 16:09   ` Morten Brørup

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=aG6Kmun_ibhZsL3K@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.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).