From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 808005B16 for ; Sun, 28 Oct 2018 22:03:44 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 17EB921F3E; Sun, 28 Oct 2018 17:03:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 28 Oct 2018 17:03:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=aNPmnriVk6Wlqxszd3mGwmcUlO2yfHoXF4OqMHedCPY=; b=hqzCCAO6dRaB /YAjfkbHfhXM0R9a4lzbDxb19tj392L3q6HggYeDoAltjNWo1qZAb1LKUDgtqJvI 28H55xp2IDzn+eKT7iTYfjOM2sAhCexOLpOs6uCRdB9BNQkS1uK3K8/1GklsRdr/ FIDDAZ71Xj3uWEP/Vtx3OibyQWJK2p8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=aNPmnriVk6Wlqxszd3mGwmcUlO2yfHoXF4OqMHedC PY=; b=NOrPqtKM156zUXRU73P0V1wrdstACCPIrhadc+DOVvpo9nQwzXzTs/3q+ FG0v0VBlFJF0AebiHfo849WlalfhC9W/XNBeQyGOTm/KPQOuf3CWsREXFIgdcDRs 9YlpV4xQdPs8G2iKsyouiD3MD1GnDh4fD3Kg6uEH2G9GvDkz1k1H4CNmPECyiXSi o62VvOPjWqbU+cZNqA3rLxDb6zV8Vb44Pg4vM0GVwduya4Ss0uknp4tPTRdl0q7f py4vOjrE2+OSdczxxM9rmdQg4NTcCqUn+O9IoY8QFugxDoKmuQVzPzwyz73JXEE+ c5J/gHU9IBY8fcJyttemv0W9JyduA== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B9C91E46B8; Sun, 28 Oct 2018 17:03:42 -0400 (EDT) From: Thomas Monjalon To: Alejandro Lucero Cc: dev@dpdk.org, anatoly.burakov@intel.com, arybchenko@solarflare.com, ferruh.yigit@intel.com Date: Sun, 28 Oct 2018 22:03:48 +0100 Message-ID: <1690955.c5uQ1SuNDL@xps> In-Reply-To: <1538743527-8285-2-git-send-email-alejandro.lucero@netronome.com> References: <1538743527-8285-1-git-send-email-alejandro.lucero@netronome.com> <1538743527-8285-2-git-send-email-alejandro.lucero@netronome.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [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: Sun, 28 Oct 2018 21:03:44 -0000 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 > Reviewed-by: Anatoly Burakov 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.