[dpdk-dev] [PATCH] test/test: improve dequeue logic for crypto operation
Akhil Goyal
akhil.goyal at nxp.com
Thu Apr 20 12:48:08 CEST 2017
Hi Pablo,
On 4/4/2017 8:41 PM, De Lara Guarch, Pablo wrote:
> Hi Akhil,
>
>> -----Original Message-----
>> From: akhil.goyal at nxp.com [mailto:akhil.goyal at nxp.com]
>> Sent: Monday, April 03, 2017 11:53 AM
>> To: dev at dpdk.org
>> Cc: Doherty, Declan; De Lara Guarch, Pablo; Akhil Goyal
>> Subject: [PATCH] test/test: improve dequeue logic for crypto operation
>>
>> From: Akhil Goyal <akhil.goyal at nxp.com>
>>
>> While enqueue/dequeue operations in test_perf_aes_sha,
>> the underlying implementation may not be able to dequeue
>> the same number of buffers as enqueued. So, it may be
>> necessary to perform more dequeue operations if the gap
>> is more than pparams->burst_size * NUM_MBUF_SETS.
>>
>> Other algos may also need to update the logic if required.
>>
>
> In which way this patch improves the dequeue logic?
> Is it improving the performance somehow? From what I see, it is unlikely that you are going to
> experience the problem, as the internal ring is PERF_NUM_OPS_INFLIGHT, which is 128,
> higher than pparams->burst_size * NUM_MBUF_SETS, which is 256.
> And even if you do meet that problem, then you would be reusing mbufs,
> but that is OK as we are not verifying the output.
>
>
> Thanks,
> Pablo
>
Sorry for the late response. Somehow the reply went to junk in my mail
client and it got missed.
The problem would arise if the underlying implementation cannot dequeue
the same number of ops as were enqueued in a single dequeue command.
Here we have a synchronous calls to enqueue and dequeue in the same
thread, so it may happen that for every enqueue of 32 ops, there are
lesser number of dequeue ops (say 16). There is no thread to dequeue the
left over 16 ops. So the difference would increase slowly and gradually
and the application will run out of buffers.
So we need a mechanism to drain the left over dequeue ops.
Regards,
Akhil
More information about the dev
mailing list