netdev - Re: [RFC net-next 0/7] Provide an ism layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f6defb9-5e68-4fe5-84f0-58477c8c897b@linux.ibm.com>
Date: Fri, 17 Jan 2025 17:20:48 +0100
From: Alexandra Winter <wintera@...ux.ibm.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: dust.li@...ux.alibaba.com, Julian Ruess <julianr@...ux.ibm.com>,
        Wenjia Zhang <wenjia@...ux.ibm.com>, Jan Karcher <jaka@...ux.ibm.com>,
        Gerd Bayer <gbayer@...ux.ibm.com>, Halil Pasic <pasic@...ux.ibm.com>,
        "D. Wythe" <alibuda@...ux.alibaba.com>,
        Tony Lu <tonylu@...ux.alibaba.com>, Wen Gu <guwen@...ux.alibaba.com>,
        Peter Oberparleiter
 <oberpar@...ux.ibm.com>,
        David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
        Andrew Lunn <andrew+netdev@...n.ch>,
        Niklas Schnelle <schnelle@...ux.ibm.com>,
        Thorsten Winkler <twinkler@...ux.ibm.com>, netdev@...r.kernel.org,
        linux-s390@...r.kernel.org, Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev
 <agordeev@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>, Simon Horman <horms@...nel.org>
Subject: Re: [RFC net-next 0/7] Provide an ism layer



On 17.01.25 16:10, Andrew Lunn wrote:
> On Fri, Jan 17, 2025 at 02:00:55PM +0100, Alexandra Winter wrote:
>>
>>
>> On 17.01.25 03:13, Dust Li wrote:
>>>>>> Modular Approach: I've made the ism_loopback an independent kernel
>>>>>> module since dynamic enable/disable functionality is not yet supported
>>>>>> in SMC. Using insmod and rmmod for module management could provide the
>>>>>> flexibility needed in practical scenarios.
>>>>
>>>> With this proposal ism_loopback is just another ism device and SMC-D will
>>>> handle removal just like ism_client.remove(ism_dev) of other ism devices.
>>>>
>>>> But I understand that net/smc/ism_loopback.c today does not provide enable/disable,
>>>> which is a big disadvantage, I agree. The ism layer is prepared for dynamic
>>>> removal by ism_dev_unregister(). In case of this RFC that would only happen
>>>> in case of rmmod ism. Which should be improved.
>>>> One way to do that would be a separate ism_loopback kernel module, like you say.
>>>> Today ism_loopback is only 10k LOC, so I'd be fine with leaving it in the ism module.
>>>> I also think it is a great way for testing any ISM client, so it has benefit for
>>>> anybody using the ism module.
>>>> Another way would be e.g. an 'enable' entry in the sysfs of the loopback device.
>>>> (Once we agree if and how to represent ism devices in genera in sysfs).
>>> This works for me as well. I think it would be better to implement this
>>> within the common ISM layer, rather than duplicating the code in each
>>> device. Similar to how it's done in netdevice.
>>>
>>> Best regards,
>>> Dust
>>
>>
>> Is there a specific example for enable/disable in the netdevice code, you have in mind?
>> Or do you mean in general how netdevice provides a common layer?
>> Yes, everything that is common for all devices should be provided by the network layer.
> 
> Again, lack of basic understanding.... but why is it not a network
> device? Network devices are not just Ethernet. We also have CAN, SLIP,
> FDDI, etc.
> 
> 	Andrew
> 

Thank you very much Andrew for spending the time and discussing this.

At the moment there is not usecase for attaching an ism interface via
struct net_device to the linux network layer.
Current client is SMC-D and they bypass the network stack.
Next client is a tty-over-ism console driver.
And Niklas Schnelle envisions TTYs, block devices, framebuffers over ISM.
None of them do need queues or headers or other things the network stack
offers, as long as the source can directly write into the target buffer.
As mentioned earlier, probably one could write an network-over-ism
driver, but nobody asks for it at the moment.

I have read about the Linux device model with devices and buses, but I
have a bit of a hard time mapping that to an existing machine with
classes, susbsystems, slots, subtypes, buses over buses and virtual
things, etc that often have the same names for different things.
So any advice for alternative placements of ism is welcome.

This is the kind of picture I have in my head:

                 SMC-sockets		     console
ISM clients:         |				|
             +-----------------+        +-----------------+
             |     SMC-D       |        |     tty-ism     |
             +-----------------+        +-----------------+
		     |			         |
+----------------------------------------------------------------------+
|            ism layer						       |
|  ism interfaces:     						       |
| ism_vp0	     ism_vp1,        ism_lo,           ism_virtio0, .. |
+----------------------------------------------------------------------+
     |			|		|
+--------------+  +--------------+ +----------------+	
| 0000:00:00.0 |  | 0000:00:00.1 | | virtual/ism/lo |	
+--------------+  +--------------+ +----------------+	
	\		/
+------------------------+
|     pci bus            |
+------------------------+


ls /sys/class/ism
ism_vp0 -> ../../devices/pci0124:00/0124:00:00.0/ism/ism_vp0
ism_vp1 -> ../../devices/pci0125:00/0125:00:00.0/ism/ism_vp1
ism_lo -> ../../devices/virtual/ism/ism_lo


Maybe all that is overkill for ISM?
I think it would be very helpful, if they show up in sysfs, but not
absolutely required.