From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A282211D4 for ; Tue, 29 Aug 2017 14:50:21 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 05:50:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,444,1498546800"; d="scan'208";a="123646590" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga004.jf.intel.com with ESMTP; 29 Aug 2017 05:50:20 -0700 To: Shahaf Shuler , dev@dpdk.org References: From: Ferruh Yigit Message-ID: <81b3f08a-da63-6b5f-7592-d41521c395e7@intel.com> Date: Tue, 29 Aug 2017 13:50:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC PATCH 2/4] ethdev: introduce Rx queue 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: Tue, 29 Aug 2017 12:50:23 -0000 On 8/7/2017 11:54 AM, Shahaf Shuler wrote: > Introduce a new API to configure Rx offloads. > > The new API will re-use existing DEV_RX_OFFLOAD_* flags > to enable the different offloads. This will ease the process > of adding a new Rx offloads, as no ABI breakage is involved. > In addition, the offload configuration can be done per queue, > instead of per port. If a device doesn't have capability to set the offload per queue how should it behave, I think it is good to define this. > > The Rx queue offload API can be used only with devices which advertize > the RTE_ETH_DEV_RXQ_OFFLOAD capability. > > The old Rx offloads API is kept for the meanwhile, in order to enable a > smooth transition for PMDs and application to the new API. > > Signed-off-by: Shahaf Shuler <...> > @@ -357,7 +357,14 @@ struct rte_eth_rxmode { > jumbo_frame : 1, /**< Jumbo Frame Receipt enable. */ > hw_strip_crc : 1, /**< Enable CRC stripping by hardware. */ > enable_scatter : 1, /**< Enable scatter packets rx handler */ > - enable_lro : 1; /**< Enable LRO */ > + enable_lro : 1, /**< Enable LRO */ > + ignore : 1; what do you think making this variable more verbose, like "ignore_rx_offloads" "dev_conf.rxmode.ignore" doesn't say on its own what is ignored. > + /** > + * When set the rxmode offloads should be ignored, > + * instead the Rx offloads will be set on rte_eth_rxq_conf. > + * This bit is temporary till rxmode Rx offloads API will > + * be deprecated. > + */ > }; <...> > +/** Device supports the rte_eth_rxq_conf offloads API */ > +#define RTE_ETH_DEV_RXQ_OFFLOAD 0x0010 Since this is temporary flag and with current implementation this is local to library, should we put this into public header? Later when all PMDs implemented this new method and we want to remove the flag, can we remove them or do we have to keep them reserved for any conflict for further new values? I guess this should be part of missing pmd-ethdev interface file (rte_ethdev_pmd.h ?). > > /** > * @internal >