OK, a private API is a good short term approach.
12/10/2017 13:41, Rybalchenko, Kirill: > Hi Thomas, > > The reason this feature is needed is to be able to program custom flow types > using a template packet rather than building up a C struct to define the > protocol. This means that users don't have to work on the DPDK internals to > support new flow types that they may be using, but can instead add them > dynamically as part of their application. There are also several customers > who are looking for this feature as part of the 17.11 LTS release. > > This patchset has been out since August and these comments are very late, > with the first objections last week, which we tried to answer. This short > notice doesn't allow us a reasonable amount of time to take them into account. > > However, to address your primary concern, we can implement this using a i40e > private API, so that we are not tying users to FDIR APIs and thus not > blocking the removal of the APIs in time. > > Ideally we would like to use rte_flow but it is based around the idea of > describing packet headers which is significantly different from the proposed > method using template packets. Longer term it may be possible to support this > in rte_flow, we could propose this for discussion in the next release, and if > there is community interest/agreement we can add it. > > We will rework this, in the short term, as a private API, as suggested above, > and then propose an rte_flow API in the longer term. Let us know if you have > any concerns about this. > > Regards, > Kirill. > > > -----Original Message----- > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > Sent: Wednesday 11 October 2017 23:27 > > To: Rybalchenko, Kirill <kirill.rybalche...@intel.com> > > Cc: dev@dpdk.org; Chilikin, Andrey <andrey.chili...@intel.com>; Xing, Beilei > > <beilei.x...@intel.com>; Wu, Jingjing <jingjing...@intel.com>; Yigit, Ferruh > > <ferruh.yi...@intel.com> > > Subject: Re: [dpdk-dev] [PATCH v5 1/4] ethdev: add support for raw flow > > type for flow director > > > > Hi, > > > > 10/10/2017 22:28, Kirill Rybalchenko: > > > Add new structure rte_eth_raw_flow to the union rte_eth_fdir_flow to > > > support filter for raw flow type. > > > > > > Signed-off-by: Kirill Rybalchenko <kirill.rybalche...@intel.com> > > > > This description does not explain why you add this new flow director type. > > It seems you are allowing a new feature to filter custom protocols. > > > > As I replied on v2, you are implementing your new feature with a deprecated > > API (there is a deprecation notice without any deadline). > > It is dangerous because this new use case will be settled on top of a > > fragile > > foundation. And because of these new users, it will be harder to drop this > > API as announced. > > It is also dangerous because you are not trying to implement your feature > > with the new rte_flow API. So we cannot be sure that it will fit for every > > use > > cases. > > If rte_flow is not good enough, we must improve it. > > > > This is my suggestion: > > 1/ Implement this interesting feature with rte_flow. > > 2/ Switch every other use cases to rte_flow. > > 3/ Let's agree on a date to drop the legacy flow director API. > > > > So this is a NACK. > > Please let's move forward.
