diff for duplicates of <1493101803.3171.246.camel@oracle.com>
diff --git a/a/1.txt b/N1/1.txt
index d80426a..c85474b 100644
--- a/a/1.txt
+++ b/N1/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'.
@@ -28,8 +28,4 @@ Or maybe you can leverage some of the already implemented emulated devices in Qe
Knut
>
-> Logan
-_______________________________________________
-Linux-nvdimm mailing list
-Linux-nvdimm@lists.01.org
-https://lists.01.org/mailman/listinfo/linux-nvdimm
\ No newline at end of file
+> Logan
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index 629392b..077a2bd 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -56,10 +56,7 @@
"ref\0009b6c0830-a728-c7ca-e6c6-2135f3f760ed\@deltatee.com\0"
]
[
- "ref\0009b6c0830-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"
@@ -68,27 +65,29 @@
"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"
+ "To\0Logan Gunthorpe <logang\@deltatee.com>",
+ " Benjamin Herrenschmidt <benh\@kernel.crashing.org>",
+ " Dan Williams <dan.j.williams\@intel.com>\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"
+ "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"
]
[
"\0000:1\0"
@@ -118,7 +117,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",
@@ -127,11 +126,7 @@
"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
diff --git a/a/1.txt b/N2/1.txt
index d80426a..225f9d4 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
->
-> Logan
-_______________________________________________
-Linux-nvdimm mailing list
-Linux-nvdimm@lists.01.org
-https://lists.01.org/mailman/listinfo/linux-nvdimm
\ No newline at end of file
+>=20
+> Logan
\ No newline at end of file
diff --git a/a/content_digest b/N2/content_digest
index 629392b..d4f6bb0 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -56,10 +56,7 @@
"ref\0009b6c0830-a728-c7ca-e6c6-2135f3f760ed\@deltatee.com\0"
]
[
- "ref\0009b6c0830-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"
@@ -68,27 +65,29 @@
"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"
+ "To\0Logan Gunthorpe <logang\@deltatee.com>",
+ " Benjamin Herrenschmidt <benh\@kernel.crashing.org>",
+ " Dan Williams <dan.j.williams\@intel.com>\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"
+ "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"
]
[
"\0000:1\0"
@@ -98,40 +97,43 @@
]
[
"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 d80426a..5c226ab 100644
--- a/a/1.txt
+++ b/N3/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'.
@@ -28,8 +28,4 @@ Or maybe you can leverage some of the already implemented emulated devices in Qe
Knut
>
-> Logan
-_______________________________________________
-Linux-nvdimm mailing list
-Linux-nvdimm@lists.01.org
-https://lists.01.org/mailman/listinfo/linux-nvdimm
\ No newline at end of file
+> Logan
\ No newline at end of file
diff --git a/a/content_digest b/N3/content_digest
index 629392b..26b2707 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -56,40 +56,14 @@
"ref\0009b6c0830-a728-c7ca-e6c6-2135f3f760ed\@deltatee.com\0"
]
[
- "ref\0009b6c0830-a728-c7ca-e6c6-2135f3f760ed-OTvnGxWRz7hWk0Htik3J/w\@public.gmane.org\0"
+ "From\0knut.omang\@oracle.com (Knut Omang)\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"
+ "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"
-]
[
"\0000:1\0"
]
@@ -97,12 +71,12 @@
"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",
@@ -110,7 +84,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",
@@ -118,7 +92,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",
@@ -127,11 +101,7 @@
"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
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.