From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <declan.doherty@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 19A7D594B
 for <dev@dpdk.org>; Mon, 27 Jun 2016 10:49:43 +0200 (CEST)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by orsmga103.jf.intel.com with ESMTP; 27 Jun 2016 01:49:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,536,1459839600"; d="scan'208";a="983927339"
Received: from dwdohert-dpdk.ir.intel.com ([163.33.210.152])
 by orsmga001.jf.intel.com with ESMTP; 27 Jun 2016 01:49:41 -0700
To: Xuelin Shi <xuelin.shi@nxp.com>, "dev@dpdk.org" <dev@dpdk.org>
References: <AM2PR04MB08490E72D59A4FDDC46CCF3E8C2D0@AM2PR04MB0849.eurprd04.prod.outlook.com>
From: Declan Doherty <declan.doherty@intel.com>
Message-ID: <40f77853-9eb3-31b6-1149-b64e0fe06360@intel.com>
Date: Mon, 27 Jun 2016 09:44:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <AM2PR04MB08490E72D59A4FDDC46CCF3E8C2D0@AM2PR04MB0849.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] example/l2fwd-crypto: maybe an issue?
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2016 08:49:44 -0000

On 23/06/16 06:30, Xuelin Shi wrote:
> Hi,
>
> Do we have assumption each core will have a separate crypto device?
>
> I have only one crypto device with several queues which are shared by multi-cores.
>
> As I run the l2fwd-crypto, only one cparam is valid and has a  good dev_id.
> The other cparam is crashing.
>
> The reason is the other qconf assoicated with the core is not initializing the dev_id
> since only one crypto device is available.
>
> Thanks,
> Forrest
>

Hey Forrest, yes we made the assumption of one device per core the 
application, we just default to using queue pair 0 of each crypto 
device. It shouldn't be to much work to modify the main() and 
initialize_cryptodevs() to instead allocate a cryptodev and queue pair 
to each set of cparams. If you are using software crypto PMDs such as 
the AESNI_MB PMD the simplest approach is just to create multiple 
devices using the EAL options.

Regards
Declan