From: Larysa Zaremba <larysa.zaremba@intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: <intel-wired-lan@lists.osuosl.org>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
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>,
Joshua Hay <joshua.a.hay@intel.com>,
Chittim Madhu <madhu.chittim@intel.com>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Emil Tantilov <emil.s.tantilov@intel.com>,
Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net] idpf: fix LAN memory regions command on some NVMs
Date: Tue, 7 Oct 2025 14:44:17 +0200 [thread overview]
Message-ID: <aOULIXcBwiUpo67E@soc-5CG4396X81.clients.intel.com> (raw)
In-Reply-To: <355b43c3-fb0b-4e94-b49f-a008843f1267@molgen.mpg.de>
On Tue, Oct 07, 2025 at 02:06:55PM +0200, Paul Menzel wrote:
> Dear Larysa,
>
>
> Am 07.10.25 um 13:46 schrieb Larysa Zaremba:
> > IPU SDK versions 1.9 through 2.0.5 require send buffer to contain a single
> > empty memory region. Set number of regions to 1 and use appropriate send
> > buffer size to satisfy this requirement.
>
> Where are the SDK requirements documented?
>
IPU SDK is a fancy name for the FW. AFAIK, aside idpf specification intel did
not publish any additional resources for it.
idpf specification [1] is unclear on the exact get command contents. What I am
fixing is the reality of the implementation of the NVMs that support CPFs too
(supported by ixd [0]).
> What are the current SDK versions?
2.1, I tested with 2.0.5 that was the latest when this patch was first
implemented in August.
>
> Do you have a reproducer?
I can reliably reproduce this on my machine with intel IPU SDK 2.0.5, the
command fails every time without this patch, causing the probe to fail. Also,
other developers such as Michal S reported such problem. It is most probably
present on older NVMs too, its just that the command was not used before the
RDMA patchset.
I have checked that the patch does not cause regression on the platforms that
use another idpf-only NVMs, used by most intel IPUs.
[0]
https://lore.kernel.org/netdev/20250516145814.5422-1-larysa.zaremba@intel.com/
[1]
https://github.com/oasis-tcs/idpf-specification/blob/main/idpf_specification.pdf
>
> > Suggested-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > ---
> > drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > index fa3ce1e4f6ac..af8b3ebee4d4 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > @@ -1016,6 +1016,9 @@ static int idpf_send_get_lan_memory_regions(struct idpf_adapter *adapter)
> > struct idpf_vc_xn_params xn_params = {
> > .vc_op = VIRTCHNL2_OP_GET_LAN_MEMORY_REGIONS,
> > .recv_buf.iov_len = IDPF_CTLQ_MAX_BUF_LEN,
> > + .send_buf.iov_len =
> > + sizeof(struct virtchnl2_get_lan_memory_regions) +
> > + sizeof(struct virtchnl2_mem_region),
> > .timeout_ms = IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC,
> > };
> > int num_regions, size;
> > @@ -1028,6 +1031,8 @@ static int idpf_send_get_lan_memory_regions(struct idpf_adapter *adapter)
> > return -ENOMEM;
> > xn_params.recv_buf.iov_base = rcvd_regions;
> > + rcvd_regions->num_memory_regions = cpu_to_le16(1);
> > + xn_params.send_buf.iov_base = rcvd_regions;
> > reply_sz = idpf_vc_xn_exec(adapter, &xn_params);
> > if (reply_sz < 0)
> > return reply_sz;
>
>
> Kind regards,
>
> Paul
next prev parent reply other threads:[~2025-10-07 12:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 11:46 Larysa Zaremba
2025-10-07 12:06 ` [Intel-wired-lan] " Paul Menzel
2025-10-07 12:44 ` Larysa Zaremba [this message]
2025-11-24 19:37 ` Singh, Krishneil K
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=aOULIXcBwiUpo67E@soc-5CG4396X81.clients.intel.com \
--to=larysa.zaremba@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=emil.s.tantilov@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=joshua.a.hay@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=madhu.chittim@intel.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pmenzel@molgen.mpg.de \
--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
all inboxes | Powered by JetHome®