[dpdk-dev] New driver (large patch) question.

[Stephen Hurd]

The bulk of the patch is the hardware interface header file.  With all the
comments, it weighs in around 800k.  If I strip the comments, it's around
300k.  If I both strip all the comments and remove all the currently unused
structures, I can get the entire patch down just below 300k, but that makes
it much harder for someone to do further development.  I'm willing to do
that though if it's what's preferred.

The other large file (560k) is just a bunch of extra debug output that
makes it easier to debug issues.  It's normally not compiled, so it sounds
like it's not wanted either.

I'll submit without comments in the hardware interface file and take it
from there.

On Wed, Mar 2, 2016 at 8:24 AM, Stephen Hemminger <
stephen at networkplumber.org> wrote:

> On Wed, 02 Mar 2016 11:21:26 +0100
> Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
>
> > Hi,
> >
> > 2016-03-01 19:56, Stephen Hurd:
> > > I submitted a new driver on Friday, and it was rejected for being over
> 300k.
> > >
> > > The rejection email suggested contacing dev-owner at dpdk.org, which I
> did on
> > > Monday with no reply.
> > >
> > > What's the process to submit patches larger than the mailing list size
> > > limit?
> >
> > A patch has two lives:
> > 1/ it must be reviewed and accepted
> > 2/ it will stay in the git history for future reference
> >
> > Those 2 periods require the patch to be well explained, with a
> > reasonnable scope and a human readable size.
> > The primary rule to think about is to introduce only one feature
> > per patch.
> > So the size should be naturally small and the mailing list don't need
> > to accept greater sizes.
> >
> > To make it short, please split your driver in several introduction steps.
> >
>
> 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
>
> Linux went through similar stages. Many drivers ended up being rewritten
> for brevity (e1000, skge, tg3). Vendor drivers seem to want to engage all
> features
> even if they have no value.
>



-- 
Stephen Hurd
Principal Engineer - Software Development
Broadcom Corporation
949-926-8039
stephen.hurd at broadcom.com