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

[Alexandra Winter <wintera@linux.ibm.com>]

On 25.02.25 02:36, Dust Li wrote:
> On 2025-02-19 12:25:59, Alexandra Winter wrote:
>>
>>
>> On 16.02.25 16:40, Wen Gu wrote:
>>>
>>>
>>> On 2025/2/10 17:38, Alexandra Winter wrote:
>>>>
>>>>
>>>> On 10.02.25 06:08, Dust Li wrote:
>>>>> On 2025-01-28 17:04:53, Alexandra Winter wrote:
>>>>>>
>>>>>>
>>>>>> 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<---

>>>>>>
>>>>>>
>>>>>
>>>>> Hi Winter,
>>>>>
>>>>> Sorry for the late reply; we were on break for the Chinese Spring
>>>>> Festival.
>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> I personally prefer MCD over Direct Memory Communication (DMC).
>>>>>
>>>>> For loopback or Virtio-ISM, DMC seems like a good choice. However, for
>>>>> IBM ISM, since there's a DMA copy involved, it doesn’t seem truly "Direct,"
>>>>> does it?
>>>>>
>>>>> Additionally, since we are providing a device, MCD feels like a more
>>>>> fitting choice, as it aligns better with the concept of a "device."
>>>>>
>>>>> Best regards,
>>>>> Dust
>>>>
>>>> Thank you for your thoughts, Dust.
>>>> For me the 'D as 'direct' is not so much about the number of copies, but more about the
>>>> aspect, that you can directly write at any offset into the buffer. I.e. no queues.
>>>> More like the D in DMA or RDMA.
>>>>
>>>
>>> IMHO the 'D' means that the CPU copy does not need to be involved, and memory access
>>> only involves between memory and IO devices. So under this semantics, I think 'DMC'
>>> also applies to s390 ism device, since IIUC the s390 ism directly access to the memory
>>> which is passed down by move_data(). The exception is lo-ism, where the device
>>> actually doesn't need to access the memory(DMB), since the data has been put into the
>>> shared memory once the sendmsg() is called and no copy or move is needed. But this
>>> is not a violation of name, just a special kind of short-cut. So DMC makes sense
>>> to me.
>>>
>>>> I am preparing a talk for netdev in March about this subject, and the more I work on it,
>>>> it seems to me that the buffers ('B'), that are
>>>> a) only authorized for a single remote device and
>>>> b) can be accessed at any offset
>>>> are the important differentiator compared other virtual devices.
>>>> So maybe 'D' for Dedicated?
>>>>
>>>> I even came up with
>>>> dibs - Dedicated Internal Buffer Sharing or
>>>> dibc - Dedicated Internal Buffer Communication
>>>> (ok, I like the sound and look of the 'I'. But being on the same hardware as opposed
>>>> to RDMA is also an important aspect.)
>>>>
>>>>
>>>> MCD - 'memory communication device' sounds rather vague to me. But if it is the
>>>> smallest common denominator, i.e. the only thing we can all agree on, I could live with it.
>>>>
>>
>>
>> Could you guys accept
>> 'DIBS - Dedicated Internal Buffer Sharing'
>> as well?
>> -> dibs_layer, /class/dibs/, dibs_dev
>>
>> That is currently my favourite.
>>
> 
> I think you might prefer a name that describes shared memory,
> but I personally believe that something reflecting the device itself
> would be more fitting.
> 
> To be honest, here’s my ranking:
> 
> MCD > DMC > DIBS
> 
> Best regards,
> Dust


Thank you keeping the discussion going, Dust.
I know there is no perfect answer, but imo good names can make things easier to
understand.
For reasons described above, I would like to have a 'B for buffer' in the prefix.
There are many I/O concepts that share memory somehow, but the concept of a dmb dedicated to
exactly 2 devices is a differentiator, imo.
I thought 'D for device' was somehow redundant and obvious. But you now you are saying that for
you the device is a differentiator? As opposed to other memory sharing techniques that work
without devices? Maybe you have a point...

So maybe DMB - Direct Memory Buffers is a good term?
I know we use it for the buffers already, but they are actually a common aspect for all devices
and clients, right? So we could define a dmb layer with generic dmb_devices that can be used by dmb_clients
to communicate via dmb_bufs.