On Mon, Feb 26 2018 at 3:22pm -0500, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > Hi > > The strncmp function should compare 4 bytes. Ah yeap, thanks. > But I'm wondering what's the purpose of this test at all? bio-based > interface doesn't support partial completions for any device - so why do > we need special code path just for nvme? request-based does support partial completions, it is the underlying devices that matter here, not the upper layer DM device type. The rationale for this atomic operation requirement is mainly historic: previously DM_TYPE_NVME_BIO_BASED was (ab)using blk_steal_bios() to retry a request that failed with a retryable error (as part of a hook that never was allowed to be introduced to the NVMe request completion code-path). For that model it was important that the underlying device not partially complete its request; because on retry all of the bios were getting stolen from the request and resubmitted in their entirety back to the upper layer bio-based device (multipath in my historic case). Now that DM_TYPE_NVME_BIO_BASED isn't making use of blk_steal_bios() we _could_ relax this constraint but I'd prefer to have the option of using blk_steal_bios() in the future. > and why can't we use it for other block devices? I'm not exactly sure about what you mean by "it" but I'll assume you mean: why can't we use direct_make_request() for other devices? I've purposely constrained DM_TYPE_NVME_BIO_BASED to mean we have a target that is an immutable singleton that is only layered on an NVMe device. I know this case to currently be uniquely suited for use with direct_make_request(): no splitting can occur and no partial completion is used by the underlying driver (the latter less important than the former). Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
