[dpdk-dev] [PATCH 1/2] eal/linux: move plugin load to very start of eal init

David Marchand david.marchand at 6wind.com
Tue Mar 10 10:08:24 CET 2015


Hello Neil,

On Mon, Mar 9, 2015 at 4:21 PM, Neil Horman <nhorman at tuxdriver.com> wrote:

> On Mon, Mar 09, 2015 at 03:56:38PM +0100, David Marchand wrote:
> > Loading shared libraries should be done at the very start of eal init so
> that
> > the code statically built in dpdk and the code loaded from shared
> objects is
> > handled (almost) the same way wrt to call to rte_eal_init().
> > The only thing that must be done before is filling the solib_list which
> is done
> > by eal_parse_args().
> >
>
>
> I don't see anything explicitly wrong with this, but at the same time it
> doesn't
> seem to fix anything.  Is there a particular bug that you're fixing in
> relation
> to your cover letter here?  Or is there some expectation that PMD's loaded
> in
> this fashion expect the dpdk to be completely uninitalized?  That would
> seem
> like a strange operational requirement to me.
>

Well, at first, I wanted to fix the virtio pmd init issue (iopl() not
called at the right place wrt to other pthreads created in rte_eal_init()).
With next patch, this issue is fixed for statically builtin virtio pmd, but
for virtio pmd as a shared object, the dlopen comes too late.
So, yes, I moved the dlopen() for this reason.

>From a more general point of view, since we support both static and dso
pmds, I would say that this is more logical to have dlopen comes very
early, since static code is "loaded" even earlier : if the current pmds
needed more than just register to the driver list, they would already have
triggered segfaults and/or bugs.


I know this change comes really late for 2.0.
I am open to other ideas but I don't want to see more #ifdef <some feature>
in eal.c (especially for a pmd), this is a non sense.

I would say that at least the patch 2 is needed for 2.0 : it fixes the
static case, but without patch 1 virtio pmd triggers a segfault on
interrupt receipt when built as a dso.


-- 
David Marchand


More information about the dev mailing list