[ovs-dev] [RFC 1/3] dpdk: Unify passing of DPDK EAL arguments.

Flavio Leitner fbl at sysclose.org
Tue Feb 5 20:19:35 UTC 2019


On Tue, Feb 05, 2019 at 06:43:08PM +0300, Ilya Maximets wrote:
> Hi Flavio.
> Thanks for taking a look.
> 
> On 05.02.2019 15:38, Flavio Leitner wrote:
> > 
> > Hi Ilya,
> > 
> > Thanks for the patch and I think we knew about that pain when we
> > exposed the very first parameter. I still remember Aaron struggling
> > to find the best path forward. Time flies and here we are.
> > 
> > The problem is that this change is not friendly from the community
> > perspective to its users. That is like an exposed API which we should
> > avoid break as much as possible.
> > 
> > For instance, there are users (OpenStack) with support life cycle of
> > 5+ years that cannot keep up with this kind of change but they expect
> > to be able to update to newer OVS.
> 
> Sure, there are users that wants stable API that will never change.
> But this is really impossible in practice. I'm working with OpenStack
> too and will have to fixup deployment tools with these changes. BTW, from
> the whole OpenStack only few deployment projects (like TripleO) will need
> to make changes and these changes are not very big.

That's only part of the work. There will be work on QA, documentation
and even migration path from one to another. And we can't change the
past for existing deployments.

> > One idea is to freeze whatever we have now and update the documentation
> > to recommend the new way. We give like a couple OVS releases and only
> > then ignore (or remove?) those parameters.
> 
> Yes, In cover letter I proposed these patches to be applied one per release.
> And current (first) patch does not remove the functionality, only docs.
> Users still will be able to use old interface, but will have warnings
> in the log. In the next release cycle we'll start ignore the values
> while still printing the warnings. This should give enough time for adaptation.
> If you feel that we need more time, we could apply the second patch to 2.14
> (or whatever number will be in 2 releases from now).

I don't think we should remove the docs if the parameters are there as
a first step. I mean, assume an existing deployment, there is a parameter
which might be in use but there is no documentation available. That
doesn't sound like a good user experience to me.

On another hand, you could introduce the new interface and update the
docs to recommend using the new one because the old one will be removed
in the future. Warning messages come next, and then finally its removal.


> > IMO in the end we are moving the problem from one place to another
> > because even with a single string, OVS users will be caught off guard
> > when DPDK changes. Yes, less pain to OVS community in the sense that
> > we don't have to add/remove/deprecate stuff, but it is still a bad
> > user experience regardless, which is not what OVS is known for.
> 
> Unfortunately, DPDK was never user-friendly enough. It tries, but still not.

Agreed.

> We're keeping few sane defaults like providing default lcore and setting the
> socket-limit if needed. And we'll try to do that in the future. The thing
> this patch tries to eliminate is the dependency tracking between different
> EAL arguments, i.e. duplicating the work with rte_eal_init() and having too
> many configuration knobs with similar meanings what does not work at the
> same time.
> 
> Right now there are no critical arguments that user must provide.
> So, IMHO, having special configs for them is really unnecessary.

Do you think the defaults work for the majority of DPDK users?

If we expose only the necessary things to consume DPDK it means we
have tight control (less combinations to worry about), otherwise if
the user can pass anything, a can of worms is opened and we have no
control of all things the user can do.

fbl



More information about the dev mailing list