All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Guixin Liu <kanie@linux.alibaba.com>
Cc: hch@lst.de, sagi@grimberg.me, kch@nvidia.com,
	d.bogdanov@yadro.com, linux-nvme@lists.infradead.org
Subject: Re: [PATCH v11 1/1] nvmet: support reservation feature
Date: Wed, 2 Oct 2024 10:09:43 +0200	[thread overview]
Message-ID: <20241002080943.GA21262@lst.de> (raw)
In-Reply-To: <20240929031410.31281-2-kanie@linux.alibaba.com>

On Sun, Sep 29, 2024 at 11:14:10AM +0800, 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).
> 3. reservation release(release and clear).
> 4. reservation report.
> 5. set feature and get feature of reservation notify mask.
> 6. get log page of reservation event.
> 
> And also make reservation configurable, one can set ns to support
> reservation before enable ns. The default of resv_enable is false.

The explanation feels a bit sparse.  It could also mentioned that
no support for persistent reservation exists, and how this code
was tested.

Also, do you have a corresponding nvmetcli patch?

> +struct nvmet_pr_register_data {
> +	__le64	crkey;
> +	__le64	nrkey;
> +};
> +
> +struct nvmet_pr_acquire_data {
> +	__le64	crkey;
> +	__le64	prkey;
> +};
> +
> +struct nvmet_pr_release_data {
> +	__le64	crkey;
> +};

Using little endian fields for purely in-memory data feels strange.
Is there a good reason for this?

> +static u16 nvmet_pr_update_reg_attr(struct nvmet_pr *pr,
> +				    struct nvmet_pr_registrant *reg,
> +				    void (*change_attr)(struct nvmet_pr_registrant *reg,
> +					void *attr),
> +				    void *attr)

Please avoid the overly long line here.  That's easiest done by
following the style used elsewhere in the nvme code using two
tab continuations:

static u16 nvmet_pr_update_reg_attr(struct nvmet_pr *pr,
		struct nvmet_pr_registrant *reg,
		void (*change_attr)(struct nvmet_pr_registrant *reg,
				void *attr),
		void *attr)

> +	change_attr(new, attr);
> +	list_replace_rcu(&holder->entry, &new->entry);
> +	rcu_assign_pointer(pr->holder, new);
> +	synchronize_rcu();
> +	kfree(holder);

Does this really need a full blown expensive synchronize_rcu vs just a
cheaper kfree_rcu_mightsleep or kfree_rcu?

> +	bool ignore_key = (bool)((cdw10 >> 3) & 1); /* Ignore existing key, bit 03 */

Overly long line.  This might also benefit from adding symbolic constants
and/or extraction helpers.

The explicit cast to bool should also not be needed.

> +	struct nvmet_pr_registrant *reg, *tmp;
> +	struct nvmet_pr *pr = &req->ns->pr;
> +	LIST_HEAD(free_list);
> +
> +	lockdep_assert_held(&pr->pr_lock);
> +
> +	rcu_assign_pointer(pr->holder, NULL);
> +
> +	list_for_each_entry_safe(reg, tmp, &pr->registrant_list, entry) {
> +		list_del_rcu(&reg->entry);
> +		if (!uuid_equal(&req->sq->ctrl->hostid, &reg->hostid))
> +			nvmet_pr_resv_preempted(pr, &reg->hostid);
> +		list_add(&reg->entry, &free_list);
> +	}
> +	synchronize_rcu();
> +	list_for_each_entry_safe(reg, tmp, &free_list, entry) {
> +		kfree(reg);
> +	}

No nee for the outer braces here.  But why do we we need the expensive
synchronize_rcu and two-step operation here anyway vs just using
kfree_rcu?

> +		/*
> +		 * Dynamic controller, set cntlid to 0xffff.
> +		 */
> +		ctrl_eds->cntlid = 0xffff;

NVME_CNTLID_DYNAMIC

> +	req->pc_ref = xa_load(&req->ns->pr_per_ctrl_refs, req->sq->ctrl->cntlid);

Overly long line.

> +	if (unlikely(!percpu_ref_tryget_live(&req->pc_ref->ref)))
> +		return NVME_SC_INTERNAL;
> +	return NVME_SC_SUCCESS;
> +}
> +
> +void nvmet_pr_put_ns_pc_ref(struct nvmet_req *req)
> +{
> +	if (req->pc_ref)
> +		percpu_ref_put(&req->pc_ref->ref);
> +}

It would be niceto have the NULL check inline to avoid the call for
for namespaces without reservation support.

> diff --git a/include/linux/nvme.h b/include/linux/nvme.h
> index 425573202295..b1be3d313bee 100644
> --- a/include/linux/nvme.h
> +++ b/include/linux/nvme.h

Please split out adding the new code points to nvme.h to a separate
prep patch.



  parent reply	other threads:[~2024-10-02  8:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-29  3:14 [PATCH v11 0/1] Implement the NVMe reservation feature Guixin Liu
2024-09-29  3:14 ` [PATCH v11 1/1] nvmet: support " Guixin Liu
2024-09-30 12:53   ` Dmitry Bogdanov
2024-10-05 14:26     ` Guixin Liu
2024-10-07  8:08       ` Dmitry Bogdanov
2024-10-08  7:27         ` Guixin Liu
2024-10-08  8:45           ` Dmitry Bogdanov
2024-10-08  9:25             ` Guixin Liu
2024-10-02  8:09   ` Christoph Hellwig [this message]
2024-10-05 15:09     ` Guixin Liu
2024-10-07  6:36       ` Christoph Hellwig

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=20241002080943.GA21262@lst.de \
    --to=hch@lst.de \
    --cc=d.bogdanov@yadro.com \
    --cc=kanie@linux.alibaba.com \
    --cc=kch@nvidia.com \
    --cc=linux-nvme@lists.infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.