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
