> > > > Having an API that could be used by parallel hardware does make sense, > > but the DPDK already has multiple packet processing infrastructure pieces. > > > > I would rather the DPDK converge on one widely used, robust and tested > > packet method. Rather than the current "choose your poison or roll > > your own" which is what we have now. The proposed graph seems to be > the best so far. > > I agree. Even I thought of saying graph can do this, as, it has higher > abstraction and runtime chaining support, but then I thought it will be self > markering. > David could you check https://www.mail- > archive.com/dev@dpdk.org/msg156318.html > If this one only focusing crypto dev + compressdev, What if we have ethdev > + compressdev + security device in the future. > graph has higher abstraction so it can accommodate ANY chaining > requirements. i.e AESNI-MB + QAT will go as a separate node
[DC] We have looked at the graph node library and we don't feel that using graph is the correct solution for what we are trying to solve here. We want to combine 2 or more packet processing functions on a packet into a single operation on a single device, be that an optimized software library such as AESNI MB or a hardware accelerator such as QAT So yes, these 2 packet processing functions could be a node (or nodes) within a graph. However they would still need to be combined together at some point to be processed on the device as a single operation. Our new proposal is to use rte_rawdev to access the devices and we propose to add a "multi-function" interface which the application and rawdev PMDs will use to create the xform chains, sessions and op chains. The full details on this new proposal have been sent to you in a separate post and we feel it addresses the concerns of the original rte_accelerator API In the future, rawdev enqueue/dequeue calls using this multi-function interface could potentially be configured as a node within a packet processing graph
