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 7D0DB2C55 for ; Fri, 4 Aug 2017 11:56:09 +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=MOkGlbg84riruX P1jsB/WTseWUWm1K+XwMCW1uxuidk=; b=NxQe0TSrAL2y1ADI8qHc0Z/fOsksCj 1u8lWW64DlukEIMaARfiIKYR/XIzNUBZg7Tl+zHCSBVhX6JAlcUhoJijtBaQgnBq mlZJiBcf+ckn+F8NTwgqkGgfvYAXx/kaNB4TD51pdTyZZtbigQALk5Cjhyvpdr3V aFGvkY05M8JFw= Received: (qmail 25683 invoked from network); 4 Aug 2017 11:56:09 +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 11:56:09 +0200 To: "De Lara Guarch, Pablo" , "users@dpdk.org" References: <3c73733b-6fe0-7480-9443-0a9f1610400d@ng4t.com> From: Dirk-Holger Lenz Message-ID: <40148ebd-cd42-54f1-d27c-c3d78328e07f@ng4t.com> Date: Fri, 4 Aug 2017 11:56:08 +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: 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 09:56:09 -0000 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