On 2023/9/25 21:29, Alexandra Winter wrote:
On 25.09.23 13:50, Alexandra Winter wrote:
On 24.09.23 17:16, Wen Gu wrote:
This patch introduces a kind of loopback device for SMC-D. The device
is created when SMC module is loaded and destroyed when the SMC module
is unloaded. The loopback device is a kernel device used only by the
SMC module and is not restricted by net namespace, so it can be used
for local inter-process or inter-container communication.
Signed-off-by: Wen Gu <guwen@xxxxxxxxxxxxxxxxx>
---
net/smc/Kconfig | 13 ++++
net/smc/Makefile | 2 +-
net/smc/af_smc.c | 12 +++-
net/smc/smc_loopback.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++++
net/smc/smc_loopback.h | 33 ++++++++++
5 files changed, 223 insertions(+), 2 deletions(-)
create mode 100644 net/smc/smc_loopback.c
create mode 100644 net/smc/smc_loopback.h
Hello Wen Gu,
thank you for adding the Kconfig, so the distributions can decide when to offer this feature.
I propose you add some kind of runtime switch as well. Not every user who loads the SMC module
may want to exploit smcd-loopback. Especially in native environements without containers.
If no RoCE interfaces or no ISM interfaces exist, the respective handling is skipped in SMC.
If loopback is always created unconditionally, there is no way to opt-out.
Another thing came to my mind:
When loopback is created and registered when the SMC module is loaded, it will implicitly always have highest priority, right?
That should be stated somewhere.
Also, if you create a runtime switch this will change, so then you need to decide about priority of loopback vs ISM device (and other future smcd-devices).
Yes. I think the question may become 'How users to define the priority of existing the smcd devices'. In the past,
all the ISMv2 has nearly same performance so priority is not very important. But now there are other virtual ISM
devices, they perform differently.
My rough idea is defining a fixed priority, such as whenever loopback-ism is enabled, it is always the first in the
slots. If fixed priority is not appropriate, low-priority devices can be prioritized by disabling high-priority devices.
So it seems that the runtime switch of the loopback-ism is even more necessary.
Thanks,
Wen Gu
