Intel i40e rx burst API non-conformance?

Intel i40e rx burst API non-conformance?

[Morten Brørup]

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.

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

Re: Intel i40e rx burst API non-conformance?

[Bruce Richardson]

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

RE: Intel i40e rx burst API non-conformance?

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Wednesday, 9 July 2025 17.28
> 
> 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.

I think that the non-conformant behavior only applies to requests for less than 32 packets.
(Maybe also for requests for numbers of packets that are not divisible by 32.)
Not for requests for 32, 64 or 128 packets.

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

I agree with your clarification of the meaning of the returned value.

This is also how our application interprets the response:
Non-full burst = "work done, normal scheduling",
Full burst = "more work potentially pending, urgent scheduling".

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