On Thu, Oct 17, 2024 at 09:22:22AM -0600, Jens Axboe wrote:
> On 10/17/24 9:13 AM, Bart Van Assche wrote:
> > On 10/17/24 4:36 AM, Ming Lei wrote:
> >> +static blk_status_t nbd_send_pending_cmd(struct nbd_device *nbd,
> >> + struct nbd_cmd *cmd)
> >> +{
> >> + struct request *req = blk_mq_rq_from_pdu(cmd);
> >> + unsigned long deadline = READ_ONCE(req->deadline);
> >> + unsigned int wait_ms = 2;
> >> + blk_status_t res;
> >> +
> >> + WARN_ON_ONCE(test_bit(NBD_CMD_REQUEUED, &cmd->flags));
> >> +
> >> + while (true) {
> >> + res = nbd_send_cmd(nbd, cmd, cmd->index);
> >> + if (res != BLK_STS_RESOURCE)
> >> + return res;
> >> + if (READ_ONCE(jiffies) + msecs_to_jiffies(wait_ms) >= deadline)
> >> + break;
> >> + msleep(wait_ms);
> >> + wait_ms *= 2;
> >> + }
> >
> > I think that there are better solutions to wait until more data
> > can be sent, e.g. by using the kernel equivalent of the C library
> > function select().
>
> It's vfs_poll() - but I don't think that'd be worth it here, the nbd
> driver sets BLK_MQ_F_BLOCKING anyway. Using a poll trigger for this
> would be a lot more complicated, and need quite a bit of support code.
Agree.
It is one unlikely event and not worth vfs_poll() here.
And the retry with exponential backoff wait should work just fine.
Thanks,
Ming
