Re: [PATCH v2 01/14] nvmet: Rapid Path Failure Recovery set controller identify fields

[Mohamed Khalfella]

On Fri 2026-02-13 16:42:55 -0800, Randy Jennings wrote:
> On Sat, Feb 7, 2026 at 5:41 AM Sagi Grimberg <sagi@xxxxxxxxxxx> wrote:
> >
> >
> > > Precisely my point. If CQT defaults to zero no delay will be inserted,
> > > but we _still_ have CCR handling. Just proving that both really are
> > > independent on each other. Hence I would prefer to have two patchsets.
> >
> > Agreed. I think it would be cleaner to review each separately. the CCR
> > can be based
> > on top of the CQT patchset, for simplicity.
> >
> Hannes, I have some concerns about structuring the CQT patches
> separate from the CCR patches.
> 
> We are trying to fix the Ghost Write data corruption, and this has
> been a long process (involving 3 modifications to the spec and a
> number of proposed patch sets).  We’ve already been told (explicitly
> and implicitly) that CCR is the more interesting solution (a
> euphemism) for solving this data corruption.  I have some concern
> that, if  separated, the CCR patches will get accepted without the CQT
> patches.
> 
> CCR does not work in all cases, so I do not see them as independent as
> you are saying here. Also, CQT is a natural time cap on the retries
> needed for CCR to handle CCR retries when it cannot succeed down some
> paths.  When used as a time cap, CQT fits well with the CCR changes.
> 
> I am concerned that it will be more complicated to review the CQT
> changes, with at least more patches to review.

True. It results in more patches to review. However, I think it is
easier to see the delay added by CQT after the it has pulled pulled into
separate set of patches.

> 
> Structuring the patches with CQT first and CCR second would take care
> of many of these concerns.
> 
> Sincerely,
> Randy Jennings