public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Keith Busch <kbusch@kernel.org>,
	Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Sagi Grimberg <sagi@grimberg.me>, "hch@lst.de" <hch@lst.de>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	"dgilbert@interlog.com" <dgilbert@interlog.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"lsf-pc@lists.linuxfoundation.org"
	<lsf-pc@lists.linuxfoundation.org>
Subject: Re: [LSF/MM/BPF BOF] Userspace command abouts
Date: Mon, 27 Feb 2023 09:20:50 +0100	[thread overview]
Message-ID: <80826e82-2b16-2ec4-764b-4caa7cdbab55@suse.de> (raw)
In-Reply-To: <Y/lpmrwuehnsWmmR@kbusch-mbp.dhcp.thefacebook.com>

On 2/25/23 02:51, Keith Busch wrote:
> On Fri, Feb 24, 2023 at 11:54:39PM +0000, Chaitanya Kulkarni wrote:
>> I do think that we should work on CDL for NVMe as it will solve some of
>> the timeout related problems effectively than using aborts or any other
>> mechanism.
> 
> That proposal exists in NVMe TWG, but doesn't appear to have recent activity.
> The last I heard, one point of contention was where the duration limit property
> exists: within the command, or the queue. From my perspective, if it's not at
> the queue level, the limit becomes meaningless, but hey, it's not up to me.

And that is one of the issues I'd like to discuss.
As it stands CDL are defined for the controller only, queuing effects 
from the transport are out of scope (for the current CDL definition).
So for NVMe-oF we would need to discuss how we can specify CDLs for 
fabrics; especially the relationship between CDLs and transport timeouts 
are ... interesting, and we need to discuss how we can correlate both.

Having it on the queue as you suggested would be cool as it would give a 
nice overall number, but discussions with the driver vendors were not 
encouraging; they're having a hard time giving timeout guarantees in 
really quirky failure cases.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman


      parent reply	other threads:[~2023-02-27  8:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16 11:50 [LSF/MM/BPF BOF] Userspace command abouts Hannes Reinecke
2023-02-16 16:40 ` Keith Busch
2023-02-17 18:53   ` Chaitanya Kulkarni
2023-02-18  9:50     ` [LSF/MM/BPF BOF] Userspace command aborts Hannes Reinecke
2023-02-21 18:15       ` Chaitanya Kulkarni
2023-02-20 11:24   ` [LSF/MM/BPF BOF] Userspace command abouts Sagi Grimberg
2023-02-21 16:25     ` Douglas Gilbert
2023-02-22 14:37       ` Sagi Grimberg
2023-02-22 14:53         ` Keith Busch
2023-02-23 15:35           ` Sagi Grimberg
2023-02-24 23:54             ` Chaitanya Kulkarni
2023-02-25  1:51               ` Keith Busch
2023-02-25  4:15                 ` Damien Le Moal
2023-02-25 16:14                   ` James Smart
2023-02-27 16:33                   ` Sagi Grimberg
2023-02-27 17:28                     ` Hannes Reinecke
2023-02-27 17:44                       ` Keith Busch
2023-02-27 21:18                         ` Damien Le Moal
2023-02-27 21:42                         ` Damien Le Moal
2023-02-28  8:05                         ` Sagi Grimberg
2023-02-27 21:17                     ` Damien Le Moal
2023-02-27  8:20                 ` Hannes Reinecke [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=80826e82-2b16-2ec4-764b-4caa7cdbab55@suse.de \
    --to=hare@suse.de \
    --cc=chaitanyak@nvidia.com \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=dgilbert@interlog.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lsf-pc@lists.linuxfoundation.org \
    --cc=martin.petersen@oracle.com \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox