[dpdk-dev] [RFC 17.08] Flow classification library

Ferruh Yigit ferruh.yigit at intel.com
Tue May 9 15:37:46 CEST 2017


On 5/6/2017 3:04 PM, Morten Brørup wrote:
> Carthago delenda est: Again with the callbacks... why not just let the application call the library's processing functions where appropriate. The hook+callback design pattern tends to impose a specific framework (or order of execution) on the DPDK user, rather than just being a stand-alone library offering some functions. DPDK is not a stack; and one of the reasons we are moving our firmware away from Linux is to avoid being enforced a specific order of processing the packets (through a whole bunch of hooks everywhere in the stack).
> 

I agree on callbacks usage, but I can't see the other option for this case.

This is for additional functionality to get flow information, while
packet processing happens. So with don't want this functionality to be
available always or to be part of the processing. And this data requires
each packet to be processed, what can be the "library's processing
function" alternative can be?

> Maybe I missed the point of this library, so bear with me if my example is stupid:
> 
> Consider a NAT router application. Does this library support processing ingress packets in the outside->inside direction after they have been processed by the NAT engine? Or how about IP fragments after passing the reassembly engine?

Implementation is not there, we have packet information, and I guess
with more processing of packets, the proper flow information can be
created for various cases. But my concern is if this should be in DPDK?

I was thinking to provide API to the application to give the flow
information with a specific key, and rest of the processing can be done
in upper layer, who calls these APIs.

> 
> 
> Generally, a generic flow processing library would be great; but such a library would need to support flow processing applications, not just byte counting. Four key functions would be required: 1. Identify which flow a packet belongs to (or "not found"), 2. Create a flow, 3. Destroy a flow, and 4. Iterate through flows (e.g. for aging or listing purposes).

Agreed, and where should this be?
Part of DPDK, or DPDK providing some APIs to enable this kind of library
on top of DPDK?

> 
> 
> Med venlig hilsen / kind regards
> - Morten Brørup
> 
> 
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John
>> Sent: Wednesday, May 3, 2017 11:16 AM
>> To: dev at dpdk.org
>> Cc: Tahhan, Maryam; Gaëtan Rivet; Yigit, Ferruh
>> Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library
>>
>>
>>
>>> -----Original Message-----
>>> From: Gaëtan Rivet [mailto:gaetan.rivet at 6wind.com]
>>> Sent: Friday, April 21, 2017 11:38 AM
>>> To: Yigit, Ferruh <ferruh.yigit at intel.com>
>>> Cc: dev at dpdk.org; Mcnamara, John <john.mcnamara at intel.com>; Tahhan,
>>> Maryam <maryam.tahhan at intel.com>
>>> Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library
>>>
>>
>>
>> Any other opinions on this proposal?
>>
>> (Original email: http://dpdk.org/ml/archives/dev/2017-April/064443.html)
>>
>> John
> 



More information about the dev mailing list