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
