RE: [PATCH] scsi: ufs: mark HPB support as BROKEN

Daejun Park
2021-10-28T01:10:48Z

Hi Ming,

> On Wed, Oct 27, 2021 at 09:16:32AM -0700, Keith Busch wrote:
> > On Wed, Oct 27, 2021 at 11:58:23PM +0800, Ming Lei wrote:
> > > On Wed, Oct 27, 2021 at 11:44:04AM -0400, Martin K. Petersen wrote:
> > > >
> > > > Ming,
> > > >
> > > > > request with scsi_cmnd may be allocated by the ufshpb driver, even it
> > > > > should be fine to call ufshcd_queuecommand() directly for this driver
> > > > > private IO, if the tag can be reused. One example is scsi_ioctl_reset().
> > > >
> > > > scsi_ioctl_reset() allocates a new request, though, so that doesn't
> > > > solve the forward progress guarantee. Whereas eh puts the saved request
> > > > on the stack.
> > >
> > > What I meant is to use one totally ufshpb private command allocated from
> > > private slab to replace the spawned request, which is sent to ufshcd_queuecommand()
> > > directly, so forward progress is guaranteed if the blk-mq request's tag can be
> > > reused for issuing this private command. This approach takes a bit effort,
> > > but avoids tags reservation.
> > >
> > > Yeah, it is cleaner to use reserved tag for the spawned request, but we
> > > need to know:
> > >
> > > 1) how many queue depth for the hba? If it is small, even 1 reservation
> > > can affect performance.
> > >
> > > 2) how many inflight write buffer commands are to be supported? Or how many
> > > is enough for obtaining expected performance? If the number is big, reserved
> > > tags can't work.
> >
> > The original and clone are not dispatched to hardware concurrently, so I
> > don't think the reserved_tags need to subtract from the generic ones.
> > The original request already accounts for the hardware resource, so the
> > clone doesn't need to consume another one.
>
> Yeah, that is why I thought the tag could be reused for the spawned(cloned)
> request, but it needs ufshpb developer to confirm, or at least
> ufshcd_queuecommand() can handle this situation. If that is true, it isn't
> necessary to use reserve tags, since the current blk-mq implementation
> requires to reserve real hardware tags space, which has to take normal
> tags.

It is true that pre-request can use the tag of READ request, but the READ
request should wait to completion of the pre-request command. However, if
the pre-request and the READ request are dispatched concurrently, it can
save the time to completion of the pre-request.

So I implemented as allocating new request and it has limit time to getting
pre-request, so it doesn't cause deadlock.

Thanks,
Daejun