All of lore.kernel.org
 help / color / mirror / Atom feed
From: Logan Gunthorpe <logang@deltatee.com>
To: Sinan Kaya <okaya@codeaurora.org>, 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>,
	Dan Williams <dan.j.williams@intel.com>,
	Keith Busch <keith.busch@intel.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
	linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org
Subject: Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device
Date: Fri, 31 Mar 2017 16:42:01 -0600	[thread overview]
Message-ID: <0280fbb4-ba9e-ac64-6bb3-b72590a54e57@deltatee.com> (raw)
In-Reply-To: <e6a74aeb-9f54-51c5-8ad9-3b6fb92c03b3@codeaurora.org>



On 31/03/17 03:38 PM, Sinan Kaya wrote:
> On 3/31/2017 5:23 PM, Logan Gunthorpe wrote:
>> What exactly would you white/black list? It can't be the NIC or the
>> disk. If it's going to be a white/black list on the switch or root port
>> then you'd need essentially the same code to ensure they are all behind
>> the same switch or root port.
> 
> What is so special about being connected to the same switch?
> 
> Why don't we allow the feature by default and blacklist by the root ports
> that don't work with a quirk.

Well root ports have the same issue here. There may be more than one
root port or other buses (ie QPI) between the devices in question. So
you can't just say "this system has root port X therefore we can always
use p2pmem". In the end, if you want to do any kind of restrictions
you're going to have to walk the tree, as the code currently does, and
figure out what's between the devices being used and black or white list
accordingly. Then seeing there's just such a vast number of devices out
there you'd almost certainly have to use some kind of white list and not
a black list. Then the question becomes which devices will be white
listed? The first to be listed would be switches seeing they will always
work. This is pretty much what we have (though it doesn't currently
cover multiple levels of switches). The next step, if someone wanted to
test with specific hardware, might be to allow the case where all the
devices are behind the same root port which Intel Ivy Bridge or newer.
However, I don't think a comprehensive white list should be a
requirement for this work to go forward and I don't think anything
you've suggested will remove any of the "ugliness".

What we discussed at LSF was that only allowing cases with a switch was
the simplest way to be sure any given setup would actually work.

> I'm looking at this from portability perspective to be honest.

I'm looking at this from the fact that there's a vast number of
topologies and devices involved, and figuring out which will work is
very complicated and could require a lot of hardware testing. The LSF
folks were primarily concerned with not having users enable the feature
and see breakage or terrible performance.

> I'd rather see the feature enabled by default without any assumptions.
> Using it with a switch is just a use case that you happened to test.
> It can allow new architectures to use your code tomorrow.

That's why I was advocating for letting userspace decide such that if
you're setting up a system with this you say to use a specific p2pmem
device and then you are responsible to test and benchmark it and decide
to use it in going forward. However, this has received a lot of push back.

Logan
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
To: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>,
	"James E.J. Bottomley"
	<jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
	"Martin K. Petersen"
	<martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>,
	Steve Wise
	<swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>,
	Stephen Bates <sbates-pv7U853sEMVWk0Htik3J/w@public.gmane.org>,
	Max Gurtovoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
	Dan Williams
	<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device
Date: Fri, 31 Mar 2017 16:42:01 -0600	[thread overview]
Message-ID: <0280fbb4-ba9e-ac64-6bb3-b72590a54e57@deltatee.com> (raw)
In-Reply-To: <e6a74aeb-9f54-51c5-8ad9-3b6fb92c03b3-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>



On 31/03/17 03:38 PM, Sinan Kaya wrote:
> On 3/31/2017 5:23 PM, Logan Gunthorpe wrote:
>> What exactly would you white/black list? It can't be the NIC or the
>> disk. If it's going to be a white/black list on the switch or root port
>> then you'd need essentially the same code to ensure they are all behind
>> the same switch or root port.
> 
> What is so special about being connected to the same switch?
> 
> Why don't we allow the feature by default and blacklist by the root ports
> that don't work with a quirk.

Well root ports have the same issue here. There may be more than one
root port or other buses (ie QPI) between the devices in question. So
you can't just say "this system has root port X therefore we can always
use p2pmem". In the end, if you want to do any kind of restrictions
you're going to have to walk the tree, as the code currently does, and
figure out what's between the devices being used and black or white list
accordingly. Then seeing there's just such a vast number of devices out
there you'd almost certainly have to use some kind of white list and not
a black list. Then the question becomes which devices will be white
listed? The first to be listed would be switches seeing they will always
work. This is pretty much what we have (though it doesn't currently
cover multiple levels of switches). The next step, if someone wanted to
test with specific hardware, might be to allow the case where all the
devices are behind the same root port which Intel Ivy Bridge or newer.
However, I don't think a comprehensive white list should be a
requirement for this work to go forward and I don't think anything
you've suggested will remove any of the "ugliness".

What we discussed at LSF was that only allowing cases with a switch was
the simplest way to be sure any given setup would actually work.

> I'm looking at this from portability perspective to be honest.

I'm looking at this from the fact that there's a vast number of
topologies and devices involved, and figuring out which will work is
very complicated and could require a lot of hardware testing. The LSF
folks were primarily concerned with not having users enable the feature
and see breakage or terrible performance.

> I'd rather see the feature enabled by default without any assumptions.
> Using it with a switch is just a use case that you happened to test.
> It can allow new architectures to use your code tomorrow.

That's why I was advocating for letting userspace decide such that if
you're setting up a system with this you say to use a specific p2pmem
device and then you are responsible to test and benchmark it and decide
to use it in going forward. However, this has received a lot of push back.

Logan

WARNING: multiple messages have this Message-ID (diff)
From: Logan Gunthorpe <logang@deltatee.com>
To: Sinan Kaya <okaya@codeaurora.org>, 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>,
	Dan Williams <dan.j.williams@intel.com>,
	Keith Busch <keith.busch@intel.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org,
	linux-nvdimm@ml01.01.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device
Date: Fri, 31 Mar 2017 16:42:01 -0600	[thread overview]
Message-ID: <0280fbb4-ba9e-ac64-6bb3-b72590a54e57@deltatee.com> (raw)
In-Reply-To: <e6a74aeb-9f54-51c5-8ad9-3b6fb92c03b3@codeaurora.org>



On 31/03/17 03:38 PM, Sinan Kaya wrote:
> On 3/31/2017 5:23 PM, Logan Gunthorpe wrote:
>> What exactly would you white/black list? It can't be the NIC or the
>> disk. If it's going to be a white/black list on the switch or root port
>> then you'd need essentially the same code to ensure they are all behind
>> the same switch or root port.
> 
> What is so special about being connected to the same switch?
> 
> Why don't we allow the feature by default and blacklist by the root ports
> that don't work with a quirk.

Well root ports have the same issue here. There may be more than one
root port or other buses (ie QPI) between the devices in question. So
you can't just say "this system has root port X therefore we can always
use p2pmem". In the end, if you want to do any kind of restrictions
you're going to have to walk the tree, as the code currently does, and
figure out what's between the devices being used and black or white list
accordingly. Then seeing there's just such a vast number of devices out
there you'd almost certainly have to use some kind of white list and not
a black list. Then the question becomes which devices will be white
listed? The first to be listed would be switches seeing they will always
work. This is pretty much what we have (though it doesn't currently
cover multiple levels of switches). The next step, if someone wanted to
test with specific hardware, might be to allow the case where all the
devices are behind the same root port which Intel Ivy Bridge or newer.
However, I don't think a comprehensive white list should be a
requirement for this work to go forward and I don't think anything
you've suggested will remove any of the "ugliness".

What we discussed at LSF was that only allowing cases with a switch was
the simplest way to be sure any given setup would actually work.

> I'm looking at this from portability perspective to be honest.

I'm looking at this from the fact that there's a vast number of
topologies and devices involved, and figuring out which will work is
very complicated and could require a lot of hardware testing. The LSF
folks were primarily concerned with not having users enable the feature
and see breakage or terrible performance.

> I'd rather see the feature enabled by default without any assumptions.
> Using it with a switch is just a use case that you happened to test.
> It can allow new architectures to use your code tomorrow.

That's why I was advocating for letting userspace decide such that if
you're setting up a system with this you say to use a specific p2pmem
device and then you are responsible to test and benchmark it and decide
to use it in going forward. However, this has received a lot of push back.

Logan

WARNING: multiple messages have this Message-ID (diff)
From: Logan Gunthorpe <logang@deltatee.com>
To: Sinan Kaya <okaya@codeaurora.org>, 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>,
	Dan Williams <dan.j.williams@intel.com>,
	Keith Busch <keith.busch@intel.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org,
	linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device
Date: Fri, 31 Mar 2017 16:42:01 -0600	[thread overview]
Message-ID: <0280fbb4-ba9e-ac64-6bb3-b72590a54e57@deltatee.com> (raw)
In-Reply-To: <e6a74aeb-9f54-51c5-8ad9-3b6fb92c03b3@codeaurora.org>



On 31/03/17 03:38 PM, Sinan Kaya wrote:
> On 3/31/2017 5:23 PM, Logan Gunthorpe wrote:
>> What exactly would you white/black list? It can't be the NIC or the
>> disk. If it's going to be a white/black list on the switch or root port
>> then you'd need essentially the same code to ensure they are all behind
>> the same switch or root port.
> 
> What is so special about being connected to the same switch?
> 
> Why don't we allow the feature by default and blacklist by the root ports
> that don't work with a quirk.

Well root ports have the same issue here. There may be more than one
root port or other buses (ie QPI) between the devices in question. So
you can't just say "this system has root port X therefore we can always
use p2pmem". In the end, if you want to do any kind of restrictions
you're going to have to walk the tree, as the code currently does, and
figure out what's between the devices being used and black or white list
accordingly. Then seeing there's just such a vast number of devices out
there you'd almost certainly have to use some kind of white list and not
a black list. Then the question becomes which devices will be white
listed? The first to be listed would be switches seeing they will always
work. This is pretty much what we have (though it doesn't currently
cover multiple levels of switches). The next step, if someone wanted to
test with specific hardware, might be to allow the case where all the
devices are behind the same root port which Intel Ivy Bridge or newer.
However, I don't think a comprehensive white list should be a
requirement for this work to go forward and I don't think anything
you've suggested will remove any of the "ugliness".

What we discussed at LSF was that only allowing cases with a switch was
the simplest way to be sure any given setup would actually work.

> I'm looking at this from portability perspective to be honest.

I'm looking at this from the fact that there's a vast number of
topologies and devices involved, and figuring out which will work is
very complicated and could require a lot of hardware testing. The LSF
folks were primarily concerned with not having users enable the feature
and see breakage or terrible performance.

> I'd rather see the feature enabled by default without any assumptions.
> Using it with a switch is just a use case that you happened to test.
> It can allow new architectures to use your code tomorrow.

That's why I was advocating for letting userspace decide such that if
you're setting up a system with this you say to use a specific p2pmem
device and then you are responsible to test and benchmark it and decide
to use it in going forward. However, this has received a lot of push back.

Logan

WARNING: multiple messages have this Message-ID (diff)
From: logang@deltatee.com (Logan Gunthorpe)
Subject: [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device
Date: Fri, 31 Mar 2017 16:42:01 -0600	[thread overview]
Message-ID: <0280fbb4-ba9e-ac64-6bb3-b72590a54e57@deltatee.com> (raw)
In-Reply-To: <e6a74aeb-9f54-51c5-8ad9-3b6fb92c03b3@codeaurora.org>



On 31/03/17 03:38 PM, Sinan Kaya wrote:
> On 3/31/2017 5:23 PM, Logan Gunthorpe wrote:
>> What exactly would you white/black list? It can't be the NIC or the
>> disk. If it's going to be a white/black list on the switch or root port
>> then you'd need essentially the same code to ensure they are all behind
>> the same switch or root port.
> 
> What is so special about being connected to the same switch?
> 
> Why don't we allow the feature by default and blacklist by the root ports
> that don't work with a quirk.

Well root ports have the same issue here. There may be more than one
root port or other buses (ie QPI) between the devices in question. So
you can't just say "this system has root port X therefore we can always
use p2pmem". In the end, if you want to do any kind of restrictions
you're going to have to walk the tree, as the code currently does, and
figure out what's between the devices being used and black or white list
accordingly. Then seeing there's just such a vast number of devices out
there you'd almost certainly have to use some kind of white list and not
a black list. Then the question becomes which devices will be white
listed? The first to be listed would be switches seeing they will always
work. This is pretty much what we have (though it doesn't currently
cover multiple levels of switches). The next step, if someone wanted to
test with specific hardware, might be to allow the case where all the
devices are behind the same root port which Intel Ivy Bridge or newer.
However, I don't think a comprehensive white list should be a
requirement for this work to go forward and I don't think anything
you've suggested will remove any of the "ugliness".

What we discussed at LSF was that only allowing cases with a switch was
the simplest way to be sure any given setup would actually work.

> I'm looking at this from portability perspective to be honest.

I'm looking at this from the fact that there's a vast number of
topologies and devices involved, and figuring out which will work is
very complicated and could require a lot of hardware testing. The LSF
folks were primarily concerned with not having users enable the feature
and see breakage or terrible performance.

> I'd rather see the feature enabled by default without any assumptions.
> Using it with a switch is just a use case that you happened to test.
> It can allow new architectures to use your code tomorrow.

That's why I was advocating for letting userspace decide such that if
you're setting up a system with this you say to use a specific p2pmem
device and then you are responsible to test and benchmark it and decide
to use it in going forward. However, this has received a lot of push back.

Logan

  reply	other threads:[~2017-03-31 22:42 UTC|newest]

Thread overview: 325+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 22:12 [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory Logan Gunthorpe
2017-03-30 22:12 ` Logan Gunthorpe
2017-03-30 22:12 ` Logan Gunthorpe
2017-03-30 22:12 ` Logan Gunthorpe
2017-03-30 22:12 ` Logan Gunthorpe
2017-03-30 22:12 ` [RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-31 18:49   ` Sinan Kaya
2017-03-31 18:49     ` Sinan Kaya
2017-03-31 18:49     ` Sinan Kaya
2017-03-31 18:49     ` Sinan Kaya
2017-03-31 18:49     ` Sinan Kaya
2017-03-31 21:23     ` Logan Gunthorpe
2017-03-31 21:23       ` Logan Gunthorpe
2017-03-31 21:23       ` Logan Gunthorpe
2017-03-31 21:23       ` Logan Gunthorpe
2017-03-31 21:23       ` Logan Gunthorpe
2017-03-31 21:38       ` Sinan Kaya
2017-03-31 21:38         ` Sinan Kaya
2017-03-31 21:38         ` Sinan Kaya
2017-03-31 21:38         ` Sinan Kaya
2017-03-31 21:38         ` Sinan Kaya
2017-03-31 22:42         ` Logan Gunthorpe [this message]
2017-03-31 22:42           ` Logan Gunthorpe
2017-03-31 22:42           ` Logan Gunthorpe
2017-03-31 22:42           ` Logan Gunthorpe
2017-03-31 22:42           ` Logan Gunthorpe
2017-03-31 23:51           ` Sinan Kaya
2017-03-31 23:51             ` Sinan Kaya
2017-03-31 23:51             ` Sinan Kaya
2017-03-31 23:51             ` Sinan Kaya
2017-03-31 23:51             ` Sinan Kaya
2017-04-01  1:57             ` Logan Gunthorpe
2017-04-01  1:57               ` Logan Gunthorpe
2017-04-01  1:57               ` Logan Gunthorpe
2017-04-01  1:57               ` Logan Gunthorpe
2017-04-01  1:57               ` Logan Gunthorpe
2017-04-01  2:17               ` okaya
2017-04-01  2:17                 ` okaya
2017-04-01  2:17                 ` okaya
2017-04-01  2:17                 ` okaya
2017-04-01  2:17                 ` okaya-sgV2jX0FEOL9JmXXK+q4OQ
2017-04-01 22:16                 ` Logan Gunthorpe
2017-04-01 22:16                   ` Logan Gunthorpe
2017-04-01 22:16                   ` Logan Gunthorpe
2017-04-01 22:16                   ` Logan Gunthorpe
2017-04-02  2:26                   ` Sinan Kaya
2017-04-02  2:26                     ` Sinan Kaya
2017-04-02  2:26                     ` Sinan Kaya
2017-04-02  2:26                     ` Sinan Kaya
2017-04-02 17:21                     ` Logan Gunthorpe
2017-04-02 17:21                       ` Logan Gunthorpe
2017-04-02 17:21                       ` Logan Gunthorpe
2017-04-02 17:21                       ` Logan Gunthorpe
2017-04-02 17:21                       ` Logan Gunthorpe
2017-04-02 21:03                       ` Sinan Kaya
2017-04-02 21:03                         ` Sinan Kaya
2017-04-02 21:03                         ` Sinan Kaya
2017-04-02 21:03                         ` Sinan Kaya
2017-04-03  4:26                         ` Logan Gunthorpe
2017-04-03  4:26                           ` Logan Gunthorpe
2017-04-03  4:26                           ` Logan Gunthorpe
2017-04-03  4:26                           ` Logan Gunthorpe
2017-04-25 11:58                           ` Marta Rybczynska
2017-04-25 11:58                             ` Marta Rybczynska
2017-04-25 11:58                             ` Marta Rybczynska
2017-04-25 11:58                             ` Marta Rybczynska
2017-04-25 11:58                             ` Marta Rybczynska
2017-04-25 16:58                             ` Logan Gunthorpe
2017-04-25 16:58                               ` Logan Gunthorpe
2017-04-25 16:58                               ` Logan Gunthorpe
2017-04-25 16:58                               ` Logan Gunthorpe
2017-04-25 16:58                               ` Logan Gunthorpe
2017-03-30 22:12 ` [RFC 2/8] cxgb4: setup pcie memory window 4 and create p2pmem region Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-04-04 10:42   ` Sagi Grimberg
2017-04-04 10:42     ` Sagi Grimberg
2017-04-04 10:42     ` Sagi Grimberg
2017-04-04 10:42     ` Sagi Grimberg
2017-04-04 10:42     ` Sagi Grimberg
2017-04-04 15:56     ` Logan Gunthorpe
2017-04-04 15:56       ` Logan Gunthorpe
2017-04-04 15:56       ` Logan Gunthorpe
2017-04-04 15:56       ` Logan Gunthorpe
2017-04-04 15:56       ` Logan Gunthorpe
2017-04-05 15:41     ` Steve Wise
2017-04-05 15:41       ` Steve Wise
2017-04-05 15:41       ` Steve Wise
2017-04-05 15:41       ` Steve Wise
2017-04-05 15:41       ` Steve Wise
2017-03-30 22:12 ` [RFC 3/8] nvmet: Use p2pmem in nvme target Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-04-04 10:40   ` Sagi Grimberg
2017-04-04 10:40     ` Sagi Grimberg
2017-04-04 10:40     ` Sagi Grimberg
2017-04-04 10:40     ` Sagi Grimberg
2017-04-04 16:16     ` Logan Gunthorpe
2017-04-04 16:16       ` Logan Gunthorpe
2017-04-04 16:16       ` Logan Gunthorpe
2017-04-04 16:16       ` Logan Gunthorpe
2017-04-04 16:16       ` Logan Gunthorpe
2017-04-06  5:47       ` Sagi Grimberg
2017-04-06  5:47         ` Sagi Grimberg
2017-04-06  5:47         ` Sagi Grimberg
2017-04-06  5:47         ` Sagi Grimberg
2017-04-06  5:47         ` Sagi Grimberg
2017-04-06 15:52         ` Logan Gunthorpe
2017-04-06 15:52           ` Logan Gunthorpe
2017-04-06 15:52           ` Logan Gunthorpe
2017-04-06 15:52           ` Logan Gunthorpe
2017-04-06 15:52           ` Logan Gunthorpe
2017-03-30 22:12 ` [RFC 4/8] p2pmem: Add debugfs "stats" file Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-04-04 10:46   ` Sagi Grimberg
2017-04-04 10:46     ` Sagi Grimberg
2017-04-04 10:46     ` Sagi Grimberg
2017-04-04 10:46     ` Sagi Grimberg
2017-04-04 10:46     ` Sagi Grimberg
2017-04-04 17:25     ` Logan Gunthorpe
2017-04-04 17:25       ` Logan Gunthorpe
2017-04-04 17:25       ` Logan Gunthorpe
2017-04-04 17:25       ` Logan Gunthorpe
2017-04-04 17:25       ` Logan Gunthorpe
2017-04-05 15:43     ` Steve Wise
2017-04-05 15:43       ` Steve Wise
2017-04-05 15:43       ` Steve Wise
2017-04-05 15:43       ` Steve Wise
2017-04-05 15:43       ` Steve Wise
2017-03-30 22:12 ` [RFC 5/8] scatterlist: Modify SG copy functions to support io memory Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-31  7:09   ` Christoph Hellwig
2017-03-31  7:09     ` Christoph Hellwig
2017-03-31  7:09     ` Christoph Hellwig
2017-03-31  7:09     ` Christoph Hellwig
2017-03-31  7:09     ` Christoph Hellwig
2017-03-31 15:41     ` Logan Gunthorpe
2017-03-31 15:41       ` Logan Gunthorpe
2017-03-31 15:41       ` Logan Gunthorpe
2017-03-31 15:41       ` Logan Gunthorpe
2017-03-31 15:41       ` Logan Gunthorpe
2017-04-03 21:20       ` Logan Gunthorpe
2017-04-03 21:20         ` Logan Gunthorpe
2017-04-03 21:20         ` Logan Gunthorpe
2017-04-03 21:20         ` Logan Gunthorpe
2017-04-03 21:20         ` Logan Gunthorpe
2017-04-03 21:44         ` Dan Williams
2017-04-03 21:44           ` Dan Williams
2017-04-03 21:44           ` Dan Williams
2017-04-03 21:44           ` Dan Williams
2017-04-03 21:44           ` Dan Williams
2017-04-03 22:10           ` Logan Gunthorpe
2017-04-03 22:10             ` Logan Gunthorpe
2017-04-03 22:10             ` Logan Gunthorpe
2017-04-03 22:10             ` Logan Gunthorpe
2017-04-03 22:10             ` Logan Gunthorpe
2017-04-03 22:47             ` Dan Williams
2017-04-03 22:47               ` Dan Williams
2017-04-03 22:47               ` Dan Williams
2017-04-03 22:47               ` Dan Williams
2017-04-03 22:47               ` Dan Williams
2017-04-03 23:12               ` Logan Gunthorpe
2017-04-03 23:12                 ` Logan Gunthorpe
2017-04-03 23:12                 ` Logan Gunthorpe
2017-04-03 23:12                 ` Logan Gunthorpe
2017-04-03 23:12                 ` Logan Gunthorpe
2017-04-04  0:07                 ` Dan Williams
2017-04-04  0:07                   ` Dan Williams
2017-04-04  0:07                   ` Dan Williams
2017-04-04  0:07                   ` Dan Williams
2017-04-04  0:07                   ` Dan Williams
2017-04-07 17:59                   ` Logan Gunthorpe
2017-04-07 17:59                     ` Logan Gunthorpe
2017-04-07 17:59                     ` Logan Gunthorpe
2017-04-07 17:59                     ` Logan Gunthorpe
2017-04-07 17:59                     ` Logan Gunthorpe
2017-03-30 22:12 ` [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-04-04 10:59   ` Sagi Grimberg
2017-04-04 10:59     ` Sagi Grimberg
2017-04-04 10:59     ` Sagi Grimberg
2017-04-04 10:59     ` Sagi Grimberg
2017-04-04 10:59     ` Sagi Grimberg
     [not found]     ` <080b68b4-eba3-861c-4f29-5d829425b5e7-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2017-04-04 15:46       ` Jason Gunthorpe
2017-04-04 15:46         ` Jason Gunthorpe
2017-04-04 15:46         ` Jason Gunthorpe
     [not found]         ` <20170404154629.GA13552-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-04-04 17:21           ` Logan Gunthorpe
2017-04-04 17:21             ` Logan Gunthorpe
2017-04-04 17:21             ` Logan Gunthorpe
2017-04-06  5:33           ` Sagi Grimberg
2017-04-06  5:33             ` Sagi Grimberg
2017-04-06  5:33             ` Sagi Grimberg
2017-04-06 16:35             ` Jason Gunthorpe
2017-04-06 16:35               ` Jason Gunthorpe
     [not found]             ` <4df229d8-8124-664a-9bc4-6401bc034be1-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2017-04-06 16:02               ` Logan Gunthorpe
2017-04-06 16:02                 ` Logan Gunthorpe
2017-04-06 16:02                 ` Logan Gunthorpe
2017-04-07 11:19               ` Stephen  Bates
2017-04-07 11:19                 ` Stephen  Bates
2017-04-07 11:19                 ` Stephen  Bates
2017-04-07 11:19                 ` Stephen  Bates
     [not found]                 ` <3E85B4D4-9EBC-4299-8209-2D8740947764-pv7U853sEMVWk0Htik3J/w@public.gmane.org>
2017-04-10  8:29                   ` Sagi Grimberg
2017-04-10  8:29                     ` Sagi Grimberg
2017-04-10  8:29                     ` Sagi Grimberg
     [not found]                     ` <7fcc3ac8-8b96-90f5-3942-87f999c7499d-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2017-04-10 16:03                       ` Logan Gunthorpe
2017-04-10 16:03                         ` Logan Gunthorpe
2017-04-10 16:03                         ` Logan Gunthorpe
2017-03-30 22:12 ` [RFC 7/8] p2pmem: Support device removal Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12 ` [RFC 8/8] p2pmem: Added char device user interface Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
2017-03-30 22:12   ` Logan Gunthorpe
     [not found] ` <1490911959-5146-1-git-send-email-logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-12  5:22   ` [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory Benjamin Herrenschmidt
2017-04-12  5:22     ` Benjamin Herrenschmidt
2017-04-12  5:22     ` Benjamin Herrenschmidt
     [not found]     ` <1491974532.7236.43.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-12 17:09       ` Logan Gunthorpe
2017-04-12 17:09         ` Logan Gunthorpe
2017-04-12 17:09         ` Logan Gunthorpe
     [not found]         ` <5ac22496-56ec-025d-f153-140001d2a7f9-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-12 21:55           ` Benjamin Herrenschmidt
2017-04-12 21:55             ` Benjamin Herrenschmidt
2017-04-12 21:55             ` Benjamin Herrenschmidt
     [not found]             ` <1492034124.7236.77.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-13 21:22               ` Logan Gunthorpe
2017-04-13 21:22                 ` Logan Gunthorpe
2017-04-13 21:22                 ` Logan Gunthorpe
     [not found]                 ` <81888a1e-eb0d-cbbc-dc66-0a09c32e4ea2-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-13 22:37                   ` Benjamin Herrenschmidt
2017-04-13 22:37                     ` Benjamin Herrenschmidt
2017-04-13 22:37                     ` Benjamin Herrenschmidt
2017-04-13 23:26                   ` Bjorn Helgaas
2017-04-13 23:26                     ` Bjorn Helgaas
2017-04-13 23:26                     ` Bjorn Helgaas
     [not found]                     ` <20170413232631.GB24910-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2017-04-14  4:16                       ` Jason Gunthorpe
2017-04-14  4:16                         ` Jason Gunthorpe
2017-04-14  4:16                         ` Jason Gunthorpe
     [not found]                         ` <20170414041656.GA30694-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-04-14  4:40                           ` Logan Gunthorpe
2017-04-14  4:40                             ` Logan Gunthorpe
2017-04-14  4:40                             ` Logan Gunthorpe
     [not found]                             ` <08c32f0d-6c7c-b65f-6453-dde0d7c173d1-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-14 11:37                               ` Benjamin Herrenschmidt
2017-04-14 11:37                                 ` Benjamin Herrenschmidt
2017-04-14 11:37                                 ` Benjamin Herrenschmidt
     [not found]                                 ` <1492169879.25766.4.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-14 11:39                                   ` Benjamin Herrenschmidt
2017-04-14 11:39                                     ` Benjamin Herrenschmidt
2017-04-14 11:39                                     ` Benjamin Herrenschmidt
2017-04-14 11:37                           ` Benjamin Herrenschmidt
2017-04-14 11:37                             ` Benjamin Herrenschmidt
2017-04-14 11:37                             ` Benjamin Herrenschmidt
     [not found]                             ` <1492169849.25766.3.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-14 17:30                               ` Logan Gunthorpe
2017-04-14 17:30                                 ` Logan Gunthorpe
2017-04-14 17:30                                 ` Logan Gunthorpe
     [not found]                                 ` <630c1c63-ff17-1116-e069-2b8f93e50fa2-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-14 19:04                                   ` Bjorn Helgaas
2017-04-14 19:04                                     ` Bjorn Helgaas
2017-04-14 19:04                                     ` Bjorn Helgaas
     [not found]                                     ` <20170414190452.GA15679-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2017-04-14 22:07                                       ` Benjamin Herrenschmidt
2017-04-14 22:07                                         ` Benjamin Herrenschmidt
2017-04-14 22:07                                         ` Benjamin Herrenschmidt
     [not found]                                         ` <1492207643.25766.18.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-15 17:41                                           ` Logan Gunthorpe
2017-04-15 17:41                                             ` Logan Gunthorpe
2017-04-15 17:41                                             ` Logan Gunthorpe
2017-04-15 22:09                                             ` Dan Williams
2017-04-15 22:09                                               ` Dan Williams
     [not found]                                               ` <CAPcyv4jUeKzKDARp6Z35kdPLKnP-M6aF8X5KpOx55CLyjnj4dA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-16  3:01                                                 ` Benjamin Herrenschmidt
2017-04-16  3:01                                                   ` Benjamin Herrenschmidt
2017-04-16  3:01                                                   ` Benjamin Herrenschmidt
     [not found]                                                   ` <1492311719.25766.37.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-16  4:46                                                     ` Logan Gunthorpe
2017-04-16  4:46                                                       ` Logan Gunthorpe
2017-04-16  4:46                                                       ` Logan Gunthorpe
2017-04-16 15:53                                                   ` Dan Williams
2017-04-16 15:53                                                     ` Dan Williams
     [not found]                                                     ` <CAPcyv4iqnz1B00Q3xG-nGrLXdOyB7ditxmwZyotksLFgUqr+jA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-16 16:34                                                       ` Logan Gunthorpe
2017-04-16 16:34                                                         ` Logan Gunthorpe
2017-04-16 16:34                                                         ` Logan Gunthorpe
     [not found]                                                         ` <5e43818e-8c6b-8be8-23ff-b798633d2a73-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-16 22:31                                                           ` Benjamin Herrenschmidt
2017-04-16 22:31                                                             ` Benjamin Herrenschmidt
2017-04-16 22:31                                                             ` Benjamin Herrenschmidt
     [not found]                                                             ` <1492381907.25766.49.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-24  7:36                                                               ` Knut Omang
2017-04-24  7:36                                                                 ` Knut Omang
2017-04-24  7:36                                                                 ` Knut Omang
2017-04-24  7:36                                                                 ` Knut Omang
     [not found]                                                                 ` <1493019397.3171.118.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-04-24 16:14                                                                   ` Logan Gunthorpe
2017-04-24 16:14                                                                     ` Logan Gunthorpe
2017-04-24 16:14                                                                     ` Logan Gunthorpe
     [not found]                                                                     ` <9b6c0830-a728-c7ca-e6c6-2135f3f760ed-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-25  6:30                                                                       ` Knut Omang
2017-04-25  6:30                                                                         ` Knut Omang
2017-04-25  6:30                                                                         ` Knut Omang
2017-04-25  6:30                                                                         ` Knut Omang
     [not found]                                                                         ` <1493101803.3171.246.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-04-25 17:03                                                                           ` Logan Gunthorpe
2017-04-25 17:03                                                                             ` Logan Gunthorpe
2017-04-25 17:03                                                                             ` Logan Gunthorpe
     [not found]                                                                             ` <0cc95df5-b9dd-6493-15fe-771d535c1020-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-25 21:23                                                                               ` Stephen  Bates
2017-04-25 21:23                                                                                 ` Stephen  Bates
2017-04-25 21:23                                                                                 ` Stephen  Bates
2017-04-25 21:23                                                                                 ` Stephen  Bates
2017-04-25 21:23                                                                   ` Stephen  Bates
2017-04-25 21:23                                                                     ` Stephen  Bates
2017-04-25 21:23                                                                     ` Stephen  Bates
2017-04-25 21:23                                                                     ` Stephen  Bates
2017-04-16 22:26                                                       ` Benjamin Herrenschmidt
2017-04-16 22:26                                                         ` Benjamin Herrenschmidt
2017-04-16 22:26                                                         ` Benjamin Herrenschmidt
     [not found]                                             ` <bff1e503-95a9-e19f-bfd9-0ff962c63a81-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
2017-04-15 22:17                                               ` Benjamin Herrenschmidt
2017-04-15 22:17                                                 ` Benjamin Herrenschmidt
2017-04-15 22:17                                                 ` Benjamin Herrenschmidt
     [not found]                                                 ` <1492294628.25766.33.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2017-04-16  5:36                                                   ` Logan Gunthorpe
2017-04-16  5:36                                                     ` Logan Gunthorpe
2017-04-16  5:36                                                     ` Logan Gunthorpe

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=0280fbb4-ba9e-ac64-6bb3-b72590a54e57@deltatee.com \
    --to=logang@deltatee.com \
    --cc=axboe@kernel.dk \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=maxg@mellanox.com \
    --cc=okaya@codeaurora.org \
    --cc=sagi@grimberg.me \
    --cc=sbates@raithlin.com \
    --cc=swise@opengridcomputing.com \
    /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.