[PATCH 23/24] ibnbd: a bit of documentation

2018-02-02 Thread Roman Pen
README with description of major sysfs entries.

Signed-off-by: Roman Pen 
Signed-off-by: Danil Kipnis 
Cc: Jack Wang 
---
 drivers/block/ibnbd/README | 272 +
 1 file changed, 272 insertions(+)

diff --git a/drivers/block/ibnbd/README b/drivers/block/ibnbd/README
new file mode 100644
index ..e0feb39fad14
--- /dev/null
+++ b/drivers/block/ibnbd/README
@@ -0,0 +1,272 @@
+***
+Infiniband Network Block Device (IBNBD)
+***
+
+Introduction
+
+
+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 using the RDMA (InfiniBand, RoCE, iWarp)
+transport. After being mapped, the remote block devices can be accessed
+on the client side as local block devices.
+
+I/O is transfered between client and server by the IBTRS transport
+modules. The administration of IBNBD and IBTRS modules is done via
+sysfs entries.
+
+Requirements
+
+
+  IBTRS kernel modules
+
+Quick Start
+---
+
+Server side:
+  # modprobe ibnbd_server
+
+Client side:
+  # modprobe ibnbd_client
+  # echo "sessname=blya path=ip:10.50.100.66 device_path=/dev/ram0" > \
+/sys/kernel/ibnbd_client/map_device
+
+  Where "sessname=" is a session name, a string to identify the session
+  on client and on server sides; "path=" is a destination IP address or
+  a pair of a source and a destination IPs, separated by comma.  Multiple
+  "path=" options can be specified in order to use multipath  (see IBTRS
+  description for details); "device_path=" is the block device to be
+  mapped from the server side. After the session to the server machine is
+  established, the mapped device will appear on the client side under
+  /dev/ibnbd.
+
+
+==
+Client Sysfs Interface
+==
+
+All sysfs files that are not read-only provide the usage information on read:
+
+Example:
+  # cat /sys/kernel/ibnbd_client/map_device
+
+  > Usage: echo "sessname= path=<[srcaddr,]dstaddr>
+  > [path=<[srcaddr,]dstaddr>] device_path=
+  > [access_mode=] [input_mode=]
+  > [io_mode=]" > map_device
+  >
+  > addr ::= [ ip: | ip: | gid: ]
+
+Entries under /sys/kernel/ibnbd_client/
+===
+
+map_device (RW)
+---
+
+Expected format is the following:
+
+sessname=
+path=<[srcaddr,]dstaddr> [path=<[srcaddr,]dstaddr> ...]
+device_path=
+[access_mode=]
+[input_mode=]
+[io_mode=]
+
+Where:
+
+sessname: accepts a string not bigger than 256 chars, which identifies
+  a given session on the client and on the server.
+ I.e. "clt_hostname-srv_hostname" could be a natural choice.
+
+path: describes a connection between the client and the server by
+ specifying destination and, when required, the source address.
+ The addresses are to be provided in the following format:
+
+ip:
+ip:
+gid:
+
+  for example:
+
+  path=ip:10.0.0.66
+ The single addr is treated as the destination.
+ The connection will be established to this
+ server from any client IP address.
+
+  path=ip:10.0.0.66,ip:10.0.1.66
+ First addr is the source address and the second
+ is the destination.
+
+  If multiple "path=" options are specified multiple connection
+  will be established and data will be sent according to
+  the selected multipath policy (see IBTRS mp_policy sysfs entry
+  description).
+
+device_path: Path to the block device on the server side. Path is specified
+relative to the directory on server side configured in the
+ 'dev_search_path' module parameter of the ibnbd_server.
+ The ibnbd_server prepends the  received from client
+with  and tries to open the
+/ block device.  On success,
+a /dev/ibnbd device file, a /sys/block/ibnbd_client/ibnbd/
+directory and an entry in /sys/kernel/ibnbd_client/devices will be
+ created.
+
+access_mode: the access_mode parameter specifies if the device is to be
+ mapped as "ro" read-only or "rw" read-write. The server allows
+a device to be exported in rw mode only once. The "migration"
+ access mode has to be specified if a second mapping in read-write
+mode is desired.
+
+ By default "rw" is used.
+
+input_mode: the input_mode parameter specifies the internal I/O
+processing mode of the block device on the client.  Accepts
+"mq" and "rq".
+
+By default "mq" mode is used.
+
+io_mode:  the io_mode parameter specifies if the device on the server
+  will be opened as blo

Re: [PATCH 23/24] ibnbd: a bit of documentation

2018-02-02 Thread Bart Van Assche
On Fri, 2018-02-02 at 15:09 +0100, Roman Pen wrote:
> +Entries under /sys/kernel/ibnbd_client/
> +===
> [ ... ]

You will need Greg KH's permission to add new entries directly under 
/sys/kernel.
Since I think that it is unlikely that he will give that permission: have you
considered to add the new client entries under /sys/class/block for the client 
and
/sys/kernel/configfs/ibnbd for the target, similar to what the NVMeOF drivers do
today?

Bart.

Re: [PATCH 23/24] ibnbd: a bit of documentation

2018-02-05 Thread Roman Penyaev
On Fri, Feb 2, 2018 at 4:55 PM, Bart Van Assche  wrote:
> On Fri, 2018-02-02 at 15:09 +0100, Roman Pen wrote:
>> +Entries under /sys/kernel/ibnbd_client/
>> +===
>> [ ... ]
>
> You will need Greg KH's permission to add new entries directly under 
> /sys/kernel.
> Since I think that it is unlikely that he will give that permission: have you
> considered to add the new client entries under /sys/class/block for the 
> client and
> /sys/kernel/configfs/ibnbd for the target, similar to what the NVMeOF drivers 
> do
> today?

/sys/kernel was chosen ages ago and I completely forgot to move it to configfs.
IBTRS is not a block device, so for some read-only entries (statistics
or states)
something else should be probably used, not configfs.  Or it is fine
to read state
of the connection from configfs?  For me sounds a bit weird.

--
Roman


Re: [PATCH 23/24] ibnbd: a bit of documentation

2018-02-05 Thread Sagi Grimberg



/sys/kernel was chosen ages ago and I completely forgot to move it to configfs.
IBTRS is not a block device, so for some read-only entries (statistics
or states)
something else should be probably used, not configfs.  Or it is fine
to read state
of the connection from configfs?  For me sounds a bit weird.


Configs go via configfs, states and alike go to sysfs (but you need your
own class device).