History log of /freebsd/sbin/nvmecontrol/reconnect.c (Results 1 – 4 of 4)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 8bba2c0f 24-Jan-2025 John Baldwin <jhb@FreeBSD.org>

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 ...


# 365b89e8 30-Dec-2024 John Baldwin <jhb@FreeBSD.org>

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 ...


Revision tags: release/14.2.0, release/13.4.0, release/14.1.0
# 0ac468c7 10-May-2024 John Baldwin <jhb@FreeBSD.org>

nvmecontrol: Free array of I/O queue pairs on failure to handoff

This is harmless but cleaner.

Reported by: Coverity Scan
CID: 1545041,1545049
Sponsored by: Chelsio Communications


# 1058c121 03-May-2024 John Baldwin <jhb@FreeBSD.org>

nvmecontrol: New commands to support Fabrics hosts

- discover: Connects to a remote Discovery controller, fetches its
Discovery Log Page, and enumerates the remote controllers described
in the l

nvmecontrol: New commands to support Fabrics hosts

- discover: Connects to a remote Discovery controller, fetches its
Discovery Log Page, and enumerates the remote controllers described
in the log page.

The -v option can be used to display the Identify Controller data
structure for the Discovery controller. This is only really useful
for debugging.

- connect: Connects to a remote I/O controller and establishes an
association of an admin queue and a single I/O queue. The
association is handed off to the in-kernel host to create a new
nvmeX device.

- connect-all: Connects to a Discovery controller and attempts to
create an association with each I/O controller enumerated in the
Discovery controller's Discovery Log Page.

- reconnect: Establishes a new association with a remote I/O
controller for an existing nvmeX device. This can be used to
restore access to a remote I/O controller after the loss of a prior
association due to a transport error, controller reboot, etc.

- disconnect: Deletes one or more nvmeX devices after detaching its
namespaces and terminating any active associations. The devices to
delete can be identified by either a nvmeX device name or the NQN of
the remote controller.

- disconnect-all: Deletes all active associations with remote
controllers.

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

show more ...