From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by dpdk.org (Postfix) with ESMTP id 5A7F37CEB for ; Tue, 10 Jul 2018 13:43:14 +0200 (CEST) Received: by mail-ed1-f66.google.com with SMTP id u11-v6so16326847eds.10 for ; Tue, 10 Jul 2018 04:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A8aPlENH2fa7XmUF+Bh2S3jnakmJq2aWIqwZAErqUss=; b=tBgYWxRgS6tRsXrnT+li99fhuqDVCK/RCtnBL9uu5VVXx0MYvVkFRx9iSMfdLRp6hE hjpmENSapj5UY7Wk3q0E/GBVPs9702F4cFFqAMqd9rndO5bUuclYLvqAK1NtR3BTLbQ3 VCmjerCcMpObkspNm1e0jTkF7aHtNzFRbRE04quPhEmjRXs23+c0TM3XVzRMKcbqrH51 AiLq2zb0KYzyKt4LGNNSE3bgs4eEw1fkukZFREV7yw3TI+FGi04rDPjVn52T+HYg0WTU 4KLto5xjAwmhLahWzgbbBlLsMqHAMBfVtdoMA9eYToSbVyoSpD9tL6goKBG+1ZAe3nV7 QbwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A8aPlENH2fa7XmUF+Bh2S3jnakmJq2aWIqwZAErqUss=; b=sX/j5vehpPdNfd1DDmKV28UfKyKiKrN7x6hxY56hm6fkfC+d+CZ4DTUCnQrkCZxIWw Q8mVc+N4Gu53RBa0qIq5KsRWNoK9wZq4Ye22UFQZ7azK+scZTfyf9xcR9r3/SGh7nMLS XGPoFAg9WuOUbgPNKQRgz54g2EMqupKKBV4U77lQDRTmn9WzzqkQbcdPEQ5gVJgQVSMk DFKkwUBNzYI74CBzAlxxLC1MFi3uqetPkIYyjHgd0EW/hRuDNqkx0Ba1JXIvrZ5PY5m/ tzHmBx57ctZkSTvojap4ml5uXZd+KLt91kiIY8l25tPYllt8x1K+Qvb085g5AJIDrU0z kqew== X-Gm-Message-State: APt69E2frreexd84mGmDQyxL6vGOyFD/Sh3jiuqRwdNEL5kvr7D9xTz9 LCZcHeYKSDl8sBEcao/AThZzAjN01tKLVaW9lgtQ3Q== X-Google-Smtp-Source: AAOMgpdbt+0c/qpfJM3f/ueqEFavrOb08keZf4P5BU4JF3/Y316AORVWvxJcowVbTGrdOAhQVvSB064ggAYhGCOSIeU= X-Received: by 2002:a50:b266:: with SMTP id o93-v6mr22261068edd.173.1531222994143; Tue, 10 Jul 2018 04:43:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:b194:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 04:43:13 -0700 (PDT) In-Reply-To: <33c605a8-cf16-b2f2-ce1d-cdc5d85bb155@intel.com> References: <1530708838-2682-1-git-send-email-alejandro.lucero@netronome.com> <1530708838-2682-2-git-send-email-alejandro.lucero@netronome.com> <24D4D56B-BE3A-43DC-AEEE-A063A11C73EC@redhat.com> <33c605a8-cf16-b2f2-ce1d-cdc5d85bb155@intel.com> From: Alejandro Lucero Date: Tue, 10 Jul 2018 12:43:13 +0100 Message-ID: To: "Burakov, Anatoly" Cc: Eelco Chaudron , dev , stable@dpdk.org, Maxime Coquelin , Ferruh Yigit Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v3 1/6] mem: add function for checking memsegs IOVAs addresses X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 11:43:14 -0000 On Tue, Jul 10, 2018 at 12:33 PM, Burakov, Anatoly < anatoly.burakov@intel.com> wrote: > On 10-Jul-18 12:14 PM, Eelco Chaudron wrote: > >> >> >> On 10 Jul 2018, at 12:52, Alejandro Lucero wrote: >> >> On Tue, Jul 10, 2018 at 11:06 AM, Eelco Chaudron >>> wrote: >>> >>> >>>> >>>> On 10 Jul 2018, at 11:34, Alejandro Lucero wrote: >>>> >>>> On Tue, Jul 10, 2018 at 9:56 AM, Eelco Chaudron >>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> On 4 Jul 2018, at 14:53, 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. >>>>>>> >>>>>>> Signed-off-by: Alejandro Lucero >>>>>>> Acked-by: Anatoly Burakov >>>>>>> --- >>>>>>> lib/librte_eal/common/eal_common_memory.c | 33 >>>>>>> ++++++++++++++++++++++++++++++ >>>>>>> lib/librte_eal/common/include/rte_memory.h | 3 +++ >>>>>>> lib/librte_eal/rte_eal_version.map | 1 + >>>>>>> 3 files changed, 37 insertions(+) >>>>>>> >>>>>>> diff --git a/lib/librte_eal/common/eal_common_memory.c >>>>>>> b/lib/librte_eal/common/eal_common_memory.c >>>>>>> index fc6c44d..f5efebe 100644 >>>>>>> --- a/lib/librte_eal/common/eal_common_memory.c >>>>>>> +++ b/lib/librte_eal/common/eal_common_memory.c >>>>>>> @@ -109,6 +109,39 @@ >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> +/* check memseg iovas are within the required range based on dma >>>>>>> mask >>>>>>> */ >>>>>>> +int >>>>>>> +rte_eal_check_dma_mask(uint8_t maskbits) >>>>>>> +{ >>>>>>> + >>>>>>> + const struct rte_mem_config *mcfg; >>>>>>> + uint64_t mask; >>>>>>> + int i; >>>>>>> + >>>>>>> >>>>>>> >>>>>>> I think we should add some sanity check to the input maskbits, i.e. >>>>>> [64,0) >>>>>> or [64, 32]? What would be a reasonable lower bound. >>>>>> >>>>>> >>>>>> This is not a user's API, so any invocation will be reviewed, but I >>>>>> guess >>>>>> >>>>> adding a sanity check here does not harm. >>>>> >>>>> Not sure about lower bound but upper should 64, although it does not >>>>> make >>>>> sense but it is safe. Lower bound is not so problematic. >>>>> >>>>> >>>>> >>>>> + /* create dma mask */ >>>>>> >>>>>> + mask = ~((1ULL << maskbits) - 1); >>>>>>> + >>>>>>> + /* get pointer to global configuration */ >>>>>>> + mcfg = rte_eal_get_configuration()->mem_config; >>>>>>> + >>>>>>> + for (i = 0; i < RTE_MAX_MEMSEG; i++) { >>>>>>> + if (mcfg->memseg[i].addr == NULL) >>>>>>> + break; >>>>>>> >>>>>>> >>>>>> Looking at some other code, it looks like NULL entries might exists. >>>> So >>>> should a continue; rather than a break; be used here? >>>> >>>> >>>> I do not think so. memsegs are allocated sequentially, so first with >>> addr >>> as NULL implies no more memsegs. >>> >> >> I was referring to the mem walk functions, rte_memseg_list_walk(). Maybe >> some having more experience with this area can review/comment. >> > > Pre-18.05, all memsegs are allocated continuously. Memseg lists and memseg > list walk functions are 18.05+. > > Alejandro, perhaps it would be worth it to tag your patchset with > "pre-18.05" to avoid similar confusion in the future? > > Yes, that will help. I'm sending a new version shortly and I'll make it clear. > -- > Thanks, > Anatoly >