DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: David Marchand <david.marchand@6wind.com>
Cc: dev@dpdk.org, Jan Viktorin <viktorin@rehivetech.com>
Subject: Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup
Date: Mon, 18 Jan 2016 16:49:34 +0100	[thread overview]
Message-ID: <3031367.ptgEOhAmUa@xps13> (raw)
In-Reply-To: <CALwxeUvHG4JPnO5xazRa0XQh4BnJHD1AnFQfR1dGL=sv7j32Cw@mail.gmail.com>

2016-01-16 16:53, David Marchand:
> On Thu, Jan 14, 2016 at 12:46 PM, Jan Viktorin <viktorin@rehivetech.com> wrote:
> > On Thu, 14 Jan 2016 11:38:16 +0100
> > David Marchand <david.marchand@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.

  reply	other threads:[~2016-01-18 15:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 10:38 David Marchand
2016-01-14 11:46 ` Jan Viktorin
2016-01-16 15:53   ` David Marchand
2016-01-18 15:49     ` Thomas Monjalon [this message]
2016-01-18 14:54 ` Declan Doherty
2016-01-18 15:45   ` David Marchand
     [not found] ` <20160118155834.04cb31f2@pcviktorin.fit.vutbr.cz>
2016-01-18 21:11   ` David Marchand
2016-01-19 10:29     ` Jan Viktorin
2016-01-19 10:59       ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3031367.ptgEOhAmUa@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=david.marchand@6wind.com \
    --cc=dev@dpdk.org \
    --cc=viktorin@rehivetech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).