From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ud15.udmedia.de (ud15.udmedia.de [194.117.254.55]) by dpdk.org (Postfix) with ESMTP id DA5292BC9 for ; Fri, 4 Aug 2017 12:11:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=ng4t.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=k1; bh=XQov4t8oDdCVz4 8+RaoPYmDU9UZIJgh+Ad2MrWmS0A8=; b=YVkG3rATbt0L1okr6gAFxdCpApzRc5 yfF2Nlq1ytIv9rftpWY5KLQ9t6uoHu7escFK0WVbNQP6bAF/DawN8+c+bpHBDOcV +Taa6cYjMYjaNVuqkBut/49Ds8+FUTqWHJEeIS6TlszoC5FmsRaK9IVXXHISYAA/ 8NkYuZ/6EuFpM= Received: (qmail 28831 invoked from network); 4 Aug 2017 12:11:37 +0200 Received: from unknown (HELO ?IPv6:2a02:8106:1:f900:2e0:4cff:fe68:158b?) (ud15?2p5@2a02:8106:1:f900:2e0:4cff:fe68:158b) by mail.ud15.udmedia.de with ESMTPSA (ECDHE-RSA-AES128-GCM-SHA256 encrypted, authenticated); 4 Aug 2017 12:11:37 +0200 To: "De Lara Guarch, Pablo" , "users@dpdk.org" References: <3c73733b-6fe0-7480-9443-0a9f1610400d@ng4t.com> <40148ebd-cd42-54f1-d27c-c3d78328e07f@ng4t.com> From: Dirk-Holger Lenz Message-ID: <8c812689-3e9b-46d7-2249-dcca2d0cb7bf@ng4t.com> Date: Fri, 4 Aug 2017 12:11:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <40148ebd-cd42-54f1-d27c-c3d78328e07f@ng4t.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] crypto device 'crypto_aesni_mb' doesn't work in secondary process X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 10:11:38 -0000 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 >