From: Thomas Monjalon <thomas@monjalon.net>
To: Alejandro Lucero <alejandro.lucero@netronome.com>
Cc: dev@dpdk.org, anatoly.burakov@intel.com,
arybchenko@solarflare.com, ferruh.yigit@intel.com
Subject: Re: [dpdk-dev] [PATCH v3 1/6] mem: add function for checking memsegs IOVAs addresses
Date: Sun, 28 Oct 2018 22:03:48 +0100 [thread overview]
Message-ID: <1690955.c5uQ1SuNDL@xps> (raw)
In-Reply-To: <1538743527-8285-2-git-send-email-alejandro.lucero@netronome.com>
05/10/2018 14:45, Alejandro Lucero:
> A device can suffer addressing limitations. This function checks
> memsegs have iovas within the supported range based on dma mask.
>
> PMDs should use this function during initialization if device
> suffers addressing limitations, returning an error if this function
> returns memsegs out of range.
>
> Another usage is for emulated IOMMU hardware with addressing
> limitations.
>
> It is necessary to save the most restricted dma mask for checking out
> memory allocated dynamically after initialization.
>
> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
I am really disappointed that no more people looked at this patch,
even after asking in several maintainers meeting:
http://mails.dpdk.org/archives/dev/2018-October/116337.html
http://mails.dpdk.org/archives/dev/2018-October/117092.html
This series will enter in 18.11-rc1 because no strong objection
(only 1 issue raised without any followup).
I had no time to review it recently, but after a quick look, I see
some details which can be improved. Please, Alejandro,
consider comments below for a separate patch in -rc2. Thanks
[...]
> +static int
> +check_iova(const struct rte_memseg_list *msl __rte_unused,
> + const struct rte_memseg *ms, void *arg)
> +{
> + uint64_t *mask = arg;
> + rte_iova_t iova;
> +
> + /* higher address within segment */
> + iova = (ms->iova + ms->len) - 1;
This black magic needs to be better commented.
> + if (!(iova & *mask))
> + return 0;
> +
> + RTE_LOG(DEBUG, EAL, "memseg iova %"PRIx64", len %zx, out of range\n",
> + ms->iova, ms->len);
> +
> + RTE_LOG(DEBUG, EAL, "\tusing dma mask %"PRIx64"\n", *mask);
> + return 1;
> +}
[...]
> --- a/lib/librte_eal/common/include/rte_memory.h
> +++ b/lib/librte_eal/common/include/rte_memory.h
> +/* check memsegs iovas are within a range based on dma mask */
> +int rte_eal_check_dma_mask(uint8_t maskbits);
You need to insert a doxygen comment, explaining the format
of the maskbits parameter, and the behaviour of the function.
The doxygen comment must also state the function is experimental.
About the name of the function, the trend is to use rte_mem_ prefix
instead of rte_eal_ in this case.
__rte_experimental tag must be added to the function prototype, I will do
when applying the patch.
next prev parent reply other threads:[~2018-10-28 21:03 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-05 12:45 [dpdk-dev] [PATCH v3 0/6] use IOVAs check based on DMA mask Alejandro Lucero
2018-10-05 12:45 ` [dpdk-dev] [PATCH v3 1/6] mem: add function for checking memsegs IOVAs addresses Alejandro Lucero
2018-10-10 8:56 ` Tu, Lijuan
2018-10-11 9:26 ` Alejandro Lucero
2018-10-28 21:03 ` Thomas Monjalon [this message]
2018-10-05 12:45 ` [dpdk-dev] [PATCH v3 2/6] mem: use address hint for mapping hugepages Alejandro Lucero
2018-10-29 16:08 ` Dariusz Stojaczyk
2018-10-29 16:40 ` Alejandro Lucero
2018-10-05 12:45 ` [dpdk-dev] [PATCH v3 3/6] bus/pci: check iommu addressing limitation just once Alejandro Lucero
2018-10-05 12:45 ` [dpdk-dev] [PATCH v3 4/6] bus/pci: use IOVAs dmak mask check when setting IOVA mode Alejandro Lucero
2018-10-05 12:45 ` [dpdk-dev] [PATCH v3 5/6] net/nfp: check hugepages IOVAs based on DMA mask Alejandro Lucero
2018-10-05 12:45 ` [dpdk-dev] [PATCH v3 6/6] net/nfp: support IOVA VA mode Alejandro Lucero
2018-10-28 21:04 ` [dpdk-dev] [PATCH v3 0/6] use IOVAs check based on DMA mask 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
-- strict thread matches above, loose matches on Subject: below --
2018-07-04 12:53 Alejandro Lucero
2018-07-04 12:53 ` [dpdk-dev] [PATCH v3 1/6] mem: add function for checking memsegs IOVAs addresses 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=1690955.c5uQ1SuNDL@xps \
--to=thomas@monjalon.net \
--cc=alejandro.lucero@netronome.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.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 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).