From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 117F5A04B1; Fri, 1 May 2020 21:00:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 55AAB1D989; Fri, 1 May 2020 21:00:47 +0200 (CEST) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by dpdk.org (Postfix) with ESMTP id D7B4E1C11C for ; Fri, 1 May 2020 21:00:45 +0200 (CEST) Received: by mail-lj1-f194.google.com with SMTP id b2so3502173ljp.4 for ; Fri, 01 May 2020 12:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=0wjPQ3ri56N9ddl6PIt8stUtNxPRCG8fc2nO+GK3viI=; b=ubsSMfuhOofb/s23V6BNABsJB/zwzXXWuGRZTmGb1UAcWSZb7gCFMoUeZMRnLCIeQJ W0bZunQIVVrAIAFSaMJf6gAi7O+1wLhuPJNmZuVHfhLqLsO3dnmHXUgrib9YRpYvSQFH eumS/Woxat7WIb1Seucq6dmQaDCsVMtivQwUE9e15wXd6P3LJ+9aOQZlBIsNxyMm5bNA iGKG4vEHqkSr2+1CvR0o0TGEag6NZCTcGz8Z4+1yOHKsSgv2U4qLfYjmt35ReOxXM6mU JQ9bWGSgbwtBIiLn5dbxbxV8jSjVVigNOGY+sp6pkDicvDMMeMpOhimsvRD+1IOC8Ol3 s4ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=0wjPQ3ri56N9ddl6PIt8stUtNxPRCG8fc2nO+GK3viI=; b=YIokOW10v7IX+uz+PhGkyqlK4CrGIIV1p99DrW0u/rAHQoSVn09cjK5EbdEZm/xteA Hqmf6QVlL1w6e7MtfZyTrLxVPPrbM/CQG5CcnZbsKIPNQMEBwfwY4jP47dUFBEB53zFk 0Z2FbAr7IdHDk1mrxByo9uRjUAAjognbRXxlb+5uXrDT45omzv7SKLlYIVn1/nl2vDCq jbstqQHzA+wSOau3MG/fWmsGf7WQINpIi/ajoeDZaYHDVtNSXgmaChK2JXjo+zycKwfJ djD/tIOzca1A7/+5uO9p4z7TdWhUhwwtVmmrUKIWcf3DlMqLAIU3pr+Bo2cgdp/2qGWB R2TQ== X-Gm-Message-State: AGi0PubzeEHvQIIsnTV+lP4ryo+PSWE3LATsbnbkVu3T7xj00tYT3HTP gcG+2uu9EPjzT+QAkJ4LLY0= X-Google-Smtp-Source: APiQypL2SXR1Th06PNPQFbStsIpSJtr4B47c/V/+Evk35d/wUIa+E6RQNCehZ5OzTUMTey27/hI2MQ== X-Received: by 2002:a05:651c:112c:: with SMTP id e12mr3156448ljo.127.1588359645176; Fri, 01 May 2020 12:00:45 -0700 (PDT) Received: from Sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id h28sm2750380lfe.80.2020.05.01.12.00.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 May 2020 12:00:44 -0700 (PDT) Date: Fri, 1 May 2020 22:00:43 +0300 From: Dmitry Kozlyuk To: "Burakov, Anatoly" Cc: dev@dpdk.org, "Dmitry Malloy (MESHCHANINOV)" , Narcisa Ana Maria Vasile , Fady Bader , Tal Shnaiderman , Bruce Richardson Message-ID: <20200501220043.12a08e31@Sovereign> In-Reply-To: <87a53d30-0cf4-2e0d-1336-3420f0e0b6d3@intel.com> References: <20200410164342.1194634-1-dmitry.kozliuk@gmail.com> <20200428235015.2820677-1-dmitry.kozliuk@gmail.com> <20200428235015.2820677-4-dmitry.kozliuk@gmail.com> <87a53d30-0cf4-2e0d-1336-3420f0e0b6d3@intel.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 3/8] eal: introduce memory management wrappers 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Thanks for pointing out the errors, see some comments inline. On 2020-04-29 18:13 GMT+0100 Burakov, Anatoly wrote: > On 29-Apr-20 12:50 AM, Dmitry Kozlyuk wrote: > > + * Reservation size. Must be a multiple of system page size. > > + * @param flags > > + * Reservation options, a combination of eal_mem_reserve_flags. > > + * @returns > > + * Starting address of the reserved area on success, NULL on failure. > > + * Callers must not access this memory until remapping it. > > + */ > > +void *eal_mem_reserve(void *requested_addr, size_t size, int flags); > > Should we also require requested_addr to be page-aligned? Yes. > Also, here and in other added API's, nitpick but our coding style guide > (and the code style in this file) suggests that return value should be > on a separate line, e.g. > > void * > eal_mem_reserve(...); Will follow your advice in v5 to keep the style within this file consistent. However, DPDK Coding Style explicitly says: Unlike function definitions, the function prototypes do not need to place the function return type on a separate line. [snip] > > + > > +int > > +rte_mem_lock(const void *virt, size_t size) > > +{ > > + return mlock(virt, size); > > This call can fail. It should pass errno as rte_errno as well, just like > all other calls from this family. > > Also, if the implementation "may require" page alignment, how about > requiring it unconditionally? IMO even better to document this function as locking all pages crossed by the address region. This would save address checking/alignment at call site and all implementations work this way. Locking memory implies paging system. -- Dmtiry Kozlyuk