Re: [RFC 0/3] Add support of iopoll for dm device

[JeffleXu <jefflexu@linux.alibaba.com>]

On 10/27/20 2:53 AM, Mike Snitzer wrote:
> What you detailed there isn't properly modeling what it needs to.
> A given dm_target_io could result in quite a few bios (e.g. for
> dm-striped we clone each bio for each of N stripes).  So the fan-out,
> especially if then stacked on N layers of stacked devices, to all the
> various hctx at the lowest layers is like herding cats.
>
> But the recursion in block core's submit_bio path makes that challenging
> to say the least.  So much so that any solution related to enabling
> proper bio-based IO polling is going to need a pretty significant
> investment in fixing block core (storing __submit_bio()'s cookie during
> recursion, possibly storing to driver provided memory location,
> e.g. DM initialized bio->submit_cookie pointer to a blk_qc_t within a DM
> clone bio's per-bio-data).
>
> SO __submit_bio_noacct would become:
>
>     retp = &ret;
>     if (bio->submit_cookie)
>            retp = bio->submit_cookie;
>     *retp = __submit_bio(bio);

Sorry for the late reply. Exactly I missed this point before. IF you 
have not started working on this, I'd

like to try to implement this as an RFC.


> I think you probably just got caught out by the recursive nature of the bio
> submission path -- makes creating a graph of submitted bios and their
> associated per-bio-data and generated cookies a mess to track (again,
> like herding cats).
>
> Could also be you didn't quite understand the DM code's various
> structures.
>
> In any case, the block core changes needed to make bio-based IO polling
> work is the main limiting factor right now.
Yes the logic is kind of subtle and maybe what I'm concerned here is 
really should be concerned

at the coding phase.


Thanks.

Jeffle Xu