Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
> 
> 
> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> [SNIP]
> [SNIP]
>>
>> My worry here is that some API's get more attention than others, but
>> requirements for freezing the API/ABI are applicable to all of them.
>>
>> Everyone loves discussing specifics of mbufs and dev API's, and I have
>> no doubt that DPDK community can arrive at a consensus with regards to
>> mbuf format etc. in a timely manner, since everyone has a vested
>> interest in those covering their use cases.
>> I have way less confidence
>> in us possibly having saner and more maintainable platform
>> initialization code,
> 
> I think you are right, however its that same lack of enthusiasm that
> would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
> specification effort becoming an endless process, as it would always be
> low on DPDK contributors priority list.
> 
> Instead I recommend we set an API freeze date to focus peoples minds,
> advertise what it means and contributors will respond and look after the
> areas they care/are responsible for.
> 
>> simply because any attempt to change those will
>> likely be met with "please keep all of the old stuff working", which
>> gets us right back to where we started.
>>
> 
> And to be honest that is a fair enough expectation from them, right?
> To Stephen's if we need to break it, let's do it once more and then
> never again.
> 

Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0 
specification" i don't mean there literally should be a document with a 
formal specification :)

Rather, i'm thinking more along the lines of, let's take a look at what 
we have, and think of ways we can reduce the amount of code and improve 
things without causing major inconveniences to great majority of users. 
As in, if we want to "break once more and then never again", then maybe 
instead of small incremental fixes here and there, we could actually do 
a more drastic change that keeps perhaps 90% users happy instead of 
100%, but which reduces maintenance/validation effort from 100% down to 30%.

As a concrete proposal, my number one dream would be to see multiprocess 
gone. I also recall desire for "DPDK to be more lightweight", and i 
maintain that DPDK *cannot* be lightweight if we are to support 
multiprocess - we can have one or the other, but not both. However, 
realistically, i don't think dropping multiprocess is ever going to 
happen - not only it is too entrenched in DPDK use cases, it is actually 
quite useful despite its flaws.

However, what *could* be realistic is to trim down complexity in EAL 
init and system code in general - to me (again, a concrete proposal!), 
that would be dropping igb_uio and supporting upstream kernel modules 
only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit 
support and legacy mem modes, and perhaps bumping kernel version and 
removing some compatibility code as well. This would remove potentially 
thousands of lines of code and keep EAL cleaner and more maintainable: 
right now, we have two different hotplug mechanisms (UIO and VFIO), lots 
of different memory/interrupt modes, etc., for no reason that is readily 
apparent to me.

So, as you can see, an effort to review and delineate what we want to 
support would be necessary if we want to ease the maintenance burden for 
either myself or anyone that inherits this code, as well as reducing the 
number of moving parts and, as a consequence, validation effort and 
amount of bugs. We can't simply do it in a random release "just 
because", but if we were to "break once more and then never again", 
perhaps this is something that could be considered.

-- 
Thanks,
Anatoly