All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: Bruce Richardson <bruce.richardson@intel.com>,
	rajesh.ravi@broadcom.com, ajit.khaparde@broadcom.com,
	jonathan.richardson@broadcom.com, scott.branden@broadcom.com,
	vikram.prakash@broadcom.com, srinath.mannam@broadcom.com,
	david.marchand@redhat.com, thomas@monjalon.net
Subject: Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps
Date: Tue, 5 Nov 2019 17:15:13 +0000	[thread overview]
Message-ID: <cdfb9a63-3899-8b2e-402a-689e7fd612bb@intel.com> (raw)
In-Reply-To: <5dd669557fc499df5e345a14c9252c095eff6c07.1572966906.git.anatoly.burakov@intel.com>

On 05-Nov-19 3:15 PM, Anatoly Burakov wrote:
> Currently, externally created heaps are supposed to be automatically
> mapped for VFIO DMA by EAL, however they only do so if, at the time of
> heap creation, VFIO is initialized and has at least one device
> available. If no devices are available at the time of heap creation (or
> if devices were available, but were since hot-unplugged, thus dropping
> all VFIO container mappings), then VFIO mapping code would have skipped
> over externally allocated heaps.
> 
> The fix is two-fold. First, we allow externally allocated memory
> segments to be marked as "heap" segments. This allows us to distinguish
> between external memory segments that were created via heap API, from
> those that were created via rte_extmem_register() API.
> 
> Then, we fix the VFIO code to only skip non-heap external segments.
> Also, since external heaps are not guaranteed to have valid IOVA
> addresses, we will skip those which have invalid IOVA addresses as well.
> 
> Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc heap")
> 
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> 
> Notes:
>      This cannot be backported to older releases as it breaks the
>      API and ABI. A separate fix is in the works for stable.
> 

Alternative, non-breaking implementation available (which will be slower 
due to O(N) memseg list heaps lookups):

http://patches.dpdk.org/patch/62486/

I'm fine with either option being merged.

The more perfect solution would've been to rename "msl->external" into 
"msl->flags" and have various flags for memseg lists, but it's too late 
to break the API now.

-- 
Thanks,
Anatoly

  reply	other threads:[~2019-11-05 17:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 15:15 [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps Anatoly Burakov
2019-11-05 17:15 ` Burakov, Anatoly [this message]
2019-11-06 13:58   ` David Marchand
2019-11-06 15:27     ` Rajesh Ravi
2019-11-06 16:03       ` Burakov, Anatoly
2019-11-06 21:53 ` David Marchand
2019-11-06 22:12   ` Thomas Monjalon
2019-11-07  6:35 ` Rajesh Ravi
2019-11-07 15:35 ` David Marchand

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=cdfb9a63-3899-8b2e-402a-689e7fd612bb@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jonathan.richardson@broadcom.com \
    --cc=rajesh.ravi@broadcom.com \
    --cc=scott.branden@broadcom.com \
    --cc=srinath.mannam@broadcom.com \
    --cc=thomas@monjalon.net \
    --cc=vikram.prakash@broadcom.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.