[dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
Burakov, Anatoly
anatoly.burakov at intel.com
Mon Apr 8 15:38:48 CEST 2019
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
More information about the dev
mailing list