From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 15E831B18C for ; Mon, 18 Sep 2017 13:32:31 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1033920D5F; Mon, 18 Sep 2017 07:32:30 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 18 Sep 2017 07:32:30 -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=bzM8RAHcY9TpASY N0H18bl1wAtOQvLo3jyJ99oB9duI=; b=BWWMQN6S2V3L5JlXCqtI7nWhxJZwH/j 9bSO7vaocAbgVLWy9j0Y7Ycb+4e2J1zTrLkDOp4GNdqhbSj5uTIOFbC60fDgj/JU X4nwzQCNjcG5VXOZ/vfDdX550BljvrZAO+NAeRqo7hWiYIHIAZoHpL7pIM/UaeXK yRLios3nVQN8= 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=bzM8RAHcY9TpASYN0H18bl1wAtOQvLo3jyJ99oB9duI=; b=p+0MzPCA TT5qskRMRsltbPZklL7/GPAtas2tyrEDwUAcxjSufQh94fa5Yg+rLVRlhLHdz3gn ovaSF9+x3AJvUYbIFH8Whn0b15dtiL+AuBGIXX3Rh15GonsUs163LyMcFhWDA2uc 6iVMaHj2zgf3G7ZZgOa3D9bL7hFrGeBscOuNnWyONq20jL1B/vuk5WDOOc3y3KHN mObMxSLJBosuDzBypRM58ozyoJvQCCxQyxHqiw6JneBattuYVxBgZIoITDQFH5td f5oOoQfEww+7jau0QY7BllJM5CNkt4xaknkgKQc9oTucXT8nx1hAPz9tzBntZg87 AJfB4DQugKGjBw== X-ME-Sender: X-Sasl-enc: FVd4E3Jq7ohftMH1zJAOLreSUcHoXp0OjUlS170zrt4w 1505734349 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BE53A7FA8B; Mon, 18 Sep 2017 07:32:29 -0400 (EDT) From: Thomas Monjalon To: "Ananyev, Konstantin" , "Richardson, Bruce" Cc: "stephen@networkplumber.org" , dev@dpdk.org, Shahaf Shuler Date: Mon, 18 Sep 2017 13:32:29 +0200 Message-ID: <32037584.9VqYmpDC01@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772584F24BFE7@irsmsx105.ger.corp.intel.com> References: <20170918110456.GB15516@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772584F24BFE7@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: Mon, 18 Sep 2017 11:32:31 -0000 18/09/2017 13:11, Ananyev, Konstantin: > From: Richardson, Bruce > > On Mon, Sep 18, 2017 at 11:57:03AM +0100, Ananyev, Konstantin wrote: > > > From: Richardson, Bruce > > > > 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. [...] [technical details skipped] [...] > > > > > > If so, then it seems reasonable to me. > > > > > > > > > > Good, thank you > > > > > > > > > > > > > > Sorry I'm a bit late to the review, but the above suggestion of separate > > > > APIs for enabling offloads, seems much better than passing in the flags > > > > in structures to the existing calls. From what I see all later revisions > > > > of this patchset still use the existing flags parameter to setup calls > > > > method. > > > > > > > > Some advantages that I see of the separate APIs: > > > > * allows some settings to be set before start, and others afterwards, > > > > with an appropriate return value if dynamic config not supported. > > > > * we can get fine grained error reporting from these - the set calls can > > > > all return the mask indicating what offloads could not be applied - > > > > zero means all ok, 1 means a problem with that setting. This may be > > > > easier for the app to use than feature discovery in some cases. > > > > * for those PMDs which support configuration at a per-queue level, it > > > > can allow the user to specify the per-port settings as a default, and > > > > then override that value at the queue level, if you just want one queue > > > > different from the rest. > > > > > > I think we all in favor to have a separate API here. > > > Though from the discussion we had at latest TB, I am not sure it is doable > > > in 17.11 timeframe. > > > > Ok, so does that imply no change in this release, and that the existing > > set is to be ignored? > > No, my understanding the current plan is to go forward with Shahaf patches, > and then apply another one (new set/get API) on top of them. Yes, it is what we agreed (hope to see it in minutes). If someone can do these new patches in 17.11 timeframe, it's great! Bruce, do you want to make it a try?