From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id C8469374 for ; Fri, 30 Jun 2017 16:12:50 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id i127so47537783wma.0 for ; Fri, 30 Jun 2017 07:12:50 -0700 (PDT) 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=tAQIaPmJkp8HZoPc5FC4UHqE07DqtoMV/Q/7uMPq3kw=; b=qZGtDy7QrURm5EOzFuKO8M9PWaB3S7vRvbL8E3a7/vxYXTI9fhwXUrmcDoFINXoa3F JndSbixZZbrYQy3JAyagJVCiT6NJpbzw+T3T3aziTuHPO1LwJf176xFPfBK5Pruf3RWp P5985xhF7gYHVg+RaDhzw5MIZJwZi8lrU6OIp7vfpK2z71RPYthZxfKTjArMdBTjaY1s yytYOmCGYYeqFv9gPre3I9fUnEE154p7S98JZt4qmEcEHK+mja9w3JzwDnl7eKSGwN/W TUId8rHsRahxOakitq98+2z9W/DuuOytj+8pyJHqWs/lWt0dDaXNzp0gZKTm826+AcZH xMhA== 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=tAQIaPmJkp8HZoPc5FC4UHqE07DqtoMV/Q/7uMPq3kw=; b=j5TFC9vfz8MmcNmTQtJ5+iz+cSRnUpvUQlwy58VGO6oHPeeeoqfju9QrI+gA9Wy45d /03QV2NI8esnqAsAThZLwOVrJG5b1YjptVndJxzWo/SWNgKzhkI7WrA9GjclkQg2UGvJ jxvZHlOuqWnFsLESgatgA8heOI/LWHUZoBUL2x9h41Cw3+cz+QzyXtNJNLLWcj3rxgon hAGeLBWEjqGbLHjw1ftqdeJAxqutII9PyU22HQcvq+x48VgxdpdM5N2hP6h8VxLDTmjH e5IzZaEp73ACa7lc+Yqxt/LyRL6Xk+FssrU9c8pfdresSxKVkQR+ZFFUkSKm3jTdu2D+ WmPQ== X-Gm-Message-State: AKS2vOw1Rh+fqAJW1yKKcFPT4/DGOm/kLwFpK1dsnkn5itx9gqH4VBus tYCQFktdvLEcqgGp X-Received: by 10.28.238.219 with SMTP id j88mr4172456wmi.33.1498831970531; Fri, 30 Jun 2017 07:12:50 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id l12sm9585443wrc.46.2017.06.30.07.12.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 30 Jun 2017 07:12:50 -0700 (PDT) Date: Fri, 30 Jun 2017 16:12:46 +0200 From: Olivier Matz To: Jerin Jacob Cc: Hemant Agrawal , Santosh Shukla , dev@dpdk.org Message-ID: <20170630161246.2af345e0@platinum> In-Reply-To: <20170620140413.GA16157@jerin> References: <20170601080559.10684-1-santosh.shukla@caviumnetworks.com> <20170619130152.GA29671@jerin> <2e78b067-0a4d-a40d-799e-6137972bd7a9@nxp.com> <20170620140413.GA16157@jerin> 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] [PATCH 0/2] Allow application set mempool handle 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, 30 Jun 2017 14:12:51 -0000 Hi, On Tue, 20 Jun 2017 19:34:15 +0530, Jerin Jacob wrote: > -----Original Message----- > > Date: Tue, 20 Jun 2017 16:07:17 +0530 > > From: Hemant Agrawal > > To: Jerin Jacob > > CC: Santosh Shukla , > > olivier.matz@6wind.com, dev@dpdk.org > > Subject: Re: [PATCH 0/2] Allow application set mempool handle > > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 > > Thunderbird/45.8.0 > > > > On 6/19/2017 6:31 PM, Jerin Jacob wrote: > > > -----Original Message----- > > > > Date: Mon, 19 Jun 2017 17:22:46 +0530 > > > > From: Hemant Agrawal > > > > To: Santosh Shukla , > > > > olivier.matz@6wind.com, dev@dpdk.org > > > > CC: jerin.jacob@caviumnetworks.com > > > > Subject: Re: [PATCH 0/2] Allow application set mempool handle > > > > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 > > > > Thunderbird/45.8.0 > > > > > > > > On 6/1/2017 1:35 PM, Santosh Shukla wrote: > > > > > Some platform can have two different NICs for example external PCI Intel > > > > > 40G card and Integrated NIC like vNIC/octeontx/dpaa2. > > > > > > > > > > Both NICs like to use their preferred pool e.g. external PCI card/ vNIC's > > > > > preferred pool would be the ring based pool and octeontx/dpaa2 preferred would > > > > > be ext-mempools. > > > > > Right now, Framework doesn't support such case. Only one pool can be > > > > > used across two different NIC's. For that, user has to statically set > > > > > CONFIG_RTE_MEMPOOL_DEFAULT_OPS=. > > > > > > > > > > So proposing two approaches: > > > > > Patch 1) Introducing eal option --pkt-mempool= > > > > > Patch 2) Introducing ethdev API called _get_preferred_pool(), where PMD driver > > > > > gets a chance to advertise their pool capability to the application. And based > > > > > on that hint- application creates pools for that driver. > > > > If the system is having more than one heterogeneous ethernet device with > > different mempool, the application has to create different mempool for each > > of the ethernet device. > > > > However, let's take a case > > As system has a DPAA2 eth device, which only work with dpaa2 mempools. > > dpaa2 ethdev will return dpaa2 mempool as preferred handler. > > > System also detect a standard PCI NIC, which can work with any software > > mempool (e.g ring_mp_mc) or with dpaa2 mempool. Given the preference, PCI > > NIC will have preferred as software mempool. > > how the application will choose between these, if it want to create only one > > mempool? > > We need add some policy in common code to help application to choose > in case if application interested in creating in one pool for > heterogeneous cases. It is more of application problem, ethdev can > return the preferred handler, let application choose interested in one. > ethdev is depended on the specific mempool not any other object. > > We will provide option 1(eal argument based one) as one policy.More sophisticated > policies we need add in application. > > > > Or, how the scheme will work if the application want to create only one > > mempool? > > option 1 (eal argument based) or we need to change the application to > choose from available ethdev count and its preferred mempool handler. I also think the approach in this patchset is not that bad: - The first step is to allow the user to specify the mempool dynamically (eal arg). One thing I don't really like is to have a mempool-related argument inside eal. It would be better if eal could provide a framework so that each libraries (ex: mbuf, mempool) can register their argument that could be changed through the command line or trough an API. Without this, it introduces a sort of dependency between eal and mempool, which I don't think is sane. - The second step is to be able to ask to the eth devices which mempool they prefer. If there is only one kind of port, it's quite easy. As suggested, more complexity could go in the application if required, or some helpers could be provided in the future. I'm sending some comments as replies to the patches.