nvmf: Refactor reconnection support

Save more data associated with a new association including the network
address of the remote controller. This permits reconnecting an
association without providi

nvmf: Refactor reconnection support

Save more data associated with a new association including the network
address of the remote controller. This permits reconnecting an
association without providing the address or other details. To use
this new mode, provide only an existing device ID to nvmecontrol's
reconnect command. An address can still be provided to request a
different address or other different settings for the new association.

The saved data includes an entire Discovery Log page entry to aim to
be compatible with other transports in the future. When a remote
controller is connected to via a Discovery Log page entry (nvmecontrol
connect-all), the raw entry is used. When a remote controller is
connected to via an explicit address, an entry is synthesized from the
parameters.

Note that this is a pseudo-ABI break for the ioctls used by nvmf(4) in
that the nvlists for handoff and reconnect now use a slightly
different set of elements. Since this is only present in main I did
not bother implementing compatability shims.

Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48214

show more ...

nvmf: Switch several ioctls to using nvlists

For requests that handoff queues from userspace to the kernel as well
as the request to fetch reconnect parameters from the kernel, switch
from using fla

nvmf: Switch several ioctls to using nvlists

For requests that handoff queues from userspace to the kernel as well
as the request to fetch reconnect parameters from the kernel, switch
from using flat structures to nvlists. In particular, this will
permit adding support for additional transports in the future without
breaking the ABI of the structures.

Note that this is an ABI break for the ioctls used by nvmf(4) and
nvmft(4). Since this is only present in main I did not bother
implementing compatability shims.

Inspired by: imp (suggestion on a different review)
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48230

show more ...

nvmf_tcp: Correct padding calculation

PDU data alignment (PDA) isn't necessarily a power of 2, just a
multiple of 4, so use roundup() instead of roundup2() to compute the
PDU data offset (PDO).

Spo

nvmf_tcp: Correct padding calculation

PDU data alignment (PDA) isn't necessarily a power of 2, just a
multiple of 4, so use roundup() instead of roundup2() to compute the
PDU data offset (PDO).

Sponsored by: Chelsio Communications

show more ...

libnvmf: Correctly set the controller and host PDA fields

The caller supplied PDU data alignment (PDA) field from
nvmf_association_params is the caller's restriction on data alignment
(so affects re

libnvmf: Correctly set the controller and host PDA fields

The caller supplied PDU data alignment (PDA) field from
nvmf_association_params is the caller's restriction on data alignment
(so affects received PDUs), and the PDA value received from the other
end is the remote end's restriction (so affects transmitted PDUs).

I had these backwards so that if the remote end advertised a PDA it
was used as the receive PDA instead of the transmit PDA.

Sponsored by: Chelsio Communications

show more ...

libnvmf: Reject invalid values of MAXH2CDATA for new associations

Sponsored by: Chelsio Communications

libnvmf: Require MAXH2CDATA to be a multiple of 4

The spec says MAXH2CDATA to is "a multiple of dwords and should be no
less than 4,096".

Sponsored by: Chelsio Communications

nvmf_tcp: Correct tests for PDU direction

Add parentheses to ensure the correct order of operations.

Reported by: GCC

libnvmf: Add internal library to support NVMe over Fabrics

libnvmf provides APIs for transmitting and receiving Command and
Response capsules along with data associated with NVMe commands.
Capsules

libnvmf: Add internal library to support NVMe over Fabrics

libnvmf provides APIs for transmitting and receiving Command and
Response capsules along with data associated with NVMe commands.
Capsules are represented by 'struct nvmf_capsule' objects.

Capsules are transmitted and received on queue pairs represented by
'struct nvmf_qpair' objects.

Queue pairs belong to an association represented by a 'struct
nvmf_association' object.

libnvmf provides additional helper APIs to assist with constructing
command capsules for a host, response capsules for a controller,
connecting queue pairs to a remote controller and optionally
offloading connected queues to an in-kernel host, accepting queue pair
connections from remote hosts and optionally offloading connected
queues to an in-kernel controller, constructing controller data
structures for local controllers, etc.

libnvmf also includes an internal transport abstraction as well as an
implementation of a userspace TCP transport.

libnvmf is primarily intended for ease of use and low-traffic use cases
such as establishing connections that are handed off to the kernel.
As such, it uses a simple API built on blocking I/O.

For a host, a consumer first populates an 'struct
nvmf_association_params' with a set of parameters shared by all queue
pairs for a single association such as whether or not to use SQ flow
control and header and data digests and creates a 'struct
nvmf_association' object. The consumer is responsible for
establishing a TCP socket for each queue pair. This socket is
included in the 'struct nvmf_qpair_params' passed to 'nvmf_connect' to
complete transport-specific negotiation, send a Fabrics Connect
command, and wait for the Connect reply. Upon success, a new 'struct
nvmf_qpair' object is returned. This queue pair can then be used to
send and receive capsules. A command capsule is allocated, populated
with an SQE and optional data buffer, and transmitted via
nvmf_host_transmit_command. The consumer can then wait for a reply
via nvmf_host_wait_for_response. The library also provides some
wrapper functions such as nvmf_read_property and nvmf_write_property
which send a command and wait for a response synchronously.

For a controller, a consumer uses a single association for a set of
incoming connections. A consumer can choose to use multiple
associations (e.g. a separate association for connections to a
discovery controller listening on a different port than I/O
controllers). The consumer is responsible for accepting TCP sockets
directly, but once a socket has been accepted it is passed to
nvmf_accept to perform transport-specific negotiation and wait for the
Connect command. Similar to nvmf_connect, nvmf_accept returns a newly
construct nvmf_qpair. However, in contrast to nvmf_connect,
nvmf_accept does not complete the Fabrics negotiation. The consumer
must explicitly send a response capsule before waiting for additional
command capsules to arrive. In particular, in the kernel offload
case, the Connect command and data are provided to the kernel
controller and the Connect response capsule is sent by the kernel once
it is ready to handle the new queue pair.

For userspace controller command handling, the consumer uses
nvmf_controller_receive_capsule to wait for a command capsule.
nvmf_receive_controller_data is used to retrieve any data from a
command (e.g. the data for a WRITE command). It can be called
multiple times to split the data transfer into smaller sizes.
nvmf_send_controller_data is used to send data to a remote host in
response to a command. It also sends a response capsule indicating
success, or an error if an internal error occurs. nvmf_send_response
is used to send a response without associated data. There are also
several convenience wrappers such as nvmf_send_success and
nvmf_send_generic_error.

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44710

show more ...