DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"techboard@dpdk.org" <techboard@dpdk.org>,
	"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
	"Honnappa Nagarahalli" <Honnappa.Nagarahalli@arm.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Ferruh Yigit <ferruh.yigit@amd.com>,
	"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
	Christian Koue Muf <ckm@napatech.com>,
	Renyong Wan <wanry@3snic.com>
Subject: Re: Process for adding a new driver?
Date: Mon, 18 Sep 2023 21:58:01 +0200	[thread overview]
Message-ID: <3206014.l52yBJDM9G@thomas> (raw)
In-Reply-To: <DBAPR08MB581431E6F0B8A61CD511558098FBA@DBAPR08MB5814.eurprd08.prod.outlook.com>

18/09/2023 16:36, Honnappa Nagarahalli:
> From: Morten Brørup <mb@smartsharesystems.com>
> > 
> > The process for adding a new library to DPDK is well documented [1].
> > 
> > What is the process for adding a new (NIC) driver?
> > 
> > It seems like the task of reviewing NIC PMDs from vendors other than
> > Broadcom/Intel/Marvell/NVIDIA falls entirely on the next-net tree
> > maintainers, Ferruh and Andrew, which doesn't seem like a reasonable
> > burden.
> > 
> > The Napatech driver is too large for Ferruh to review, which in my opinion [2]
> > is an unreasonable argument for not accepting it.
> > 
> > And the 3SNIC driver got no attention by any reviewers [3]. (Although
> > Stephen did provide some basic feedback after they polled for review.)
> > 
> > Overall, I think we should put much more trust in hardware vendors to
> > provide high quality drivers for their hardware. We want vendors to upstream
> > their drivers, with all the benefits of having the code public. If we make it too
> > difficult, they will simply keep their drivers private instead.
> 
> Difficulty vs quality control? IMO, it is good to add more drivers. May be we need to control quality through testing reports?

There are different kind of quality aspects.
Functional testing is one quality criteria.
Grouping code in something understandable with clear explanations is another one.
Being consistent with the rest of the codebase (design or code style)
may be other quality criteria.

The difficult exercise is to ask the right level of investment from the vendor.
Don't forget that adding a driver is a win-win situation.



      reply	other threads:[~2023-09-18 19:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18  7:08 Morten Brørup
2023-09-18 11:46 ` Ferruh Yigit
2023-09-18 14:36 ` Honnappa Nagarahalli
2023-09-18 19:58   ` Thomas Monjalon [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=3206014.l52yBJDM9G@thomas \
    --to=thomas@monjalon.net \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=ckm@napatech.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mb@smartsharesystems.com \
    --cc=techboard@dpdk.org \
    --cc=wanry@3snic.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).