From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <adrien.mazarguil@6wind.com> Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id B16F94F90 for <dev@dpdk.org>; Mon, 27 Aug 2018 17:14:19 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id u12-v6so12675396wrr.4 for <dev@dpdk.org>; Mon, 27 Aug 2018 08:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FGfa/v4vGHlqtf4nalFXN+z3wzjV3MA/yVviLWGK+tw=; b=kCDLgy/p5kBXAWRf9QQ10e2bbrd6ouPO4DfiEHjZDQOr2fr8awJ8UkLuFCyV/Jixfc sQWoiMUM+Q119fb4CClKYPXrmwp1k23cdG+w5fB9tPszrbOPvMUUqAna55javV0HHcEI ApAw+15ihyM87qoNml7PIe9M6DMpqdbPneqV5+fTDLqaHoGfQ7mPLfXWGcz8d/oreimI GYLE3UDUb96v98JzxrdtIKVfIWz4X42mpcGimtmVNERY7GrT/geVUiOlrBUPbJkOAVPx 2RR0eBDRUP6VF7VdYxnFsWVYXnuzlZDsguPzVEai4cwl12dcCagkEFvh50/mjGPVj01l Zukw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FGfa/v4vGHlqtf4nalFXN+z3wzjV3MA/yVviLWGK+tw=; b=rfhBKfVT4TDTgbDngR5Z6wRwjA8fw7TSvXZCNd9wvxkdI3JYeASn0hUNxDTiVV7lsN 3TfxcPBchhySSjTNWlC5b3hvXnnPkPet/y2ykSop3cLW87D+UP5YJnnFo1UAE/ExcTOZ Zaf2xEoDSBEXQ8pBhv/5bjZFVlw8nBMD1KlqDNRr40+0Yy7oQlM0EsxSQ9WhU53pTqNH 9l2+N/APRi4WEK7KcIhSE9ux5fyLEJGRHdcr4jqVJqD6Vxa1eGphA3k40lwVmW/LLRK9 Dv2/01gbDtvMTRyZLTYq26hirVcc0D8ubDZrRkWzC9gSAtKqJSgVjTiXgZ4xshU/USW+ JTUQ== X-Gm-Message-State: APzg51Bh7IurgUYk4dlbwLh3IWEuAYDTxZU/cl0fC5EAWuFgyrvYGILu yGLMJP+coHr0/ttv6BTgP36bqA== X-Google-Smtp-Source: ANB0VdaUqoksbnHONoyTBmL89EBrs61CCWTlZ8AfHYUEoEsVyAXZuW4dcTTT8hwCLwwXqaefAhIyYQ== X-Received: by 2002:adf:a11c:: with SMTP id o28-v6mr9131851wro.169.1535382859401; Mon, 27 Aug 2018 08:14:19 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id s2-v6sm14009307wrn.83.2018.08.27.08.14.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 08:14:18 -0700 (PDT) Date: Mon, 27 Aug 2018 17:14:02 +0200 From: Adrien Mazarguil <adrien.mazarguil@6wind.com> To: Ferruh Yigit <ferruh.yigit@intel.com> Cc: dev@dpdk.org Message-ID: <20180827151402.GF3695@6wind.com> References: <cover.1507193185.git.adrien.mazarguil@6wind.com> <20180803132032.29038-1-adrien.mazarguil@6wind.com> <30a6f2d0-1f0c-c549-9fd1-7e1782990943@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30a6f2d0-1f0c-c549-9fd1-7e1782990943@intel.com> Subject: Re: [dpdk-dev] [PATCH v2 0/7] ethdev: add flow API object converter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 15:14:19 -0000 On Thu, Aug 23, 2018 at 02:48:37PM +0100, Ferruh Yigit wrote: > On 8/3/2018 2:36 PM, Adrien Mazarguil wrote: > > This is a follow up to the "Flow API helpers enhancements" series submitted > > almost a year ago [1]. The new title is due to the reduced scope of this > > version. > > > > rte_flow_conv() is a flexible replacement to rte_flow_copy(), itself a > > temporary solution pending something better [2]. It replaces a lot of > > duplicated code found in testpmd and removes some of the maintenance burden > > that developers tend to forget (me included) when modifying pattern > > item or actions (updating app/test-pmd/config.c to be clear). > > > > This series was unearthed in order to complete the implementation of > > RTE_FLOW_ACTION_TYPE_ENCAP_(VXLAN|NVGRE) in testpmd [3] without having to > > duplicate existing code once again. > > > > See individual patches for specific changes in this version. > > > > v2 changes: > > > > - rte_flow_copy() is kept, albeit deprecated, no API/ABI impact. > > - Updated bonding PMD. > > - No more automatic generation of rte_flow_conv.h. > > > > [1] https://mails.dpdk.org/archives/dev/2017-October/077551.html > > [2] https://mails.dpdk.org/archives/dev/2017-July/070492.html > > [3] Currently the command-line parser (cmdline_flow.c) is aware of these > > actions, however config.c isn't. Flow rules with such actions cannot > > be created and cannot be validated with PMDs that implement them. > > > > Adrien Mazarguil (7): > > ethdev: add flow API object converter > > ethdev: add flow API item/action name conversion > > app/testpmd: rely on flow API conversion function > > net/failsafe: switch to flow API object conversion function > > net/bonding: switch to flow API object conversion function > > ethdev: deprecate rte_flow_copy function > > ethdev: add missing item/actions to flow object converter > > Patch needs to be rebased to target v18.11 (in map file), Right, will do it for v3. > and indeed new APIs > (rte_flow_conv) needs to be experimental. This is what I did at first. Problem is that experimental APIs cannot be used in internal code without triggering a compilation error unless ALLOW_EXPERIMENTAL_API is defined (bonding cannot rely on an API marked as experimental). Since this series reimplements rte_flow_copy() as a wrapper to rte_flow_conv(), I thought it didn't make sense for internal code to keep using the former either. Considering this, shall I add -DDALLOW_EXPERIMENTAL_API to bonding PMD or keep things not experimental? > And needs to remove deprecation notice in this patchset. Doesn't it make sense to deprecate this function immediately after providing a replacement on top of which it is reimplemented? Users end up using the new function whether they want it or not. I don't think maintaining the old duplicated code around is the right thing to do either. > Also do you think does make sense to announce this change in release notes? I'm not sure it's worth a release note. It's a rather obscure helper function part of rte_flow. We didn't do it for rte_flow_copy() for instance. Please confirm if you think it's needed. > Apart from above, any volunteer for reviewing actual implementation? I hope Gaetan will take a look, he added rte_flow_copy() after all :) -- Adrien Mazarguil 6WIND