[ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization from cmdline to db

Aaron Conole aconole at redhat.com
Mon Jan 11 18:51:01 UTC 2016


Zoltan Kiss <zoltan.kiss at linaro.org> writes:
> On 08/01/16 16:31, Aaron Conole wrote:
>> Panu Matilainen <pmatilai at 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.

You won't find such a discussion - it's never been "required," as
such. It is very desirable, as having such automatic behavior reduces the
amount of steps required to get up and running with DPDK enabled
OVS. This is, imho, the argument of both Panu and Kevin when they think
a big on/off switch is less than elegant. I tend to agree with that, as well.

If the user is going through the trouble of compiling with DPDK support, and
then wants to add a DPDK port, having to also set
"other_config:dpdk=yes" seems like too many ok dialogs. I hope the
analogy makes sense.

That said, it's really an unneeded enhancement, and I've pitched the
idea to folks at the office within my elastic-shooting range. The answer
has been consistently "This is an enhancement, not a requirement." So
I'll drop the lazy-init feature for now.

>> 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?

As I wrote above, the 'second' part of this is a great follow up
enhancement, but for now I'm going to go back to the giant flag, and we
can take it as 'future development'.



More information about the dev mailing list