[ovs-dev] [RFC 0/2] dpdk: minor refactor of the initialization step

Aaron Conole 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
software issue?

> 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
wrong).

> 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
>> 'initialized').
>> 
>> 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(-)
>> 
>> --
>> 2.14.3


More information about the dev mailing list