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 527C07CBD for ; Wed, 13 Sep 2017 15:20:45 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E26B620EF3; Wed, 13 Sep 2017 09:20:44 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 13 Sep 2017 09:20:44 -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=uAldagbr+nh/84d IaxbShCTyIlc/Zxon9XTMBUZvrWk=; b=B11mSwlgcLSDbF8MCTLPibwoE39qgtc opVYrVFZGq6B71LKooOfXtsroyOkqYpiHgX8WOLeAsNKMSyKBUN/V5OqZ+tB9h0y KtBgnzByQbMm1FOrl9JDFWoY/4Y7czpLm/vqljyX6l3wQkRpLoz+/w8Z+zKW8L3X OKYeHnz3jkyU= 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=uAldagbr+nh/84dIaxbShCTyIlc/Zxon9XTMBUZvrWk=; b=FwLVCGWI 9n3foYMZyBlkQsorcvon7UmK+nRNVNz7l3WjHS97PL0Bq+uAvD4+CWX4slUftsHJ twLqyelKmcPJbY5WUwc5yJjiknmMb1TCxS2EocK4X2XlZy9ny+X0ZhWC4gbE9MLm VMFDBIMujMw5O65cLWp+lRijJ1i5YIc/1EU2tDyTEmb8/a3VM3dsNewQK20l61oh emDecD1k9CLW2d5rSCY+PdkZmMCb8RcDAQJIwCKG+q61Owc/1oW6Puke74nvXyDT sbouXrS4i/fCPdZGmOzYw6+LR6+zutfjDLgNF+18aAGmvchc3JQWv8v3Sxn2Nm9A KIt6moL2q6ZmZA== X-ME-Sender: X-Sasl-enc: 41tLIL0gj52aI7IvMUiTKln5CePc6ySLmTicD/iLRJQz 1505308844 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 970A924A6C; Wed, 13 Sep 2017 09:20:44 -0400 (EDT) From: Thomas Monjalon To: "Ananyev, Konstantin" , stephen@networkplumber.org Cc: dev@dpdk.org, Shahaf Shuler Date: Wed, 13 Sep 2017 15:20:43 +0200 Message-ID: <12544923.ZPp1eIik3W@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772584F24A738@irsmsx105.ger.corp.intel.com> References: <1868308.cPa78Soq0s@xps> <2601191342CEEE43887BDE71AB9772584F24A738@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Wed, 13 Sep 2017 13:20:45 -0000 13/09/2017 14:56, Ananyev, Konstantin: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 13/09/2017 13:16, Shahaf Shuler: > > > Wednesday, September 13, 2017 12:28 PM, Thomas Monjalon: > > > > I still think we must streamline ethdev API instead of complexifying. > > > > We should drop the big "configure everything" and configure offloads one by > > > > one, and per queue (the finer grain). > > > > > > The issue is, that there is some functionality which cannot be achieved when configuring offload per queue. > > > For example - vlan filter on intel NICs. The PF can set it even without creating a single queue, in order to enable it for the VFs. > > > > As it is a device-specific - not documented - side effect, > > I won't consider it. > > Hmm, are you saying that if there are gaps in our documentation it ok to break things? If it is not documented, we did not explicitly agree on it. How an application knows that setting a PF settings will have effect on related VFs? > Once again - you suggest to break existing functionality without providing any > alternative way to support it. It is not a functionality, it is a side effect. What happens if a VF changes this settings? error? Is this error documented? > Surely I will NACK such proposal. Nothing to nack, I agree with v3 which doesn't break ixgbe VLAN settings. 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. > > However I understand it may be better to be able to configure > > per-port offloads with a dedicated per-port function. > > I agree with the approach of the v3 of this series. > > > > Let me give my overview of offloads: > > > > We have simple offloads which are configured by just setting a flag. > > The same flag can be set per-port or per-queue. > > This offload can be set before starting or on the fly. > > We currently have no generic way to set it on the fly. > > > > We have also more complicate offloads which require more configuration. > > They are set with the rte_flow API. > > They can be per-port, per-queue, on the fly or not (AFAIK). > > > > I think we must discuss "on the fly" capability. > > It requires probably to set up simple offloads (flags) with a dedicated > > function instead of using "configure" and "queue_setup" functions. > > This new capability can be implemented in a different series. > > > > Opinions?