DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: Shahaf Shuler <shahafs@mellanox.com>,
	"dev@dpdk.org" <dev@dpdk.org>, Olga Shern <olgas@mellanox.com>,
	Yongseok Koh <yskoh@mellanox.com>,
	"pawelx.wodkowski@intel.com" <pawelx.wodkowski@intel.com>,
	"gowrishankar.m@linux.vnet.ibm.com"
	<gowrishankar.m@linux.vnet.ibm.com>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
	"shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>
Subject: Re: [dpdk-dev] [RFC] ethdev: introduce DMA memory mapping for external memory
Date: Mon, 19 Nov 2018 09:04:15 -0800
Message-ID: <20181119090415.56a16eca@xeon-e3> (raw)
In-Reply-To: <ec227962-d6c2-134f-fc33-567a228f99d1@intel.com>

On Thu, 15 Nov 2018 10:59:36 +0000
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:

> > Unfortunately it cannot be done at least w/ Mellanox.
> > In Mellanox the kernel driver is the one which maps the memory. The mapping returns a key which identify a memory region which was just registered to the device.
> > There is a complete separation between the ports, meaning one port mapping cannot be used by in the other port, even if the key is known.
> > 
> > The separation is not only in ports, but also in processes (two primary ones, for secondary we have a way to share). If two process work on the same device, the must register the memory independently.  
> 
> Ah, OK.
> 
> So, we're right back to where we started. Right now, external memory 
> expects to behave the same way as all other memory - you don't need to 
> perform DMA mapping for it.
> 
> That said, part of the reason *why* it was done that way was because 
> there is no way to trigger VFIO DMA mapping for NXP (or was it MLX?) 
> devices. If you look at initial versions of the patchset, the DMA 
> mapping was actually done manually. Then, i became convinced that doing 
> this automatically is the way to go, both because it erases the 
> usability differences as far as memory types are concerned, and because 
> it enables whatever services that are subscribing to memory events to 
> receive notifications about external memory as well (i.e. consistency).
> 
> Given that it's still an experimental API, we can tinker with it all we 
> like, so it's not set in stone. However, i would really like to keep the 
> current automagic thing, because DMA mapping may not be the only user of 
> memory callbacks - they can be used for debug purposes, or for any other 
> things.

If you look at the netvsc PMD, you will discover it to has the kernel
setup the receive memory area. There is some flexibility about where it
is mmap'd but the memory is coming from pinned kernel memory.

      parent reply	other threads:[~2018-11-19 17:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-04 12:41 Shahaf Shuler
2018-11-14 11:19 ` Burakov, Anatoly
2018-11-14 14:53   ` Shahaf Shuler
2018-11-14 17:06     ` Burakov, Anatoly
2018-11-15  9:46       ` Shahaf Shuler
2018-11-15 10:59         ` Burakov, Anatoly
2018-11-19 11:20           ` Shahaf Shuler
2018-11-19 17:18             ` Burakov, Anatoly
     [not found]               ` <DB7PR05MB442643DFD33B71797CD34B5EC3D90@DB7PR05MB4426.eurprd05.prod.outlook.com>
2018-11-20 10:55                 ` Burakov, Anatoly
2018-11-22 10:06                   ` Shahaf Shuler
2018-11-22 10:41                     ` Burakov, Anatoly
2018-11-22 11:31                       ` Shahaf Shuler
2018-11-22 11:34                         ` Burakov, Anatoly
2019-01-14  6:12                         ` Shahaf Shuler
2019-01-15 12:07                           ` Burakov, Anatoly
2019-01-16 11:04                             ` Shahaf Shuler
2018-11-19 17:04           ` Stephen Hemminger [this message]

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=20181119090415.56a16eca@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=anatoly.burakov@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=gowrishankar.m@linux.vnet.ibm.com \
    --cc=olgas@mellanox.com \
    --cc=pawelx.wodkowski@intel.com \
    --cc=shahafs@mellanox.com \
    --cc=shreyansh.jain@nxp.com \
    --cc=thomas@monjalon.net \
    --cc=yskoh@mellanox.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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git