From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: <dev@dpdk.org>, "Thomas Monjalon" <thomas@monjalon.net>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>
Subject: Re: [RFC] ethdev: clarify rte_eth_tx_burst() return value and ownership semantics
Date: Wed, 18 Feb 2026 09:13:24 -0800 [thread overview]
Message-ID: <20260218091324.17a671dd@phoenix.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65728@smartserver.smartshare.dk>
On Wed, 18 Feb 2026 09:48:04 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:
> > + *
> > + * A return value equal to *nb_pkts* means that all packets have been
> > + * consumed, and this is likely to signify that other output packets
> > * could be immediately transmitted again. Applications that implement
> > a
> > * "send as many packets to transmit as possible" policy can check
> > this
> > * specific case and keep invoking the rte_eth_tx_burst() function
> > until
> > * a value less than *nb_pkts* is returned.
> > *
> > + * If a packet cannot be transmitted due to an error (for example, an
> > + * invalid offload flag), the driver must still consume it and free
> > the
> > + * mbuf, rather than stopping at that point. Such packets should be
> > + * counted in the *tx_errors* port statistic.
>
> The above paragraph is driver centric, it should be application centric.
Most of the applications are doing it right already since everybody
starts with l2fwd, or l3fwd. The problem I see is buggy drivers.
> Suggest rephrasing as:
>
> If a packet cannot be transmitted due to an error (for example, an invalid offload flag), the rte_eth_tx_burst() function will still consume it, rather than stopping at that point.
> Such packets are counted in the *oerrors* port statistic.
>
> NB: In struct rte_eth_stats [1], the error counter is named "oerrors", not "tx_errors".
>
> [1]: https://elixir.bootlin.com/dpdk/v25.11/source/lib/ethdev/rte_ethdev.h#L273
Good point, I was thinking of the per-queue stats and xstats.
> While discussing details...
> Let's say a packet has 4 segments, and the driver only has 2 descriptors remaining available.
> In that case, I think the driver should not consume the packet, but leave it for the application to either drop it or retry transmitting it later.
> Do we want to mention this case too, or is it a semi-obvious case of the descriptor ring having no more room?
There are also other cases of backpressure like when driver talks to kernel and gets EAGAIN or EBUSY
next prev parent reply other threads:[~2026-02-18 17:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 18:00 [RFC] ethdev: clarify rte_eth_tx_burst() return value and ownership semantics Stephen Hemminger
2026-02-17 6:41 ` Andrew Rybchenko
2026-02-17 14:54 ` Stephen Hemminger
2026-02-18 8:48 ` Morten Brørup
2026-02-18 8:52 ` Bruce Richardson
2026-02-18 17:13 ` Stephen Hemminger [this message]
2026-02-18 17:32 ` Morten Brørup
2026-02-19 0:44 ` [PATCH v2] " Stephen Hemminger
2026-02-19 7:20 ` Morten Brørup
2026-02-19 19:00 ` Stephen Hemminger
2026-02-19 19:00 ` Stephen Hemminger
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=20260218091324.17a671dd@phoenix.local \
--to=stephen@networkplumber.org \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
--cc=thomas@monjalon.net \
/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