[LSF/MM/BPF TOPIC] TP4129 KATO correctoins and clarification

[Ballard, Curtis C (HPE Storage)]

If there are specific aspects of TP4129 that are broken, I would be interested in learning more about them and how they are broken. If this topic were to be discussed at LSF, that could be part of the conversation.  What parts are broken (or cause concern), what the issues are, are there any ideas on how they could be fixed?

Curtis Ballard
Strategist, Storage Technology
Hewlett Packard Enterprise

-----Original Message-----
From: Linux-nvme <linux-nvme-bounces at lists.infradead.org> On Behalf Of Daniel Wagner
Sent: Friday, January 31, 2025 9:20 AM
To: Hannes Reinecke <hare at suse.de>
Cc: Christoph Hellwig <hch at infradead.org>; linux-nvme at lists.infradead.org; Mohamed Khalfella <mkhalfella at purestorage.com>; Sagi Grimberg <sagi at grimberg.me>; John Meneghini <jmeneghi at redhat.com>; Randy Jennings <randyj at purestorage.com>; Keith Busch <kbusch at kernel.org>; lsf-pc at lists.linux-foundation.org
Subject: Re: [LSF/MM/BPF TOPIC] TP4129 KATO correctoins and clarification

On Fri, Jan 31, 2025 at 12:02:59PM +0100, Hannes Reinecke wrote:
> On 1/31/25 10:32, Christoph Hellwig wrote:
> > On Fri, Jan 31, 2025 at 10:24:31AM +0100, Daniel Wagner wrote:
> > > Hi,
> > > 
> > > The KATO handling in the spec got updated via the TP4129. In short it
> > > mandatas that failing requests should be delayed by some value before
> > > retried on a different path.
> > 
> > TP4129 is broken and the TWG has been told that.  There is absolutely no
> > point in either implementing it or rehashing the discussion over and
> > over again.  Concentrate on making 8028 useful instead.  And if you want
> > a discussion, "why do people people push stupid things though the
> > NVMe TWG and then comaplain later about the lack of implementations"
> > might be more useful.
> 
> Okay, let's rephrase that to 'Improve NVMe-oF error handling'.
> We are trying to get TP8028 out into the open until LSF,
> then we can discuss that and also how to fold in the
> 'command cancel' patchset into the overall picture.

Yes, that basically was the idea for this proposal. I should have called
it differently. 'Improve NVMe-oF error handling' sounds about right.