linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alexander V. Buev" <a.buev@yadro.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: <linux-block@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@lst.de>,
	Mikhail Malygin <m.malygin@yadro.com>, <linux@yadro.com>
Subject: Re: [PATCH 1/3] block: bio-integrity: add PI iovec to bio
Date: Fri, 29 Oct 2021 13:59:16 +0300	[thread overview]
Message-ID: <20211029105916.6eedcdpd2jho2c5q@yadro.com> (raw)
In-Reply-To: <yq1cznov6q7.fsf@ca-mkp.ca.oracle.com>

> 
> Alexander,
> 
> Thanks for working on this!
> 
> > +		if (bip->bip_flags & BIP_RELEASE_PAGES) {
> > +			bio_integrity_payload_release_pages(bip);
> > +		}
> 
> In my parallel attempt the flag was called BIP_USER_MAPPED to mirror
> BIO_USER_MAPPED. But with the latter now gone it doesn't really
> matter. BIP_RELEASE_PAGES is fine.
ok 

> I find bio_integrity_payload_release_pages() a bit long. All the other
> functions just use a bio_integrity_ prefix and take a bio. But no
> biggie.
> 
> > +int bio_integrity_add_pi_iovec(struct bio *bio, struct iovec *pi_iov)
> 
> bio_integrity_add_iovec(), please. _pi is redundant.

I definitely agree with this (As with other similar notes)
It's just my habit of naming functions by struct name.

> 
> > +	bip_set_seed(bip, bio->bi_iter.bi_sector);
> > +
> > +	if (bi->flags & BLK_INTEGRITY_IP_CHECKSUM)
> > +		bip->bip_flags |= BIP_IP_CHECKSUM;
> 
> The last couple of months I have been working on a version of our DIX/PI
> qualification tooling that does not depend on the DB I/O stack.
> 
> For the test tooling to work I need to be able to pass the seed and the
> BIP_* flags as part of the command. The tooling needs to be able to
> select the type of checksum and to be able to disable checking for
> initiator and target on a per-I/O basis. So these would need to be
> passed in.
> 
> Note that extended PI formats have been defined in NVMe. These allow for
> larger CRCs and reference tags to be specified in addition to a storage
> tag. So we'll need to be careful when defining the SQE fields here.
 
After discussion, I plan to start by adding a pointer to the PI data 
in SQE struct.
This struct now has some padding that can be used for this.
Size of PI data can be determined according to integrity profile of
device and size of normal data.

Also, as recommended, the new version will use opcodes instead of the flag.

Thanks everyone for the detailed feedback. It's important for me.
I will try to correct all the issue's in the next version.

But some later )


-- 
Alexander Buev

  reply	other threads:[~2021-10-29 10:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 11:24 [PATCH 0/3] implement direct IO with integrity Alexander V. Buev
2021-10-28 11:24 ` [PATCH 1/3] block: bio-integrity: add PI iovec to bio Alexander V. Buev
2021-10-28 15:16   ` Christoph Hellwig
2021-10-29  0:11   ` Chaitanya Kulkarni
2021-10-29  4:27   ` Martin K. Petersen
2021-10-29 10:59     ` Alexander V. Buev [this message]
2021-10-29  8:40   ` kernel test robot
2021-10-29  8:53   ` kernel test robot
2021-10-29  9:48   ` kernel test robot
2021-10-28 11:24 ` [PATCH 2/3] block: io_uring: add IO_WITH_PI flag to SQE Alexander V. Buev
2021-10-28 11:24 ` [PATCH 3/3] block: fops: handle IOCB_USE_PI in direct IO Alexander V. Buev
2021-10-28 15:17   ` Christoph Hellwig
2021-10-29  9:04   ` kernel test robot
2021-10-28 15:13 ` [PATCH 0/3] implement direct IO with integrity Jens Axboe
2021-10-28 15:18   ` Christoph Hellwig
2021-10-28 15:20     ` Jens Axboe
2021-10-28 15:44       ` Mikhail Malygin
2021-10-28 15:50         ` Jens Axboe
2021-10-28 15:56           ` Pavel Begunkov
2021-10-28 16:22             ` Jens Axboe
2021-10-28 17:11               ` Pavel Begunkov
2021-10-28 17:45                 ` Jens Axboe
2021-10-29  3:39       ` Martin K. Petersen
2021-10-28 15:25   ` Jens Axboe

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=20211029105916.6eedcdpd2jho2c5q@yadro.com \
    --to=a.buev@yadro.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux@yadro.com \
    --cc=m.malygin@yadro.com \
    --cc=martin.petersen@oracle.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).