Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
patch tested by dirk.lenz and works for one virtual device On 08/01/2017 11:32 AM, Thomas Monjalon wrote: 01/08/2017 10:17, Gaëtan Rivet: 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. Have you loaded the mempool driver? 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. The problem is that the plugins initialization depends on tailqs, log and memory initialization. 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. Thank you
Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
01/08/2017 10:17, Gaëtan Rivet: > 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. Have you loaded the mempool driver? > 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. The problem is that the plugins initialization depends on tailqs, log and memory initialization. > 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. Thank you
Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
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
Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
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.
Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
I forgot to tell that this happens with 17.08rc2 and latest clone from git.
[dpdk-users] If shared libraries are used vdev doesn't work anymore
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.
