Re: [PATCH net-next v3 00/11] net/smc: SMC intra-OS shortcut with loopback-ism

[Paolo Abeni <pabeni@redhat.com>]

On Tue, 2024-03-12 at 22:27 +0800, Wen Gu wrote:
> This patch set acts as the second part of the new version of [1] (The first
> part can be referred from [2]), the updated things of this version are listed
> at the end.
> 
> - Background
> 
> SMC-D is now used in IBM z with ISM function to optimize network interconnect
> for intra-CPC communications. Inspired by this, we try to make SMC-D available
> on the non-s390 architecture through a software-implemented Emulated-ISM device,
> that is the loopback-ism device here, to accelerate inter-process or
> inter-containers communication within the same OS instance.
> 
> - Design
> 
> This patch set includes 3 parts:
> 
>  - Patch #1-#2: some prepare work for loopback-ism.
>  - Patch #3-#7: implement loopback-ism device. Noted that loopback-ism now
>    serves only SMC and no userspace interface exposed.
>  - Patch #10-#15: memory copy optimization for intra-OS scenario.
> 
> The loopback-ism device is designed as an ISMv2 device and not be limited to
> a specific net namespace, ends of both inter-process connection (1/1' in diagram
> below) or inter-container connection (2/2' in diagram below) can find the same
> available loopback-ism and choose it during the CLC handshake.
> 
>  Container 1 (ns1)                              Container 2 (ns2)
>  +-----------------------------------------+    +-------------------------+
>  | +-------+      +-------+      +-------+ |    |        +-------+        |
>  | | App A |      | App B |      | App C | |    |        | App D |<-+     |
>  | +-------+      +---^---+      +-------+ |    |        +-------+  |(2') |
>  |     |127.0.0.1 (1')|             |192.168.0.11       192.168.0.12|     |
>  |  (1)|   +--------+ | +--------+  |(2)   |    | +--------+   +--------+ |
>  |     `-->|   lo   |-` |  eth0  |<-`      |    | |   lo   |   |  eth0  | |
>  +---------+--|---^-+---+-----|--+---------+    +-+--------+---+-^------+-+
>               |   |           |                                  |
>  Kernel       |   |           |                                  |
>  +----+-------v---+-----------v----------------------------------+---+----+
>  |    |                            TCP                               |    |
>  |    |                                                              |    |
>  |    +--------------------------------------------------------------+    |
>  |                                                                        |
>  |                           +--------------+                             |
>  |                           | smc loopback |                             |
>  +---------------------------+--------------+-----------------------------+
> 
> loopback-ism device creates DMBs (shared memory) for each connection peer.
> Since data transfer occurs within the same kernel, the sndbuf of each peer
> is only a descriptor and point to the same memory region as peer DMB, so that
> the data copy from sndbuf to peer DMB can be avoided in loopback-ism case.
> 
>  Container 1 (ns1)                              Container 2 (ns2)
>  +-----------------------------------------+    +-------------------------+
>  | +-------+                               |    |        +-------+        |
>  | | App C |-----+                         |    |        | App D |        |
>  | +-------+     |                         |    |        +-^-----+        |
>  |               |                         |    |          |              |
>  |           (2) |                         |    |     (2') |              |
>  |               |                         |    |          |              |
>  +---------------|-------------------------+    +----------|--------------+
>                  |                                         |
>  Kernel          |                                         |
>  +---------------|-----------------------------------------|--------------+
>  | +--------+ +--v-----+                           +--------+ +--------+  |
>  | |dmb_desc| |snd_desc|                           |dmb_desc| |snd_desc|  |
>  | +-----|--+ +--|-----+                           +-----|--+ +--------+  |
>  | +-----|--+    |                                 +-----|--+             |
>  | | DMB C  |    +---------------------------------| DMB D  |             |
>  | +--------+                                      +--------+             |
>  |                                                                        |
>  |                           +--------------+                             |
>  |                           | smc loopback |                             |
>  +---------------------------+--------------+-----------------------------+
> 
> - Benchmark Test
> 
>  * Test environments:
>       - VM with Intel Xeon Platinum 8 core 2.50GHz, 16 GiB mem.
>       - SMC sndbuf/DMB size 1MB.
> 
>  * Test object:
>       - TCP: run on TCP loopback.
>       - SMC lo: run on SMC loopback-ism.
> 
> 1. ipc-benchmark (see [3])
> 
>  - ./<foo> -c 1000000 -s 100
> 
>                             TCP                  SMC-lo
> Message
> rate (msg/s)              81433                  143938(+76.75%)
> 
> 2. sockperf
> 
>  - serv: <smc_run> taskset -c <cpu> sockperf sr --tcp
>  - clnt: <smc_run> taskset -c <cpu> sockperf { tp | pp } --tcp --msg-size={ 64000 for tp | 14 for pp } -i 127.0.0.1 -t 30
> 
>                             TCP                  SMC-lo
> Bandwidth(MBps)         4903.07                 7978.69(+62.73%)
> Latency(us)               6.095                   3.539(-41.94%)
> 
> 3. nginx/wrk
> 
>  - serv: <smc_run> nginx
>  - clnt: <smc_run> wrk -t 8 -c 1000 -d 30 http://127.0.0.1:80
> 
>                            TCP                   SMC-lo
> Requests/s           161665.67                244272.41(+51.10%)
> 
> 4. redis-benchmark
> 
>  - serv: <smc_run> redis-server
>  - clnt: <smc_run> redis-benchmark -h 127.0.0.1 -q -t set,get -n 400000 -c 200 -d 1024
> 
>                            TCP                   SMC-lo
> GET(Requests/s)       88790.23                117474.30(+32.31%)
> SET(Requests/s)       87508.20                118623.96(+35.57%)
> 
> 
> Change log:
> 
> v3->v2:
> - Patch #11: use tasklet_schedule(&conn->rx_tsklet) instead of smcd_cdc_rx_handler()
>   to avoid possible recursive locking of conn->send_lock and use {read|write}_lock_bh()
>   to acquire dmb_ht_lock.
> 
> v2->v1:
> Link: https://lore.kernel.org/netdev/20240307095536.29648-1-guwen@linux.alibaba.com/
> - All the patches: changed the term virtual-ISM to Emulated-ISM as defined by SMCv2.1.
> - Patch #3: optimized the description of SMC_LO config. Avoid exposing loopback-ism
>   to sysfs and remove all the knobs until future definition clear.
> - Patch #3: try to make lockdep happy by using read_lock_bh() in smc_lo_move_data().
> - Patch #6: defaultly use physical contiguous DMB buffers.
> - Patch #11: defaultly enable DMB no-copy for loopback-ism and free the DMB in
>   unregister_dmb or detach_dmb when dmb_node->refcnt reaches 0, instead of using
>   wait_event to keep waiting in unregister_dmb.
> 
> v1->RFC:
> Link: https://lore.kernel.org/netdev/20240111120036.109903-1-guwen@linux.alibaba.com/
> - Patch #9: merge rx_bytes and tx_bytes as xfer_bytes statistics:
>   /sys/devices/virtual/smc/loopback-ism/xfer_bytes
> - Patch #10: add support_dmb_nocopy operation to check if SMC-D device supports
>   merging sndbuf with peer DMB.
> - Patch #13 & #14: introduce loopback-ism device control of DMB memory type and
>   control of whether to merge sndbuf and DMB. They can be respectively set by:
>   /sys/devices/virtual/smc/loopback-ism/dmb_type
>   /sys/devices/virtual/smc/loopback-ism/dmb_copy
>   The motivation for these two control is that a performance bottleneck was
>   found when using vzalloced DMB and sndbuf is merged with DMB, and there are
>   many CPUs and CONFIG_HARDENED_USERCOPY is set [4]. The bottleneck is caused
>   by the lock contention in vmap_area_lock [5] which is involved in memcpy_from_msg()
>   or memcpy_to_msg(). Currently, Uladzislau Rezki is working on mitigating the
>   vmap lock contention [6]. It has significant effects, but using virtual memory
>   still has additional overhead compared to using physical memory.
>   So this new version provides controls of dmb_type and dmb_copy to suit
>   different scenarios.
> - Some minor changes and comments improvements.
> 
## Form letter - net-next-closed

The merge window for v6.9 has begun and we have already posted our pull
request. Therefore net-next is closed for new drivers, features, code
refactoring and optimizations. We are currently accepting bug fixes
only.

Please repost when net-next reopens after March 25th.

RFC patches sent for review only are obviously welcome at any time.

See:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle

-- 
pw-bot: defer