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

[Morten Brørup]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Tuesday, May 9, 2017 3:38 PM
> To: Morten Brørup; Mcnamara, John; dev at dpdk.org
> Cc: Tahhan, Maryam; Gaëtan Rivet
> Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library
> 
> 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?
> 

As I understand it, your library (and other libraries using the same hook) calls a function for each packet via the PMD RX hook. Why not just let the application call this function (i.e. the callback function) wherever the application developer thinks it is appropriate? If the application calls it as the first thing after rte_eth_rx_burst(), the result will probably be the same as the current hook+callback design.


> > 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?
> 

Part of DPDK, so it will take advantage of any offload features provided by the advanced NICs. Most network security appliances are flow based, not packet based, so I thought your RFC intended to add flow support beyond RSS hashing to DPDK 17.08.

Our StraightShaper product is flow based and stateful for each flow. As a simplified example, consider a web server implemented using DPDK... It must get all the packets related to the HTTP request, regardless how these packets arrive (possibly fragmented, possibly via multiple interfaces through multipath routing or link aggregation, etc.). Your current library does not support this, so a flow based product like ours cannot use your library. But it might still be perfectly viable for IPFIX for simple L2/L3 forwarding products.


Med venlig hilsen / kind regards
- Morten Brørup