diff for duplicates of <1493101803.3171.246.camel@oracle.com> diff --git a/a/1.txt b/N1/1.txt index f3f5155..4719f8a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,9 +1,9 @@ -On Mon, 2017-04-24 at 10:14 -0600, Logan Gunthorpe wrote: +On Mon, 2017-04-24@10:14 -0600, Logan Gunthorpe wrote: > > On 24/04/17 01:36 AM, Knut Omang wrote: > > My first reflex when reading this thread was to think that this whole domain -> > lends it self excellently to testing via Qemu. Could it be that doing this in -> > the opposite direction might be a safer approach in the long run even though +> > lends it self excellently to testing via Qemu. Could it be that doing this in? +> > the opposite direction might be a safer approach in the long run even though? > > (significant) more work up-front? > > That's an interesting idea. We did do some very limited testing on qemu @@ -11,7 +11,7 @@ On Mon, 2017-04-24 at 10:14 -0600, Logan Gunthorpe wrote: > no support for any RDMA devices which are a part of our primary use > case. -Yes, that's why I used 'significant'. One good thing is that given resources +Yes, that's why I used 'significant'. One good thing is that given resources? it can easily be done in parallel with other development, and will give additional insight of some form. @@ -19,7 +19,7 @@ insight of some form. > given the array of hardware that needs to be supported and the deep > functional knowledge required to figure out appropriate restrictions. -From my naive perspective it seems it need not even be a full model to get some benefits, +>From my naive perspective it seems it need not even be a full model to get some benefits, just low level functionality tests with some instances of a device that offers some MMIO space 'playground'. @@ -29,7 +29,3 @@ Knut > > Logan -_______________________________________________ -Linux-nvdimm mailing list -Linux-nvdimm@lists.01.org -https://lists.01.org/mailman/listinfo/linux-nvdimm diff --git a/a/content_digest b/N1/content_digest index 73f9dcc..2e7d7a9 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -17,37 +17,17 @@ "ref\01492381907.25766.49.camel@kernel.crashing.org\0" "ref\01493019397.3171.118.camel@oracle.com\0" "ref\09b6c0830-a728-c7ca-e6c6-2135f3f760ed@deltatee.com\0" - "ref\09b6c0830-a728-c7ca-e6c6-2135f3f760ed-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org\0" - "From\0Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0" - "Subject\0Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0" + "From\0knut.omang@oracle.com (Knut Omang)\0" + "Subject\0[RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0" "Date\0Tue, 25 Apr 2017 08:30:03 +0200\0" - "To\0Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>" - Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> - " Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>\0" - "Cc\0Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>" - Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> - James E.J. Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> - Martin K. Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> - linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org - Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> - Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> - Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvdimm <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org> - Max Gurtovoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> - " Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>\0" "\00:1\0" "b\0" - "On Mon, 2017-04-24 at 10:14 -0600, Logan Gunthorpe wrote:\n" + "On Mon, 2017-04-24@10:14 -0600, Logan Gunthorpe wrote:\n" "> \n" "> On 24/04/17 01:36 AM, Knut Omang wrote:\n" "> > My first reflex when reading this thread was to think that this whole domain\n" - "> > lends it self excellently to testing via Qemu. Could it be that doing this in\302\240\n" - "> > the opposite direction might be a safer approach in the long run even though\302\240\n" + "> > lends it self excellently to testing via Qemu. Could it be that doing this in?\n" + "> > the opposite direction might be a safer approach in the long run even though?\n" "> > (significant) more work up-front?\n" "> \n" "> That's an interesting idea. We did do some very limited testing on qemu\n" @@ -55,7 +35,7 @@ "> no support for any RDMA devices which are a part of our primary use\n" "> case. \n" "\n" - "Yes, that's why I used 'significant'. One good thing is that given resources\302\240\n" + "Yes, that's why I used 'significant'. One good thing is that given resources?\n" "it can easily be done in parallel with other development, and will give additional\n" "insight of some form.\n" "\n" @@ -63,7 +43,7 @@ "> given the array of hardware that needs to be supported and the deep\n" "> functional knowledge required to figure out appropriate restrictions.\n" "\n" - "From my naive perspective it seems it need not even be a full model to get some benefits,\n" + ">From my naive perspective it seems it need not even be a full model to get some benefits,\n" "just low level functionality tests with some instances of a\n" "device that offers some MMIO space 'playground'.\n" "\n" @@ -72,10 +52,6 @@ "Knut\n" "\n" "> \n" - "> Logan\n" - "_______________________________________________\n" - "Linux-nvdimm mailing list\n" - "Linux-nvdimm@lists.01.org\n" - https://lists.01.org/mailman/listinfo/linux-nvdimm + > Logan -af983ebe7469d5f288c52106945013982ea489ad6bfcd84ba2ae47d871527c23 +42693d81772d30f072cf530392efc41b33179f7d91c4b2c2f6f89d734ff56710
diff --git a/a/1.txt b/N2/1.txt index f3f5155..03e86bd 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,35 +1,38 @@ On Mon, 2017-04-24 at 10:14 -0600, Logan Gunthorpe wrote: -> +>=20 > On 24/04/17 01:36 AM, Knut Omang wrote: -> > My first reflex when reading this thread was to think that this whole domain -> > lends it self excellently to testing via Qemu. Could it be that doing this in -> > the opposite direction might be a safer approach in the long run even though +> > My first reflex when reading this thread was to think that this whole d= +omain +> > lends it self excellently to testing via Qemu. Could it be that doing t= +his in=C2=A0 +> > the opposite direction might be a safer approach in the long run even t= +hough=C2=A0 > > (significant) more work up-front? -> +>=20 > That's an interesting idea. We did do some very limited testing on qemu > with one iteration of our work. However, it's difficult because there is > no support for any RDMA devices which are a part of our primary use -> case. +> case.=20 -Yes, that's why I used 'significant'. One good thing is that given resources -it can easily be done in parallel with other development, and will give additional +Yes, that's why I used 'significant'. One good thing is that given resource= +s=C2=A0 +it can easily be done in parallel with other development, and will give add= +itional insight of some form. > I also imagine it would be quite difficult to develop those models > given the array of hardware that needs to be supported and the deep > functional knowledge required to figure out appropriate restrictions. -From my naive perspective it seems it need not even be a full model to get some benefits, +>From my naive perspective it seems it need not even be a full model to get = +some benefits, just low level functionality tests with some instances of a device that offers some MMIO space 'playground'. -Or maybe you can leverage some of the already implemented emulated devices in Qemu? +Or maybe you can leverage some of the already implemented emulated devices = +in Qemu? Knut -> +>=20 > Logan -_______________________________________________ -Linux-nvdimm mailing list -Linux-nvdimm@lists.01.org -https://lists.01.org/mailman/listinfo/linux-nvdimm diff --git a/a/content_digest b/N2/content_digest index 73f9dcc..6029609 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -17,65 +17,69 @@ "ref\01492381907.25766.49.camel@kernel.crashing.org\0" "ref\01493019397.3171.118.camel@oracle.com\0" "ref\09b6c0830-a728-c7ca-e6c6-2135f3f760ed@deltatee.com\0" - "ref\09b6c0830-a728-c7ca-e6c6-2135f3f760ed-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org\0" - "From\0Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0" + "From\0Knut Omang <knut.omang@oracle.com>\0" "Subject\0Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0" "Date\0Tue, 25 Apr 2017 08:30:03 +0200\0" - "To\0Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>" - Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> - " Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>\0" - "Cc\0Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>" - Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> - James E.J. Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> - Martin K. Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> - linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org - Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> - Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> - Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvdimm <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org> - Max Gurtovoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> - " Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>\0" + "To\0Logan Gunthorpe <logang@deltatee.com>" + Benjamin Herrenschmidt <benh@kernel.crashing.org> + " Dan Williams <dan.j.williams@intel.com>\0" + "Cc\0Bjorn Helgaas <helgaas@kernel.org>" + Jason Gunthorpe <jgunthorpe@obsidianresearch.com> + Christoph Hellwig <hch@lst.de> + Sagi Grimberg <sagi@grimberg.me> + James E.J. Bottomley <jejb@linux.vnet.ibm.com> + Martin K. Petersen <martin.petersen@oracle.com> + Jens Axboe <axboe@kernel.dk> + Steve Wise <swise@opengridcomputing.com> + Stephen Bates <sbates@raithlin.com> + Max Gurtovoy <maxg@mellanox.com> + Keith Busch <keith.busch@intel.com> + linux-pci@vger.kernel.org + linux-scsi <linux-scsi@vger.kernel.org> + linux-nvme@lists.infradead.org + linux-rdma@vger.kernel.org + linux-nvdimm <linux-nvdimm@ml01.01.org> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + " Jerome Glisse <jglisse@redhat.com>\0" "\00:1\0" "b\0" "On Mon, 2017-04-24 at 10:14 -0600, Logan Gunthorpe wrote:\n" - "> \n" + ">=20\n" "> On 24/04/17 01:36 AM, Knut Omang wrote:\n" - "> > My first reflex when reading this thread was to think that this whole domain\n" - "> > lends it self excellently to testing via Qemu. Could it be that doing this in\302\240\n" - "> > the opposite direction might be a safer approach in the long run even though\302\240\n" + "> > My first reflex when reading this thread was to think that this whole d=\n" + "omain\n" + "> > lends it self excellently to testing via Qemu. Could it be that doing t=\n" + "his in=C2=A0\n" + "> > the opposite direction might be a safer approach in the long run even t=\n" + "hough=C2=A0\n" "> > (significant) more work up-front?\n" - "> \n" + ">=20\n" "> That's an interesting idea. We did do some very limited testing on qemu\n" "> with one iteration of our work. However, it's difficult because there is\n" "> no support for any RDMA devices which are a part of our primary use\n" - "> case. \n" + "> case.=20\n" "\n" - "Yes, that's why I used 'significant'. One good thing is that given resources\302\240\n" - "it can easily be done in parallel with other development, and will give additional\n" + "Yes, that's why I used 'significant'. One good thing is that given resource=\n" + "s=C2=A0\n" + "it can easily be done in parallel with other development, and will give add=\n" + "itional\n" "insight of some form.\n" "\n" "> I also imagine it would be quite difficult to develop those models\n" "> given the array of hardware that needs to be supported and the deep\n" "> functional knowledge required to figure out appropriate restrictions.\n" "\n" - "From my naive perspective it seems it need not even be a full model to get some benefits,\n" + ">From my naive perspective it seems it need not even be a full model to get =\n" + "some benefits,\n" "just low level functionality tests with some instances of a\n" "device that offers some MMIO space 'playground'.\n" "\n" - "Or maybe you can leverage some of the already implemented emulated devices in Qemu?\n" + "Or maybe you can leverage some of the already implemented emulated devices =\n" + "in Qemu?\n" "\n" "Knut\n" "\n" - "> \n" - "> Logan\n" - "_______________________________________________\n" - "Linux-nvdimm mailing list\n" - "Linux-nvdimm@lists.01.org\n" - https://lists.01.org/mailman/listinfo/linux-nvdimm + ">=20\n" + > Logan -af983ebe7469d5f288c52106945013982ea489ad6bfcd84ba2ae47d871527c23 +a41e0b8b6728e9e426fd8150da835d258773d593b2287103131bc2eba6ffc28d
diff --git a/a/1.txt b/N3/1.txt index f3f5155..f38e17c 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -19,7 +19,7 @@ insight of some form. > given the array of hardware that needs to be supported and the deep > functional knowledge required to figure out appropriate restrictions. -From my naive perspective it seems it need not even be a full model to get some benefits, +>From my naive perspective it seems it need not even be a full model to get some benefits, just low level functionality tests with some instances of a device that offers some MMIO space 'playground'. @@ -29,7 +29,3 @@ Knut > > Logan -_______________________________________________ -Linux-nvdimm mailing list -Linux-nvdimm@lists.01.org -https://lists.01.org/mailman/listinfo/linux-nvdimm diff --git a/a/content_digest b/N3/content_digest index 73f9dcc..7f5dc86 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -17,29 +17,30 @@ "ref\01492381907.25766.49.camel@kernel.crashing.org\0" "ref\01493019397.3171.118.camel@oracle.com\0" "ref\09b6c0830-a728-c7ca-e6c6-2135f3f760ed@deltatee.com\0" - "ref\09b6c0830-a728-c7ca-e6c6-2135f3f760ed-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org\0" - "From\0Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0" + "From\0Knut Omang <knut.omang@oracle.com>\0" "Subject\0Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0" "Date\0Tue, 25 Apr 2017 08:30:03 +0200\0" - "To\0Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>" - Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> - " Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>\0" - "Cc\0Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>" - Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> - James E.J. Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> - Martin K. Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> - linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org - Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> - Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> - Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvdimm <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org> - Max Gurtovoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> - " Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>\0" + "To\0Logan Gunthorpe <logang@deltatee.com>" + Benjamin Herrenschmidt <benh@kernel.crashing.org> + " Dan Williams <dan.j.williams@intel.com>\0" + "Cc\0Bjorn Helgaas <helgaas@kernel.org>" + Jason Gunthorpe <jgunthorpe@obsidianresearch.com> + Christoph Hellwig <hch@lst.de> + Sagi Grimberg <sagi@grimberg.me> + James E.J. Bottomley <jejb@linux.vnet.ibm.com> + Martin K. Petersen <martin.petersen@oracle.com> + Jens Axboe <axboe@kernel.dk> + Steve Wise <swise@opengridcomputing.com> + Stephen Bates <sbates@raithlin.com> + Max Gurtovoy <maxg@mellanox.com> + Keith Busch <keith.busch@intel.com> + linux-pci@vger.kernel.org + linux-scsi <linux-scsi@vger.kernel.org> + linux-nvme@lists.infradead.org + linux-rdma@vger.kernel.org + linux-nvdimm <linux-nvdimm@ml01.01.org> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + " Jerome Glisse <jglisse@redhat.com>\0" "\00:1\0" "b\0" "On Mon, 2017-04-24 at 10:14 -0600, Logan Gunthorpe wrote:\n" @@ -63,7 +64,7 @@ "> given the array of hardware that needs to be supported and the deep\n" "> functional knowledge required to figure out appropriate restrictions.\n" "\n" - "From my naive perspective it seems it need not even be a full model to get some benefits,\n" + ">From my naive perspective it seems it need not even be a full model to get some benefits,\n" "just low level functionality tests with some instances of a\n" "device that offers some MMIO space 'playground'.\n" "\n" @@ -72,10 +73,6 @@ "Knut\n" "\n" "> \n" - "> Logan\n" - "_______________________________________________\n" - "Linux-nvdimm mailing list\n" - "Linux-nvdimm@lists.01.org\n" - https://lists.01.org/mailman/listinfo/linux-nvdimm + > Logan -af983ebe7469d5f288c52106945013982ea489ad6bfcd84ba2ae47d871527c23 +30db4e032a8c681f6befbc8689e87dd1b1d38a969014fdf22fb1720cbd021dd3
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.