From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pradeepfn@gmail.com>
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
 [209.85.208.50]) by dpdk.org (Postfix) with ESMTP id 9B7F5231E
 for <users@dpdk.org>; Wed, 29 Aug 2018 22:20:25 +0200 (CEST)
Received: by mail-ed1-f50.google.com with SMTP id k14-v6so4846296edr.13
 for <users@dpdk.org>; Wed, 29 Aug 2018 13:20:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=H8Q8nmLY3iNrWmrtV49iZ6+sDzy9kOoi/ov2OIeia2w=;
 b=gIdAa6Twl5zOA9zxAjiFfn+IrDmaaEfwGI4gEQjUdSCLrZM/W4UBgURrW8DlnP2CXh
 SC7TPZp62VHRs0SJTIdFN8XmEnrCnVtm1lDF5m1RvhgeTP0xjouqQUsGIJQgjT/hIi0C
 NUGnP7orjHnw821Tjv3sK7I6Bl08nbxvHJWxsqfZuLpVnLCw9RFfcayZtnxo7sGhJEa4
 km3TWFIvHnAD6xHE+NSZdAsZLsvpDfsxQxrooXjDonX1YCM7GB9yPKRntjS24sYe1/lw
 yctAFlrf+Q1q6LVpVeGEd3cZRgYCHmLHpsk9cF3WkI606Q22pbnwr/ikE32WGPM/+Ljo
 15xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=H8Q8nmLY3iNrWmrtV49iZ6+sDzy9kOoi/ov2OIeia2w=;
 b=XPvwFM2IkrqL6xoMXTewEchrobdXY2uzagKGqP0A7DbO9aRrmh8lUZF84RasxQqJ9A
 4QyQ/uSU6gURAhpRGO/FBENDdt0+snxssdoQxgFexHr5H84xveuaxfsCHluwuMAwF55J
 iTbyiXH6UJEkoffc9j52uo1nhNUguUpiEHHoOJV1d1ywkmKkkb2rnodO7Qoi6RSdTaNT
 m2GK3cjaox5GKHKBU1y7oorwBQhL8EpeecDEeQdoPfxnEK0TSK/TlSXDIh79PBQoCPST
 G6d/ardg1f8YWXiH1JDLIw82qVIStLeg4m1BqvW2oOKROpgomw58Ix8lMPGVUelF/Jet
 /yfg==
X-Gm-Message-State: APzg51CPdFrEaNwsGqdPlegsqx/J+hecSmYTdj2m080RwGMjpnPa6UZV
 5oBZpDbzbdG5C1Ji/iYklueVEXqWp9nVgBsNtYRtrKLr
X-Google-Smtp-Source: ANB0VdYG5L2ipWM5HqroXQHRN+xRQ46b6/V56aagadEOPzn46WERUgeGHuUGEaub1OCHf9PvNuZYksCs5dVfk54tvIc=
X-Received: by 2002:a50:ba59:: with SMTP id
 25-v6mr9566464eds.214.1535574025165; 
 Wed, 29 Aug 2018 13:20:25 -0700 (PDT)
MIME-Version: 1.0
From: Pradeep Fernando <pradeepfn@gmail.com>
Date: Wed, 29 Aug 2018 16:20:14 -0400
Message-ID: <CAPSEm=YV0sPKtV7YNr72OgaNq8BkqVaNz7XSobTAj-NETz2C4Q@mail.gmail.com>
To: users@dpdk.org
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: [dpdk-users] Question on dpdk memory allocation.
X-BeenThere: users@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK usage discussions <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
 <mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
 <mailto:users-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2018 20:20:25 -0000

Hi all,

My target software stack does not support hugetlbfs, but it supports
huge-paged mmaps. I'm trying to port dpdk huge-page allocate logic to use
mmap based allocations. Hence the below question. I use dpdk 16.11.1  (
slightly old i know :) )

I see that, there is
1. malloc based allocation
2. mmap over hugetlbfs allocation
in
https://github.com/pradeepfn/dpdk/blob/8af51192e564a0331896cd1594a830d92a228845/lib/librte_eal/linuxapp/eal/eal_memory.c#L962

The memory_zone allocator of dpdk uses physically contiguous memory
segments as described in -
https://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#memory-segments-and-memory-zones-memzone
.

This explains why, huge-page mappings are stored in mem-segment structures
in  virtual/physical contiguous blocks. -- after complex mapping/remapping
process.

But how does malloc allocation ( no_hugetlbfs) provides same guarantees. It
is virtually contiguous but not physically contiguous beyond 4KB. How does
malloc allocation works with memzone_allocator in that case?

thanks
--Pradeep