On 12/30/2021 5:30 PM, Keith Busch wrote:
On Thu, Dec 30, 2021 at 04:38:57PM +0200, Max Gurtovoy wrote:
On 12/29/2021 10:57 PM, Keith Busch wrote:
On Wed, Dec 29, 2021 at 06:39:02PM +0100, Christoph Hellwig wrote:
(except for the fact that it, just like the other rq_list helpers
really should go into blk-mq.h, where all request related bits moved
early in this cycle)
Agreed, I just put it here because it's where the other macros live. But
'struct request' doesn't exist in this header, so it does seem out of
place. For v3, I'll add a preceding patch to move them all to blk-mq.h.
Did you see the discussion I had with Jens ?
I did, yes. That's when I noticed the error handling wasn't right, and
doing it correctly was a bit clunky. This series was supposed to make it
easier for drivers to use the new interface.
Seems it works only for non-shared tagsets and it means that it will work
only for NVMe devices that have 1 namespace and will not work for NVMf
drivers.
I am aware shared tags don't get to use the batched queueing, but that's
orthogonal to this series.
Yes. This series probably should be squashed to Jens's and merged together.
Most PCIe NVMe SSDs only have 1 namespace, so it generally works out for
those.
There are SSDs that support NS management and also devices that support
multiple NS (NVIDIA's NVMe SNAP device support many NSs).
Also all the fabrics controllers support it.
I don't think we need to restrict capable controllers from not working
with the batching feature from day 1.
Unless, we'll do some changes in the block layer and/or remove this
condition.
I think it just may work if we export blk_mq_get_driver_tag().
do you have a suggestion for the NVMe/PCI driver ?
I can run it in my lab if you don't have an SSD with more than 1 NS..
