[P4] Fwd: Re: [dpdk-users] Run-to-completion or Pipe-line for QAT PMD in DPDK

[Sándor Laki]

A teljes thread itt érhető el: 
http://mails.dpdk.org/archives/users/2019-January/003877.html

Üdv.

S

2019.01.18. 14:18 keltezéssel, Sándor Laki írta:
>
> Ez relevánsnak tűnik a crypto szempontjából és érdemes figyelembe 
> venni a szívások elkerülése végett.
>
> Üdv.
> S
>
>
>
> -------- Továbbított üzenet --------
> Tárgy: 	Re: [dpdk-users] Run-to-completion or Pipe-line for QAT PMD in 
> DPDK
> Dátum: 	Fri, 18 Jan 2019 13:13:43 +0000
> Feladó: 	Trahe, Fiona <fiona.trahe at intel.com>
> Címzett: 	Changchun Zhang <changchun.zhang at oracle.com>, users at dpdk.org 
> <users at dpdk.org>
> CC: 	Trahe, Fiona <fiona.trahe at intel.com>
>
>
>
> Hi Alex,
>
>> -----Original Message-----
>> From: users [mailto:users-bounces at dpdk.org] On Behalf Of Changchun Zhang
>> Sent: Thursday, January 17, 2019 11:01 PM
>> To: users at dpdk.org
>> Subject: [dpdk-users] Run-to-completion or Pipe-line for QAT PMD in DPDK
>>
>> Hi,
>>
>>
>>
>> I have user question on using the QAT device in the DPDK.
>>
>> In the real design, after calling enqueuer_burst() on the specified 
>> queue pair at one of the lcore,
>> usually which one is usually done?
>>
>> 1. should we do run-to-completion to call dequeuer_burst() waiting 
>> for the device finishing the
>> crypto operation,
>>
>> 2. or should we do pipe-line, in which we return right after 
>> enqueuer_burst() and release the CPU.
>> And call dequeuer_burst() on other thread function?
>>
>> Option 1 is more like synchronous and can be seen on all the DPDK 
>> crypto examples, while option 2 is
>> asynchronous which I have never seen in any reference design if I 
>> missed anything.
> [Fiona] Option 2 is not possible with QAT - the dequeue must be called 
> in the same thread as the enqueue. This is
> optimised without atomics for best performance - if this is a problem 
> let us know. However best performance is not quite using option 1 and 
> not a synchronous blocking method. If you enqueue and then go straight 
> to dequeue, you're not getting the best advantage from the
> cycles freed up by offloading. i.e. best to enqueue a burst, then go 
> do some other work, like maybe collecting more requests for next 
> enqueue or other processing, then dequeue. Take and process whatever 
> ops are dequeued - this
> will not necessarily match up with the number you've enqueued - 
> depends on how quickly you call the dequeue.
> Don't wait until all the enqueued ops are dequeued before enqueuing 
> the next batch.
> SO it's asynchronous. But in the same thread.
> You'll get best throughput when you keep the input filled up so the 
> device has operations to work on and
> regularly dequeue a burst. Dequeuing too often will waste cycles in 
> the overhead calling the API, dequeuing too
> slowly will cause the device to back up. Ideally tune for your 
> application to find the sweet spot in
> between these 2 extremes.
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Mentes a vírusoktól. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> P4 mailing list
> P4 at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/p4

-- 
Sándor Laki, PhD
Assistant professor
Department of Information Systems
Eötvös Loránd University
Pázmány Péter stny. 1/C
H-1117, Budapest, Hungary
Room 2.506
Web: http://lakis.web.elte.hu
Phone: +36 1 372 2869 / 8477
Cell: +36 70 374 2646



---
Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/p4/attachments/20190124/725beb93/attachment.html>