Hi Kirill,

On Thu, Oct 12, 2017 at 11:41:50AM +0000, Rybalchenko, Kirill wrote:
> 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.

I am not trying to push for its integration through rte_flow at this stage
and I don't mind the chosen PMD-specific approach, I'm just curious about
the reasons that made it hard to implement as a RTE_FLOW_ITEM_RAW thing?
(e.g. a rule with a pattern that only contains one or several such items)

Please have a look at the rte_flow_item_raw structure in rte_flow.h, tell me
what's missing in there and I'll take it into account during the next
overhaul. Thanks in advance for your feedback.

-- 
Adrien Mazarguil
6WIND

Reply via email to