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).
