From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 698961836DD for ; Wed, 26 Jun 2024 15:50:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719417019; cv=none; b=k8IrTIQnsWtWwdzpRg26kXnKRnugfepWQeG2eWpWuZ6JocQ7ZDGH3BRoPx5ci0CB2oMa1BALVHjjMd8G7UsFz9EfVFYbzjrGkKgWcTjFJtGFebt/3pfgvuINgO+zys+8Krr3mg/zavvLzeRWQbMzoWzmMIFUTC8MeGexXygOej0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719417019; c=relaxed/simple; bh=udilUP9QJArcgyMP6AgqugC0tzaFDqpIwZeV/EYoOjw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=oT0InhT4K+kb/SdBlCdmI7G08dgpTNUbnWtyd25Oh5UnLrbWxtLjje10q3eOxKr5XJWVOldONEg7cxy21ViVNJz5G8C/SbYnevoF8lbAz64SKOwrHDVmnjC5S+dQ9sIG0WiX14/qZ/fLu6+6FN6Z7blbUFLZ9I0xdoSa/JktUJM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NGKZdkB9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NGKZdkB9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 707C4C116B1; Wed, 26 Jun 2024 15:50:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719417019; bh=udilUP9QJArcgyMP6AgqugC0tzaFDqpIwZeV/EYoOjw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NGKZdkB9wmHhzG1udefXK8CwYhsvgWTSxQF4so9tYeWPv2xt2NFJKOeCh84sEDUAe MAQIF9W5vjTpp7MMCzDd3iVWR2y2SI6cTu+QH4wDVaA9qZhsNYnjBHiMcs1dgm3gYp TOaIlj27JITIV/4mMXTOhwcqMgnsd+ovaNRaYKw6SLrsCoWYleP/WsgdO4vzNUhPf5 xdEumhD4xXpkBFqBj5o9H1sO1NHt+NFCNi08mLsSijrAomVDTgn5R8YP4FU1L40Mqm C7Yr/W1hKYdK0q6tRq9eTr8XvdsdITf5eMsImtCSCBOEwLn4qVVrx386TzS62oWpFb J3vXLCn+g/HVg== Date: Wed, 26 Jun 2024 08:50:17 -0700 From: Jakub Kicinski To: Aurelien Aptel Cc: Sagi Grimberg , "linux-nvme@lists.infradead.org" , "netdev@vger.kernel.org" , "hch@lst.de" , "kbusch@kernel.org" , "axboe@fb.com" , Chaitanya Kulkarni , "davem@davemloft.net" , Shai Malin , "malin1024@gmail.com" , Yoray Zack , Jason Gunthorpe , Tariq Toukan , mgurtovoy@nvidia.com, galshalom@nvidia.com, borisp@nvidia.com, ogerlitz@nvidia.com Subject: Re: [PATCH v25 00/20] nvme-tcp receive offloads Message-ID: <20240626085017.553f793f@kernel.org> In-Reply-To: <253v81vpw4t.fsf@nvidia.com> References: <20240529160053.111531-1-aaptel@nvidia.com> <20240530183906.4534c029@kernel.org> <9ed2275c-7887-4ce1-9b1d-3b51e9f47174@grimberg.me> <253v81vpw4t.fsf@nvidia.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 26 Jun 2024 18:21:54 +0300 Aurelien Aptel wrote: > 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? I'm not sure we're on the same page. The ask is to run the tests on the netdev testing branch, at 12h cadence, and generate a simple JSON file with results we can ingest into our reporting. Extra points to reporting it to KCIDB. You mention "framework that is focused on netdev", IDK what you mean.