[PATCH v7 1/1] nvmet: support reservation feature

[Sagi Grimberg]

On 28/02/2024 5:40, Guixin Liu wrote:
>
> 在 2024/2/28 11:21, Keith Busch 写道:
>> On Wed, Feb 28, 2024 at 10:21:57AM +0800, Guixin Liu wrote:
>>> 在 2024/2/28 08:40, Sagi Grimberg 写道:
>>>> Hey Guixin,
>>>>
>>>> On 01/02/2024 4:32, Guixin Liu wrote:
>>>>> This patch implements the reservation feature, includes:
>>>>> 1. reservation register(register, unregister and replace).
>>>>> 2. reservation acquire(acquire, preempt, preempt and abort).
>>>>
>>>> Overall patchset looks in decent shape to me now.
>>>>
>>>> I do have one more question though.
>>> My thanks for your patient review.
>>>> You say that this patchset implements preempt and abort, however I 
>>>> don't
>>>> see how this is actually implemented or even how can it be implemented
>>>> at all at this point.
>>> Yes, the nvme target does not do any useful workto abort command, the
>>> comment of nvmet_execute_abort() says that
>>>
>>> "we are not required to do any useful work, and we couldn't really do a
>>> useful abort",
>>>
>>> so I don't know what to do about preempt and abort, and the NVMe 
>>> spec says
>>> that the abort is best effor.
>>>
>>> My statement here may be a little inaccurate.
>> I think you may be mixing up the NVMe "Abort" command with a different
>> command, "Reservation Acquire", where RACQA is set to value 010b,
>> "Preempt and Abort".
>
> Sorry, I just want to explain that I dont know how to implement 
> "preempt and abort"

unlike abort, preempt-and-abort needs a semantic guarantee because the 
consumer
may rely on this for fencing purposes. So it cannot be supported in 
"best effort" I think.

A possible implementation would be not to abort as there is no such 
interface, but
nvmet may wait for all pending ns IO to complete and disallowing new IO 
to come in
(using percpu_ref_kill and percpu_ref_resurrect on ns->ref). This won't 
work very efficiently
withALL_REGS reservations though.