linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Max Gurtovoy <maxg@mellanox.com>
Cc: linux-block@vger.kernel.org, axboe@kernel.dk,
	martin.petersen@oracle.com, linux-nvme@lists.infradead.org,
	keith.busch@intel.com, hch@lst.de, sagi@grimberg.me,
	shlomin@mellanox.com, israelr@mellanox.com
Subject: Re: [PATCH v4 1/3] block: centralize PI remapping logic to the block layer
Date: Sun, 08 Sep 2019 22:21:51 -0400	[thread overview]
Message-ID: <yq1mufei4zk.fsf@oracle.com> (raw)
In-Reply-To: <1567956405-5585-1-git-send-email-maxg@mellanox.com> (Max Gurtovoy's message of "Sun, 8 Sep 2019 18:26:43 +0300")


Hi Max!

> @@ -309,7 +308,7 @@ static void sd_set_flush_flag(struct scsi_disk *sdkp)
>  {
>  	struct scsi_disk *sdkp = to_scsi_disk(dev);
>  
> -	return sprintf(buf, "%u\n", sdkp->protection_type);
> +	return sprintf(buf, "%u\n", sdkp->disk->protection_type);

I'm fine with moving the prepare/complete logic to the block layer. But
the block layer should always be using information from the integrity
profile. sdkp->protection_type is a SCSI disk property which is used to
pick the right integrity profile when a device is discovered and
registered.

 - sdkp->protection_type is the type the disk is formatted with. This
   may or may not be the same as the metadata format used by DIX and the
   block layer.

 - The DIX protection type (which is what matters for protection
   information preparation) is encapsulated in the integrity profile
   registered for the block device. The profile describes an abstract
   protection format and can (at least in theory) carry non-T10 PI
   protection information.

Linux currently uses the Type 1 block layer integrity profile for
devices formatted with T10 PI Types 0, 1, and 2. And the Type 3 block
layer integrity profile for devices formatted with T10 PI Type 3. This
profile is what we should be keying off of in t10-pi.c, not the
protection_type (the fact that protection_type is even there is because
the code was lifted out from sd.c).

I would prefer to introduce .prepare_fn and .complete_fn for the Type 1
profile to match the existing .generate_fn and verify_fn. And then adapt
t10_pi_prepare() / t10_pi_complete() to plug into these new
callbacks. The need for protection_type and Type 3 matching goes away in
that case since the callbacks would only be set for the Type 1 profile.

>  static inline unsigned short
> +blk_integrity_interval_shift(struct request_queue *q)
> +{
> +	return q->limits.logical_block_shift;
> +}
> +

Why not use bio_integrity_intervals() or bi->interval_exp?

Note that for T10 PI Type 2, the protection interval is not necessarily
the logical block size.

-- 
Martin K. Petersen	Oracle Linux Engineering

  parent reply	other threads:[~2019-09-09  2:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-08 15:26 [PATCH v4 1/3] block: centralize PI remapping logic to the block layer Max Gurtovoy
2019-09-08 15:26 ` [PATCH v4 2/3] block: don't remap ref tag for T10 PI type 0 Max Gurtovoy
2019-09-09  2:22   ` Martin K. Petersen
2019-09-09  2:36     ` Keith Busch
2019-09-09  2:49       ` Martin K. Petersen
2019-09-09 13:31         ` Max Gurtovoy
2019-09-08 15:26 ` [PATCH v4 3/3] nvme: remove PI values definition from NVMe subsystem Max Gurtovoy
2019-09-09  2:21 ` Martin K. Petersen [this message]
2019-09-09 13:55   ` [PATCH v4 1/3] block: centralize PI remapping logic to the block layer Max Gurtovoy
2019-09-10  2:29     ` Martin K. Petersen
2019-09-10 22:27       ` Max Gurtovoy
2019-09-11  1:16         ` Martin K. Petersen
2019-09-11  9:12           ` Max Gurtovoy
2019-09-13 22:20             ` Martin K. Petersen
2019-09-16  8:03               ` Christoph Hellwig
2019-09-16 17:19                 ` Martin K. Petersen

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=yq1mufei4zk.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=israelr@mellanox.com \
    --cc=keith.busch@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=maxg@mellanox.com \
    --cc=sagi@grimberg.me \
    --cc=shlomin@mellanox.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).