On Thu, Mar 5, 2020 at 10:32 PM Coyle, David <david.co...@intel.com> wrote: > > > > > > > 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.
It is possible with graph architecture where, when application gives two nodes and they are connected then it will be possible to replace to an optimized node at runtime. Having said that, It is NOT good to dedicate the graph as THE MODEL for pipeline. i,e user should need to get both options rather sticking to one model. In that way, it makes sense to not abstract as a graph. > > 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 Yes. Makes sense. >
