Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 Jan 2022 15:38:13 +0100
From:   Klaus Jensen <its@irrelevant.dk>
To:     Keith Busch <kbusch@kernel.org>
Cc:     linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-block@vger.kernel.org, axboe@kernel.dk, hch@lst.de,
        martin.petersen@oracle.com, colyli@suse.de, arnd@arndb.de
Subject: Re: [RFC 0/7] 64-bit data integrity field support
Message-ID: <YfFc1f2MoSQzyxZ4@apples>
References: <20220124160107.1683901-1-kbusch@kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="vd57dnmutxBObqid"
Content-Disposition: inline
In-Reply-To: <20220124160107.1683901-1-kbusch@kernel.org>
Precedence: bulk


--vd57dnmutxBObqid
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jan 24 08:01, Keith Busch wrote:
> The NVM Express protocol added enhancements to the data integrity field
> formats beyond the T10 defined protection information. A detailed
> description of the new formats can be found in the NVMe's NVM Command
> Set Specification, section 5.2, available at:
>=20
>   https://nvmexpress.org/wp-content/uploads/NVM-Command-Set-Specification=
-1.0b-2021.12.18-Ratified.pdf
>=20
> This series implements one possible new format: the CRC64 guard with
> 48-bit reference tags. This does not add support for the variable
> "storage tag" field.
>=20
> The NVMe CRC64 parameters (from Rocksoft) were not implemented in the
> kernel, so a software implementation is included in this series based on
> the generated table. This series does not include any possible hardware
> excelleration (ex: x86's pclmulqdq), so it's not very high performant
> right now.
>=20

Hi Keith,

Tested this on QEMU and (assuming we didnt implement the same bugs) it
looks good functionally for separate metadata. However, it should also
be able to support PRACT (i.e. pi strip/insert device-side) if
nvme_ns_has_pi() is updated to also match on the 16 byte pi tuple. I
made it work by just hitting it with a hammer and changing the
comparison to hard-coded 16 bytes, but it should of course handle both
cases.

Naveen and I will post the emulated implementation (that certainly isnt
very high performant either) on qemu-block ASAP if others are interested
in giving this a spin without having hardware available.

--vd57dnmutxBObqid
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmHxXNIACgkQTeGvMW1P
DentcAf/W/roVVj60nLr0claSmtY5JLuq/07TsbgeykeS04Yr9AWpPp79Yvwnus/
sEZAxGWyDdn+J5CdJJ3YYG0xt6J1ET+i6JWTw7jG8Mx4dzKU+MjhT7IosuavGieg
L5xs02jpT3+l+aBNOlSspom8WaN8EcxPOKRKzF4Ew0kwtta10XoMfU4W9ceuSp62
GbNWKqnpyoCyQeVW5/AOZQ9/58V84So0roA0Vj4joICOVyofj7VDYSespsI8+y4y
CtYSypgpp/3GdJ8YaKcuNN7Z1k18GUb6sYBSbRNeCknh9FHsAMVkcoC6yKUXA8tD
p0sG5s5m+F1HeG0lKi6Y+0/T6q8nzw==
=DnBV
-----END PGP SIGNATURE-----

--vd57dnmutxBObqid--