From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by dpdk.org (Postfix) with ESMTP id 2F6EE8E74 for ; Fri, 27 Apr 2018 18:30:12 +0200 (CEST) Received: by mail-it0-f54.google.com with SMTP id j186-v6so2511344ita.5 for ; Fri, 27 Apr 2018 09:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hnvwxpvB/Xp2/7fgHGSDIRVA346VgZLWwuSgeAmVrEc=; b=c+W7iy0l5broNEY0HS0vgL87vLSCrxEK5h/1ujLQ479eWK+7zXI22ycBfxsz5TfiF8 oIA5k3DC4q97BOTdCcwKQWW7eKFxKd3zUfiM77TY2bvebbaF10dsDLxEN0S6JKDl5rTL ehzbxdu9G8EfO85oAW27SctjbAuPoYW7siY0E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hnvwxpvB/Xp2/7fgHGSDIRVA346VgZLWwuSgeAmVrEc=; b=VOItcDctdr7+Jx/9CW0dk1it0I4gpaMPzrOy/oztzIakaLaVl58H1cklt+OgvbESCA 0D7qLJyPJgbeiPlV0lHkUnxDdIruTepEcJALdpvHpNPKKOX/oSaPLbzRmrPrG4DjMTaC +GC/QeJhh4Uma2P+Tb2mwvH40qz9TA7hNkWnIR65FYXhANlSybe24CNs1L418qY9w3q+ t+WsuGii8L3oB+Fp8KkUU/rkUYkqTzX7JVTzICLTPYQr0sxRPavgXwR/g5SfgITLR48J D/Q09l1bZ+LmrQOrW3CWiB25IvpEhKMAMsjq/Xv59qqt3rZssH0H4MpNLamr0eBXIwm0 3hxQ== X-Gm-Message-State: ALQs6tCm8Um/iFATICC1HV+pduYGmsiCdkQbBUnXau2m43LmBBjZpyqQ g//ATlA5o2oUV7caz5p072YKohnJjiOaPNG72ntMBA== X-Google-Smtp-Source: AB8JxZohSXVktJIv9acIelqCm9ejHF4qJ1375Y8dqNkBqcawasZMHGcPyB6fpRNg3EOA3ysvEK30sEY08iXE4JbFZ5w= X-Received: by 2002:a24:7801:: with SMTP id p1-v6mr2531691itc.20.1524846611498; Fri, 27 Apr 2018 09:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.140.131 with HTTP; Fri, 27 Apr 2018 09:30:11 -0700 (PDT) In-Reply-To: References: <20180328045120.40098-1-ajit.khaparde@broadcom.com> From: Scott Branden Date: Fri, 27 Apr 2018 09:30:11 -0700 Message-ID: To: Srinath Mannam Cc: "Burakov, Anatoly" , Ajit Khaparde , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] eal: add request to map reserved physical memory 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: , X-List-Received-Date: Fri, 27 Apr 2018 16:30:12 -0000 Hi Anatoly, We'd appreciate your input so we can come to a solution of supporting the necessary memory allocations? On 23 April 2018 at 02:23, Srinath Mannam wrote: > Hi Anatoly, > > Our requirement is, that separate memory segment (speed memory window) > need to be allocated outside huge pages segment. > your thoughts discussed in the link (dynamic memory allocations in > DPDK) are exactly matches with our requirement. > We tried to fit our requirement in the existing memory model with > minimum changes, So we followed this approach. > Memory model in DPDK managed using socket ids. So I also attached new > memory segment to un-used socket which allows to allocate memory using > rte_malloc. > > Please add me in your discussions. I am very much interested to join > in your discussions and contribute in development. > > Please point me the sources in DPDK related to this part of implementation. > > > Thank you. > > > Regards, > > Srinath. > > > On Thu, Apr 12, 2018 at 8:05 PM, Burakov, Anatoly > wrote: > > On 28-Mar-18 5:51 AM, Ajit Khaparde wrote: > >> > >> From: Srinath Mannam > >> > >> Reserved physical memory is requested from kernel > >> and it will be mapped to user space. > >> This memory will be mapped to IOVA using VFIO. > >> And this memory will be provided to SPDK to allocate > >> NVMe CQs. > >> > >> Signed-off-by: Srinath Mannam > >> Signed-off-by: Scott Branden > >> Signed-off-by: Ajit Khaparde > >> --- > > > > > > Hi Srinath, > > > > I've seen this kind of approach implemented before to add additional > memory > > types to DPDK (redefining "unused" socket id's to mean something else), > and > > i don't like it. > > > > What would be better is to design a new API to support different memory > > types. Some groundwork for this was already laid for this release > (switching > > to memseg lists), but more changes will be needed down the line. My ideal > > approach would be to have pluggable memory allocators. I've outlined > some of > > my thoughts on this before [1], you're welcome to join/continue that > > discussion, and make sure whatever comes out of it is going to be useful > for > > all of us :) I was planning to (attempt to) restart that discussion, and > > this seems like as good an opportunity to do that as any other. > > > > Now that the memory hotplug stuff is merged, i'll hopefully get more time > > prototyping. > > > > So, as it is, it's a NACK from me, but let's work together on something > > better :) > > > > [1] http://dpdk.org/ml/archives/dev/2018-February/090937.html > > > > -- > > Thanks, > > Anatoly >