From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) by dpdk.org (Postfix) with ESMTP id 7A4E12FDD for ; Tue, 4 Apr 2017 08:58:42 +0200 (CEST) Received: by mail-wr0-f173.google.com with SMTP id w11so199055709wrc.3 for ; Mon, 03 Apr 2017 23:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=VV9PAdMPuv0d3UW25p1w829Qopj3+gPZeTFSmZfW4s4=; b=pxNr1aDNLaAu4j6ThJJGhMfkbYWgP2H4PFbHtcd+C1F+lq/73qXOrrr8j+1sMv9AtE fov4j7Y1FWpVXLitc1MWvkpIZ19lHeLG72P2vSdKbbFUlgao8Cy7o4cqEeZbt8OUGQ2d xf5jQvieXG2gUzUgS/J5GxrzZLS3fMTnsZGnvoXt6BUAvaFSTo7MXTpX9Zu0qDS3xN5N QHbpZ0lIzy1YAFxQOrnvGbI/gyx6+uaMWd0yGoxggOevacBA60cgOGaSaaM7kvyxkl0j RDGVJmP8lpaUn3WZx+WdXTnZhjFVpbKEXQLtkut7CEI/rZTGKsYcNLw4gT3B2cGlU5nb 5fzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=VV9PAdMPuv0d3UW25p1w829Qopj3+gPZeTFSmZfW4s4=; b=IWnwjwpyx8FacLR5C2Evcm83yj75NW5WMoUf0UE1oJ5bk1CEg7aBMhv5M6DtwzU3fb YZb5PCI2a+2VoYTg75qionYG2mBJPu1xekF6Ve9/WudmpWcgLbUuYLn7/3C3PFe7K2PI HdYU4qu6nerK+p+F+AvbUPOgBFMikntP+qGGxVTUkUnJ/48cJGn6mPwcyoSJYWencVwH 8zBAGY8UyGSYp4tGdJJIue8LKH7D3NsTZ/CHZgPMlGJoWb4XtupaI7gd4JHOVRv7AOto 3mE607H2qi5qyiighJR0G7isCq2dZEgIGSF6qSADmL82aw8DDvGTjA0kZiO8vv2N9Q4E n1XA== X-Gm-Message-State: AFeK/H2LFFdoeUkMItpULOTmTWwV1Wnt5VK8RaMYdiMkvW5JvW1/cZ8zdFhqr+abp63dOJIQ X-Received: by 10.28.154.7 with SMTP id c7mr13339373wme.119.1491289121940; Mon, 03 Apr 2017 23:58:41 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id m90sm17181938wmi.34.2017.04.03.23.58.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 23:58:41 -0700 (PDT) From: Thomas Monjalon To: Hemant Agrawal Cc: dev@dpdk.org, Olivier Matz , shreyansh.jain@nxp.com Date: Tue, 04 Apr 2017 08:58:40 +0200 Message-ID: <6998997.LVRpf6MECD@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3c18f62b-252b-5184-07e0-0b4cb136d467@nxp.com> References: <1491210729-9755-1-git-send-email-hemant.agrawal@nxp.com> <20170403171958.5ff2f3ab@platinum> <3c18f62b-252b-5184-07e0-0b4cb136d467@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] mempool: introduce flag to indicate hw mempool 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, 04 Apr 2017 06:58:42 -0000 2017-04-04 11:05, Hemant Agrawal: > Hi Olivier, > > On 4/3/2017 8:49 PM, Olivier Matz wrote: > > Hi Hemant, > > > > On Mon, 3 Apr 2017 14:42:09 +0530, Hemant Agrawal wrote: > >> Hardware pools need to distinguish between buffers allocated using > >> software or hardware backed pools. > >> > >> Some HW NICs may choose to autonomously free the pickets during > >> transmit if the packet is from HW pool. While they should not do > >> it for software backed pools. > >> > >> Such flag would also help when multiple pools are being handled by > >> a PMD, saving costly compare operations for any internal marker. > >> > >> Signed-off-by: Hemant Agrawal > >> --- > >> lib/librte_mempool/rte_mempool.h | 5 +++++ > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h > >> index 991feaa..91dbd21 100644 > >> --- a/lib/librte_mempool/rte_mempool.h > >> +++ b/lib/librte_mempool/rte_mempool.h > >> @@ -263,6 +263,11 @@ struct rte_mempool { > >> #define MEMPOOL_F_SC_GET 0x0008 /**< Default get is "single-consumer".*/ > >> #define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */ > >> #define MEMPOOL_F_NO_PHYS_CONTIG 0x0020 /**< Don't need physically contiguous objs. */ > >> +#define MEMPOOL_F_HW_POOL (1 << ((sizeof(int) * 8) - 1)) /**< Internal: > >> + * Hardware offloaded pool. This information may be used by the > >> + * NIC or other hw. Some NICs autonomously free the HW backed pool packets. */ > >> + > >> +/**< Don't need physically contiguous objs. */ > >> > >> /** > >> * @internal When debug is enabled, store some statistics. > > > > > > One thing is still not clear to me: in your driver, you check this flag: > > - if it is unset, you reallocate a packet from your hw pool, you copy > > some metadata, and you send it to the hw. > > - if it is set, you assume that you can call mempool_to_bpid(mp) and directly > > send it to the hw. > > > > I think this is not correct. The test you want to do in your driver is: > > "is it the pool that I registered for my hardware"? > > It is not: > > "is it a hardware managed pool?". > > I think what you are doing here prevents to use 2 hardware mempools > > at the same time, because they would all have this flag, and mempool_to_bpid() > > would probably crash. > > > > No, I am only trying to differentiate between hw and software pool > packets. I don't see a possiblity of having two different orthogonal hw > mempool types working in the system. At any point of time when you are > running DPDK on a particular type of hardware, you will only have *one* > type of hardware backed pools in your implementation. The number of > mempool instances may be many but all will able to work with > mempool_to_bpid(). No you could have different HW mempools on one system. Please imagine PCI NICs which provide a mempool. (other argument: never say never ;) > The application may send packet allocated from a *ring* pool instead of > using "hw" pool. > > So, it is sufficient to just check if the pool is offloaded or not. HW > can take care of all the supported pools. > > > Instead, can't you just compare the mempool pointer to a value stored internally > > in the driver? > > There can be more than one instance of mempool, the driver is capable of > supporting multiple hw offloaded mempools. Each dpaa2 PMD port may have > different mempool instance registered. > > So, pointer comparison is not practical unless I start storing the > mempool driver pointer. Is it difficult to store this pointer?