On 5/9/2017 8:24 PM, Morten Brørup wrote: >> -----Original Message----- >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit >> Sent: Tuesday, May 9, 2017 3:38 PM >> To: Morten Brørup; Mcnamara, John; dev@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. >
Agreed, I will send an updated RFC, thanks. > >>> 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 >
