DPDK patches and discussions
 help / color / mirror / Atom feed
From: Alejandro Lucero <alejandro.lucero@netronome.com>
To: dev@dpdk.org
Cc: stable@dpdk.org, anatoly.burakov@intel.com,
	maxime.coquelin@redhat.com, ferruh.yigit@intel.com
Subject: [dpdk-dev] [PATCH v3 0/6] use IOVAs check based on DMA mask
Date: Wed,  4 Jul 2018 13:53:52 +0100	[thread overview]
Message-ID: <1530708838-2682-1-git-send-email-alejandro.lucero@netronome.com> (raw)

This patchset adds, mainly, a check for ensuring IOVAs are within a
restricted range due to addressing limitations with some devices. There
are two known cases: NFP and IOMMU VT-d emulation.

With this check IOVAs out of range are detected and PMDs can abort
initialization. For the VT-d case, IOVA VA mode is allowed as long as
IOVAs are within the supported range, avoiding to forbid IOVA VA by
default.

For the addressing limitations known cases, there are just 40(NFP) or
39(VT-d) bits for handling IOVAs. When using IOVA PA, those limitations
imply 1TB(NFP) or 512M(VT-d) as upper limits, which is likely enough for
most systems. With machines using more memory, the added check will
ensure IOVAs within the range.

With IOVA VA, and because the way the Linux kernel serves mmap calls
in 64 bits systems, 39 or 40 bits are not enough. It is possible to
give an address hint with a lower starting address than the default one
used by the kernel, and then ensuring the mmap uses that hint or hint plus
some offset. With 64 bits systems, the process virtual address space is
large enoguh for doing the hugepages mmaping within the supported range
when those addressing limitations exist. This patchset also adds a change
for using such a hint making the use of IOVA VA a more than likely
possibility when there are those addressing limitations.

The check is not done by default but just when it is required. This
patchset adds the check for NFP initialization and for setting the IOVA
mode is an emulated VT-d is detected.

This patchset applies on 17.11.3.

Similar changes will be submitted to main DPDK branch soon.

v2:
 - add get_addr_hint function
 - call munmap when hint given and not used by mmap
 - create dma mask in one step
 - refactor logs

v3:
 - add new API functions to map files

             reply	other threads:[~2018-07-04 12:54 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-04 12:53 Alejandro Lucero [this message]
2018-07-04 12:53 ` [dpdk-dev] [PATCH v3 1/6] mem: add function for checking memsegs IOVAs addresses Alejandro Lucero
2018-07-10  8:56   ` [dpdk-dev] [dpdk-stable] " Eelco Chaudron
2018-07-10  9:34     ` Alejandro Lucero
2018-07-10 10:06       ` Eelco Chaudron
2018-07-10 10:52         ` Alejandro Lucero
2018-07-10 11:14           ` Eelco Chaudron
2018-07-10 11:33             ` Burakov, Anatoly
2018-07-10 11:43               ` Alejandro Lucero
2018-07-10 11:55                 ` Eelco Chaudron
2018-07-10 11:40             ` Alejandro Lucero
2018-07-04 12:53 ` [dpdk-dev] [PATCH v3 2/6] ethdev: add function for checking IOVAs by a device Alejandro Lucero
2018-07-07 17:30   ` Andrew Rybchenko
2018-07-10  8:57   ` [dpdk-dev] [dpdk-stable] " Eelco Chaudron
2018-07-10  9:42     ` Alejandro Lucero
2018-07-10  9:44       ` Alejandro Lucero
2018-07-04 12:53 ` [dpdk-dev] [PATCH v3 3/6] bus/pci: use IOVAs check when setting IOVA mode Alejandro Lucero
2018-07-10 10:14   ` [dpdk-dev] [dpdk-stable] " Eelco Chaudron
2018-07-10 15:37     ` Alejandro Lucero
2018-07-04 12:53 ` [dpdk-dev] [PATCH v3 4/6] mem: use address hint for mapping hugepages Alejandro Lucero
2018-07-10 11:15   ` [dpdk-dev] [dpdk-stable] " Eelco Chaudron
2018-07-04 12:53 ` [dpdk-dev] [PATCH v3 5/6] net/nfp: check hugepages IOVAs based on DMA mask Alejandro Lucero
2018-07-10 10:17   ` [dpdk-dev] [dpdk-stable] " Eelco Chaudron
2018-07-04 12:53 ` [dpdk-dev] [PATCH v3 6/6] net/nfp: support IOVA VA mode Alejandro Lucero
2018-07-10 10:18   ` [dpdk-dev] [dpdk-stable] " Eelco Chaudron
2018-10-05 12:45 [dpdk-dev] [PATCH v3 0/6] use IOVAs check based on DMA mask Alejandro Lucero
2018-10-28 21:04 ` Thomas Monjalon
2018-10-29  8:23   ` Yao, Lei A
2018-10-29  8:42     ` Thomas Monjalon
2018-10-29  9:07       ` Thomas Monjalon
2018-10-29  9:25         ` Alejandro Lucero
2018-10-29  9:44           ` Yao, Lei A
2018-10-29  9:36       ` Yao, Lei A
2018-10-29  9:48         ` Thomas Monjalon
2018-10-29 10:11           ` Alejandro Lucero
2018-10-29 10:15             ` Alejandro Lucero
2018-10-29 11:39               ` Alejandro Lucero
2018-10-29 11:46                 ` Thomas Monjalon
2018-10-29 12:55                   ` Alejandro Lucero
2018-10-29 13:18                     ` Yao, Lei A
2018-10-29 13:40                       ` Alejandro Lucero
2018-10-29 14:18                         ` Thomas Monjalon
2018-10-29 14:35                           ` Alejandro Lucero
2018-10-29 18:54                           ` Yongseok Koh
2018-10-29 19:37                             ` Alejandro Lucero
2018-10-30 10:10                               ` Burakov, Anatoly
2018-10-30 10:11                           ` Burakov, Anatoly
2018-10-30 10:19                             ` Alejandro Lucero
2018-10-30  3:20                         ` Lin, Xueqin
2018-10-30  9:41                           ` Alejandro Lucero
2018-10-30 10:33                             ` Lin, Xueqin
2018-10-30 10:38                               ` Alejandro Lucero
2018-10-30 12:21                                 ` Lin, Xueqin
2018-10-30 12:37                                   ` Alejandro Lucero
2018-10-30 14:04                                     ` Alejandro Lucero
2018-10-30 14:14                                       ` Burakov, Anatoly
2018-10-30 14:45                                         ` Alejandro Lucero
2018-10-30 14:45                                       ` Lin, Xueqin
2018-10-30 14:57                                         ` Alejandro Lucero
2018-10-30 15:09                                           ` Lin, Xueqin
2018-10-30 10:18                 ` Burakov, Anatoly
2018-10-30 10:23                   ` Alejandro Lucero

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=1530708838-2682-1-git-send-email-alejandro.lucero@netronome.com \
    --to=alejandro.lucero@netronome.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=stable@dpdk.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).