[ovs-dev] [RFC 0/2] dpdk: minor refactor of the initialization step
aconole at redhat.com
Mon Apr 9 15:32:26 UTC 2018
"Mooney, Sean K" <sean.k.mooney at intel.com> writes:
> So just from a deployment tools point of view I would like to point out that
> This change could break existing workflow that deploy ovs in a docker container.
> Kolla ansible assumes that if the docker ovs_vswitchd container is
> still running that the
> is infact running in dpdk mode when we set dpdk-init=true.
Is there a way to test this out and see the behavior?
It does seem strange that for a possible configuration error we abort()
running the vswitchd (and with --monitor set, it will continue to
abort() over and over - so I guess you're also not using the monitor
thread?). In the case that an abort does happen, does the Kolla script
distinguish between issues where dpdk setup failed vs. some other
> Can I request that if you make this change you add something along the lines of
> dpdk-init-is-fatal=true/false so that we can explicitly say which behavior we want.
> I would not be surprised if people have built monitoring around "is
> the ovs-vswitchd running"
I think they have, but I don't know that they use it to infer such
low-level details (meaning a crash implies that dpdk configuration is
> To infer at least at a highlevel that "everything is fine" where as
> the log message/db field proposed
> Here will invalidate that.
I've added Assaf Mueller from our Open Stack team as well - maybe he has
some additional details on those mechanisms outside of Kolla (maybe it
exists in some kind of director / other software too, as you point out).
> it would be ease to check that field but its work that needs to be
> done in multiple places.
I think such a knob wouldn't be useful. I believe it would either
have to be defaulted to 'dpdk-init-is-fatal=true' to abort on failure
(which most users would want to change making it an undesirable
default), or the Kolla ansible scripts (and other detection mechanisms
for dpdk failure - if they exist) would need to change. Maybe there's
another approach, though?
>> -----Original Message-----
>> From: Aaron Conole [mailto:aconole at redhat.com]
>> Sent: Thursday, April 5, 2018 10:23 PM
>> To: dev at openvswitch.org
>> Cc: Stokes, Ian <ian.stokes at intel.com>; Kevin Traynor
>> <ktraynor at redhat.com>; Ilya Maximets <i.maximets at samsung.com>; Loftus,
>> Ciara <ciara.loftus at intel.com>; Mooney, Sean K
>> <sean.k.mooney at intel.com>; Terry Wilson <twilson at redhat.com>
>> Subject: [RFC 0/2] dpdk: minor refactor of the initialization step
>> Sometimes, DPDK initialization can fail, but ovs-vswitchd will abort in
>> that case. When that occurs, ovs-vswitchd will be restarted by the
>> monitor and immediately abort. This is rather unfriendly to users, who
>> would prefer to possibly correct the issue or at least, not have lots
>> of processes continually spawning.
>> This series accepts that rte_eal_init() can and does fail for real. It
>> reflects the initialization status in the database, as well as adding
>> the DPDK version (where appropriate).
>> Submitted as RFC to spawn discussion around the type to reflect for the
>> initialized information. Presented here as a boolean - however, it
>> might be more interesting to be a 'string' and have more elaborate
>> details (ex: 'failed - ovs_strerror(rte_errno)' or 'uninitialized' or
>> Aaron Conole (2):
>> dpdk: allow init to fail
>> dpdk: reflect status and version in the database
>> lib/dpdk-stub.c | 10 ++++++++++
>> lib/dpdk.c | 31 +++++++++++++++++++++++++------
>> lib/dpdk.h | 3 ++-
>> vswitchd/bridge.c | 5 +++++
>> vswitchd/vswitch.ovsschema | 11 ++++++++---
>> vswitchd/vswitch.xml | 11 +++++++++++
>> 6 files changed, 61 insertions(+), 10 deletions(-)
More information about the dev