From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 6E03C137C for ; Mon, 28 Aug 2017 12:57:15 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A49562142B; Mon, 28 Aug 2017 06:57:14 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 28 Aug 2017 06:57:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=YBWLUJOP0glgIJ9 cg4XyAUgEPOG0PbJt5Vt1bYMx2kM=; b=DRMhW7C0J12Uqbf7PB9OQVZyiI8cKcj 16BC/5ZBsbe13LmekOVaOxv/AaGu2H42CFsG9ev79H9lug0m5syAxBqjQ0fyOP0q R0JkQaW0xjrj4WST2OQI9ceIOUQ7PZF6hywvZD/Ug8YDnLI/cL2aofct2GX3YfLM bFgo1EPYdGw4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=YBWLUJOP0glgIJ9cg4XyAUgEPOG0PbJt5Vt1bYMx2kM=; b=GTiWGNdv V9WyHkZfCJvghK2/wT89uCESRXZplVkwLmWkEAvglWO8Ssi+ZJOk3KqzUGSJGISS JBSGm0ONa08fooHJuAPuumIiLs9K2m/PnXfX2PeDSyxtQtNfXd5i6xNo0ZQ3EwVK SQln+qvor4tD6MqeqmdXA0KmqnxsJTKeqHb5HgzLe93wchdfn3GfAnvJsad1tZdB phKge24WpgcJWIaocnIFcdnb7M6e9zO45JXGs0g7QnlViUUzfvnUnfHKzw6+TuGf iCNaUNvjEizvceJymH7C893kLkPPdLYLwAWZvxfgFP5fZkjZdkdHJ/4P/SIWrOGQ eTzqVwHX/QBbQg== X-ME-Sender: X-Sasl-enc: T5n57/iFfdCjpFOdkAXKilVgxi+nV83hWppshkxtSarG 1503917834 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4B7922444E; Mon, 28 Aug 2017 06:57:14 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: dev@dpdk.org, Shahaf Shuler Date: Mon, 28 Aug 2017 12:57:13 +0200 Message-ID: <4428518.N1h1dqvDrp@xps> In-Reply-To: <20170828050007.GA10095@jerin> References: <20170828050007.GA10095@jerin> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH 0/4] ethdev new offloads API 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: Mon, 28 Aug 2017 10:57:15 -0000 28/08/2017 07:00, Jerin Jacob: > From: Shahaf Shuler > > Friday, August 25, 2017 1:32 PM, Jerin Jacob: > > > > > > > > The new API does not have an equivalent for the below Tx flags: > > > > > > > > * ETH_TXQ_FLAGS_NOREFCOUNT > > > > * ETH_TXQ_FLAGS_NOMULTMEMP > > > > > > IMO, it make sense to keep those flags as PMD optimization if an application > > > does not need reference count and multi mempool in the application. > > > As example, An non trivial application like l3fwd does not need both of them. > > > > The l3fwd application is yet another simple example from DPDK tree. Am not sure that a complete vRouter/vSwitch implementation is with the same characteristics. > > But not all dpdk applications are complete vRouter/vSwitch implementation. > > > Moreover, I think the fact there is an application which is able to use it is not enough. IMO there needs to be some basic functionality always provided by the PMDs and not controlled by flags. > > For example, let's say we have an application which always sends the mbufs with the same ol_flags, or even with the same length. > > Does ETH_TXQ_FLAGS_NOREFCOUNT comes in same category like mbuf->ol_flags? > > > Will it make sense to add more flags to control it? > > Will it makes sense to run RFC2544 benchmark with testpmd io forwarding with those flags? > > > > If the answer is yes, maybe those flags (and others to follow) belong on different location on ethdev. However for sure they are not offloads. > > I am not sure about the reason for opting out mempool related flags. > In the context of HW assisted external mempool managers, Enabling reference count is an offload > from Ethernet device. > For example, with external HW assisted mempool, ethdev driver needs to > have different way of forming TXQ descriptor in case if reference count > is enabled(as, in the case of HW assisted mempool managers, bu default, > HW frees the packet on send) > > I am fine with moving the flags to some where else if it is make sense to you.But > from PMD optimization perspective, I think it is important have these flags. Why not. Please Jerin, could you work on moving these settings in a new API? We can have a function to enable such optimizations. However I am not sure ethdev is the right place as these hints apply to any mbuf. Other related question: what happens if other libraries manipulate these mbufs with special optimization hints? Should they be aware?