From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Tony Nguyen <anthony.l.nguyen@intel.com>,
<intel-wired-lan@lists.osuosl.org>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Jacob Keller <jacob.e.keller@intel.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
<nxne.cnse.osdt.itp.upstreaming@intel.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH iwl-next v2 0/5] ice: add support for devmem/io_uring Rx and Tx
Date: Wed, 4 Feb 2026 16:04:40 +0100 [thread overview]
Message-ID: <635a79b4-28a3-4052-b69f-bded7496d5aa@intel.com> (raw)
In-Reply-To: <93f55dd6-44a5-4309-aed1-30e352cd2825@intel.com>
From: Alexander Lobakin <aleksander.lobakin@intel.com>
Date: Thu, 29 Jan 2026 12:03:28 +0100
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Thu, 4 Dec 2025 16:51:28 +0100
>
>> Now that ice uses libeth for managing Rx buffers and supports
>> configurable header split, it's ready to get support for sending
>> and receiving packets with unreadable (to the kernel) frags.
>>
>> Extend libeth just a little bit to allow creating PPs with custom
>> memory providers and make sure ice works correctly with the netdev
>> ops locking. Then add the full set of queue_mgmt_ops and don't
>> unmap unreadable frags on Tx completion.
>> No perf regressions for the regular flows and no code duplication
>> implied.
>>
>> Credits to the fbnic developers, which's code helped me understand
>> the memory providers and queue_mgmt_ops logics and served as
>> a reference.
>>
>> Alexander Lobakin (5):
>> libeth: pass Rx queue index to PP when creating a fill queue
>> libeth: handle creating pools with unreadable buffers
>> ice: migrate to netdev ops lock
>> ice: implement Rx queue management ops
>> ice: add support for transmitting unreadable frags
>>
>> drivers/net/ethernet/intel/ice/ice_lib.h | 11 +-
>> drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +
>> drivers/net/ethernet/intel/idpf/idpf_txrx.h | 2 +
>> include/net/libeth/rx.h | 2 +
>> include/net/libeth/tx.h | 2 +-
>> drivers/net/ethernet/intel/iavf/iavf_txrx.c | 1 +
>> drivers/net/ethernet/intel/ice/ice_base.c | 194 ++++++++++++++------
>> drivers/net/ethernet/intel/ice/ice_lib.c | 56 +++++-
>> drivers/net/ethernet/intel/ice/ice_main.c | 50 ++---
>> drivers/net/ethernet/intel/ice/ice_sf_eth.c | 2 +
>> drivers/net/ethernet/intel/ice/ice_txrx.c | 43 +++--
>> drivers/net/ethernet/intel/ice/ice_xsk.c | 4 +-
>> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 13 ++
>> drivers/net/ethernet/intel/libeth/rx.c | 46 +++++
>> 14 files changed, 325 insertions(+), 103 deletions(-)
>>
>> ---
>> From v1[0]:
>> * rebase on top of the latest next-queue;
>> * fix a typo 'rxq_ixd' -> 'rxq_idx' (Tony).
>>
>> Testing hints:
>> * regular Rx and Tx for regressions;
>> * <kernel root>/tools/testing/selftests/drivers/net/hw/ contains
>> scripts for testing netmem Rx and Tx, namely devmem.py and
>> iou-zcrx.py (read the documentation first).
>>
>> [0] https://lore.kernel.org/intel-wired-lan/20251125173603.3834486-1-aleksander.lobakin@intel.com
>
> Current status from the validation:
>
> * io_uring tests pass, except for tests which try to setup RSS Rx
> contexts -- after recent changes in the kernel, seems like at least
> some of our drivers return -EOPNOTSUPP when trying to configure RSS.
Ok this might be due to that those scripts try to create new RSS
contexts. In fact zcrx works.
>
> Tony, did you have any related reports or planned fixes?
>
> * devmem -- only the Tx test fails, may be related to our complicated
> .ndo_start_xmit() logic in ice, I'll investigate this as soon as
> I get some details from the val.
In fact it works, it's just that by default without isolating TCP Rx
flows the completion packet may finish on any queue, not only the ones
bound to devmem. So ncdevmem reports "Ok" when the completion actually
hit the devmem Rx queue. Actual devmem Tx always works -- the output is
visible on the receiver side even when ncdevmem says "missing Tx
completion".
With that said, the only issue is that the bugfix was sent today for.
I'll merge it into the series and respin it once the window opens.
Thanks,
Olek
prev parent reply other threads:[~2026-02-04 15:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-04 15:51 [PATCH iwl-next v2 0/5] ice: add support for devmem/io_uring Rx and Tx Alexander Lobakin
2025-12-04 15:51 ` [PATCH iwl-next v2 1/5] libeth: pass Rx queue index to PP when creating a fill queue Alexander Lobakin
2026-02-06 16:34 ` [Intel-wired-lan] " Nowlin, Alexander
2025-12-04 15:51 ` [PATCH iwl-next v2 2/5] libeth: handle creating pools with unreadable buffers Alexander Lobakin
2026-02-06 16:33 ` [Intel-wired-lan] " Nowlin, Alexander
2025-12-04 15:51 ` [PATCH iwl-next v2 3/5] ice: migrate to netdev ops lock Alexander Lobakin
2026-01-19 18:05 ` [Intel-wired-lan] " Alexander Lobakin
2026-01-20 17:34 ` [PATCH iwl-next] ice: fix system hang on `ethtool -L` Alexander Lobakin
2026-01-21 7:18 ` Loktionov, Aleksandr
2026-01-21 16:00 ` Alexander Lobakin
2026-02-06 16:35 ` [Intel-wired-lan] [PATCH iwl-next v2 3/5] ice: migrate to netdev ops lock Nowlin, Alexander
2025-12-04 15:51 ` [PATCH iwl-next v2 4/5] ice: implement Rx queue management ops Alexander Lobakin
2026-02-06 16:29 ` [Intel-wired-lan] " Nowlin, Alexander
2025-12-04 15:51 ` [PATCH iwl-next v2 5/5] ice: add support for transmitting unreadable frags Alexander Lobakin
2026-02-06 16:27 ` [Intel-wired-lan] " Nowlin, Alexander
2026-01-29 11:03 ` [PATCH iwl-next v2 0/5] ice: add support for devmem/io_uring Rx and Tx Alexander Lobakin
2026-01-29 17:07 ` Tony Nguyen
2026-02-04 15:04 ` Alexander Lobakin [this message]
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=635a79b4-28a3-4052-b69f-bded7496d5aa@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nxne.cnse.osdt.itp.upstreaming@intel.com \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.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