[dpdk-dev] DPDK Release Status Meeting 9/04/2020

[dpdk-dev] DPDK Release Status Meeting 9/04/2020

[Ferruh Yigit]

Minutes 9 April 2020
--------------------

Agenda:
* Release Dates
* Highlights
* Subtrees

Participants:
* Arm
* Intel
* Marvell
* Mellanox
* NXP
* Red Hat


Release Dates
-------------

* v20.05 dates:
  * Integration/Merge/RC1:	Friday 17 April 2020
  * Release:			Wednesday 20 May 2020

  * Marvell, Arm, Mellanox & Broadcom already sent roadmap for 20.05, all
    vendors please share the roadmap for the release.


Highlights
----------

* CI failures (ones reported in patchwork)
  **We will be more strict and failing patches will be blocked**


Subtrees
--------

* main
    * crypto tree will be pulled today
    * There is lack of review, some patches stalled
      * gcc10 patches
      * bit operations (may be postponed to next release)
      * cleanup resources on shutdown
      * windows memory management
      * __rte_internal for ABI checks
        * high priority and not very active now, looking for volunteer
    * CI failures are not taken into account
      * Failures are ignored until maintainer points, this is not scalable
      * **We will be more strict and failing patches will be blocked**
        * If there is a false positive author should send note about it
          * In long term false positives will be fixed
    * graph library
      * No major blocking issue, trending to be merged in this release
      * There will be a new version
      * Thomas will review it
    * tracing library
      * Some concerns on the API, it is copy/paste of log API
      * Lacking more reviews
    * ifproxy library
      * Will be postponed to next release
    * telemetry and rawdev patches are in the backlog

* next-net
  * Pulled from sub-trees and some patches merged
  * It is progressing, there are ~60 patches in backlog, nothing big
  * New igc PMD reviewed, waiting for changes
  * ABI issues with mlx PMD should be resolved before next pull

* next-crypto
  * Test for security API and bbdev patchset are under review

* next-eventdev
  * pull request sent, no more patches expected for -rc1

* next-virtio
  * There will be reviews this week
  * Tree was not active for a while but may prepare a pull request based
    on merged patches

* next-net-intel
  * Two series merged, reviews are going on

* next-net-mlx
  * Some series merged and pulled to next-net

* next-net-mrvl
  * All patches merged for -rc1

* LTS

  * 18.11.7-rc1 is out, please test
    * http://inbox.dpdk.org/dev/20200320193403.18959-1-ktraynor@redhat.com/
      * RedHat, Intel & Mellanox sent test reports
    * Release planned for next week



DPDK Release Status Meetings
============================

The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.

The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.

Re: [dpdk-dev] DPDK Release Status Meeting 9/04/2020

[Jerin Jacob]

>     * tracing library
>       * Some concerns on the API, it is copy/paste of log API

The following API  signatures are taken from log API.

1) void rte_trace_global_level_set(uint32_t level);
2) uint32_t rte_trace_global_level_get(void);
3) uint32_t rte_trace_level_get(rte_trace_t trace);
4) int rte_trace_level_set(rte_trace_t trace, uint32_t level);
5) int rte_trace_pattern(const char *pattern, bool enable);
6) int rte_trace_regexp(const char *regex, bool enable);

I have intentionally kept public API similar to rte_log wherever it is
possible. Reason being,

1) In the future, it is easy to replace rte_log with trace _if needed_.
2) Avoid the new API learning curve.
3) I did not find anything wrong with the existing log API to improve
on at least on API that selected to copy the prototype.

If there are specific comments on why we need to take the deviation
from log API on the above schematics. I am happy to change it.

>       * Lacking more reviews

Just FYI:
There is enough documentation on the programming model and
implementation details if someone likes to kick start the review.

http://patches.dpdk.org/patch/67792/

Re: [dpdk-dev] DPDK Release Status Meeting 9/04/2020

[Thomas Monjalon]

09/04/2020 15:10, Jerin Jacob:
> >     * tracing library
> >       * Some concerns on the API, it is copy/paste of log API
> 
> The following API  signatures are taken from log API.
> 
> 1) void rte_trace_global_level_set(uint32_t level);
> 2) uint32_t rte_trace_global_level_get(void);
> 3) uint32_t rte_trace_level_get(rte_trace_t trace);
> 4) int rte_trace_level_set(rte_trace_t trace, uint32_t level);
> 5) int rte_trace_pattern(const char *pattern, bool enable);
> 6) int rte_trace_regexp(const char *regex, bool enable);
> 
> I have intentionally kept public API similar to rte_log wherever it is
> possible. Reason being,
> 
> 1) In the future, it is easy to replace rte_log with trace _if needed_.
> 2) Avoid the new API learning curve.
> 3) I did not find anything wrong with the existing log API to improve
> on at least on API that selected to copy the prototype.
> 
> If there are specific comments on why we need to take the deviation
> from log API on the above schematics. I am happy to change it.

Please remove global level.
We'll try to remove it from rte_log as well.
Let's continue discussion in the patch thread.

Re: [dpdk-dev] DPDK Release Status Meeting 9/04/2020

[Jerin Jacob]

On Thu, Apr 9, 2020 at 7:06 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 09/04/2020 15:10, Jerin Jacob:
> > >     * tracing library
> > >       * Some concerns on the API, it is copy/paste of log API
> >
> > The following API  signatures are taken from log API.
> >
> > 1) void rte_trace_global_level_set(uint32_t level);
> > 2) uint32_t rte_trace_global_level_get(void);
> > 3) uint32_t rte_trace_level_get(rte_trace_t trace);
> > 4) int rte_trace_level_set(rte_trace_t trace, uint32_t level);
> > 5) int rte_trace_pattern(const char *pattern, bool enable);
> > 6) int rte_trace_regexp(const char *regex, bool enable);
> >
> > I have intentionally kept public API similar to rte_log wherever it is
> > possible. Reason being,
> >
> > 1) In the future, it is easy to replace rte_log with trace _if needed_.
> > 2) Avoid the new API learning curve.
> > 3) I did not find anything wrong with the existing log API to improve
> > on at least on API that selected to copy the prototype.
> >
> > If there are specific comments on why we need to take the deviation
> > from log API on the above schematics. I am happy to change it.
>
> Please remove global level.

Any specific reasoning?

> We'll try to remove it from rte_log as well.

Currently, In the log library, when EAL command-line argument
specifies the "--log-level=x" it will call
the  rte_log_global_level_set().

Is the suggestion to make rte_log_global_level_set() as an internal
EAL API or remove that feature?
If we remove, then I dont know, how we can map --log-level or
--trace-level EAL command-line argument.

> Let's continue discussion in the patch thread.

Yes. Please. Inline comments in the trace library code helps.


>
>
>