Add support for absolute random zones

[fio.git] / HOWTO

diff --git a/HOWTO b/HOWTO
index 4d3a8c8cec73c8c46d8a608e948810a5adf0a5f6..dc99e9989a47a262cc432ef8f5507acd6e54c85a 100644 (file)
--- a/HOWTO
+++ b/HOWTO
@@ -1254,6 +1254,9 @@ I/O type
                **zoned**
                                Zoned random distribution
 
+               **zoned_abs**
+                               Zone absolute random distribution
+
        When using a **zipf** or **pareto** distribution, an input value is also
        needed to define the access pattern. For **zipf**, this is the `Zipf
        theta`. For **pareto**, it's the `Pareto power`. Fio includes a test
@@ -1278,10 +1281,23 @@ I/O type
 
                random_distribution=zoned:60/10:30/20:8/30:2/40
 
-       similarly to how :option:`bssplit` works for setting ranges and percentages
-       of block sizes. Like :option:`bssplit`, it's possible to specify separate
-       zones for reads, writes, and trims. If just one set is given, it'll apply to
-       all of them.
+       A **zoned_abs** distribution works exactly like the **zoned**, except
+       that it takes absolute sizes. For example, let's say you wanted to
+       define access according to the following criteria:
+
+               * 60% of accesses should be to the first 20G
+               * 30% of accesses should be to the next 100G
+               * 10% of accesses should be to the next 500G
+
+       we can define an absolute zoning distribution with:
+
+               random_distribution=zoned_abs=60/20G:30/100G:10/500g
+
+       Similarly to how :option:`bssplit` works for setting ranges and
+       percentages of block sizes. Like :option:`bssplit`, it's possible to
+       specify separate zones for reads, writes, and trims. If just one set
+       is given, it'll apply to all of them. This goes for both **zoned**
+       **zoned_abs** distributions.
 
 .. option:: percentage_random=int[,int][,int]
 
@@ -1751,7 +1767,8 @@ I/O engine
                **rdma**
                        The RDMA I/O engine supports both RDMA memory semantics
                        (RDMA_WRITE/RDMA_READ) and channel semantics (Send/Recv) for the
-                       InfiniBand, RoCE and iWARP protocols.
+                       InfiniBand, RoCE and iWARP protocols. This engine defines engine
+                       specific options.
 
                **falloc**
                        I/O engine that does regular fallocate to simulate data transfer as
@@ -1893,10 +1910,15 @@ with the caveat that when used on the command line, they must come after the
                this will be the starting port number since fio will use a range of
                ports.
 
-.. option:: hostname=str : [netsplice] [net]
+   [rdma]
 
-       The hostname or IP address to use for TCP or UDP based I/O.  If the job is
-       a TCP listener or UDP reader, the hostname is not used and must be omitted
+               The port to use for RDMA-CM communication. This should be the same value
+               on the client and the server side.
+
+.. option:: hostname=str : [netsplice] [net] [rdma]
+
+       The hostname or IP address to use for TCP, UDP or RDMA-CM based I/O.  If the job
+       is a TCP listener or UDP reader, the hostname is not used and must be omitted
        unless it is a valid UDP multicast address.
 
 .. option:: interface=str : [netsplice] [net]
@@ -2002,6 +2024,21 @@ with the caveat that when used on the command line, they must come after the
 
        The size of the chunk to use for each file.
 
+.. option:: verb=str : [rdma]
+
+       The RDMA verb to use on this side of the RDMA ioengine connection. Valid
+       values are write, read, send and recv. These correspond to the equivalent
+       RDMA verbs (e.g. write = rdma_write etc.). Note that this only needs to be
+       specified on the client side of the connection. See the examples folder.
+
+.. option:: bindname=str : [rdma]
+
+       The name to use to bind the local RDMA-CM connection to a local RDMA device.
+       This could be a hostname or an IPv4 or IPv6 address. On the server side this
+       will be passed into the rdma_bind_addr() function and on the client site it
+       will be used in the rdma_resolve_add() function. This can be useful when
+       multiple paths exist between the client and the server or in certain loopback
+       configurations.
 
 I/O depth
 ~~~~~~~~~