mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-11-22 03:04:34 +01:00
2da066ef6d
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 |
||
|---|---|---|
| .. | ||
| atf.test.mk | ||
| auto.obj.mk | ||
| bsd.arch.inc.mk | ||
| bsd.clang-analyze.mk | ||
| bsd.compat.mk | ||
| bsd.compat.pre.mk | ||
| bsd.compiler.mk | ||
| bsd.confs.mk | ||
| bsd.cpu.mk | ||
| bsd.crunchgen.mk | ||
| bsd.dep.mk | ||
| bsd.dirs.mk | ||
| bsd.doc.mk | ||
| bsd.dtb.mk | ||
| bsd.endian.mk | ||
| bsd.files.mk | ||
| bsd.incs.mk | ||
| bsd.info.mk | ||
| bsd.init.mk | ||
| bsd.kmod.mk | ||
| bsd.lib.mk | ||
| bsd.libnames.mk | ||
| bsd.linker.mk | ||
| bsd.links.mk | ||
| bsd.man.mk | ||
| bsd.mkopt.mk | ||
| bsd.nls.mk | ||
| bsd.obj.mk | ||
| bsd.opts.mk | ||
| bsd.own.mk | ||
| bsd.port.mk | ||
| bsd.port.options.mk | ||
| bsd.port.post.mk | ||
| bsd.port.pre.mk | ||
| bsd.port.subdir.mk | ||
| bsd.prog.mk | ||
| bsd.progs.mk | ||
| bsd.README | ||
| bsd.sanitizer.mk | ||
| bsd.snmpmod.mk | ||
| bsd.subdir.mk | ||
| bsd.suffixes-posix.mk | ||
| bsd.suffixes.mk | ||
| bsd.symver.mk | ||
| bsd.sys.mk | ||
| bsd.sysdir.mk | ||
| bsd.test.mk | ||
| dirdeps-options.mk | ||
| dirdeps-targets.mk | ||
| dirdeps.mk | ||
| gendirdeps.mk | ||
| googletest.test.inc.mk | ||
| googletest.test.mk | ||
| host-target.mk | ||
| install-new.mk | ||
| jobs.mk | ||
| kmod.opts.mk | ||
| local.autodep.mk | ||
| local.dirdeps-options.mk | ||
| local.dirdeps-targets.mk | ||
| local.dirdeps.mk | ||
| local.gendirdeps.mk | ||
| local.init.mk | ||
| local.meta.sys.env.mk | ||
| local.sys.dirdeps.env.mk | ||
| local.sys.dirdeps.mk | ||
| local.sys.env.mk | ||
| local.sys.machine.mk | ||
| local.sys.mk | ||
| Makefile | ||
| meta2deps.py | ||
| meta2deps.sh | ||
| meta.autodep.mk | ||
| meta.stage.mk | ||
| meta.subdir.mk | ||
| meta.sys.mk | ||
| netbsd-tests.test.mk | ||
| plain.test.mk | ||
| src.init.linux.mk | ||
| src.init.mk | ||
| src.libnames.mk | ||
| src.lua.mk | ||
| src.opts.mk | ||
| src.sys.env.mk | ||
| src.sys.mk | ||
| src.sys.obj.mk | ||
| src.tools.mk | ||
| stage-install.sh | ||
| suite.test.mk | ||
| sys.dependfile.mk | ||
| sys.dirdeps.mk | ||
| sys.mk | ||
| tap.test.mk | ||
| version_gen.awk | ||