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: <dc2ff4c83ce8f7884872068570454f285510bda2.camel@linux.ibm.com>
Date: Fri, 17 Jan 2025 11:38:39 +0100
From: Niklas Schnelle <schnelle@...ux.ibm.com>
To: dust.li@...ux.alibaba.com, Alexandra Winter <wintera@...ux.ibm.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>
Cc: 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 Fri, 2025-01-17 at 10:13 +0800, Dust Li wrote:
> > 
---8<---
> > 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). 
> > 
> > 
> > So where does the 'H' come from? If you want to call it Shared Memory _D_evice?
> 
> Oh, I was trying to refer to SHM(Share memory file in the userspace, see man
> shm_open(3)). SMD is also OK.
> 
> > 
> > 
> > To my knowledge, a
> > > > "Shared Memory Device" better encapsulates the functionality we're
> > > > aiming to implement. 
> > 
> > 
> > Could you explain why that would be better?
> > 'Internal Shared Memory' is supposed to be a bit of a counterpart to the
> > Remote 'R' in RoCE. Not the greatest name, but it is used already by our ISM
> > devices and by ism_loopback. So what is the benefit in changing it?
> 
> I believe that if we are going to separate and refine the code, and add
> a common subsystem, we should choose the most appropriate name.
> 
> In my opinion, "ISM" doesn’t quite capture what the device provides.
> Since we’re adding a "Device" that enables different entities (such as
> processes or VMs) to perform shared memory communication, I think a more
> fitting name would be better. If you have any alternative suggestions,
> I’m open to them.

I kept thinking about this a bit and I'd like to propose yet another
name for this group of devices: Memory Communication Devices (MCD)

One important point I see is that there is a bit of a misnomer in the
existing ISM name in that our ISM device does in fact *not* share
memory in the common sense of the "shared memory" wording. Instead it
copies data between partitions of memory that share a common
cache/memory hierarchy while not sharing the memory itself. loopback-
ism and a possibly future virtio-ism on the other hand would share
memory in the "shared memory" sense. Though I'd very much hope they
will retain a copy mode to allow use in partition scenarios.

With that background I think the common denominator between them and
the main idea behind ISM is that they facilitate communication via
memory buffers and very simple and reliable copy/share operations. I
think this would also capture our planned use-case of devices (TTYs,
block devices, framebuffers + HID etc) provided by a peer on top of
such a memory communication device.

Thanks,
Niklas