[dpdk-dev] Minutes of techboard meeting 2017-03-02

Olivier MATZ olivier.matz at 6wind.com
Tue Mar 7 14:10:29 CET 2017


A meeting of the DPDK technical board was held last Wednesday,
2017-03-02. Below are the meeting minutes.

Please note that meetings are open to all to attend. The next meeting is
planned for March 20th, and any topics to be referred to the tech board
for discussion at that meeting should be emailed to techboard at dpdk.org
by March 15th at the latest.


- Bruce Richardson
- Hemant Agrawal
- Jan Blunck
- Jerin Jacob
- Konstantin Ananyev
- Olivier Matz
- Stephen Hemminger
- Thomas Monjalon
- Yuanhan Liu

1. General Meeting Admin

- Olivier Matz volunteered to chair this meeting (meeting chair is a
  rotating role), and Konstantin Ananyev volunteered to chair the next

- Next meeting was agreed to be at the same time in more than two weeks:
  monday 20th March @ 3pm UTC (4pm France, 11pm PRC, 7am US Pacific).

  Konstantin to send a reminder with agenda a few days in advance.

2. Check website update for tech board membership etc. is done

The website details of the Tech board is out of date, both membership
and its mode of operation and scope. Thomas has already sent a patch
proposition for the website and some comments have been done.

Bruce will propose a rewording of Thomas' patch, then it has to be acked
by all techboard members.

3. Check we have reached a consensus about new library addition to dpdk

The following is a summary of what was discussed, but not yet formally

a. Library addition policy

Until now, there was no policy for the addition of new libraries in DPDK
repository. We want to clarify what makes a good set of criteria for
accepting a lib into DPDK. This question is tied to the scope of DPDK,
which still requires a better definition. We think we can start by
delivering some guidelines:

- DPDK is a collection of libs
- DPDK is not a networking stack
- DPDK is about performance in userspace
- DPDK focuses on data path
- DPDK includes examples which are illustration usage
- DPDK should not impose a driver/event/lib model

Obvious examples are EAL, drivers, buffer management libraries. Other
discussed examples are LPM and event library.

It has been decided that library addition will be discussed case by
case, with majority approval.

Some good criteria for the libraries are:

- well-maintained
- self-contained: the lib should be only using the core libraries via
  the public API.
- unit-tested: we should have unit test for libraries.

There was a debate about welcoming many new libraries vs encouraging to
maintain them in another repository (that could be hosted on dpdk.org).

Cons for many libs in the DPDK repo:

- many dependencies when reworking core libs, which can discourage them
- many libraries may confuse new users
- letting less reviewed libraries may decrease code quality or give a
  bad feeling

Cons for libs in external repo (when possible):

- need to link many different projects together to do something
- libraries will get broken more often, requiring more maintenance for
  the lib maintainer

b. Library removal policy

We need to make it easy to get rid of unmaintained stuff.

- For example, if there are questions about a lib/example, and no
  maintainer response for a release cycle it should be dropped as
- For example, a library having critical bugs open for a release
  would also be good candidates for removal.

Today, we don't know how widely a library is used so it's difficult to
use this criteria.

c. Integration of metrics libraries is accepted

This library extends statistics reporting to include peak and average
data-rate metrics. It is composed of a statistics reporting library, a
latency measurement library, and a bitrate calculation library.

d. Integration of NXP shared driver code is accepted

NXP drivers require a base hw interface layer that is shared among
several PMDs (net, crypto and upcoming eventdev).

The proper place will be discussed on the mailing list.

4. Should the techboard take any action for some old patches?

This will also be covered by Bruce's rewording of Thomas' patch.

Thomas suggested to ask this question at each meeting: which threads
need a specific action?

5. Community questions/issues


6. Action Summary

- Bruce to send a reword of Thomas' website patch.
- Konstantin to send a reminder for next meeting with agenda a few days
  in advance.

More information about the dev mailing list