DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Vincent JARDIN <vincent.jardin@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] New driver (large patch) question.
Date: Wed, 2 Mar 2016 23:43:28 +0000	[thread overview]
Message-ID: <20160302234327.GC10724@bricha3-MOBL3> (raw)
In-Reply-To: <56D77229.1080100@6wind.com>

On Thu, Mar 03, 2016 at 12:07:21AM +0100, Vincent JARDIN wrote:
> Please,
> 
> Le 02/03/2016 22:30, Stephen Hurd a écrit :
> >Too many of the DPDK drivers are bloated.
> >>Recall the venerable paraphrase of Pascal, "I made this so long because I
> >>did not have time to make it shorter."
> >>https://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn%27t_read
> 
> Keep In Simple, Small Is Beautiful, the big drivers with dead codes are not
> easy to be maintained. We have lot of duplication of efforts between the
> kernel and some DPDK PMDs,
> 
> Currently, the breakdown of Lines of Codes of the PMDs are:
> 
> 492 ring
> 522 null
> 666 af_packet
> 829 pcap
> 1229 szedata2
> 1300 mpipe
> 1411 xenvirt
> 2036 nfp
> 2260 vmxnet3
> 3074 virtio
> 4129 mlx4
> 4205 bonding
> 4524 mlx5
> 4904 enic
> 7654 cxgbe
> 7969 fm10k
> 27862 ixgbe
> 29209 e1000
> 31392 i40e
> 38031 bnx2x
> 
> (I did use cloc).
> 
> Vincent

Hi Vincent,

I think most of us would wholehearted agree with the "small is beautiful"
sentiment.

However, I disagree with the assumption that these counts reflect the maintenance
burden of these drivers. The Intel drivers, as do some others, use a "base code"
model, where there is a set of code shared between various platforms. This code
should not be included in the maintenance calculation since it is explicitly not
being maintained by the DPDK project itself. A better metric of the overhead of
the various drivers would be the LOC count excluding any base code.

Now, if you are considering the code size for compilation time, or release package
sizing - then it's a fair metric! :-)

Regards,
/Bruce

      reply	other threads:[~2016-03-02 23:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAJ9nmBaWh8WsuzQcAfrebjaFNYSGsGxEd5Y5DQfWTPuxYY8XWQ@mail.gmail.com>
2016-03-02 10:21 ` Thomas Monjalon
2016-03-02 16:24   ` Stephen Hemminger
2016-03-02 21:30     ` Stephen Hurd
2016-03-02 21:54       ` Thomas Monjalon
2016-03-02 22:06         ` Stephen Hurd
2016-03-02 22:12           ` Wiles, Keith
2016-03-02 22:15           ` Thomas Monjalon
2016-03-02 23:10             ` Stephen Hurd
2016-03-03  0:29               ` Thomas Monjalon
2016-03-03  1:04                 ` Stephen Hurd
2016-03-03  5:53               ` Qiu, Michael
2016-03-03 19:40                 ` Stephen Hurd
2016-03-02 23:07       ` Vincent JARDIN
2016-03-02 23:43         ` Bruce Richardson [this message]

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=20160302234327.GC10724@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=vincent.jardin@6wind.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).