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 BAED3A00BE; Fri, 12 Jun 2020 22:24:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3F9D61BF53; Fri, 12 Jun 2020 22:24:35 +0200 (CEST) Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by dpdk.org (Postfix) with ESMTP id 6A9CA322C for ; Fri, 12 Jun 2020 22:24:33 +0200 (CEST) Received: by mail-lf1-f65.google.com with SMTP id x22so6180205lfd.4 for ; Fri, 12 Jun 2020 13:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wAeX30bykr0mb9gFH5HKnUhU8I/bx27/HRai1d07uGU=; b=J4VvBRwK9ueKeNTc8U3JOF9yEyNU6AiePDUbkYFhzEB9DY+ZQv2yIlsjYtfqoShJUR ANJULYsjdZuPw+ZMIyb4RwDNTk67Jvx0SB7sxzSYac5bnYKrS0hkK5FclhD9b35K90Q0 dTM4Be6suUcFnn61xrp3K045rSqgUrxRPVwSbrqlucPSbTd68/8qdmpBMK8FUVS630ho Qk05g+szm+RBIPddp7iifx/S+F79vMTphZ3hEcjRCJus1xcSKQB+ZtCTk2ZMrXgbLieC jquKwlAs7nHlX8FBuAG8QNZZJBZOUP0neLiYxDwFaB7VeFk8DNMYW2fk0mcdCdB/lVZA CVKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wAeX30bykr0mb9gFH5HKnUhU8I/bx27/HRai1d07uGU=; b=hA1rzeVA+LK2C3QQDfnWU9q1rF50bJFzxAWMLauZEcrJa5tIusKbTXsNud4k+Ftwzp cfd0Uepz3VIHoQl8aJ4nFl/PL6JqeRrmW5QMI9KZEG72sRCDKv/JMGPWwmvu7vNaKpb6 V9IMjKGVnstzAuzZSWBXCNDjbTFTQwC42UIa83v4rflAuXO+SKUWLHTOXr21uQ3rXhwV k4iNpIVpivQxrGgNVcULT+dGeN/BtAP6AlGlDcVE95qEWZopDSYr4HrfNfI9mVSEAojr M1hVgVIpqXS+pUy8G40Tc/xz8goJniguU+2qN7nZJWTPlC9MhsONgxE6TgrXh5v2MNsh 8/Tw== X-Gm-Message-State: AOAM532hLq7Ba/S39260BKYOoDriU4ezJ6OBXNBKho1KJJ8GlyCvqniZ V5IHrjTJFEReuPt80b2K+KnZQbnXKmYjCHOKsaY= X-Google-Smtp-Source: ABdhPJwAiAmkJ1gAy20VlkI12nDrx6nu8NNqppJVdPjG9+TtfK9QQoRVT1Dvl2vR3DOsmvqbopKIzyXLuT0NjRuM6Oo= X-Received: by 2002:a05:6512:15c:: with SMTP id m28mr7680285lfo.126.1591993472828; Fri, 12 Jun 2020 13:24:32 -0700 (PDT) MIME-Version: 1.0 References: <20200608074153.29611-1-dmitry.kozliuk@gmail.com> <1737252.Ab5UzTuNQf@thomas> <8606444.FnLyTyo8xH@thomas> In-Reply-To: <8606444.FnLyTyo8xH@thomas> From: Dmitry Kozliuk Date: Fri, 12 Jun 2020 23:24:20 +0300 Message-ID: To: Thomas Monjalon Cc: dpdk-dev , Dmitry Malloy , Narcisa Ana Maria Vasile , Fady Bader , Tal Shnaiderman , Anatoly Burakov , Bruce Richardson , Ray Kinsella , Neil Horman Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v8 03/11] 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" > > > Not sure if they are in DPDK scope, apart from rte_mem_lock, which > > generalizes rte_mem_lock_page already in rte_memory.h. What may be > typical > > use cases for data-plane apps? I can see testpmd using mmap for > allocating > > external memory (because of possible use of hugepages), does it need > these > > functions exposed? > > There is a chance the application needs such functions > for another part of its dataplane. Such reasoning can justify any API. DPDK needs compatibility layers, but collecting and providing them is not the goal of the kit. I can only think of using mmap in data plane as a high-performance IPC with non-DPDK management app. Please add the @internal tag in doxygen to make the status clear. > OK. > > > > +#include > > > > > > I think we should find a better file name for these wrappers. > > > "EAL memory" means DPDK memory allocator in my mind. > > > We need a file name which is about OS-independent wrappers, > > > or libc wrappers. > > > What about rte_libc_mem.h? rte_mem_os.h? something else? > > > > See above, but anyway, "libc" is non-generic. > > Why libc is not generic? > It means nothing on Windows. Also, mmap has little to do with libc. Which file name can it be? > Your rte_mem_os.h sounds good, except internal header better be rte_eal_mem_os.h. Alternative: rte_eal_paging.h. >