From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f179.google.com (mail-wj0-f179.google.com [209.85.210.179]) by dpdk.org (Postfix) with ESMTP id AB37011D9 for ; Tue, 31 Jan 2017 11:32:01 +0100 (CET) Received: by mail-wj0-f179.google.com with SMTP id b20so12622064wjs.2 for ; Tue, 31 Jan 2017 02:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=C6p7vPe77CADBNDlvEy8eKV2t1HS0cWMWvy2AxPbJx0=; b=WBfSK2FK7Pb3Jiz/cDs7fIkY1tVdvQRRo451tr4RzeWW9D+9G3eGN/gdwnr9t7XhZy QoFvBOjlbAlJEmmLsTjZdVBzK/hjQav6hXxc6atrNlDMWlf9TscdRhxBTDVs+bXomb9U OzfoLGPVqqHSov5nz/6FVgG6ttfeez/A72iMbIg/RRQXjxXMV3R/NuDQvpD4A/XtaKwq Fj0jTKB6D18p2cVShBh/po1RFuZQ6Js0w7JrOFkdMYeQx2T42u1IK/zl2fShPJmIzmMk /OWPpLnnpUd/zWYC6OXJccxvmtxBSzhHIeJjjgn9YMTv/xXdjroCHT9ssjq19QZtA3HP S+2Q== 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=C6p7vPe77CADBNDlvEy8eKV2t1HS0cWMWvy2AxPbJx0=; b=F/00yjiCdOnHW0+aOUP+4oUUDjEC7Sx/pLYsagz9a+It7m67zAu4e0rfgl0WhGXWyx RffEczo6LxPeCSyiaPQgPjE4pnwD3r1kiAY5FZQq7/oRHKVouzpwcBWaicVACOvwVtDX QCurqKzBB/eN5nnSPv69I60jU0rU1mEafyqfvuwsawBhZUsnOKEx4Eqs9BPIpWv9olQl Jl76/7who1EtNqabyxtReO01b+utEi37A9dR4m8xDNLUzMu6vbOec7C0WB3ZgtQR9zmT FFcxBNp5C139pfmSoxfOGqBqfbVGFMea3G1z8Qv6x7v32PhFEg9R6cBuqJ1Jx5cS1xiS pl6A== X-Gm-Message-State: AIkVDXIqJjnbzzXcy0DPu0DXFDvR8O0nUFhpGeAef8GFYJE8E5vC63hwIP28YmsW2X2Si/j3 X-Received: by 10.223.162.133 with SMTP id s5mr15192269wra.157.1485858721417; Tue, 31 Jan 2017 02:32:01 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id n13sm27573240wrn.40.2017.01.31.02.32.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 31 Jan 2017 02:32:01 -0800 (PST) Date: Tue, 31 Jan 2017 11:31:58 +0100 From: Olivier Matz To: Santosh Shukla Cc: , , , Message-ID: <20170131113158.25f74dc3@platinum> In-Reply-To: <20170116153022.GA8179@santosh-Latitude-E5530-non-vPro> References: <1474292567-21912-1-git-send-email-olivier.matz@6wind.com> <1474292567-21912-3-git-send-email-olivier.matz@6wind.com> <20170116153022.GA8179@santosh-Latitude-E5530-non-vPro> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 2/7] mbuf: use helper to create the pool 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: Tue, 31 Jan 2017 10:32:01 -0000 Hi Santosh, On Mon, 16 Jan 2017 21:00:37 +0530, Santosh Shukla wrote: > Hi Olivier, > > > On Mon, Sep 19, 2016 at 03:42:42PM +0200, Olivier Matz wrote: > > When possible, replace the uses of rte_mempool_create() with > > the helper provided in librte_mbuf: rte_pktmbuf_pool_create(). > > > > This is the preferred way to create a mbuf pool. > > > > By the way, akso update the documentation. > > > > I am working on ext-mempool pmd driver for cvm soc. > So interested in this thread. > > Wondering why this thread not followed up, is it > because we don't want to deprecate rte_mempool_create()? > Or if we want to then in which release you are targeting. It seems that the RFC patchset was not the proper way to fix the issue. On the other hand, this particular patch should be integrated, as highlighted by Hemant too. Thanks for reminding it. > Beside that some high level comment - > - Your changeset missing mempool test application i.e.. > test_mempool.c/ test_mempool_perf.c; Do you plan to accomodate them? As answered in the other thread, I think there is nothing to change in test_mempool*.c, since this patch is just about mbuf pools. > - ext-mempool does not necessarily need MBUF_CACHE_SIZE. Let HW-mngr > to directly handover buffer to application; Rather caching same > buffer per core way. It will save some cycles. What do you think? It's still possible to set the cache size to 0. In that case, it will directly call rte_mempool_ops_dequeue_bulk(). But, given the function call to ops->dequeue() and the few tests, it is probably faster to use the cache, even with a fast hw allocation. > - I figured out that ext-mempool API not mapping well on cvm hw; For > few reason: > Lets say application calls: > rte_pktmbuf_pool_create() > --> rte_mempool_create_empty() > --> rte_mempool_ops_byname() > --> rte_mempool_populate_default() > -->> rte_mempool_ops_alloc() > --> ext-mempool-specific-pool-create handle > [...] I'm answering in the other thread. Thanks, Olivier