Process for adding a new driver?

Process for adding a new driver?

[Morten Brørup]

Dear DPDK tech board,

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.

@Maxime: I propose to put this on the agenda for the coming techboard meeting.


[1]: https://doc.dpdk.org/guides/contributing/new_library.html
[2]: http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87BAF@smartserver.smartshare.dk/
[3]: http://inbox.dpdk.org/dev/6df9c00f-23a0-423f-840b-4ecf20ff82fc@3snic.com/


Med venlig hilsen / Kind regards,
-Morten Brørup

Re: Process for adding a new driver?

[Ferruh Yigit]

On 9/18/2023 8:08 AM, Morten Brørup wrote:
> Dear DPDK tech board,
> 
> 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.
> 

Ack.
Also for the vendors that has specific tree, new drivers are still
reviewed by next-net maintainers.

> The Napatech driver is too large for Ferruh to review, which in my opinion [2] is an unreasonable argument for not accepting it.
> 

Nope, this is not the exact reason for not accepting.

I tried explain on reply to below thread, but briefly main reason is, it
is a big chunk of code to be consumed by anyone, not just me, like the
consumers of that device.

Target is to improve the quality, if the driver split into per feature
patches, even if I can't find review comments to improve the quality, it
enables others (more smarter reviewers) to improve the code.

> And the 3SNIC driver got no attention by any reviewers [3]. (Although Stephen did provide some basic feedback after they polled for review.)
> 

True, unfortunately.
This is different issue from the Napatech one, and this is more a
bandwidth issue, so I think we can discuss these two separately.

I mentioned about this on DPDK summit meeting, it helps to have pipeline
of reviewers, like when I am not available I should know that Morten
will be doing the driver reviews.
There are many vendors actively contributing to DPDK, their support to
add more reviewers to next-net is appreciated.


> 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.
> 

Agree that this is another approach worth considering.

This may work for some cases, the vendor trees are sample of it already,
but those are the ones already part of the community for a while and
have their track record, do we want to give same level of trust by default?

Or we can even lower the bar to accept any code from any vendor by
default, assuming CI checks are in place, this still won't help on
discussions like if driver should have side channel socket interface or
not etc.. And in this approach, for long run, how it will be different
vendor sharing driver via a public git repo or upstreamed to dpdk.org? I
think we can add value in dpdk.org which may sometimes means requesting
more work from vendor.


> @Maxime: I propose to put this on the agenda for the coming techboard meeting.
> 

Please invite me too :)

> 
> [1]: https://doc.dpdk.org/guides/contributing/new_library.html
> [2]: http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87BAF@smartserver.smartshare.dk/
> [3]: http://inbox.dpdk.org/dev/6df9c00f-23a0-423f-840b-4ecf20ff82fc@3snic.com/
> 
> 
> Med venlig hilsen / Kind regards,
> -Morten Brørup
> 

RE: Process for adding a new driver?

[Honnappa Nagarahalli]

> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Monday, September 18, 2023 2:08 AM
> To: techboard@dpdk.org; maxime.coquelin@redhat.com
> Cc: dev@dpdk.org; Ferruh Yigit <ferruh.yigit@amd.com>;
> andrew.rybchenko@oktetlabs.ru; Christian Koue Muf <ckm@napatech.com>;
> Renyong Wan <wanry@3snic.com>
> Subject: Process for adding a new driver?
> 
> Dear DPDK tech board,
> 
> 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?

> 
> @Maxime: I propose to put this on the agenda for the coming techboard
> meeting.
> 
> 
> [1]: https://doc.dpdk.org/guides/contributing/new_library.html
> [2]:
> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87BAF
> @smartserver.smartshare.dk/
> [3]: http://inbox.dpdk.org/dev/6df9c00f-23a0-423f-840b-
> 4ecf20ff82fc@3snic.com/
> 
> 
> Med venlig hilsen / Kind regards,
> -Morten Brørup

Re: Process for adding a new driver?

[Thomas Monjalon]

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.