From: Steve Wise
Some cxgb4 cards expose memory as part of BAR4. This patch registers
this memory as a p2pmem device.
Signed-off-by: Steve Wise
Signed-off-by: Logan Gunthorpe
Signed-off-by: Stephen Bates
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 3 +
drivers/net/ethernet/chelsio
We create a configfs attribute in each nvme-fabrics target port to
enable p2p memory use. When enabled, the port will only then use the
p2p memory if a p2p memory device can be found which is behind the
same switch as the RDMA port and all the block devices in use. If
the user enabled it an no devi
Hello,
As discussed at LSF/MM we'd like to present our work to enable
copy offload support in NVMe fabrics RDMA targets. We'd appreciate
some review and feedback from the community on our direction.
This series is not intended to go upstream at this point.
The concept here is to use memory that's
From: Steve Wise
For each p2pmem instance, add a "stats" file to show
the gen_pool statistics.
Signed-off-by: Steve Wise
Signed-off-by: Logan Gunthorpe
Signed-off-by: Stephen Bates
---
drivers/memory/p2pmem.c | 49 +
include/linux/p2pmem.h |
p2pmem will always be iomem so if we ever access it, we should be using
the correct methods to read and write to it.
Signed-off-by: Logan Gunthorpe
Signed-off-by: Stephen Bates
Signed-off-by: Steve Wise
---
drivers/nvme/target/core.c| 18 --
drivers/nvme/target/fabrics-
A p2pmem device is simply a PCI card with a BAR space that points to
regular memory. This may be an independent PCI card or part of another
completely unrelated device (like an IB card or a NVMe card). The
p2pmem device is designed such that other drivers may register p2pmem
memory for use by the s
This creates a userspace interface to use p2pmemory. A user can use
mmap on the p2pmem char device to get buffers from the corresponding
device. This allows a user to use p2p memory with existing
interfaces like RDMA and O_DIRECT.
This patch is a bit more controversial because people don't want to
This patch creates a list of callbacks to notify users of this memory
that the p2pmem device is going away or gone.
In nvmet-rdma, we disconnect any queue using p2p memory.
The remote side will then automatically reconnect in a
couple seconds and regular system memory (or a different p2pmem device
Now that we are using p2pmem SG buffers we occasionally have to copy
to and from this memory. For this, we add an iomem flag to
sg_copy_buffer for copying with iomemcpy. We also add the sg_iocopy_
variants to use this more easily.
Signed-off-by: Logan Gunthorpe
Signed-off-by: Stephen Bates
Signe
On Thu, Mar 30, 2017 at 10:19 AM, Linda Knippers wrote:
> On 03/30/2017 01:12 PM, Dan Williams wrote:
>> On Thu, Mar 30, 2017 at 10:06 AM, Linda Knippers
>> wrote:
>>>
>>>
>>> On 3/30/2017 12:56 PM, Dan Williams wrote:
>> [..]
Patches welcome :).
>>>
>>>
>>> You won't like my patch for that
On 03/30/2017 01:12 PM, Dan Williams wrote:
> On Thu, Mar 30, 2017 at 10:06 AM, Linda Knippers
> wrote:
>>
>>
>> On 3/30/2017 12:56 PM, Dan Williams wrote:
> [..]
>>> Patches welcome :).
>>
>>
>> You won't like my patch for that because I agree with Jeff. :-)
>>
>> Right now I'm more interested i
On Thu, Mar 30, 2017 at 10:06 AM, Linda Knippers wrote:
>
>
> On 3/30/2017 12:56 PM, Dan Williams wrote:
[..]
>> Patches welcome :).
>
>
> You won't like my patch for that because I agree with Jeff. :-)
>
> Right now I'm more interested in seeing if I can modify the tests to not
> require nfit_tes
On 3/30/2017 12:56 PM, Dan Williams wrote:
On Thu, Mar 30, 2017 at 9:08 AM, Linda Knippers wrote:
On 03/29/2017 04:30 PM, Dan Williams wrote:
On Wed, Mar 29, 2017 at 1:19 PM, Jeff Moyer wrote:
Dan Williams writes:
On Wed, Mar 29, 2017 at 1:02 PM, Jeff Moyer wrote:
Dan Williams writes
On Thu, Mar 30, 2017 at 9:08 AM, Linda Knippers wrote:
> On 03/29/2017 04:30 PM, Dan Williams wrote:
>> On Wed, Mar 29, 2017 at 1:19 PM, Jeff Moyer wrote:
>>> Dan Williams writes:
>>>
On Wed, Mar 29, 2017 at 1:02 PM, Jeff Moyer wrote:
> Dan Williams writes:
>
>> +check_min_kve
Dear Customer,
We can not deliver your parcel arrived at March 26.
Review the document that is attached to this e-mail!
With gratitude,
Javier Barry,
UPS Office Manager.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mail
On 03/29/2017 04:30 PM, Dan Williams wrote:
> On Wed, Mar 29, 2017 at 1:19 PM, Jeff Moyer wrote:
>> Dan Williams writes:
>>
>>> On Wed, Mar 29, 2017 at 1:02 PM, Jeff Moyer wrote:
Dan Williams writes:
> +check_min_kver()
> +{
> + local ver="$1"
> + : "${KVER:=$(
On 3/29/2017 6:26 PM, Elliott, Robert (Persistent Memory) wrote:
-Original Message-
From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf
Of lijun@dell.com
Sent: Wednesday, March 29, 2017 4:41 PM
To: dan.j.willi...@intel.com; lijunpan2...@gmail.com
Subject: RE: [PA
On 3/29/2017 5:41 PM, lijun@dell.com wrote:
Dell - Internal Use - Confidential
-Original Message-
From: Dan Williams [mailto:dan.j.willi...@intel.com]
Sent: Wednesday, March 29, 2017 1:13 PM
To: Lijun Pan
Cc: linux-nvdimm@lists.01.org; Pan, Lijun ; Hayes,
Stuart
Subject: Re: [
On Wed, Mar 29, 2017 at 05:04:31PM -0400, Jeff Moyer wrote:
> Well, the goal was to be somewhat smart about it, by not even trying to
> test things that aren't implemented or configured into the current
> kernel (such as device dax, for example). Upon thinking about it
> further, I don't think tha
On Thu, Mar 30, 2017 at 02:16:00PM +0800, Xiong Zhou wrote:
> Ccing Eryu
>
> On Wed, Mar 29, 2017 at 02:12:25PM -0700, Dan Williams wrote:
> > On Wed, Mar 29, 2017 at 2:04 PM, Jeff Moyer wrote:
> > > Dan Williams writes:
> > >
> > >>> Can we stop with this kernel version checking, please? T
20 matches
Mail list logo
