From nobody Thu Jul 13 04:02:12 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R1gsw4Bz1z4n8pl for ; Thu, 13 Jul 2023 04:02:12 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R1gsw3n7Zz3G7b; Thu, 13 Jul 2023 04:02:12 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689220932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=OBJjCkja034nLnLvevjCS6pNcARwbixodHEosqbI6HU=; b=H73fb9tsMNWWcy0W4dIEPB79zqnnqsQ1Hj+xlK5SsJ5y3FKdBy95QDbAdA8naXsRRyHs5e /lO5q/6Q42/2qhqpoVN3ybgpPxLoN5bM3UgyJwVIawS6B3yJY/YAbRxNrdAlYKkfOHU1Py KIQ514DIYCK6NxB4g1t4VkeSz4uC6x+Zal9n3b/2RJ9JzCVXA0BulgJkIfa9aq+O5Gg3y+ EqcQ8bPPhEAGBGAQkKC2q+tVoLloD3/GbFHiIlKkF1Ivz0sIu3fAOH49HDpTmP2aIDTxVX 7CZYfk/SmqC0gHFMUIRxI4iUgW+vIlHeeEdk1FD04b1DRe99X0ulAB3rkgQg/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689220932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=OBJjCkja034nLnLvevjCS6pNcARwbixodHEosqbI6HU=; b=aMpavhLIu7TBGa90jHCIvHB/b3HecaIBpBbaee3ZNezx9/MZ516O6iG6pQnpJqC+D3bSnL TYKpwuiV9B/vXNg2JF0JgCxac+rgRgEXteaq3tUG6BMro03mpidNoxKVPth9GBzpRvE0YC QU0HI/y4AOFsqbhgcwdQ6eH+hj+TpJMOQrPsEHkPpALeOv8O1WdaxZ0/Sc9LrZbmIRxXSr +65do1JsNubEnDq5e8wvN0xu4YznoqwVOdzPkYetWK0hxlyafUQ3tKKqX9RJk2RHkU9NX1 uotEPKy5xUhGBi42bgiOKU1W6+g6v1g8Fi4Ly5GxNRR1hJ4mE/N1JF0bH3oDGw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689220932; a=rsa-sha256; cv=none; b=SNrmEdPm69wwI5PRfH7qIqZFmcW6bQxV1xiBdlzrJ+Wy+cVMrIbINl8uvTGarZh92QiRWp iyL6Ta/G0/T8wfweKAisxt1/i6FXUCcPqFLGz8j+xMhvax7IxMoaSMXFFY5sGR4C/3amTZ i3dl+tTmqkljOIDRkJ89RZ+xxl4UTJtGiNFseo7N4izVjSRLRN95T9LY/lyXTevU7iLo8R k8GgeRSwbMJxVEKeyNQuE3lat0/qiQlSpXaPYd7ZznKcBSObjn8fmxwZF076ZHd0PmI4dW CehRjn0IG2JFP+NRJuoxIIYY/Z1ilGw4MNB6NHylPElk1tIOIVXKXXaZmbWd7g== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R1gsw2tkLzc3s; Thu, 13 Jul 2023 04:02:12 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.17.1/8.17.1) with ESMTP id 36D42CSJ083997; Thu, 13 Jul 2023 04:02:12 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.17.1/8.17.1/Submit) id 36D42C7h083996; Thu, 13 Jul 2023 04:02:12 GMT (envelope-from git) Date: Thu, 13 Jul 2023 04:02:12 GMT Message-Id: <202307130402.36D42C7h083996@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Graham Perrin Subject: git: 38ac636039 - main - status: 2023q2: nvmf: markup, minor changes List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: grahamperrin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 38ac6360396e6b41a332272abcd69466da75e79b Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by grahamperrin: URL: https://cgit.FreeBSD.org/doc/commit/?id=38ac6360396e6b41a332272abcd69466da75e79b commit 38ac6360396e6b41a332272abcd69466da75e79b Author: Graham Perrin AuthorDate: 2023-07-13 03:59:15 +0000 Commit: Graham Perrin CommitDate: 2023-07-13 03:59:15 +0000 status: 2023q2: nvmf: markup, minor changes Link to a manual page. Other changes, minor. Approved-by: salvadore Fixes: 4222032e43 Status/2023Q2/nvmf.adoc: Improvements Pull-request: https://github.com/freebsd/freebsd-doc/pull/208 --- website/content/en/status/report-2023-04-2023-06/nvmf.adoc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/website/content/en/status/report-2023-04-2023-06/nvmf.adoc b/website/content/en/status/report-2023-04-2023-06/nvmf.adoc index a9ceefdaea..f9477918e4 100644 --- a/website/content/en/status/report-2023-04-2023-06/nvmf.adoc +++ b/website/content/en/status/report-2023-04-2023-06/nvmf.adoc @@ -5,7 +5,7 @@ link:https://github.com/bsdjhb/freebsd/tree/nvmf2[nvmf2 branch] URL: link:https: Contact: John Baldwin -NVMe over Fabrics enables communication with a storage device usingthe NVMe protocol over a network fabric. +NVMe over Fabrics enables communication with a storage device using the NVMe protocol over a network fabric. This is similar to using iSCSI to export a storage device over a network using SCSI commands. NVMe over Fabrics currently defines network transports for Fibre Channel, RDMA, and TCP. @@ -20,19 +20,19 @@ The branch also contains an in-kernel Fabrics implementation. [.filename]#nvmf.ko# contains an NVMe over Fabrics host (initiator) which connects to a remote controller and exports remote namespaces as disk devices. Similar to the man:nvme[4] driver for NVMe over PCI-express, namespaces are exported via [.filename]#/dev/nvmeXnsY# devices which only support simple operations, but are also exported as ndaX disk devices via CAM. Unlike man:nvme[4], man:nvmf[4] does not support the man:nvd[4] disk driver. -nvmecontrol can be used with remote namespaces and remote controllers, for example to fetch log pages, display identify info, etc. +man:nvmecontrol[8] can be used with remote namespaces and remote controllers, for example to fetch log pages, display identify info, etc. Note that man:nvmf[4] is currently a bit simple and some error cases are still a TODO. -If an error occurs, the queues (and backing network connections) are dropped, but the devices stay around, but with I/O requests paused. -'nvmecontrol reconnect' can be used to connect a new set of network connections to resume operation. -Unlike iSCSI which uses a persistent daemon (man:iscsid[8]) to reconnect after an error, reconnections must be done manually. +If an error occurs, the queues (and backing network connections) are dropped, but the devices stay around, with I/O requests paused. +`nvmecontrol reconnect` can be used to connect a new set of network connections to resume operation. +Unlike iSCSI which uses a persistent daemon (man:iscsid[8]) to reconnect after an error, reconnections must be made manually. The current code is very new and likely not robust. It is certainly not ready for production use. -Experienced users who do not mind all their data vanishing in a puff of smoke after a kernel panic and who have an interest in NVMe over Fabrics can start testing it at their own risk. +Experienced users who do not mind all their data vanishing in a puff of smoke after a kernel panic, and who have an interest in NVMe over Fabrics, can start testing it at their own risk. The next main task is to implement a Fabrics controller (target in SCSI language). -Probably a simple one in userland first followed by a "real" one that offloads the data handling to the kernel but is somewhat integrated with man:ctld[8] so that individual disk devices can be exported either via iSCSI or NVMe or both using a single config file and daemon to manage all of that. +Probably a simple one in userland first followed by a "real" one that offloads the data handling to the kernel but is somewhat integrated with man:ctld[8] so that individual disk devices can be exported via iSCSI or NVMe, or via both using a single config file and daemon to manage all of that. This may require a fair bit of refactoring in ctld to make it less iSCSI-specific. Working on the controller side will also validate some of the currently under-tested API design decisions in the transport-independent layer. I think it probably does not make sense to merge any of the NVMe over Fabrics changes into the tree until after this step.