Re: [dpdk-users] crypto device 'crypto_aesni_mb' doesn't work in secondary process

[Dirk-Holger Lenz <dirk.lenz@ng4t.com>]

Hello Pablo,

perhaps it was a bit misleading what I told, primary

and secondary processes start with the same arguments

to rte_eal_init() but the secondary processes additionally

have the secondary flag (and different settings for the cores).

Best regards

Dirk


On 08/04/2017 11:56 AM, Dirk-Holger Lenz wrote:
> Hello Pablo,
>
> thanks for the quick answer.
>
> I think that in general resources like pools and devices
>
> need to be created by the primary process. That's
>
> the reason that we implemented a process (our dpdk
>
> process) which creates the resources on request by
>
> applications which start and stop dynamically and which
>
> are working as secondary processes. These applications
>
> even don't know which type of Ethernet device or crypto
>
> device they get, they simply ask for one of them.
>
> For the Ethernet devices and QAT and even for the openssl
>
> this works fine (QAT and i40evf worked in the past, we are
>
> investigating why they are not doing for us with 17.08rc4).
>
> I hope that it is possible to make that working for
>
> aesni_mb as well.
>
> Best regards
>
> Dirk
>
>
> On 08/04/2017 11:37 AM, De Lara Guarch, Pablo wrote:
>> Hi Dirk,
>>
>>> -----Original Message-----
>>> From: users [mailto:users-bounces@dpdk.org] On Behalf Of Dirk-Holger
>>> Lenz
>>> Sent: Friday, August 4, 2017 9:14 AM
>>> To: users@dpdk.org
>>> Subject: [dpdk-users] crypto device 'crypto_aesni_mb' doesn't work in
>>> secondary process
>>>
>>> when the crypto device of type 'crypto_aesni_mb' is
>>>
>>> created in the primary process a secondary process
>>>
>>> crashes when writing into the encryption queue.
>>>
>>> The dequeue function rte_cryptodev_dequeue_burst()
>>>
>>> crashes in flush_mb_mgr() when it tries to access the
>>>
>>> structure of function pointers qp->op_fns.
>>>
>>> The reason is that this structure is allocated by the
>>>
>>> primary process in its memory which is not accessible
>>>
>>> in the secondary process (of course also the function
>>>
>>> pointers are pointing to code of the primary process).
>>>
>> Virtual devices have to be initialized in both processes,
>> as they cannot be shared between them.
>>
>> Thanks,
>> Pablo
>