[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <635a79b4-28a3-4052-b69f-bded7496d5aa@intel.com>
Date: Wed, 4 Feb 2026 16:04:40 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Tony Nguyen <anthony.l.nguyen@...el.com>,
<intel-wired-lan@...ts.osuosl.org>
CC: Przemek Kitszel <przemyslaw.kitszel@...el.com>, Andrew Lunn
<andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, "Eric
Dumazet" <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Jacob Keller
<jacob.e.keller@...el.com>, Aleksandr Loktionov
<aleksandr.loktionov@...el.com>, <nxne.cnse.osdt.itp.upstreaming@...el.com>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH iwl-next v2 0/5] ice: add support for devmem/io_uring Rx
and Tx
From: Alexander Lobakin <aleksander.lobakin@...el.com>
Date: Thu, 29 Jan 2026 12:03:28 +0100
> From: Alexander Lobakin <aleksander.lobakin@...el.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
Powered by blists - more mailing lists