- s/tranfers/transfers/

MFC after:	3 days

These libraries don't install anything, so they shouldn't have a
PACKAGE setting.  This avoids surprising behaviour in future if
e.g. manpages are added to an internal library.

Reported by:	des
Differential Revision:	https://reviews.freebsd.org/D51901

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

This moves the checks previously under #ifdef STRICT in
nvmf_nqn_valid() into a separate helper for userland.  This
requires that the NQN starts with "nqn.YYYY-MM." followed by at
least one additional character.

Reviewed by:	asomers
Differential Revision:	https://reviews.freebsd.org/D48767

Use a timer in the nvmf(4) driver to periodically trigger a devctl
"RECONNECT" notification.  A trigger in the /etc/devd/nvmf.conf file
invokes "nvmecontrol reconnect nvmeX" upon each notification.  This
differs from iSCSI which uses a dedicated daemon (iscsid(8)) to wait
inside a custom ioctl for an iSCSI initiator event to occur, but I
think this design might be simpler.

Similar to nvme-cli, the interval between reconnection attempts is
specified in seconds by the --reconnect-delay argument to the connect
and reconnect commands.  Note that nvme-cli uses -c for short letter
of this command, but that was already taken so nvmecontrol uses -r.
The default is 10 seconds to match Linux.

In addition, a second timeout can be used to force a full detach of a
disconnected the nvmeX device after the controller loss timeout
expires.  The timeout for this is specified in seconds by the
--ctrl-loss-tmo/-l options (identical to nvme-cli).  The default is
600 seconds.

Either of these timers can be disabled by setting the timer to 0.  In
that case, the associated action (devctl notifications or full detach)
will not occur after a disconnect.

Note that this adds a dedicated taskqueue for nvmf tasks instead of
using taskqueue_thread as the controller loss task could deadlock
waiting for the completion of other tasks queued to taskqueue_thread.
(Specifically, tearing down the CAM SIM can trigger
destroy_dev_sched_cb() and waits for the callback to run, but the
callback is scheduled to run in a task on taskqueue_thread.  Possibly,
destroy_dev_sched should be using a dedicated taskqueue.)

Reviewed by:	imp (earlier version)
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D50222

This returns an nvlist indicating if a Fabrics host is connected and
the time of the most recent disconnection.

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

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

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

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

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