> > On 5/17/2017 3:54 PM, Ananyev, Konstantin wrote: > > Hi Ferruh, > > Please see my comments/questions below. > > Thanks for review. > > > Thanks > > Konstantin > > <...> > > > I think it was discussed already, but I still wonder why rte_flow_item > > can't be used for that approach? > > Missed this one: > > Gaëtan also had same comment, copy-paste from other mail related to my > concerns using rte_flow: > > " > rte_flow is to create flow rules in PMD level, but what this library > aims to collect flow information, independent from if underlying PMD > implemented rte_flow or not. > > So issues with using rte_flow for this use case: > 1- It may not be implemented for all PMDs (including virtual ones). > 2- It may conflict with other rte_flow rules created by user. > 3- It may not gather all information required. (I mean some actions > here, count like ones are easy but rte_flow may not be so flexible to > extract different metrics from flows) > "
I am not talking about actions - I am talking about using rte_flow_item (or similar approach) to allow user to define what flow he likes to have. Then the flow_classify library would use that information to generate the internal structures(/code) it will use to classify the incoming packets. I understand that we might not support all define rte_flow_items straightway, we could start with some limited set and add new ones on a iterative basis. Basically what I am talking about - SW implementation for rte_flow. Konstantin