[dpdk-dev] Proposal for a big eal / ethdev cleanup

[Thomas Monjalon]

2016-01-16 16:53, David Marchand:
> On Thu, Jan 14, 2016 at 12:46 PM, Jan Viktorin <viktorin at rehivetech.com> wrote:
> > On Thu, 14 Jan 2016 11:38:16 +0100
> > David Marchand <david.marchand at 6wind.com> wrote:
> >> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> >> follow) and eal structures.
[...]
> >> ABI is most likely broken with this, but I think this discussion can come later.
> >
> > I was trying in my initial approach to stay as much API and ABI backwards
> > compatible as possible to be acceptable into upstream. As just a few
> > people have shown their interest in these changes, I consider the ABI
> > compatibility very important.
> >
> > I can see, that your approach does not care too much... Otherwise, it looks
> > good to me. It is closer to the Linux drivers infra, so it seems to be clearer
> > then the current one.
> 
> I did this on purpose.
> From my point of view, we will have an API/ABI breakage in this code
> at one point.
> So I sent this mail to show where I'd like us to go, because this
> looks saner on the mid/long term.
[...]
> > Another point is that the ethdev infra should not know about the
> > underlying bus infra. The question is whether we do a big clean
> > up (extract PCI-bus code out) or a small clean up (give the ethdev
> > infra a hint which bus system it deals with).
> 
> Yes, and I think these two choices are reflected by our two respective
> proposals :-)


Regarding the API/ABI breaks and how the big the changes must be, I'd say
it is nice to have some changes without breaking the user interfaces.
Though sometimes there is a great value to refactor things and break them.
In such case, it is better to do the big changes at once so the breaking
would impact only one version instead of breaking the same API again and
again.
About this proposal, I vote for: +1

[...]
> > Moreover, there is no way how to pass arguments to pdevs, only to
> > vdevs. This was shortly disscussed in [2] for the szedata2 PMD.
> >
> > [2] http://dpdk.org/ml/archives/dev/2015-October/026285.html
> 
> Shorty discussed with Thomas, yes.
> But after some experiments, it appears that you can pass devargs after
> a whitelist option at init (--pci-whitelist
> xxxx:xx:xx.x,whataniceoptionwehavehere=1).
> This does not work for hotplug.
> This is undocumented and this looks like a workaround, so I would
> prefer we come up with a better api for 2.3.

Yes we need also to redefine the command line syntax to have a generic way
of passing per-device parameters to the drivers.