On 08/01/16 16:31, Aaron Conole wrote:
Panu Matilainen <pmati...@redhat.com> writes:
On 01/04/2016 11:46 PM, Aaron Conole wrote:
Existing DPDK integration is provided by use of command line options which
must be split out and passed to librte in a special manner. However, this
forces any configuration to be passed by way of a special DPDK flag, and
interferes with ovs+dpdk packaging solutions.
This commit delays dpdk initialization until the first DPDK netdev is added
to the bridge, at which point ovs initializes librte.
On thing to keep in mind is that rte_eal_init() can and will tear down
the entire process on failure since DPDK calls rte_panic() if
something so much as sneezes. In current OVS this occurs on service
startup where its relatively harmless, but with lazy initialization
there could be already be other activity that is in risk of getting
terminated when the first DPDK port is added.
Fixing rte_eal_init() to gracefully return on failure has been
discussed, and agreed on in principle, on DPDK list but all current
DPDK versions are nasty wrt that.
- Panu -
So, I've waffled back and forth on this. I understand the reason to be
nervous about an always init option (because that wastes lots of
resources when the system won't ever use dpdk). I also understand the
possible issues *today* with dpdk_init, but even then, it's a dpdk issue
which we want fixed anyway, so I don't know that this should hold up
this patch.
I couldn't find the original email where this discussion happened: why
is it required to be able to init DPDK on the fly? I mean it's a nice
bit, but brings in a lot of trouble. On the other hand, asking the user
to set a "other_config:odp=true" and then restart ovs-vswitchd is not a
huge thing to ask.
It's definitely a more elegant solution to do the lazy init, but I think
there could be times where we want a "stop everything" button for
occasions where testing without DPDK doing it's thing are desired.
However, I think I've come up with a solution that gives us flexibility
to support these cases without much additional work, so let me know what
you think:
First, go back to the dpdk true/false flag
Second, add a patch in the series which changes true/false to a tristate
on/off/lazy allowing the policy of when to initialize DPDK to be user
defined. We can default it to 'off' or 'lazy', but it can be changed to
'on' if we want.
What do folks think? Too much work and code for not enough gains?
Thanks,
Aaron
PS: Thanks for looking at this, Panu!
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev