On 16.01.25 21:08, Andrew Lunn wrote: >> +ISM (INTERNAL SHARED MEMORY) >> +M: Alexandra Winter <wintera@xxxxxxxxxxxxx> >> +L: netdev@xxxxxxxxxxxxxxx >> +S: Supported >> +F: include/linux/ism.h >> +F: net/ism/ > > Is there any high level documentation about this? As the ISM devices were developed for SMC-D, the only documentation is about their usage for SMC-D. e.g.: https://www.ibm.com/support/pages/system/files/inline-files/IBM%20Shared%20Memory%20Communications%20Version%202.1%20Emulated-ISM_0.pdf (page 33) https://community.ibm.com/community/user/ibmz-and-linuxone/viewdocument/2021-07-15-boosting-tcp-networking?CommunityKey=c1293167-6d93-448e-8854-3068846d3dfe&tab=librarydocuments But those do not go into much detail. We now want to provide interfaces for other usecases in Linux. ism.h would be the place to explicitely state the assumptions, restrictions and requirements in a single place, so future devices and clients know about them. > > A while back, TI was trying to upstream something for one of there > SoCs. It was a multi CPU system, with not all CPUs used for SMP, but > one or two kept for management and real time tasks, not even running > Linux. They had a block of shared memory used for communication > between the CPUs/OSes, along with rproc. They layered an ethernet > driver on top of this, with buffers for frames in the shared memory. > > Could ISM be used for something like this? > > Andrew If the communication endpoints were represented as devices, that sounds like a similar concept. I think you could implement a client that provides network devices on top of ism devices. (mapping MACs to GIDs) As the memory buffers are set up for 1 sender and 1 receiver, it would either create some additional latency, if you setup buffers for each message or additional memory consumption, if you try to keep and re-use the buffers. I'm not sure what the benefit ISM would provide as ethernet device. A shared network card would probably outperform such a usecase. SMC exploits ISM for TCP traffic. There the buffers are kept per socket connection, and a lot of the TCP/IP mechanisms are not neccessary, because transport is reliable, synchronous and in-order. Thus latency is minimal.
