From: Stephen Hemminger <firstname.lastname@example.org> To: "Burakov, Anatoly" <email@example.com> Cc: Shahaf Shuler <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Olga Shern <email@example.com>, Yongseok Koh <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Thomas Monjalon <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.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: <firstname.lastname@example.org> On Thu, 15 Nov 2018 10:59:36 +0000 "Burakov, Anatoly" <email@example.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.
prev 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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 \ firstname.lastname@example.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