- 08 Jul, 2016 5 commits
-
-
Christoph Hellwig authored
This patch implements the RDMA host (initiator in SCSI speak) driver. It can be used to connect to remote NVMe over Fabrics controllers over Infiniband, RoCE or iWarp, and uses the existing NVMe core driver as well a the new fabrics library. To connect to all NVMe over Fabrics controller reachable on a given taget port using RDMA/CM use the following command: nvme connect-all -t rdma -a $IPADDR This requires the latest version of nvme-cli with Fabrics support. Signed-off-by:
Jay Freyensee <james.p.freyensee@intel.com> Signed-off-by:
Ming Lin <ming.l@ssi.samsung.com> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Steve Wise <swise@opengridcomputing.com> Tested-by:
Jens Axboe <axboe@fb.com>
-
Christoph Hellwig authored
This patch implements the RDMA transport for the NVMe over Fabrics target, which allows exporting NVMe over Fabrics functionality over RDMA fabrics (Infiniband, RoCE, iWARP). All NVMe logic is in the generic target and this module just provides a small glue between it and the generic code in the RDMA subsystem. Signed-off-by: Armen Baloyan <armenx.baloyan@intel.com>, Signed-off-by:
-
Sagi Grimberg authored
NVMe over Fabrics RDMA transport defines a connection establishment protocol over the RDMA connection manager. This header will be used by both the host and target drivers to negotiate the connection establishment parameters. Signed-off-by:
-
Christoph Hellwig authored
The nvme fabric (RDMA, FC, etc...) can introduce port, link or node failures that may require a reconnect to re-establish the connection. Add a new reconnecting state that will initially be used by the RDMA driver. Reviewed-by:
-
Sagi Grimberg authored
The new nvme-rdma driver will need to reinitialize all the tags as part of the error recovery procedure (realloc the tag memory region). Add a helper in blk-mq for it that can iterate over all requests in a tagset to make this easier. Signed-off-by:
Stephen Bates <Stephen.Bates@pmcs.com> Signed-off-by:
-
- 07 Jul, 2016 19 commits
-
-
Matias Bjørling authored
The __nvm_submit_ppa() function is not used outside lightnvm core. Signed-off-by:
Matias Bjørling <m@bjorling.me> Signed-off-by:
-
Matias Bjørling authored
The passed by reference ppa list in nvm_set_rqd_list() is updated when multiple planes are available. In that case, each PPA plane is incremented when the device side PPA list is created. This prevents the caller to rely on the PPA list to be unmodified after a call. Signed-off-by:
-
Matias Bjørling authored
The gen_mark_blk_bad function marks the wrong block when a block is on a different channel. Fix the index calculation, so that it updates the correct block. Reported-by:
Javier Gonzalez <javier@cnexlabs.com> Signed-off-by:
-
Matias Bjørling authored
The nvm_get_blk() function is called with rlun->lock held. This is ok when the media manager implementation doesn't go out of its atomic context. However, if a media manager persists its metadata, and guarantees that the block is given to the target, this is no longer a viable approach. Therefore, clean up the flow of rrpc_map_page, and make sure that nvm_get_blk() is called without any locks acquired. Signed-off-by:
-
Matias Bjørling authored
The [get/put]_blk API enables targets to get ownership of blocks at runtime. This information is currently not recorded on disk, and the information is therefore lost on power failure. To restore the metadata, the [get/put]_blk must persist its metadata. In that case, we need to control the outer lock, so that we can disable them while updating the on-disk metadata. Fortunately, the _unlocked versions can be removed, which allows us to move the lock into the [get/put]_blk functions. Signed-off-by:
-
Matias Bjørling authored
The ->list, ->open_list, and ->closed_list lists were previously used for statistics. However, their usage have been removed, and thus these can safely be removed. Signed-off-by:
-
Matias Bjørling authored
If a media manager tries to initialize it targets upon media manager initialization, the media manager will need to know which target types are available in LightNVM. The lists of which managers and target types are available shares the same lock. Therefore, on initialization, the nvm_lock is taken by LightNVM core, which later leads to a deadlock when target types are enumerated by the media manager. Add an exclusive lock for target types to resolve this conflict. Signed-off-by:
-
Matias Bjørling authored
To enable persistent block management to easily control creation and removal of targets, we move target management into the media manager. The LightNVM core continues to maintain which target types are registered, while the media manager now keeps track of its initialized targets. Two new callbacks for the media manager are introduced. create_tgt and remove_tgt. Note that remove_tgt returns 0 on successfully removing a target, and returns 1 if the target was not found. Signed-off-by:
-
Matias Bjørling authored
The generic manager should be called the general media manager, and instead of using the rather long name of "gennvm" in front of each data structures, use "gen" instead to shorten it. Update the description of the media manager as well to make the media manager purpose clearer. Signed-off-by:
-
Matias Bjørling authored
The responsibility of the media manager is not to keep track of open/closed blocks. This is better maintained within a target, that already manages this information on writes. Remove the statistics and merge the states NVM_BLK_ST_OPEN and NVM_BLK_ST_CLOSED. Signed-off-by:
-
Matias Bjørling authored
A couple of small checkpatch fixups to stop it from complaining. ./drivers/lightnvm/core.c:360: WARNING: line over 80 characters ./drivers/lightnvm/core.c:360: ERROR: trailing statements should be on next line ./drivers/lightnvm/core.c:503: WARNING: Block comments use a trailing */ on a separate line Signed-off-by:
-
Matias Bjørling authored
Checkpatch found two incidents where the type was preferred to be written out in full. ./drivers/lightnvm/rrpc.h:184: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' ./drivers/lightnvm/rrpc.h:209: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' ./drivers/lightnvm/rrpc.c:51: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Signed-off-by:
-
Johannes Thumshirn authored
Mark functions not used by ouside of thier implementing file as static. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Johannes Thumshirn authored
According to the OpenChannel SSD interface specification the NAND flash MLC page pairing information's number of page page pairings field is the first two bytes in the MLC Page Pairing data structure. The hardware's data structure itself is little endian so annotate it as such, like the rest of lighnvm's data structures. Signed-off-by:
-
Javier González authored
The ->reserved bit is not initialized when allocated on stack. This may lead targets to misinterpret the PPA as cached. Signed-off-by:
-
Javier González authored
Expose media manager mark_blk() to targets, as done for the rest of the media manager callback functions. Signed-off-by:
-
Wenwei Tao authored
Break the loop when rqd is not null to reduce an unnecessary schedule. Signed-off-by:
Wenwei Tao <ww.tao0320@gmail.com> Signed-off-by:
-
Dan Carpenter authored
We accidentally return zero here when ERR_PTR(-ENOMEM) is intended. Fixes: a07b4970 ('nvmet: add a generic NVMe target') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Arnd Bergmann authored
CONFIG_NVME_TARGET has a correct CONFIG_CONFIGFS_FS dependency, but the newly added NVME_TARGET_LOOP is missing this, resulting in a link failure: drivers/nvme/built-in.o: In function `nvmet_init_configfs': loop.c:(.init.text+0x2a0): undefined reference to `config_group_init' loop.c:(.init.text+0x2c0): undefined reference to `config_group_init_type_name' loop.c:(.init.text+0x318): undefined reference to `configfs_register_subsystem' drivers/nvme/built-in.o: In function `nvmet_exit_configfs': loop.c:(.exit.text+0x9c): undefined reference to `configfs_unregister_subsystem' This adds the same dependency here. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 3a85a5de ("nvme-loop: add a NVMe loopback host driver") Signed-off-by:
-
- 05 Jul, 2016 14 commits
-
-
Yijing Wang authored
We have assigned sb->block_size before the switch, so remove the redundant one. Reviewed-by:
Coly Li <colyli@suse.de> Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Acked-by:
Eric Wheeler <bcache@lists.ewheeler.net> Signed-off-by:
-
Yijing Wang authored
There is no return in continue_at(), update the documentation. Signed-off-by:
-
Yijing Wang authored
Cache_sb is not used in cache_alloc, and we have copied sb info to cache->sb already, remove it. Reviewed-by:
-
Christoph Hellwig authored
This patch implements adds nvme-loop which allows to access local devices exported as NVMe over Fabrics namespaces. This module can be useful for easy evaluation, testing and also feature experimentation. To createa nvme-loop device you need to configure the NVMe target to export a loop port (see the nvmetcli documentaton for that) and then connect to it using nvme connect-all -t loop which requires the very latest nvme-cli version with Fabrics support. Signed-off-by:
-
Christoph Hellwig authored
This patch introduces a implementation of NVMe subsystems, controllers and discovery service which allows to export NVMe namespaces across fabrics such as Ethernet, FC etc. The implementation conforms to the NVMe 1.2.1 specification and interoperates with NVMe over fabrics host implementations. Configuration works using configfs, and is best performed using the nvmetcli tool from http://git.infradead.org/users/hch/nvmetcli.git, which also has a detailed explanation of the required steps in the README file. Signed-off-by:
Armen Baloyan <armenx.baloyan@intel.com> Signed-off-by:
Anthony Knapp <anthony.j.knapp@intel.com> Signed-off-by:
-
Sagi Grimberg authored
The new NVMe over fabrics target will make use of this outside from a module. Signed-off-by:
-
Sagi Grimberg authored
Periodic keep-alive is a mandatory feature in NVMe over Fabrics, and optional in NVMe 1.2.1 for PCIe. This patch adds periodic keep-alive sent from the host to verify that the controller is still responsive and vice-versa. The keep-alive timeout is user-defined (with keep_alive_tmo connection parameter) and defaults to 5 seconds. In order to avoid a race condition where the host sends a keep-alive competing with the target side keep-alive timeout expiration, the host adds a grace period of 10 seconds when publishing the keep-alive timeout to the target. In case a keep-alive failed (or timed out), a transport specific error recovery kicks in. For now only NVMe over Fabrics is wired up to support keep alive, but we can add PCIe support easily once controllers actually supporting it become available. Signed-off-by:
Steve Wise <swise@chelsio.com> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
-
Sagi Grimberg authored
KAS: keep-alive support and granularity of kato in units of 100 ms nvme_admin_keep_alive opcode: 0x18 Signed-off-by:
-
Christoph Hellwig authored
The NVMe over Fabrics library provides an interface for both transports and the nvme core to handle fabrics specific commands and attributes independent of the underlying transport. In addition, the fabrics library adds a misc device interface that allow actually creating a fabrics controller, as we can't just autodiscover it like in the PCI case. The nvme-cli utility has been enhanced to use this interface to support fabric connect and discovery. Signed-off-by: Armen Baloyan <armenx.baloyan@intel.com>, Signed-off-by: Jay Freyensee <james.p.freyensee@intel.com>, Signed-off-by:
-
Christoph Hellwig authored
The NVMe over Fabrics specification defines a protocol interface and related extensions to NVMe that enable operation over network protocols. The NVMe over Fabrics specification has an NVMe Transport binding for each NVMe Transport. This patch adds the fabrics related definitions: - fabric specific command set and error codes - transport addressing and binding definitions - fabrics sgl extensions - controller identification fabrics enhancements - discovery log page definition Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Ming Lin authored
- delete_controller: This attribute allows to delete a controller. A driver is not obligated to support it (pci doesn't) so it is created only if the driver supports it. The new fabrics drivers will support it (essentialy a disconnect operation). Usage: echo > /sys/class/nvme/nvme0/delete_controller - subsysnqn: This attribute shows the subsystem nqn of the configured device. If a driver does not implement the get_subsysnqn method, the file will not appear in sysfs. - transport: This attribute shows the transport name. Added a "name" field to struct nvme_ctrl_ops. For loop, cat /sys/class/nvme/nvme0/transport loop For RDMA, cat /sys/class/nvme/nvme0/transport rdma For PCIe, cat /sys/class/nvme/nvme0/transport pcie - address: This attributes shows the controller address. The fabrics drivers that will implement get_address can show the address of the connected controller. example: cat /sys/class/nvme/nvme0/address traddr=192.168.2.2,trsvcid=1023 Signed-off-by:
-
Christoph Hellwig authored
NVMe over fabrics will use __nvme_submit_sync_cmd in the the transport and require a few tweaks to it. For that we export it and add a few more paramters: 1. allow passing a queue ID to the block layer For the NVMe over Fabrics connect command we need to able to specify a queue ID that we want to send the command on. Add a qid parameter to the relevant functions to enable this behavior. 2. allow submitting at_head commands In cases where we want to (re)connect to a controller where we have inflight queued commands we want to first connect and only then allow the other queued commands to be kicked. This will prevents failures in controller resets and reconnects. 3. allow passing flags to blk_mq_allocate_request Both for Fabrics connect the the keep-alive feature in NVMe 1.2.1 we want to be able to use reserved requests. Reviewed-by:
-
Christoph Hellwig authored
For Fabrics we're not going through an intermediate reset state (at least for now). Reviewed-by:
-
Ming Lin authored
For some protocols like NVMe over Fabrics we need to be able to send initialization commands to a specific queue. Based on an earlier patch from Christoph Hellwig <hch@lst.de>. Signed-off-by:
-
- 28 Jun, 2016 1 commit
-
-
Bartlomiej Zolnierkiewicz authored
MG_DISK_MAJ is defined as 0 so dynamic block major number allocation is used by the driver and the assigned major number is stored in host->major. This patch fixes error path in mg_probe() to use host->major instead of using MG_DISK_MAJ. Cc: unsik Kim <donari75@gmail.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
- 14 Jun, 2016 1 commit
-
-
Lars Ellenberg authored
crypto_alloc_hash returns an ERR_PTR(), not NULL. Also reset peer_integrity_tfm to NULL, to not call crypto_free_hash() on an errno in the cleanup path. Reported-by:
Insu Yun <wuninsu@gmail.com> Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
-
