DPDK usage discussions
 help / color / mirror / Atom feed
* [dpdk-users] If shared libraries are used vdev doesn't work anymore
@ 2017-07-31 14:58 Dirk-Holger Lenz
  2017-07-31 15:57 ` Dirk-Holger Lenz
  2017-07-31 20:23 ` Thomas Monjalon
  0 siblings, 2 replies; 6+ messages in thread
From: Dirk-Holger Lenz @ 2017-07-31 14:58 UTC (permalink / raw)
  To: users

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
  2017-07-31 14:58 [dpdk-users] If shared libraries are used vdev doesn't work anymore Dirk-Holger Lenz
@ 2017-07-31 15:57 ` Dirk-Holger Lenz
  2017-07-31 20:23 ` Thomas Monjalon
  1 sibling, 0 replies; 6+ messages in thread
From: Dirk-Holger Lenz @ 2017-07-31 15:57 UTC (permalink / raw)
  To: users

I forgot to tell that this happens with 17.08rc2 and latest clone from git.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
  2017-07-31 14:58 [dpdk-users] If shared libraries are used vdev doesn't work anymore Dirk-Holger Lenz
  2017-07-31 15:57 ` Dirk-Holger Lenz
@ 2017-07-31 20:23 ` Thomas Monjalon
  2017-08-01  8:17   ` Gaëtan Rivet
  1 sibling, 1 reply; 6+ messages in thread
From: Thomas Monjalon @ 2017-07-31 20:23 UTC (permalink / raw)
  To: Dirk-Holger Lenz, gaetan.rivet; +Cc: users, dev

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
  2017-07-31 20:23 ` Thomas Monjalon
@ 2017-08-01  8:17   ` Gaëtan Rivet
  2017-08-01  9:32     ` Thomas Monjalon
  0 siblings, 1 reply; 6+ messages in thread
From: Gaëtan Rivet @ 2017-08-01  8:17 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: Dirk-Holger Lenz, users, 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
  2017-08-01  8:17   ` Gaëtan Rivet
@ 2017-08-01  9:32     ` Thomas Monjalon
  2017-08-02 14:11       ` Dirk-Holger Lenz
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Monjalon @ 2017-08-01  9:32 UTC (permalink / raw)
  To: Gaëtan Rivet; +Cc: Dirk-Holger Lenz, users, dev

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
  2017-08-01  9:32     ` Thomas Monjalon
@ 2017-08-02 14:11       ` Dirk-Holger Lenz
  0 siblings, 0 replies; 6+ messages in thread
From: Dirk-Holger Lenz @ 2017-08-02 14:11 UTC (permalink / raw)
  To: Thomas Monjalon, Gaëtan Rivet; +Cc: users, dev

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-08-02 14:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-31 14:58 [dpdk-users] If shared libraries are used vdev doesn't work anymore Dirk-Holger Lenz
2017-07-31 15:57 ` Dirk-Holger Lenz
2017-07-31 20:23 ` Thomas Monjalon
2017-08-01  8:17   ` Gaëtan Rivet
2017-08-01  9:32     ` Thomas Monjalon
2017-08-02 14:11       ` Dirk-Holger Lenz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).