DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Alejandro Lucero <alejandro.lucero@netronome.com>, dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] Fwd: [PATCH v2 1/5] mem: add function for checking memsegs IOVAs addresses
Date: Thu, 4 Oct 2018 16:39:08 +0100	[thread overview]
Message-ID: <dae3a481-f49d-f671-dcd9-87f7176d9ae9@intel.com> (raw)
In-Reply-To: <CAD+H992V6a6CttknrhJ=sRwrRGVAKSX84e1RYX3o6p=o9ZVkyw@mail.gmail.com>

On 04-Oct-18 1:59 PM, Alejandro Lucero wrote:
> I sent this email only to Anatoly. Sending it again to mailing list.
> 
> On Wed, Oct 3, 2018 at 1:43 PM Burakov, Anatoly <anatoly.burakov@intel.com>
> wrote:
> 
>> On 31-Aug-18 1:50 PM, Alejandro Lucero wrote:
>>> A device can suffer addressing limitations. This functions checks
>>> memsegs have iovas within the supported range based on dma mask.
>>>
>>> PMD should use this during initialization if supported devices
>>> suffer addressing limitations, returning an error if this function
>>> returns memsegs out of range.
>>>
>>> Another potential usage is for emulated IOMMU hardware with addressing
>>> limitations.
>>>
>>> It is necessary to save the most restricted dma mask for checking
>>> memory allocated dynamically after initialization.
>>>
>>> Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
>>> ---
>>>    lib/librte_eal/common/eal_common_memory.c         | 56
>> +++++++++++++++++++++++
>>>    lib/librte_eal/common/include/rte_eal_memconfig.h |  3 ++
>>>    lib/librte_eal/common/include/rte_memory.h        |  3 ++
>>>    lib/librte_eal/common/malloc_heap.c               | 12 +++++
>>>    lib/librte_eal/linuxapp/eal/eal.c                 |  2 +
>>>    lib/librte_eal/rte_eal_version.map                |  1 +
>>>    6 files changed, 77 insertions(+)
>>>
>>> diff --git a/lib/librte_eal/common/eal_common_memory.c
>> b/lib/librte_eal/common/eal_common_memory.c
>>> index fbfb1b0..bdd8f44 100644
>>> --- a/lib/librte_eal/common/eal_common_memory.c
>>> +++ b/lib/librte_eal/common/eal_common_memory.c
>>> @@ -383,6 +383,62 @@ struct virtiova {
>>>        rte_memseg_walk(dump_memseg, f);
>>>    }
>>>
>>> +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;
>>> +     if (!(iova & *mask))
>>> +             return 0;
>>> +
>>> +     RTE_LOG(INFO, EAL, "memseg iova %"PRIx64", len %zx, out of
>> range\n",
>>> +                        ms->iova, ms->len);
>>> +
>>> +     RTE_LOG(INFO, EAL, "\tusing dma mask %"PRIx64"\n", *mask);
>>
>> IMO putting these as INFO is overkill. I'd prefer not to spam the output
>> unless it's really important. Can this go under DEBUG?
>>
>>
> This checks comes from a device or from the alloc_pages_on_heap when
> expanding memory. If the check discovers an address out of mask, a device
> can not be used or the new memory can not be allocated. I think having this
> info will help to understand why the device initialization or the memory
> allocation are failing.
> 

If this text is only displayed whenever there's an error, the log output 
should be ERR, not INFO. If the error may or may not happen depending on 
who called this function, then this information is not important enough 
to display to the user (it should be displayed in the error handler of 
the caller), and DEBUG should suffice.

> 
>> Also, the message is misleading. You stop before you have a chance to
>> check other masks, which may restrict them even further. You're
>> outputting the message about using DMA mask XXX but this may not be the
>> final DMA mask.
>>
> 
> Well, this is the first triggering, and it is enough for reporting the
> problem and avoiding the device or the new memory to be used.
> 
> Note that the mask is per device, and for the memory allocation case, it is
> the most restrictive dma mask. So there are no other masks to try.

Fair enough.

> 
> 
> 
>>
>>> +     /* Stop the walk and change mask */
>>> +     *mask = 0;
>>> +     return 1;

No need for out-of-band communication, _walk() function will return 1 if 
walk was stopped prematurely. Just check return value of walk().

-- 
Thanks,
Anatoly

  reply	other threads:[~2018-10-04 15:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 12:50 [dpdk-dev] [PATCH v2 0/5] use IOVAs check based on DMA mask Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 1/5] mem: add function for checking memsegs IOVAs addresses Alejandro Lucero
2018-10-03 12:43   ` Burakov, Anatoly
     [not found]     ` <CAD+H991m6qauwX+P=muKe6bAjNLUrcBaGbxFXkMV60OVNvRgPg@mail.gmail.com>
2018-10-04 12:59       ` [dpdk-dev] Fwd: " Alejandro Lucero
2018-10-04 15:39         ` Burakov, Anatoly [this message]
2018-10-04 17:41           ` Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 2/5] mem: use address hint for mapping hugepages Alejandro Lucero
2018-10-03 12:50   ` Burakov, Anatoly
2018-10-04 11:43     ` Alejandro Lucero
2018-10-04 12:08       ` Burakov, Anatoly
2018-10-04 13:15         ` Alejandro Lucero
2018-10-04 15:43           ` Burakov, Anatoly
2018-10-04 17:58             ` Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 3/5] bus/pci: use IOVAs check when setting IOVA mode Alejandro Lucero
2018-10-03 12:55   ` Burakov, Anatoly
2018-10-04 13:35     ` Alejandro Lucero
2018-10-04 15:49       ` Burakov, Anatoly
2018-10-04 17:59         ` Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 4/5] net/nfp: check hugepages IOVAs based on DMA mask Alejandro Lucero
2018-08-31 12:50 ` [dpdk-dev] [PATCH v2 5/5] net/nfp: support IOVA VA mode Alejandro Lucero
2018-10-02 16:33 ` [dpdk-dev] [PATCH v2 0/5] use IOVAs check based on DMA mask Alejandro Lucero
2018-10-02 21:21   ` Thomas Monjalon

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=dae3a481-f49d-f671-dcd9-87f7176d9ae9@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=dev@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).