Re: [dpdk-dev] [RFC 0/4] cpu-crypto API choices

2019-11-20 Thread Jerin Jacob
On Mon, Nov 18, 2019 at 5:27 PM Ananyev, Konstantin wrote: > > Hi Jerin, Hi Konstantin, > > Thanks for input, my answers inline. > Other guys - please provide your input. > Thanks > Konstantin > > > > Originally both SW and HW crypto PMDs use rte_crypot_op based API to > > > process the crypto w

Re: [dpdk-dev] [RFC 0/4] cpu-crypto API choices

2019-11-18 Thread Ananyev, Konstantin
Hi Jerin, Thanks for input, my answers inline. Other guys - please provide your input. Thanks Konstantin > > Originally both SW and HW crypto PMDs use rte_crypot_op based API to > > process the crypto workload asynchronously. This way provides uniformity > > to both PMD types, but also introduce

Re: [dpdk-dev] [RFC 0/4] cpu-crypto API choices

2019-11-13 Thread Jerin Jacob
On Wed, Nov 6, 2019 at 12:11 AM Konstantin Ananyev wrote: > > Originally both SW and HW crypto PMDs use rte_crypot_op based API to > process the crypto workload asynchronously. This way provides uniformity > to both PMD types, but also introduce unnecessary performance penalty to > SW PMDs that ha

[dpdk-dev] [RFC 0/4] cpu-crypto API choices

2019-11-05 Thread Konstantin Ananyev
Originally both SW and HW crypto PMDs use rte_crypot_op based API to process the crypto workload asynchronously. This way provides uniformity to both PMD types, but also introduce unnecessary performance penalty to SW PMDs that have to "simulate" HW async behavior (crypto-ops enqueue/dequeue, HW ad