From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore Date: Tue, 1 Aug 2017 10:17:59 +0200 Message-ID: <20170801081759.GO11154@bidouze.vm.6wind.com> References: <9fb283ed-223d-713e-4722-21278f4cfd6e@ng4t.com> <2197043.BsW04uu1lT@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Dirk-Holger Lenz , users@dpdk.org, dev@dpdk.org To: Thomas Monjalon Return-path: Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) by dpdk.org (Postfix) with ESMTP id 0C478910F for ; Tue, 1 Aug 2017 10:18:09 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id v105so3601991wrb.0 for ; Tue, 01 Aug 2017 01:18:09 -0700 (PDT) Content-Disposition: inline In-Reply-To: <2197043.BsW04uu1lT@xps> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, On Mon, Jul 31, 2017 at 10:23:50PM +0200, Thomas Monjalon wrote: > 31/07/2017 16:58, Dirk-Holger Lenz: > > If dpdk is built with 'CONFIG_RTE_BUILD_SHARED_LIB=y' then > > using the vdev feature (args: e.g. -c 3 -n 4 --vdev="crypto_openssl") > > the rte_eal_init() returns 'ERROR: failed to parse device "crypto_openssl"'. > > It looks to me that rte_eal_devargs_add() calling rte_eal_devargs_parse() > > is trying to check the device name before the shared libraries are read > > and the internal data arrays are setup. > > Yes, you're right: eal_parse_args() is called before eal_plugins_init(). > The fix is not small: we should split the args parsing to parse the > device arguments after loading shared libraries. > > It is a release blocker. I saw that yesterday, tried to investigate a bit. I have currently an issue when launching testpmd when BUILD_SHARED_LIB=y. Mbufs fail to be allocated. I was not able to find the root cause for this. Anyway, I guess there are two possible solutions: - Delayed device validation - Earlier plugins init Thomas you seem to propose the first one, I agree that it will probably be a little involved to implement but I guess it's feasible in time. However, I don't yet understand why the second one is not possible from the get-go. It makes sense in any case that the system should be stabilized as soon as possible - i.e. that underlying subsystems such as plugins and capabilities are loaded first to expose a stable set of capabilities to any subsequent initializations. So, I will lack time to investigate the issue with testpmd and shared libs. If anyone has any idea, I will gladly hear it. In the meantime, I will test those two solutions, see what would be feasible, and try to propose one shortly. Regards, -- Gaëtan Rivet 6WIND