netdev - RE: [PATCH v25 00/20] nvme-tcp receive offloads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <253v81vpw4t.fsf@nvidia.com>
Date: Wed, 26 Jun 2024 18:21:54 +0300
From: Aurelien Aptel <aaptel@...dia.com>
To: Sagi Grimberg <sagi@...mberg.me>, Jakub Kicinski <kuba@...nel.org>
Cc: "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "hch@....de"
 <hch@....de>, "kbusch@...nel.org" <kbusch@...nel.org>, "axboe@...com"
 <axboe@...com>, Chaitanya Kulkarni <chaitanyak@...dia.com>,
 "davem@...emloft.net" <davem@...emloft.net>, Shai Malin
 <smalin@...dia.com>, "malin1024@...il.com" <malin1024@...il.com>, Yoray
 Zack <yorayz@...dia.com>, Jason Gunthorpe <jgg@...dia.com>, Tariq Toukan
 <tariqt@...dia.com>, mgurtovoy@...dia.com, galshalom@...dia.com,
 borisp@...dia.com, ogerlitz@...dia.com
Subject: RE: [PATCH v25 00/20] nvme-tcp receive offloads

Hi,

We have taken some time to review your documents and code and have had
several internal discussions regarding the CI topic. We truly appreciate
the benefits that a CI setup could bring. However, we believe that since
this feature primarily relies on nvme-tcp, it might achieve better
coverage and testing if integrated with blktest. Your design focuses on
the netdev layer, which we don't think is sufficient.

blktests/nvme is designed to test the entire nvme upstream
infrastructure including nvme-tcp that targets corner cases and bugs in
on-going development.  Chaitanya, Shinichiro, Daniel and other
developers are actively developing blktests and running these tests in
timely manner on latest branch in linux-nvme repo and for-next branch in
linux-block repo.

Again, we are open to provide NIC so that others can also test this
feature on upstream kernel on our NIC to facilitate easier testing
including distros, as long as they are testing this feature on upstream
kernel. In this way we don't have to replicate the nvme-block storage
stack infra/tools/tests in the framework that is focused on netdev
development and yet achieve good coverage, what do you think?

Thanks