Re: [PATCH 1/5] blk-mq: Export reading mq request state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2019-03-08 at 11:15 -0700, Keith Busch wrote:
+AD4 On Fri, Mar 08, 2019 at 10:07:23AM -0800, Bart Van Assche wrote:
+AD4 +AD4 On Fri, 2019-03-08 at 10:40 -0700, Keith Busch wrote:
+AD4 +AD4 +AD4 Drivers may need to know the state of their requets.
+AD4 +AD4 
+AD4 +AD4 Hi Keith,
+AD4 +AD4 
+AD4 +AD4 What makes you think that drivers should be able to check the state of their
+AD4 +AD4 requests? Please elaborate.
+AD4 
+AD4 Patches 4 and 5 in this series.
+AD4  
+AD4 +AD4 +AD4 diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
+AD4 +AD4 +AD4 index faed9d9eb84c..db113aee48bb 100644
+AD4 +AD4 +AD4 --- a/include/linux/blkdev.h
+AD4 +AD4 +AD4 +-+-+- b/include/linux/blkdev.h
+AD4 +AD4 +AD4 +AEAAQA -241,6 +-241,15 +AEAAQA struct request +AHs
+AD4 +AD4 +AD4  	struct request +ACo-next+AF8-rq+ADs
+AD4 +AD4 +AD4  +AH0AOw
+AD4 +AD4 +AD4  
+AD4 +AD4 +AD4 +-/+ACoAKg
+AD4 +AD4 +AD4 +- +ACo blk+AF8-mq+AF8-rq+AF8-state() - read the current MQ+AF8-RQ+AF8AKg state of a request
+AD4 +AD4 +AD4 +- +ACo +AEA-rq: target request.
+AD4 +AD4 +AD4 +- +ACo-/
+AD4 +AD4 +AD4 +-static inline enum mq+AF8-rq+AF8-state blk+AF8-mq+AF8-rq+AF8-state(struct request +ACo-rq)
+AD4 +AD4 +AD4 +-+AHs
+AD4 +AD4 +AD4 +-	return READ+AF8-ONCE(rq-+AD4-state)+ADs
+AD4 +AD4 +AD4 +-+AH0
+AD4 +AD4 
+AD4 +AD4 Please also explain how drivers can use this function without triggering a
+AD4 +AD4 race condition with the code that modifies rq-+AD4-state.
+AD4 
+AD4 Either queisced or within a timeout handler that already locks the
+AD4 request lifetime.

Hi Keith,

For future patch series submissions please include a cover letter. The two patch
series that you posted today don't have a cover letter so I can only guess what
the purpose of these two patch series is. Is the purpose of this patch series
perhaps to speed up error handling? If so, why did you choose the approach of
iterating over outstanding requests and telling the block layer to terminate
these requests? I think that the NVMe spec provides a more elegant mechanism,
namely deleting the I/O submission queues. According to what I read in the
1.3c spec deleting an I/O submission queue forces an NVMe controller to post a 
completion for every outstanding request. See also section 5.6 in the NVMe
1.3c spec.

Bart.



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux