From: Dust Li <dust.li@linux.alibaba.com>
To: Alexandra Winter <wintera@linux.ibm.com>,
Wenjia Zhang <wenjia@linux.ibm.com>,
Jan Karcher <jaka@linux.ibm.com>,
Gerd Bayer <gbayer@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>,
"D. Wythe" <alibuda@linux.alibaba.com>,
Tony Lu <tonylu@linux.alibaba.com>,
Wen Gu <guwen@linux.alibaba.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Julian Ruess <julianr@linux.ibm.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Thorsten Winkler <twinkler@linux.ibm.com>,
netdev@vger.kernel.org, linux-s390@vger.kernel.org,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Simon Horman <horms@kernel.org>
Subject: Re: [RFC net-next 0/7] Provide an ism layer
Date: Thu, 16 Jan 2025 17:32:31 +0800 [thread overview]
Message-ID: <20250116093231.GD89233@linux.alibaba.com> (raw)
In-Reply-To: <20250115195527.2094320-1-wintera@linux.ibm.com>
On 2025-01-15 20:55:20, Alexandra Winter wrote:
Hi Winter,
I'm fully supportive of the refactor!
Interestingly, I developed a similar RFC code about a month ago while
working on enhancing internal communication between guest and host
systems. Here are some of my thoughts on the matter:
Naming and Structure: I suggest we refer to it as SHD (Shared Memory
Device) instead of ISM (Internal Shared Memory). To my knowledge, a
"Shared Memory Device" better encapsulates the functionality we're
aiming to implement. It might be beneficial to place it under
drivers/shd/ and register it as a new class under /sys/class/shd/. That
said, my initial draft also adopted the ISM terminology for simplicity.
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.
Abstraction of ISM Device Details: I propose we abstract the ISM device
details by providing SMC with helper functions. These functions could
encapsulate ism->ops, making the implementation cleaner and more
intuitive. This way, the struct ism_device would mainly serve its
implementers, while the upper helper functions offer a streamlined
interface for SMC.
Structuring and Naming: I recommend embedding the structure of ism_ops
directly within ism_dev rather than using a pointer. Additionally,
renaming it to ism_device_ops could enhance clarity and consistency.
>This RFC is about providing a generic shim layer between all kinds of
>ism devices and all kinds of ism users.
>
>Benefits:
>- Cleaner separation of ISM and SMC-D functionality
>- simpler and less module dependencies
>- Clear interface definition.
>- Extendable for future devices and clients.
Fully agree.
>
>Request for comments:
>---------------------
>Any comments are welcome, but I am aware that this series needs more work.
>It may not be worth your time to do an in-depth review of the details, I am
>looking for feedback on the general idea.
>I am mostly interested in your thoughts and recommendations about the general
>concept, the location of net/ism, the structure of include/linux/ism.h, the
>KConfig and makefiles.
>
>Status of this RFC:
>-------------------
>This is a very early RFC to ask you for comments on this general idea.
>The RFC does not fullfill all criteria required for a patchset.
>The whole set compiles and runs, but I did not try all combinations of
>module and built-in yet. I did not check for checkpatch or any other checkers.
>Also I have only done very rudimentary quick tests of SMC-D. More testing is
>required.
>
>Background / Status quo:
>------------------------
>Currently s390 hardware provides virtual PCI ISM devices (ism_vpci). Their
>driver is in drivers/s390/net/ism_drv.c. The main user is SMC-D (net/smc).
>ism_vpci driver offers a client interface so other users/protocols
>can also use them, but it is still heavily intermingled with the smc code.
>Namely, the ISM vPCI module cannot be used without the SMC module, which
>feels artificial.
>
>The ISM concept is being extended:
>[1] proposed an ISM loopback interface (ism_lo), that can be used on non-s390
>architectures (e.g. between containers or to test SMC-D). A minimal implementation
>went upstream with [2]: ism_lo currently is a part of the smc protocol and rather
>hidden.
>
>[3] proposed a virtio definition of ISM (ism_virtio) that can be used between
>kvm guests.
>
>We will shortly send an RFC for an ISM client that uses ISM as transport for TTY.
>
>Concept:
>--------
>Create a shim layer in net/ism that contains common definitions and code for
>all ism devices and all ism clients.
>Any device or client module only needs to depend on this ism layer module and
>any device or client code only needs to include the definitions in
>include/linux/ism.h
>
>Ideas for next steps:
>---------------------
>- sysfs representation? e.g. as /sys/class/ism ?
>- provide a full-fledged ism loopback interface
> (runtime enable/disable, sysfs device, ..)
I think it's better if we can make this common for all ISM devices.
but yeah, that shoud be the next step.
Best regards,
Dust
>- additional clients (tty over ism)
>- additional devices (virtio-ism, ...)
>
>Link: [1] https://lore.kernel.org/netdev/1695568613-125057-1-git-send-email-guwen@linux.alibaba.com/
>Link: [2] https://lore.kernel.org/linux-kernel//20240428060738.60843-1-guwen@linux.alibaba.com/
>Link: [3] https://groups.oasis-open.org/communities/community-home/digestviewer/viewthread?GroupId=3973&MessageKey=c060ecf9-ea1a-49a2-9827-c92f0e6447b2&CommunityKey=2f26be99-3aa1-48f6-93a5-018dce262226&hlmlt=VT
>
>Alexandra Winter (7):
> net/ism: Create net/ism
> net/ism: Remove dependencies between ISM_VPCI and SMC
> net/ism: Use uuid_t for ISM GID
> net/ism: Add kernel-doc comments for ism functions
> net/ism: Move ism_loopback to net/ism
> s390/ism: Define ismvp_dev
> net/smc: Use only ism_ops
>
> MAINTAINERS | 7 +
> drivers/s390/net/Kconfig | 10 +-
> drivers/s390/net/Makefile | 4 +-
> drivers/s390/net/ism.h | 27 ++-
> drivers/s390/net/ism_drv.c | 467 ++++++++++++-------------------------
> include/linux/ism.h | 299 +++++++++++++++++++++---
> include/net/smc.h | 52 +----
> net/Kconfig | 1 +
> net/Makefile | 1 +
> net/ism/Kconfig | 27 +++
> net/ism/Makefile | 8 +
> net/ism/ism_loopback.c | 366 +++++++++++++++++++++++++++++
> net/ism/ism_loopback.h | 59 +++++
> net/ism/ism_main.c | 171 ++++++++++++++
> net/smc/Kconfig | 13 --
> net/smc/Makefile | 1 -
> net/smc/af_smc.c | 12 +-
> net/smc/smc_clc.c | 6 +-
> net/smc/smc_core.c | 6 +-
> net/smc/smc_diag.c | 2 +-
> net/smc/smc_ism.c | 112 +++++----
> net/smc/smc_ism.h | 29 ++-
> net/smc/smc_loopback.c | 427 ---------------------------------
> net/smc/smc_loopback.h | 60 -----
> net/smc/smc_pnet.c | 8 +-
> 25 files changed, 1183 insertions(+), 992 deletions(-)
> create mode 100644 net/ism/Kconfig
> create mode 100644 net/ism/Makefile
> create mode 100644 net/ism/ism_loopback.c
> create mode 100644 net/ism/ism_loopback.h
> create mode 100644 net/ism/ism_main.c
> delete mode 100644 net/smc/smc_loopback.c
> delete mode 100644 net/smc/smc_loopback.h
>
>--
>2.45.2
>
next prev parent reply other threads:[~2025-01-16 9:32 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 19:55 [RFC net-next 0/7] Provide an ism layer Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 1/7] net/ism: Create net/ism Alexandra Winter
2025-01-16 20:08 ` Andrew Lunn
2025-01-17 12:06 ` Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 2/7] net/ism: Remove dependencies between ISM_VPCI and SMC Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 3/7] net/ism: Use uuid_t for ISM GID Alexandra Winter
2025-01-20 17:18 ` Simon Horman
2025-01-22 14:46 ` Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 4/7] net/ism: Add kernel-doc comments for ism functions Alexandra Winter
2025-01-15 22:06 ` Halil Pasic
2025-01-20 6:32 ` Dust Li
2025-01-20 9:56 ` Alexandra Winter
2025-01-20 10:07 ` Julian Ruess
2025-01-20 11:35 ` Alexandra Winter
2025-01-20 10:34 ` Niklas Schnelle
2025-01-22 15:02 ` Dust Li
2025-01-15 19:55 ` [RFC net-next 5/7] net/ism: Move ism_loopback to net/ism Alexandra Winter
2025-01-20 3:55 ` Dust Li
2025-01-20 9:31 ` Alexandra Winter
2025-02-06 17:36 ` Julian Ruess
2025-02-10 10:39 ` Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 6/7] s390/ism: Define ismvp_dev Alexandra Winter
2025-01-15 19:55 ` [RFC net-next 7/7] net/smc: Use only ism_ops Alexandra Winter
2025-01-16 9:32 ` Dust Li [this message]
2025-01-16 11:55 ` [RFC net-next 0/7] Provide an ism layer Julian Ruess
2025-01-16 16:17 ` Alexandra Winter
2025-01-16 17:08 ` Julian Ruess
2025-01-17 2:13 ` Dust Li
2025-01-17 10:38 ` Niklas Schnelle
2025-01-17 15:02 ` Andrew Lunn
2025-01-17 16:00 ` Niklas Schnelle
2025-01-17 16:33 ` Andrew Lunn
2025-01-17 16:57 ` Niklas Schnelle
2025-01-17 20:29 ` Andrew Lunn
2025-01-20 6:21 ` Dust Li
2025-01-20 12:03 ` Alexandra Winter
2025-01-20 16:01 ` Andrew Lunn
2025-01-20 17:25 ` Alexandra Winter
2025-01-18 15:31 ` Dust Li
2025-01-28 16:04 ` Alexandra Winter
2025-02-10 5:08 ` Dust Li
2025-02-10 9:38 ` Alexandra Winter
2025-02-11 1:57 ` Dust Li
2025-02-16 15:40 ` Wen Gu
2025-02-19 11:25 ` [RFC net-next 0/7] Provide an ism layer - naming Alexandra Winter
2025-02-25 1:36 ` Dust Li
2025-02-25 8:40 ` Alexandra Winter
2025-01-17 13:00 ` [RFC net-next 0/7] Provide an ism layer Alexandra Winter
2025-01-17 15:10 ` Andrew Lunn
2025-01-17 16:20 ` Alexandra Winter
2025-01-20 10:28 ` Alexandra Winter
2025-01-22 3:04 ` Dust Li
2025-01-22 12:02 ` Alexandra Winter
2025-01-22 12:05 ` Alexandra Winter
2025-01-22 14:10 ` Dust Li
2025-01-17 15:06 ` Andrew Lunn
2025-01-17 15:38 ` Alexandra Winter
2025-02-16 15:38 ` Wen Gu
2025-01-17 11:04 ` Alexandra Winter
2025-01-18 15:24 ` Dust Li
2025-01-20 11:45 ` Alexandra Winter
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=20250116093231.GD89233@linux.alibaba.com \
--to=dust.li@linux.alibaba.com \
--cc=agordeev@linux.ibm.com \
--cc=alibuda@linux.alibaba.com \
--cc=andrew+netdev@lunn.ch \
--cc=borntraeger@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gbayer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=guwen@linux.alibaba.com \
--cc=hca@linux.ibm.com \
--cc=horms@kernel.org \
--cc=jaka@linux.ibm.com \
--cc=julianr@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=pabeni@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=tonylu@linux.alibaba.com \
--cc=twinkler@linux.ibm.com \
--cc=wenjia@linux.ibm.com \
--cc=wintera@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.