On 28/01/2017 13:14, Yuanhan Liu wrote:
[..]
I'll apply the patch from Remy which fixes a case where process creates
I would ask you not to apply that. IMO, his patch may have "fixed" a crash
he saw, but it doesn't looks like to me it really fixes anything: the driver
may reference rte_eth_data belongs to another driver -- things can't be
right afterwards.
I've self-NAK'd it as the code path it was aimed at no longer occurrs.
I'll restart this discussion with a bigger picture of what multiproc is,
and what are the issues.
Great! And I'm keen to know how the multiproc is actually used in real
life (and why they don't use multiple thread). Most importantly, does
people really care about it? (I fixed few virtio multiproc issues that
I know there are some people/companies using it, and I want to know if
there are more).
The use-cases I'm coming across are to allow the attaching/detaching of
external agents mainly for information-reporting purposes, without
having to leave hooks everywhere. In this case main advantage is the
relative ease that processes can be hot-plugged in a way threads cannot.
I suppose something more heavyweight might be a primary process as a
host physical interconnect, with secondary processes being virtual
machines - in this case these might be large semi-independent code-bases
one does not want in the same process image.
To me the major down-side with DPDK's multiprocess model is how
address-space layout randomisation can trip things up. I know parts of
the code seems ASLR-safe, but I very much doubt all of it is.
..Remy
