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 3062CA04F8; Sun, 22 Dec 2019 16:33:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1984C397D; Sun, 22 Dec 2019 16:33:17 +0100 (CET) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by dpdk.org (Postfix) with ESMTP id C2C351C01; Sun, 22 Dec 2019 16:33:14 +0100 (CET) Received: by mail-ot1-f43.google.com with SMTP id r27so18709146otc.8; Sun, 22 Dec 2019 07:33:14 -0800 (PST) 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; bh=ouMI3uN1o6lJfPeP5is2Bxef0S5YVFeg5MARDybLOZM=; b=jZa9A2qIe5tAgCNMNT80e2MSkhJZJKBPuk6Uk3M8P8QXBMrnjUn0MU0rUF4hHwLqn1 EC3vn4hDY4S/Mqbt4diAe6Fvb8dJOPtiY+BFdwjjt0BxCahaflhjippwwNogyIiEIz/Z gHAZhZQNR8dHHU1pDNF4XxZjHadUeZVy7nHD0VnwRSLTt1cCD8zQ1ePNplGlEKaVsIvO mmndpL+37ukYXGiXi983RS4K7Gyf/qzcaF5cxiLH5+nHeWIe+umgVDXxWqzVT8nLXPqF 2qiNxLULe9O4+NVnJN1Zxuz003le3m0tpmlIAdXBSoOXcbYXSgx3PnzcD9g4GDVj3hIs kv+w== 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; bh=ouMI3uN1o6lJfPeP5is2Bxef0S5YVFeg5MARDybLOZM=; b=eY8c848lG2O/OCz3AnjZnW+0MS0iGMTHE3cUiiJ8xuuqBqgpa1JNeyx3+wHJuz2rKU W2oXGbUIDJ2HfAlmpNEfRFA6eqo1rn8dQUzJ8gvXBdW5pDkiFl/+hoFLP7i+eGg4iY/i bD0LW3DSTLmewzKN6qpWbrEx+UKF2q30C0nITTqN/41g+p8qX9X90cjtZbbr7vGtav2R AemKcDOLx+7Hb5WmZyn7osrB9r1wPpONIJxzuD92Yqggt7jjGVM91pby8GcuEn5rp2/f YAEWZ/b1cyH5Vow6/UWUpmSkRG05ANEdAAAkw5l89/k37+mNSNGSEYk9eyZxWDPklJiW ASzg== X-Gm-Message-State: APjAAAULs9VexEmRUCPsJfJnzuTyn3o3CsLs45xeE0woQ7LMFsMD+fZv p6G0yU0vmjz9lV63YWqP3rWSjEsD5Z5ZS51aGdiSy7T5bVs= X-Google-Smtp-Source: APXvYqwFvTN+/sqcrHjh3Cm7BmqYXOXBtlI2ssgRhL9Z13cyozNXIyqrbjKkttXyV6lG3Qc2NPLxVdXhJruQ71Lia94= X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr26625329otr.82.1577028793720; Sun, 22 Dec 2019 07:33:13 -0800 (PST) MIME-Version: 1.0 References: <20191219130620.30ade5fa@hermes.lan> In-Reply-To: From: Byonggon Chun Date: Mon, 23 Dec 2019 00:33:04 +0900 Message-ID: To: dev@dpdk.org, users@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [dpdk-users] Should ''shmget" not be used to consume hugepages in DPDK? 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" x-posting to dev mailing list. Hi all. I'm Kubernetes contributors and I'm working to make container isolation of hugepages that allows us to set hugepages limit per container cgroup. (At this point, limits are set on pod level cgroup even though we asked hugepages as the container level resource) I tore down testPMD and some parts of DPDK lib and I got a question after i found there is no usage of "shmget" in DPDK. My question is that Should "shmget" not be used to consume hugepages in DPDK? And here is following questions: 1) If we don't have to use "shmget", Why? Does it affect performance? 2) If I use "shmget" to get hugepages, should I call "mlock" syscall for it? For more details, as I know there are three ways to consume hugepages in kubernetes. 1) shmget with SHM_HUGETLB 2) mmap with hugetlbs filebacking 3) mmap with MAP_ANONYMOUS | MAP_HUGETLB And I found that testPMD calls mlock syscall when it maps an anonymous hugepages or external allocated hugepages.https://github.com/DPDK/dpdk/blob/924e55fb340623f03fdf2ff7fbcfd78819d1db25/app/test-pmd/testpmd.c#L896https://github.com/DPDK/dpdk/blob/924e55fb340623f03fdf2ff7fbcfd78819d1db25/app/test-pmd/testpmd.c#L916 Thanks. On Fri, Dec 20, 2019 at 9:42 PM Byonggon Chun wrote: > > shmget is a legacy Unix API and there is no point in using it. > > Yeah, I agree with it, > I also prefer to use mmap with hugetlbfs in a DPDK container. > > The reason why I started this mail thread is some DPDK users still use > shmget to consume hugepages, and I just wanted to find a good rationale to > convince them to use mmap. > > But, at this point, I have only one rationale : shmget is a legacy UINIX > API. > > On Fri, Dec 20, 2019 at 6:06 AM Stephen Hemminger < > stephen@networkplumber.org> wrote: > >> On Fri, 20 Dec 2019 01:23:50 +0900 >> Byonggon Chun wrote: >> >> > Hi all. >> > I'm Kubernetes contributors and I'm working to make container isolation >> of >> > hugepages that allows us to set hugepages limit per container cgroup. >> > (At this point, limits are set on pod level cgroup even though we asked >> > hugepages as the container level resource) >> > >> > I tore down testPMD and some parts of DPDK lib and I got a question >> after i >> > found there is no usage of "shmget" in DPDK. >> > >> > My question is that Should "shmget" not be used to consume hugepages in >> > DPDK? >> > And here is following questions: >> > 1) If we don't have to use "shmget", Why? Does it affect performance? >> > 2) If I use "shmget" to get hugepages, should I call "mlock" syscall >> for it? >> > >> > For more details, as I know there are three ways to consume hugepages in >> > kubernetes. >> > 1) shmget with SHM_HUGETLB >> > 2) mmap with hugetlbs filebacking >> > 3) mmap with MAP_ANONYMOUS | MAP_HUGETLB >> > >> > And I found that testPMD calls mlock syscall when it maps an anonymous >> > hugepages or external allocated hugepages. >> > >> https://github.com/DPDK/dpdk/blob/924e55fb340623f03fdf2ff7fbcfd78819d1db25/app/test-pmd/testpmd.c#L896 >> > >> https://github.com/DPDK/dpdk/blob/924e55fb340623f03fdf2ff7fbcfd78819d1db25/app/test-pmd/testpmd.c#L916 >> > >> > Thanks. >> >> shmget is a legacy Unix API and there is no point in using it. >> For new applications libhugetlbfs is preferable. >> >