From: Stephen Hemminger <stephen@networkplumber.org>
To: Gregory Etelson <getelson@nvidia.com>
Cc: <dev@dpdk.org>, <mkashani@nvidia.com>,
Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Subject: Re: [PATCH 1/2] ethdev: support selective Rx data
Date: Mon, 2 Feb 2026 10:17:58 -0800 [thread overview]
Message-ID: <20260202101758.5904983e@phoenix.local> (raw)
In-Reply-To: <20260202160903.254621-1-getelson@nvidia.com>
On Mon, 2 Feb 2026 18:09:02 +0200
Gregory Etelson <getelson@nvidia.com> wrote:
> In some cases application does not need to receive entire packet
> from port hardware.
> If application could receive required Rx data only and safely discard
> the rest of Rx packet data, that could improve port performance by
> reducing PCI bandwidth and application memory consumption.
>
> Selective Rx data allows application to receive
> only pre-configured packet segments and discard the rest.
> For example:
> - Deliver the first N bytes only.
> - Deliver the last N bytes only.
> - Deliver N1 bytes from offset Off1 and N2 bytes from offset Off2.
>
> Selective Rx data is implemented on-top of the existing Rx
> BUFFER_SPLIT functionality:
> - The rte_eth_rxseg_split will use the NULL mempool for data segments
> that should be discarded.
> - PMD will not create MBUF segments if no data was read.
>
> For example: Deliver Ethernet header only
>
> Rx queue segments configuration:
> struct rte_eth_rxseg_split split[2] = {
> {
> .mp = <some mempool>,
> .length = sizeof(struct rte_ether_hdr)
> },
> {
> .mp = NULL, /* discard data */
> .length = <MTU>
> }
> };
>
> Received MBUF configuration:
> mbuf[0].pkt_len = sizeof(struct rte_ether_hdr);
> mbuf[0].data_len = sizeof(struct rte_ether_hdr);
> mbuf[0].next = NULL; /* The next segment did not deliver data */
And nb_segs should be 1?
And mbuf must still pass sanity check?
>
> After selective Rx, the mbuf packet length reflects only the
> existing data that was actually received, and can be less than the
> original wire packet length.
>
> A PMD activates the selective Rx data capability by setting the
> rte_eth_rxseg_capa.selective_read bit.
>
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
> ---
Need documentation updates as well.
At a minimum:
- entry in nic/guides/features/default.ini
- update to the ethdev documentation
- release note
It would also be good if one or more examples used split but
that can wait.
next prev parent reply other threads:[~2026-02-02 18:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 16:09 [PATCH 1/2] ethdev: support selective Rx data Gregory Etelson
2026-02-02 16:09 ` [PATCH 2/2] app/testpmd: " Gregory Etelson
2026-02-02 17:37 ` Stephen Hemminger
2026-02-02 18:17 ` Stephen Hemminger [this message]
2026-05-09 21:56 ` [PATCH v2 00/10] selective Rx Thomas Monjalon
2026-05-09 21:56 ` [PATCH v2 01/10] app/testpmd: print Rx split capabilities Thomas Monjalon
2026-05-09 21:56 ` [PATCH v2 02/10] ethdev: introduce selective Rx Thomas Monjalon
2026-05-09 21:56 ` [PATCH v2 03/10] app/testpmd: support " Thomas Monjalon
2026-05-09 21:56 ` [PATCH v2 04/10] common/mlx5: add null MR functions Thomas Monjalon
2026-05-09 21:56 ` [PATCH v2 05/10] net/mlx5: fix Rx split segment counter type Thomas Monjalon
2026-05-09 21:56 ` [PATCH v2 06/10] net/mlx5: support selective Rx Thomas Monjalon
2026-05-09 21:56 ` [PATCH v2 07/10] net/mlx5: reindent previous changes Thomas Monjalon
2026-05-09 21:56 ` [PATCH v2 08/10] common/mlx5: remove callbacks for MR registration Thomas Monjalon
2026-05-09 21:57 ` [PATCH v2 09/10] dts: fix topology capability comparison Thomas Monjalon
2026-05-09 21:57 ` [PATCH v2 10/10] dts: add selective Rx tests Thomas Monjalon
2026-05-10 16:19 ` [PATCH v2 00/10] selective Rx 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=20260202101758.5904983e@phoenix.local \
--to=stephen@networkplumber.org \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=getelson@nvidia.com \
--cc=mkashani@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.