From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 5E84C1AEEB for ; Mon, 18 Sep 2017 13:04:23 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 04:04:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,412,1500966000"; d="scan'208";a="901295951" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.24]) by FMSMGA003.fm.intel.com with SMTP; 18 Sep 2017 04:04:19 -0700 Received: by (sSMTP sendmail emulation); Mon, 18 Sep 2017 12:04:18 +0100 Date: Mon, 18 Sep 2017 12:04:18 +0100 From: Bruce Richardson To: "Ananyev, Konstantin" Cc: Thomas Monjalon , "stephen@networkplumber.org" , "dev@dpdk.org" , Shahaf Shuler Message-ID: <20170918110417.GA15516@bricha3-MOBL3.ger.corp.intel.com> References: <12544923.ZPp1eIik3W@xps> <2601191342CEEE43887BDE71AB9772584F24AA9D@irsmsx105.ger.corp.intel.com> <6120098.SpXJOblVKo@xps> <20170918103154.GA13172@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772584F24BFBF@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772584F24BFBF@irsmsx105.ger.corp.intel.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the 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, 18 Sep 2017 11:04:23 -0000 On Mon, Sep 18, 2017 at 11:57:03AM +0100, Ananyev, Konstantin wrote: > > > > -----Original Message----- > > From: Richardson, Bruce > > Sent: Monday, September 18, 2017 11:32 AM > > To: Thomas Monjalon > > Cc: Ananyev, Konstantin ; stephen@networkplumber.org; dev@dpdk.org; Shahaf Shuler > > > > Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API > > > > On Thu, Sep 14, 2017 at 10:02:26AM +0200, Thomas Monjalon wrote: > > > 13/09/2017 23:42, Ananyev, Konstantin: > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > 13/09/2017 14:56, Ananyev, Konstantin: > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > Konstantin, I would like your opinion about the proposal below. > > > > > It is about making on the fly configuration more generic. > > > > > You say it is possible to configure VLAN on the fly, > > > > > and I think we should make it possible for other offload features. > > > > > > > > It would be a good thing, but I don't think it is possible for all offloads. > > > > For some of them you still have to stop the queue(port) first. > > > > > > > > Also I am not sure what exactly do you propose? > > > > Is that something like that: > > > > - wipe existing offload bitfileds from rte_eth_rxmode (already done by Shahaf) > > > > - Instead of uint64_t offloads inside both rte_eth_rxmode and te_eth_rxconf > > > > Introduce new functions: > > > > > > > > int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask); > > > > int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t offload_mask); > > Would be useful to have a valid mask here, to indicate what bits to use. > > That way, you can adjust one bit without worrying about what other bits > > you may change in the process. There are probably apps out there that > > just want to toggle a single bit on, and off, at runtime while ignoring > > others. > > Alternatively, we can have set/unset functions which enable/disable > > offloads, based on the mask. > > My thought was that people would do: > > uint64_t offload = rte_eth_get_port_rx_offload(port); > offload |= RX_OFFLOAD_X; > offload &= ~RX_OFFLOAD_Y; > rte_eth_set_port_rx_offload(port, offload); > > In that case, I think we don't really need a mask. > Sure, that can work, I'm not concerned either way. Overall, I think my slight preference would be to have set/unset, enable/disable functions to make it clear what is happening, rather than having to worry about the complete set each time. uint64_t rte_eth_port_rx_offload_enable(port_id, offload_mask) uint64_t rte_eth_port_rx_offload_disable(port_id, offload_mask) each returning the bits failing (or bits changed if you like, but I prefer bits failing as return value, since it means 0 == no_error). /Bruce