Message-ID: <b3d13533-45bd-4504-aa02-82c88b047033@kernel.org>
Date: Thu, 12 Jun 2025 08:02:38 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Khalid Mughal <khalid.mughal@...el.com>, intel-wired-lan@...ts.osuosl.org
Cc: netdev@...r.kernel.org, Sridhar Samudrala <sridhar.samudrala@...el.com>
Subject: Re: [PATCH] net: Add new iccnet driver

On 11/06/2025 17:54, Khalid Mughal wrote:
> Intel(R) IPU ICCNET (Inter-Complex Communication Network) Driver:
> 
> The iccnet (Inter-Core Communication Network) driver enables sideband
> channel communication between the Management-Complex and the
> Compute-Complex, both powered by ARMv8 CPUs, on the Intel IPU
> (Infrastructure Processing Unit). The driver establishes descriptor
> rings for transmission and reception using a shared memory region
> accessible to both CPU complexes. The TX ring of one CPU maps
> directly to the RX ring of the other CPU.
> 
> == Initial and Evolving Use Cases ==
> 
> The initial use case was limited to simple utilities like scp, ssh,
> etc. However, iccnet evolved into the primary communication channel
> for iSCSI. In this scenario, Compute-Complex requires iSCSI to boot
> its OS, with the Management-Complex acting as an iSCSI server
> utilizing its SSD/NVMe storage. As a result, iccnet is now the
> default communication interface between Management-Complex and
> Compute-Complex for iSCSI. Since iSCSI relies on TCP/IP, a proper
> netdev driver is required.
> 
> == Driver Design ==
> 
> The iccnet is implemented as a generic netdev driver, enabling
> seamless integration with the Linux TCP/IP stack, without requiring
> custom socket APIs. The driver uses ARPHRD_RAWIP, forming a
> point-to-point link between Management-Complex and Compute-Complex.
> 
> It uses a reserved 2MB section of shared memory (outside the OS
> domains of Management-Complex and Compute-Complex), within a larger
> shared memory region. The driver follows a simple descriptor ring
> model. Each descriptor includes a status word with an ownership bit
> and a buffer for packet/frame data.
> On transmit:
>   Data is copied via memcpy() (no DMA available),
>   The ownership bit is set, and
>   An interrupt is triggered to notify the peer.
> On receive:
>   The interrupt handler processes the packet,
>   Copies the data via memcpy(), and
>   Resets the ownership bit.
> 
> Since the iccnet driver does not include an Ethernet header and lacks
> ARP support, a static route must be added after module insertion, e.g.
>     On Compute-Complex: ip route add 10.0.0.1 dev iccnet
>     On Management-Complex: ip route add 10.0.0.2 dev iccnet
> 
> == Alternative Solutions Considered ==
> 
> Before developing iccnet, several existing solutions were evaluated,
> but none met the requirements:
> 1. virtio-net: Requires a backend device model between CPU complexes.
> 2. veth (Virtual Ethernet): Only works within the same Linux network
>    namespace and does not support shared memory communication.
> 3. PRMsg (Remote Processor Messaging): Cannot expose a netdev
>    interface, which is required for iSCSI.
> 4. Mailbox Framework: Similar to RPMsg; lacks netdev support,
>    making it unsuitable for iSCSI.
> 
> Signed-off-by: Khalid Mughal <khalid.mughal@...el.com>
> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@...el.com>
> ---
> v2:
> - Fixed issues highlighted by Marcin Szycik
> v3:
> - Fixed internal-kbuild-all build warning
> v4:
> - Changed iccnet header padding
> ---
>  .../devicetree/bindings/net/intel,iccnet.yaml |  71 +++

That's a separate patch.

Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.

<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.

Please kindly resend and include all necessary To/Cc entries.
</form letter>

Best regards,
Krzysztof

Powered by blists - more mailing lists