[PATCH v3 00/25] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

here is v3 of IBNBD/IBTRS patches, which have minor changes:
sparse fixes, comments, sysfs API changes, etc.

 Changelog
 ---------

v3:
  o Sparse fixes:
     - le32 -> le16 conversion
	 - pcpu and RCU wrong declaration
	 - sysfs: dynamically alloc array of sockaddr structures to reduce
	   size of a stack frame

  o Rename sysfs folder on client and server sides to show source and
    destination addresses of the connection, i.e.:
	   .../<session-name>/paths/<src@dst>/

  o Remove external inclusions from Makefiles.

v2:
  o IBNBD:
     - No legacy request IO mode, only MQ is left.

  o IBTRS:
     - No FMR registration, only FR is left.

     - By default memory is always registered for the sake of the security,
	   i.e. by default no pd is created with IB_PD_UNSAFE_GLOBAL_RKEY.

	 - Server side (target) always does memory registration and exchanges
	   MRs dma addresses with client for direct writes from client side.

	 - Client side (initiator) has `noreg_cnt` module option, which specifies
	   sg number, from which read IO should be registered.  By default 0
	   is set, i.e. always register memory for read IOs. (IBTRS protocol
	   does not require registration for writes, which always go directly
	   to server memory).

	 - Proper DMA sync with ib_dma_sync_single_for_(cpu|device) calls.

     - Do signalled IB_WR_LOCAL_INV.

	 - Avoid open-coding of string conversion to IPv4/6 sockaddr,
	   inet_pton_with_scope() is used instead.

     - Introduced block device namespaces configuration on server side
	   (target) to avoid security gap in not trusted environment, when
	   client can map a block device which does not belong to him.
	   When device namespaces are enabled on server side, server opens
	   device using client's session name in the device path, where
	   session name is a random token, e.g. GUID.  If server is configured
	   to find device namespaces in a folder /run/ibnbd-guid/, then
	   request to map device 'sda1' from client with session 'A' (or any
	   token) will be resolved by path /run/ibnbd-guid/A/sda1.

     - README is extended with description of IBTRS and IBNBD protocol,
	   e.g. how IB IMM field is used to acknowledge IO requests or
	   heartbeats.

     - IBTRS/IBNBD client and server modules are registered as devices in
	   the kernel in order to have all sysfs configuration entries under
	   /sys/devices/virtual/ in order not to spoil /sys/kernel directory.
	   I failed to switch configuration to configfs, because of the
	   several reasons:

	   a) configfs entries created from kernel side using
	      configfs_register_group() API call can't be removed from
		  userspace side using rmdir() syscall.  That is required
		  behaviour for IBTRS when session is created by API call and
		  not from userspace.
			   
          Actually, I have a patch for configfs to solve a), but then
		  b) comes.

       b) configfs show/store callbacks are racy by design (in
	      contradiction to kernfs), i.e. even dentry is unhashed, opener
		  of it can be faster and in few moments later those callbacks
		  can be invoked.  To guarantee that all openers left and nobody
		  is able to access an entry after configfs_drop_dentry() is
		  returned additional hairy code should be written with wait
		  queues, locks, etc.  I didn't like at all what I eventually
		  got, gave up and left as is, i.e. sysfs.
			    

  What is left unchanged on IBTRS side but was suggested to modify:

     - Bart suggested to use sbitmap instead of calling find_first_zero_bit()
	   and friends.  I found calling pure bit API is more explicit in
	   comparison to sbitmap - there is no need in using sbitmap_queue
	   and all the power of wait queues, no benefits in terms of LoC
	   as well.
	   
     - I did several attempts to unify approach of wrapping ib_device
	   with ULP device structure (e.g. device pool or using ib_client
	   API) but it turns out to be that none of these approaches bring
	   simplicity, so IBTRS still creates ULP specific device on demand
	   and keeps it in the list.

     - Sagi suggested to extend inet_pton_with_scope() with gid to
	   sockaddr conversion, but after IPv6 conversion (gid is compliant
	   with IPv6) special RDMA magic should be done in order to setup
	   IB port space range, which is very specific and does not fit to
	   be some generic library helper.  And am I right that gid is not
	   used and seems dying?

  * https://lwn.net/Articles/755075/

v1:
  - IBTRS: load-balancing and IO fail-over using multipath features were added.

  - Major parts of the code were rewritten, simplified and overall code
    size was reduced by a quarter.

  * https://lwn.net/Articles/746342/

v0:
  - Initial submission

  * https://lwn.net/Articles/718181/


 Introduction
 -------------

IBTRS (InfiniBand Transport) is a reliable high speed transport library
which allows for establishing connection between client and server
machines via RDMA. It is optimized to transfer (read/write) IO blocks
in the sense that it follows the BIO semantics of providing the
possibility to either write data from a scatter-gather list to the
remote side or to request ("read") data transfer from the remote side
into a given set of buffers.

IBTRS is multipath capable and provides I/O fail-over and load-balancing
functionality, i.e. in IBTRS terminology, an IBTRS path is a set of RDMA
CMs and particular path is selected according to the load-balancing policy.

IBNBD (InfiniBand Network Block Device) is a pair of kernel modules
(client and server) that allow for remote access of a block device on
the server over IBTRS protocol. After being mapped, the remote block
devices can be accessed on the client side as local block devices.
Internally IBNBD uses IBTRS as an RDMA transport library.

Why?

   - IBNBD/IBTRS is developed in order to map thin provisioned volumes,
     thus internal protocol is simple.
   - IBTRS was developed as an independent RDMA transport library, which
     supports fail-over and load-balancing policies using multipath, thus
     it can be used for any other IO needs rather than only for block
     device.
   - IBNBD/IBTRS is faster than NVME over RDMA.
     Old comparison results:
     https://www.spinics.net/lists/linux-rdma/msg48799.html
     New comparison results: see performance measurements section below.

Key features of IBTRS transport library and IBNBD block device:

o High throughput and low latency due to:
   - Only two RDMA messages per IO.
   - IMM InfiniBand messages on responses to reduce round trip latency.
   - Simplified memory management: memory allocation happens once on
     server side when IBTRS session is established.

o IO fail-over and load-balancing by using multipath.  According to
  our test loads additional path brings ~20% of bandwidth.  

o Simple configuration of IBNBD:
   - Server side is completely passive: volumes do not need to be
     explicitly exported.
   - Only IB port GID and device path needed on client side to map
     a block device.
   - A device is remapped automatically i.e. after storage reboot.

Commits for kernel can be found here:
   https://github.com/profitbricks/ibnbd/commits/linux-4.17-rc7--ibnbd-v3

The out-of-tree modules are here:
   https://github.com/profitbricks/ibnbd/

Vault 2017 presentation:
   http://events.linuxfoundation.org/sites/events/files/slides/IBNBD-Vault-2017.pdf


 Performance measurements
 ------------------------

o FR and FMR:

  Firstly I would like to start performance measurements with (probably
  well known) observations that FR is slower than FMR by ~40% on Mellanox
  ConnectX-2 and by ~15% on ConnectX-3. That is a huge numbers, e.g. FIO
  results on IBNBD:

  - on ConnectX-2 (MT26428)
    x64 CPUs AMD Opteron(tm) Processor 6282 SE

     rw=randread, bandwidth in Kbytes:
     jobs   IBNBD (FMR)   IBNBD (FR)     Change
       x1       1037624       932951     -10.1%
       x8       2569649       1543074    -40.0%
      x16       2751461       1531282    -44.3%
      x24       2360887       1396153    -40.9%
      x32       1873174       1215334    -35.1%
      x40       1995846       1255781    -37.1%
      x48       2004740       1240931    -38.1%
      x56       2076871       1250333    -39.8%
      x64       2051668       1229389    -40.1%

  - on ConnectX-3 (MT4099)
    x40 CPUs Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz

     rw=randread, bandwidth in Kbytes:
     jobs   IBNBD (FMR)   IBNBD (FR)     Change
       x1       2243322       1961216    -12.6%
       x8       4389048       4012912     -8.6%
      x16       4473103       4033837     -9.8%
      x24       4570209       3939186    -13.8%
      x32       4576757       3843434    -16.0%
      x40       4468110       3696896    -17.3%
      x48       4848049       4106259    -15.3%
      x56       4872790       4141374    -15.0%
      x64       4967287       4207317    -15.3%

  I missed the whole history why FMR is considered as outdated, why FMR
  is a no way, I would very much appreciate if someone would explain me
  why FR should be prefered. Is there a link with a clear explanation?

o IBNBD and NVMEoRDMA

  Here I would like to publish IBNBD and NVMEoRDMA comparison results
  with FR memory registration on each IO (i.e. with the following modules
  params: 'register_always=Y' for NVME and 'noreg_cnt=0' for IBTRS).

  - on ConnectX-2 (MT26428)
    x64 CPUs AMD Opteron(tm) Processor 6282 SE

     rw=randread, bandwidth in Kbytes:
     jobs        IBNBD     NVMEoRDMA     Change
       x1       932951        975425      +4.6%
       x8      1543074       1504416      -2.5%
      x16      1531282       1432937      -6.4%
      x24      1396153       1244858     -10.8%
      x32      1215334       1066607     -12.2%
      x40      1255781       1076841     -14.2%
      x48      1240931       1066453     -14.1%
      x56      1250333       1065879     -14.8%
      x64      1229389       1064199     -13.4%

     rw=randwrite, bandwidth in Kbytes:
     jobs        IBNBD     NVMEoRDMA     Change
       x1       1416413      1181102     -16.6%
       x8       2438615      1977051     -18.9%
      x16       2436924      1854223     -23.9%
      x24       2430527      1714580     -29.5%
      x32       2425552      1641288     -32.3%
      x40       2378784      1592788     -33.0%
      x48       2202260      1511895     -31.3%
      x56       2207013      1493400     -32.3%
      x64       2098949      1432951     -31.7%


  - on ConnectX-3 (MT4099)
    x40 CPUs Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz

     rw=randread, bandwidth in Kbytes:
     jobs        IBNBD     NVMEoRDMA     Change
       x1      1961216       2046572      +4.4%
       x8      4012912       4059410      +1.2%
      x16      4033837       3968410      -1.6%
      x24      3939186       3770729      -4.3%
      x32      3843434       3623869      -5.7%
      x40      3696896       3448772      -6.7%
      x48      4106259       3729201      -9.2%
      x56      4141374       3732954      -9.9%
      x64      4207317       3805638      -9.5%

     rw=randwrite, bandwidth in Kbytes:
     jobs        IBNBD     NVMEoRDMA     Change
       x1      3195637       2479068     -22.4%
       x8      4576924       4541743      -0.8%
      x16      4581528       4555459      -0.6%
      x24      4692540       4595963      -2.1%
      x32      4686968       4540456      -3.1%
      x40      4583814       4404859      -3.9%
      x48      4969587       4710902      -5.2%
      x56      4996101       4701814      -5.9%
      x64      5083460       4759663      -6.4%

  The interesting observation is that on machine with Intel CPUs and
  ConnectX-3 card the difference between IBNBD and NVME bandwidth is
  significantly smaller comparing to AMD and ConnectX-2.  I did not
  thoroughly investiage that behaviour, but suspect that the devil
  is in Intel vs AMD architecture and probably how NUMAs are organized,
  i.e. Intel has 2 NUMA nodes against 8 on AMD.  If someone is interested
  in those results and can point me out where to dig on NVME side I can
  investigate deeply why exactly NVME bandwidth significantly drops on
  AMD machine with Connect-X2.

  Latest shiny graphs are here:
  https://docs.google.com/spreadsheets/d/1vxSoIvfjPbOWD61XMeN2_gPGxsxrbIUOZADk1UX5lj0

Roman Pen (25):
  sysfs: export sysfs_remove_file_self()
  ibtrs: public interface header to establish RDMA connections
  ibtrs: private headers with IBTRS protocol structs and helpers
  ibtrs: core: lib functions shared between client and server modules
  ibtrs: client: private header with client structs and functions
  ibtrs: client: main functionality
  ibtrs: client: statistics functions
  ibtrs: client: sysfs interface functions
  ibtrs: server: private header with server structs and functions
  ibtrs: server: main functionality
  ibtrs: server: statistics functions
  ibtrs: server: sysfs interface functions
  ibtrs: include client and server modules into kernel compilation
  ibtrs: a bit of documentation
  ibnbd: private headers with IBNBD protocol structs and helpers
  ibnbd: client: private header with client structs and functions
  ibnbd: client: main functionality
  ibnbd: client: sysfs interface functions
  ibnbd: server: private header with server structs and functions
  ibnbd: server: main functionality
  ibnbd: server: functionality for IO submission to file or block dev
  ibnbd: server: sysfs interface functions
  ibnbd: include client and server modules into kernel compilation
  ibnbd: a bit of documentation
  MAINTAINERS: Add maintainer for IBNBD/IBTRS modules

 MAINTAINERS                                    |   14 +
 drivers/block/Kconfig                          |    2 +
 drivers/block/Makefile                         |    1 +
 drivers/block/ibnbd/Kconfig                    |   22 +
 drivers/block/ibnbd/Makefile                   |   11 +
 drivers/block/ibnbd/README                     |  299 +++
 drivers/block/ibnbd/ibnbd-clt-sysfs.c          |  685 ++++++
 drivers/block/ibnbd/ibnbd-clt.c                | 1817 +++++++++++++++
 drivers/block/ibnbd/ibnbd-clt.h                |  172 ++
 drivers/block/ibnbd/ibnbd-log.h                |   71 +
 drivers/block/ibnbd/ibnbd-proto.h              |  364 +++
 drivers/block/ibnbd/ibnbd-srv-dev.c            |  413 ++++
 drivers/block/ibnbd/ibnbd-srv-dev.h            |  149 ++
 drivers/block/ibnbd/ibnbd-srv-sysfs.c          |  242 ++
 drivers/block/ibnbd/ibnbd-srv.c                |  946 ++++++++
 drivers/block/ibnbd/ibnbd-srv.h                |  100 +
 drivers/infiniband/Kconfig                     |    1 +
 drivers/infiniband/ulp/Makefile                |    1 +
 drivers/infiniband/ulp/ibtrs/Kconfig           |   20 +
 drivers/infiniband/ulp/ibtrs/Makefile          |   13 +
 drivers/infiniband/ulp/ibtrs/README            |  390 ++++
 drivers/infiniband/ulp/ibtrs/ibtrs-clt-stats.c |  455 ++++
 drivers/infiniband/ulp/ibtrs/ibtrs-clt-sysfs.c |  520 +++++
 drivers/infiniband/ulp/ibtrs/ibtrs-clt.c       | 2844 ++++++++++++++++++++++++
 drivers/infiniband/ulp/ibtrs/ibtrs-clt.h       |  315 +++
 drivers/infiniband/ulp/ibtrs/ibtrs-log.h       |   91 +
 drivers/infiniband/ulp/ibtrs/ibtrs-pri.h       |  470 ++++
 drivers/infiniband/ulp/ibtrs/ibtrs-srv-stats.c |  110 +
 drivers/infiniband/ulp/ibtrs/ibtrs-srv-sysfs.c |  307 +++
 drivers/infiniband/ulp/ibtrs/ibtrs-srv.c       | 2003 +++++++++++++++++
 drivers/infiniband/ulp/ibtrs/ibtrs-srv.h       |  177 ++
 drivers/infiniband/ulp/ibtrs/ibtrs.c           |  611 +++++
 drivers/infiniband/ulp/ibtrs/ibtrs.h           |  325 +++
 fs/sysfs/file.c                                |    1 +
 34 files changed, 13962 insertions(+)
 create mode 100644 drivers/block/ibnbd/Kconfig
 create mode 100644 drivers/block/ibnbd/Makefile
 create mode 100644 drivers/block/ibnbd/README
 create mode 100644 drivers/block/ibnbd/ibnbd-clt-sysfs.c
 create mode 100644 drivers/block/ibnbd/ibnbd-clt.c
 create mode 100644 drivers/block/ibnbd/ibnbd-clt.h
 create mode 100644 drivers/block/ibnbd/ibnbd-log.h
 create mode 100644 drivers/block/ibnbd/ibnbd-proto.h
 create mode 100644 drivers/block/ibnbd/ibnbd-srv-dev.c
 create mode 100644 drivers/block/ibnbd/ibnbd-srv-dev.h
 create mode 100644 drivers/block/ibnbd/ibnbd-srv-sysfs.c
 create mode 100644 drivers/block/ibnbd/ibnbd-srv.c
 create mode 100644 drivers/block/ibnbd/ibnbd-srv.h
 create mode 100644 drivers/infiniband/ulp/ibtrs/Kconfig
 create mode 100644 drivers/infiniband/ulp/ibtrs/Makefile
 create mode 100644 drivers/infiniband/ulp/ibtrs/README
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-clt-stats.c
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-clt-sysfs.c
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-clt.c
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-clt.h
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-log.h
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-pri.h
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-srv-stats.c
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-srv-sysfs.c
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-srv.c
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs-srv.h
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs.c
 create mode 100644 drivers/infiniband/ulp/ibtrs/ibtrs.h

Signed-off-by: Roman Pen <roman.penyaev@xxxxxxxxxxxxxxxx>
Cc: Danil Kipnis <danil.kipnis@xxxxxxxxxxxxxxxx>
Cc: Jack Wang <jinpu.wang@xxxxxxxxxxxxxxxx>

-- 
2.13.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux