From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing methodology.
Date: Fri, 10 Mar 2017 19:37:58 +0000 [thread overview]
Message-ID: <1489174661.2548.5.camel@sandisk.com> (raw)
In-Reply-To: <CO2PR04MB2184DB653C04FB620B41435486670@CO2PR04MB2184.namprd04.prod.outlook.com>
On Tue, 2017-01-10 at 22:40 +0000, Chaitanya Kulkarni wrote:
> Participants:-
> ------------------
> I'd like to invite developers from different subsystems to discuss an app=
roach towards=A0
> a unified testing methodology for storage stack and device drivers belong=
s to=A0
> different subsystems.
>=20
> Topics for Discussion:-
> ------------------------------
> As a part of discussion following are some of the key points which we can=
focus on:-
> 1. What are the common components of the kernel used by the various subsy=
stems?
> 2. What are the potential target drivers which can benefit from this appr=
oach?=A0
> =A0 (e.g. NVMe, NVMe Over Fabric, Open Channel Solid State Drives etc.)
> 3. What are the desired features that can be implemented in this Framewor=
k?
> =A0 (code coverage, unit tests, stress testings, regression, generating C=
occinelle reports etc.)=A0
> 4. Desirable Report generation mechanism?
> 5. Basic performance validation?
> 6. Whether QEMU can be used to emulate some of the H/W functionality to c=
reate a test=A0
> =A0 platform? (Optional subsystem specific)
Regarding existing test software: the SRP test software is a thorough test =
of
the Linux block layer, SCSI core, dm-mpath driver, dm core, SRP initiator a=
nd
target drivers and also of the asynchronous I/O subsystem. This test suite
includes experimental support for the NVMeOF drivers. This test suite suppo=
rts
the rdma_rxe driver which means that an Ethernet adapter is sufficient to r=
un
these tests.
Note: the focus of this test suite is the regular I/O path and device remov=
al.
This test suite neither replaces the libiscsi tests nor xfstests.
See also https://github.com/bvanassche/srp-test.
Bart.=
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing methodology.
Date: Fri, 10 Mar 2017 19:37:58 +0000 [thread overview]
Message-ID: <1489174661.2548.5.camel@sandisk.com> (raw)
In-Reply-To: <CO2PR04MB2184DB653C04FB620B41435486670@CO2PR04MB2184.namprd04.prod.outlook.com>
On Tue, 2017-01-10 at 22:40 +0000, Chaitanya Kulkarni wrote:
> Participants:-
> ------------------
> I'd like to invite developers from different subsystems to discuss an approach towards
> a unified testing methodology for storage stack and device drivers belongs to
> different subsystems.
>
> Topics for Discussion:-
> ------------------------------
> As a part of discussion following are some of the key points which we can focus on:-
> 1. What are the common components of the kernel used by the various subsystems?
> 2. What are the potential target drivers which can benefit from this approach?
> (e.g. NVMe, NVMe Over Fabric, Open Channel Solid State Drives etc.)
> 3. What are the desired features that can be implemented in this Framework?
> (code coverage, unit tests, stress testings, regression, generating Coccinelle reports etc.)
> 4. Desirable Report generation mechanism?
> 5. Basic performance validation?
> 6. Whether QEMU can be used to emulate some of the H/W functionality to create a test
> platform? (Optional subsystem specific)
Regarding existing test software: the SRP test software is a thorough test of
the Linux block layer, SCSI core, dm-mpath driver, dm core, SRP initiator and
target drivers and also of the asynchronous I/O subsystem. This test suite
includes experimental support for the NVMeOF drivers. This test suite supports
the rdma_rxe driver which means that an Ethernet adapter is sufficient to run
these tests.
Note: the focus of this test suite is the regular I/O path and device removal.
This test suite neither replaces the libiscsi tests nor xfstests.
See also https://github.com/bvanassche/srp-test.
Bart.
WARNING: multiple messages have this Message-ID (diff)
From: Bart.VanAssche@sandisk.com (Bart Van Assche)
Subject: [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing methodology.
Date: Fri, 10 Mar 2017 19:37:58 +0000 [thread overview]
Message-ID: <1489174661.2548.5.camel@sandisk.com> (raw)
In-Reply-To: <CO2PR04MB2184DB653C04FB620B41435486670@CO2PR04MB2184.namprd04.prod.outlook.com>
On Tue, 2017-01-10@22:40 +0000, Chaitanya Kulkarni wrote:
> Participants:-
> ------------------
> I'd like to invite developers from different subsystems to discuss an approach towards?
> a unified testing methodology for storage stack and device drivers belongs to?
> different subsystems.
>
> Topics for Discussion:-
> ------------------------------
> As a part of discussion following are some of the key points which we can focus on:-
> 1. What are the common components of the kernel used by the various subsystems?
> 2. What are the potential target drivers which can benefit from this approach??
> ? (e.g. NVMe, NVMe Over Fabric, Open Channel Solid State Drives etc.)
> 3. What are the desired features that can be implemented in this Framework?
> ? (code coverage, unit tests, stress testings, regression, generating Coccinelle reports etc.)?
> 4. Desirable Report generation mechanism?
> 5. Basic performance validation?
> 6. Whether QEMU can be used to emulate some of the H/W functionality to create a test?
> ? platform? (Optional subsystem specific)
Regarding existing test software: the SRP test software is a thorough test of
the Linux block layer, SCSI core, dm-mpath driver, dm core, SRP initiator and
target drivers and also of the asynchronous I/O subsystem. This test suite
includes experimental support for the NVMeOF drivers. This test suite supports
the rdma_rxe driver which means that an Ethernet adapter is sufficient to run
these tests.
Note: the focus of this test suite is the regular I/O path and device removal.
This test suite neither replaces the libiscsi tests nor xfstests.
See also https://github.com/bvanassche/srp-test.
Bart.
next prev parent reply other threads:[~2017-03-10 19:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CO2PR04MB218427BF42159B20FB26F74186670@CO2PR04MB2184.namprd04.prod.outlook.com>
2017-01-10 22:40 ` [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing methodology Chaitanya Kulkarni
2017-01-10 22:40 ` Chaitanya Kulkarni
2017-01-10 22:40 ` Chaitanya Kulkarni
2017-01-11 7:42 ` Hannes Reinecke
2017-01-11 7:42 ` Hannes Reinecke
2017-01-11 7:42 ` Hannes Reinecke
2017-01-11 9:19 ` Johannes Thumshirn
2017-01-11 9:19 ` Johannes Thumshirn
2017-01-11 9:19 ` Johannes Thumshirn
2017-01-11 9:24 ` Christoph Hellwig
2017-01-11 9:24 ` Christoph Hellwig
2017-01-11 9:40 ` Hannes Reinecke
2017-01-11 9:40 ` Hannes Reinecke
2017-01-11 9:40 ` Hannes Reinecke
2017-03-10 19:37 ` Bart Van Assche [this message]
2017-03-10 19:37 ` Bart Van Assche
2017-03-10 19:37 ` Bart Van Assche
2017-01-12 11:01 ` [Lsf-pc] " Sagi Grimberg
2017-01-12 11:01 ` Sagi Grimberg
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=1489174661.2548.5.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=Chaitanya.Kulkarni@wdc.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.