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

Alexandra Winter
2025-01-28T16:05:06Z

On 18.01.25 16:31, Dust Li wrote:
> On 2025-01-17 11:38:39, Niklas Schnelle wrote:
>> 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.
>
> Make sense, I agree with MCD.
>
> Best regard,
> Dust
>

In the discussion with Andrew Lunn, it showed that
a) we need an abstract description of 'ISM' devices (noted)
b) DMBs (Direct Memory Buffers) are a critical differentiator.

So what do your think of Direct Memory Communication (DMC) as class name for these devices?

I don't have a strong preference (we could also stay with ISM). But DMC may be a bit more
concrete than MCD or ISM.