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).
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? 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). Med venlig hilsen / kind regards - Morten Brørup > -----Original Message----- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Mcnamara, John > Sent: Wednesday, May 3, 2017 11:16 AM > To: dev@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.ri...@6wind.com] > > Sent: Friday, April 21, 2017 11:38 AM > > To: Yigit, Ferruh <ferruh.yi...@intel.com> > > Cc: dev@dpdk.org; Mcnamara, John <john.mcnam...@intel.com>; Tahhan, > > Maryam <maryam.tah...@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
