From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; Fri, 1 May 2020 21:00:45 +0200 (CEST)
Received: by mail-lj1-f194.google.com with SMTP id b2so3502173ljp.4
for <dev@dpdk.org>; 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 <dmitry.kozliuk@gmail.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, "Dmitry Malloy (MESHCHANINOV)" <dmitrym@microsoft.com>,
Narcisa Ana Maria Vasile <Narcisa.Vasile@microsoft.com>, Fady Bader
<fady@mellanox.com>, Tal Shnaiderman <talshn@mellanox.com>, Bruce
Richardson <bruce.richardson@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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:
<snip>
> > + * 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