| Message ID | 20221123055827.26996-1-nj.shetty@samsung.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Implement copy offload support | expand |
(+ Shinichiro) On 11/22/22 21:58, Nitesh Shetty wrote: > The patch series covers the points discussed in November 2021 virtual > call [LSF/MM/BFP TOPIC] Storage: Copy Offload [0]. > We have covered the initial agreed requirements in this patchset and > further additional features suggested by community. > Patchset borrows Mikulas's token based approach for 2 bdev > implementation. > > This is on top of our previous patchset v4[1]. Now that series is converging, since patch-series touches drivers and key components in the block layer you need accompany the patch-series with the blktests to cover the corner cases in the drivers which supports this operations, as I mentioned this in the call last year.... If you need any help with that feel free to send an email to linux-block and CC me or Shinichiro (added in CC )... -ck
On Wed, Nov 23, 2022 at 10:56:23PM +0000, Chaitanya Kulkarni wrote: > (+ Shinichiro) > > On 11/22/22 21:58, Nitesh Shetty wrote: > > The patch series covers the points discussed in November 2021 virtual > > call [LSF/MM/BFP TOPIC] Storage: Copy Offload [0]. > > We have covered the initial agreed requirements in this patchset and > > further additional features suggested by community. > > Patchset borrows Mikulas's token based approach for 2 bdev > > implementation. > > > > This is on top of our previous patchset v4[1]. > > Now that series is converging, since patch-series touches > drivers and key components in the block layer you need accompany > the patch-series with the blktests to cover the corner cases in the > drivers which supports this operations, as I mentioned this in the > call last year.... > > If you need any help with that feel free to send an email to linux-block > and CC me or Shinichiro (added in CC )... > > -ck > Yes any help would be appreciated. I am not familiar with blktest development/testing cycle. Do we need add blktests along with patch series or do we need to add after patch series gets merged(to be merged)? Thanks Nitesh
On 11/29/22 04:16, Nitesh Shetty wrote: > On Wed, Nov 23, 2022 at 10:56:23PM +0000, Chaitanya Kulkarni wrote: >> (+ Shinichiro) >> >> On 11/22/22 21:58, Nitesh Shetty wrote: >>> The patch series covers the points discussed in November 2021 virtual >>> call [LSF/MM/BFP TOPIC] Storage: Copy Offload [0]. >>> We have covered the initial agreed requirements in this patchset and >>> further additional features suggested by community. >>> Patchset borrows Mikulas's token based approach for 2 bdev >>> implementation. >>> >>> This is on top of our previous patchset v4[1]. >> >> Now that series is converging, since patch-series touches >> drivers and key components in the block layer you need accompany >> the patch-series with the blktests to cover the corner cases in the >> drivers which supports this operations, as I mentioned this in the >> call last year.... >> >> If you need any help with that feel free to send an email to linux-block >> and CC me or Shinichiro (added in CC )... >> >> -ck >> > > Yes any help would be appreciated. I am not familiar with blktest > development/testing cycle. Do we need add blktests along with patch > series or do we need to add after patch series gets merged(to be merged)? > > Thanks > Nitesh > > we have many testcases you can refer to as an example. Your cover-letter mentions that you have tested this code, just move all the testcases to the blktests. More importantly for a feature like this you should be providing outstanding testcases in your github tree when you post the series, it should cover critical parts of the block layer and drivers in question. The objective here is to have blktests updated when the code is upstream so all the distros can test the code from upstream blktest repo. You can refer to what we have done it for NVMeOF in-band authentication (Thanks to Hannes and Sagi in linux-nvme email-archives. -ck
On Wed, Nov 30, 2022 at 12:05:00AM +0000, Chaitanya Kulkarni wrote: > On 11/29/22 04:16, Nitesh Shetty wrote: > > On Wed, Nov 23, 2022 at 10:56:23PM +0000, Chaitanya Kulkarni wrote: > >> (+ Shinichiro) > >> > >> On 11/22/22 21:58, Nitesh Shetty wrote: > >>> The patch series covers the points discussed in November 2021 virtual > >>> call [LSF/MM/BFP TOPIC] Storage: Copy Offload [0]. > >>> We have covered the initial agreed requirements in this patchset and > >>> further additional features suggested by community. > >>> Patchset borrows Mikulas's token based approach for 2 bdev > >>> implementation. > >>> > >>> This is on top of our previous patchset v4[1]. > >> > >> Now that series is converging, since patch-series touches > >> drivers and key components in the block layer you need accompany > >> the patch-series with the blktests to cover the corner cases in the > >> drivers which supports this operations, as I mentioned this in the > >> call last year.... > >> > >> If you need any help with that feel free to send an email to linux-block > >> and CC me or Shinichiro (added in CC )... > >> > >> -ck > >> > > > > Yes any help would be appreciated. I am not familiar with blktest > > development/testing cycle. Do we need add blktests along with patch > > series or do we need to add after patch series gets merged(to be merged)? > > > > Thanks > > Nitesh > > > > > > we have many testcases you can refer to as an example. > Your cover-letter mentions that you have tested this code, just move > all the testcases to the blktests. > > More importantly for a feature like this you should be providing > outstanding testcases in your github tree when you post the > series, it should cover critical parts of the block layer and > drivers in question. > > The objective here is to have blktests updated when the code > is upstream so all the distros can test the code from > upstream blktest repo. You can refer to what we have done it > for NVMeOF in-band authentication (Thanks to Hannes and Sagi > in linux-nvme email-archives. > > -ck > Sure, next version will update blktest. Thank you, Nitesh