All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maged Mokhtar" <mmokhtar@petasan.org>
To: target-devel@vger.kernel.org
Subject: Re: [PATCH 01/33] TCMU PR: first commit to implement TCMU PR
Date: Sat, 16 Jun 2018 11:04:56 +0000	[thread overview]
Message-ID: <98377f59e90bc902e03fcc2a4ecf9e21.squirrel@host449.hostmonster.com> (raw)
In-Reply-To: <20180615182342.6239-1-lszhu@suse.com>


Hi Zhu,

These are my comments for the patch set:

1) patches 18-24, 28, 30,32 (+ the yet to be implemented pr functions) :
instead of bypassing target_core_pr.c and re-writing all the existing pr
logic again, can we use existing code but just have get/set functions to
read/write the pr data from/to the backend. Example of
target_scsi3_emulate_pr_out:

sense_reason_t target_scsi3_emulate_pr_out(struct se_cmd *cmd) {
	get pr data callback  /* new code */
	switch (sa) {
	case PRO_REGISTER:
		ret = core_scsi3_emulate_pro_register(..)
		break;
	case PRO_RESERVE:
		ret = core_scsi3_emulate_pro_reserve(..);
	..........
	}
	set pr data callback  /* new code */
}

This is over-simplified as there could be extra locking but should be
relatively minor. target_core_pr.c can have default implementation to
get/set from static variable. Backends can over-ride this to support
clustered distribution but they would not need to re-implement pr logic.

2) patch 4: existing set pr function
static int tcmu_set_dev_pr_info(struct tcmu_dev *udev, void *val)
better use char* than void* since it is a null terminated string rather
than a buffer with length

3) patch 4: existing set pr function
static int tcmu_set_dev_pr_info(struct tcmu_dev *udev, void *val)
better is
static int tcmu_set_dev_pr_info(struct tcmu_dev *udev, char *val_old, char
*val_new)
so in addition to the new pr we also include the old pr, this will allow
backends that support atomic operations like ceph to implement this via an
atomic compare and set. This is the method used in existing SUSE
target_core_rbd and is more robust in a clustered environment.

4) patch 20 tcmu_execute_pr_register_existing: the update key should also
update any reservation by the old key (if any) in addition to the
registration. Point 1) would avoid this.

5) patch 24 tcmu_execute_pr_read_keys: the add_len should reflect the
total needed length rather than the truncated length. This was fixed
recently in target_core_pr.c by David. Again Point 1) would avoid this.

6) patch 15:
#define TCMU_PR_INFO_XATTR_MAX_SIZE 8192
	buf_remain = TCMU_PR_INFO_XATTR_ENCODED_MAXLEN(pr_info->num_regs);
	if (buf_remain > TCMU_PR_INFO_XATTR_MAX_SIZE) {
		pr_err("PR info too large for encoding: %zd\n", buf_remain);
		return -EINVAL;
	}
should probably increase TCMU_PR_INFO_XATTR_MAX_SIZE, 8k limits
registrations to 16 nexus


7) Minor observation, some patches could be combined, for example patches
5-17 deal with string decode/encode could be made in fewer patches.

Maged




  parent reply	other threads:[~2018-06-16 11:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 18:23 [PATCH 01/33] TCMU PR: first commit to implement TCMU PR Zhu Lingshan
2018-06-15 18:32 ` Zhu Lingshan
2018-06-16  5:22 ` Christoph Hellwig
2018-06-16  7:08 ` Zhu Lingshan
2018-06-16 11:04 ` Maged Mokhtar [this message]
2018-06-16 11:08 ` Zhu Lingshan
2018-06-16 19:20 ` Mike Christie
2018-06-16 19:25 ` Mike Christie
2018-06-17  4:40 ` Zhu Lingshan
2018-06-18 11:09 ` Christoph Hellwig
2018-06-18 11:10 ` Christoph Hellwig
2018-06-18 11:12 ` Christoph Hellwig
2018-06-18 11:31 ` Zhu Lingshan
2018-06-18 11:41 ` David Disseldorp
2018-06-19 14:29 ` 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=98377f59e90bc902e03fcc2a4ecf9e21.squirrel@host449.hostmonster.com \
    --to=mmokhtar@petasan.org \
    --cc=target-devel@vger.kernel.org \
    /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.