Re: [PATCH v11 0/9] Logging unification and enhancements
On 2024-03-24 03:33, Stephen Hemminger wrote: Improvements and unification of logging library (for 24.07 release). This version works on all platforms: Linux, Windows and FreeBSD. This is update to rework patch set. It adds several new features to the console log output. * Putting a timestamp on console output which is useful for analyzing performance of startup codes. Timestamp is optional and must be enabled on command line. * Displaying console output with colors. It uses the standard conventions used by many other Linux commands for colorized display. The default is to enable color if the console output is going to a terminal. But it can be always on or disabled by command line flag. This default was chosen based on what dmesg(1) command does. I find color helpful because DPDK drivers and libraries print lots of not very useful messages. And having error messages highlighted in bold face helps. This might also get users to pay more attention to error messages. Many bug reports have earlier messages that are lost because there are so many info messages. * Use of syslog on Linux is replaced by using journal API (over unix domain socket). This replaces legacy syslog; (almost) all Linux distros have switched to journal. Is "switched to journal" the same as "switched to systemd", or are there non-systemd journal API implementations? I'm guessing there are quite a few Linux-based embedded systems that doesn't use systemd. Ideally, you would like to have journal as the Linux default, and then syslog as a build-time option. Will add a release note in next release (after this is merged) v11 - rework to be portable to Windows drop syslog support and support journal instead Stephen Hemminger (9): windows: make getopt functions have const properties eal: make eal_log_level_parse common eal: do not duplicate rte_init_alert() messages eal: change rte_exit() output to match rte_log() log: drop syslog support, and make code common log: add hook for printing log messages log: add timestamp option log: add support for systemd journal log: colorize log output app/test/test_eal_flags.c | 38 +- doc/guides/linux_gsg/linux_eal_parameters.rst | 27 - .../prog_guide/env_abstraction_layer.rst | 5 +- doc/guides/prog_guide/log_lib.rst | 41 +- lib/eal/common/eal_common_debug.c | 11 +- lib/eal/common/eal_common_options.c | 123 ++--- lib/eal/common/eal_internal_cfg.h | 2 +- lib/eal/common/eal_options.h | 7 +- lib/eal/freebsd/eal.c | 54 +- lib/eal/linux/eal.c | 52 +- lib/eal/unix/eal_debug.c | 3 +- lib/eal/windows/eal.c | 39 +- lib/eal/windows/getopt.c | 23 +- lib/eal/windows/include/getopt.h | 8 +- lib/log/log.c | 513 -- lib/log/log_freebsd.c | 12 - lib/log/log_internal.h| 16 +- lib/log/log_linux.c | 61 --- lib/log/log_windows.c | 18 - lib/log/meson.build | 5 +- lib/log/version.map | 2 + 21 files changed, 656 insertions(+), 404 deletions(-) delete mode 100644 lib/log/log_freebsd.c delete mode 100644 lib/log/log_linux.c delete mode 100644 lib/log/log_windows.c
Re: [PATCH] dma/cnxk: fix driver header
22/03/2024 17:04, Tyler Retzlaff:
> On Fri, Mar 22, 2024 at 02:52:55PM +0100, David Marchand wrote:
> > Add missing 'extern "C"' to file.
> > Using __rte_internal requires including rte_compat.h.
> >
> > Fixes: 1693345b6a33 ("dma/cnxk: support DMA event enqueue/dequeue")
> >
> > Signed-off-by: David Marchand
>
> Acked-by: Tyler Retzlaff
Applied, thanks.
Re: [PATCH 1/2] net/mlx5/hws: fix rule resize status check
21/03/2024 15:24, Yevgeny Kliteynik:
> The check to detect if a rule is in resize was done incorrectly,
> this can lead to an incorrect function call upon completion for
> rules which are not in resize (move).
> Since the resize_info is in a union we cannot rely only on the
> pointer value but also need to make sure the matcher is in resize
> process, this assures us the resize info is valid.
>
> Fixes: 762feceb8294 ("net/mlx5/hws: support resizable matchers")
>
> Signed-off-by: Yevgeny Kliteynik
> Signed-off-by: Alex Vesker
> Acked-by: Matan Azrad
Series applied, thanks.
Re: [PATCH] net/mlx5/hws: fix invalid memory access in decapl3
22/03/2024 11:01, Gregory Etelson:
> From: Alex Vesker
>
> In case decapL3 action is created we would access header
> data even in case the SHARED flag is not set, this would
> lead to an invalid memory access.
>
> Fixes: 3a6c50215c07 ("net/mlx5/hws: support multi-pattern")
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Alex Vesker
Applied, thanks.
Re: [PATCH v2] net/mlx5: fix sync meter action
19/03/2024 12:24, Gregory Etelson:
> PMD implements sync METER flow action as async.
> Queue selected for sync operations is `MLX5_HW_INV_QUEUE`.
> That dummy queue value is translated into `CTRL_QUEUE_ID(priv)`.
> Async job allocation converts INV queue into the real value, but
> job release does not.
>
> This patch fixes the queue value provided to `flow_hw_job_put()`.
>
> This patch also removes dead code found in METER_MARK
> destroy handler.
>
> Coverity issue: 415806
> Coverity issue: 415804
>
> Fixes: 4359d9d1f76b ("net/mlx5: fix sync meter processing in HWS")
>
> Signed-off-by: Gregory Etelson
> Acked-by: Dariusz Sosnowski
Applied, thanks.
Re: [PATCH] maintainers: update for gve/igc/ntb drivers
22/03/2024 14:59, Junfeng Guo: > Remove myself from maintainers. > > Signed-off-by: Junfeng Guo Applied, thanks for your work.
Re: [PATCH v2] doc: update LTS maintenance to 3 years
17/01/2024 17:24, Kevin Traynor: > The existing official policy was to maintain LTS releases for 2 years. > > 19.11 and 20.11 LTS releases were maintained for 3 years and there was > not significant issues caused by code divergence from main etc. > > Update the policy to indicate 3 years maintenance for LTS releases, but > note that it depends on community support. > > Signed-off-by: Kevin Traynor More opinions, comments or acks?
Re: [PATCH v4] doc: update guideline for fix commit messages
20/03/2024 10:59, Power, Ciara: > From: Ferruh Yigit > > On 2/8/2024 10:51 AM, Sivaramakrishnan Venkat wrote: > > > Maintainers remove the Cc author line when merging the patch. > > > So, the guidelines is updated with a suggestion for the placement of > > > Cc lines in a commit message for easy merging. > > > > > > Signed-off-by: Sivaramakrishnan Venkat > > > > > > > > > > Acked-by: Ferruh Yigit > > Acked-by: Ciara Power Applied, thanks.
Re: [PATCH] doc/linux_gsg: add amd configuration section
24/01/2024 19:10, Vipin Varghese: > Add AMD EPYC SoC tuning guide as new section of linux getting > started guide. > > Signed-off-by: Vipin Varghese Applied, with a bit of reformatting, thanks.
Re: [PATCH] Spelling: Fixed a spelling mistake.
22/03/2024 00:03, Flore:
> Caught by codespell
>
> Signed-off-by: Flore Norceide
added root cause
Fixes: fc1f2750a3ec ("doc: programmers guide")
Cc: sta...@dpdk.org
and added your name in .mailmap
Applied, thanks.
Re: [PATCH] Spelling: Fixed a spelling.
22/03/2024 00:02, EmiAoki: > Caught by codespell. > > Signed-off-by: emi Please what is your full name exactly? We need it as a contribution policy known as "Developer’s Certificate of Origin".
Re: [PATCH] Spelling: Fixed a spelling.
25/03/2024 02:12, Thomas Monjalon:
> 22/03/2024 00:02, EmiAoki:
> > Caught by codespell.
> >
> > Signed-off-by: emi
>
> Please what is your full name exactly?
> We need it as a contribution policy known as "Developer’s Certificate of
> Origin".
Found it above: "Emi Aoki" and confirmed with external sources.
added root cause
Fixes: 9d5ba88c2d41 ("doc: add ARM profiling methods")
Cc: sta...@dpdk.org
and added your name in .mailmap
Applied, thanks.
Re: [PATCH] Spelling: Fix spelling mistake.
21/03/2024 23:41, masoumeh.farhadi...@gmail.com:
> From: Masi
>
> Caught by codespell.
>
> Signed-off-by: Masi
added root cause
Fixes: 7622291b641d ("examples/ipsec-secgw: allow to specify neighbour MAC
address")
Cc: sta...@dpdk.org
and added your name in .mailmap
Applied, thanks.
Re: [PATCH] Spelling : Fix spelling mistake.
21/03/2024 23:35, Fidel Castro:
> Caught by codespell.
>
> Signed-off-by: Fidel Castro
added root cause
Fixes: 2653bee888b4 ("test/power: check all environment types")
Cc: sta...@dpdk.org
and added your name in .mailmap
Applied, thanks.
Re: [PATCH] Spelling: Fix Spelling mistake.
22/03/2024 00:05, vinh.t.tra...@gmail.com:
> From: vtran0314
>
> Caught by codespell.
>
> Signed-off-by: Vinh Tran
[..]
> - TEST_ASSERT_NULL(cfgfile, "Expected failured did not occur");
> + TEST_ASSERT_NULL(cfgfile, "Expected failed did not occur");
Correct wording should be "Expected failure".
And there are 3 more occurrences in this file.
I've completed the fix, added root cause
Fixes: c54e7234bc9e ("test/cfgfile: add basic unit tests")
Cc: sta...@dpdk.org
and added your name in .mailmap
Signed-off-by: Vinh Tran
Signed-off-by: Thomas Monjalon
Re: [PATCH] Spelling: Fixed a spelling mistake.
22/03/2024 00:16, hollynichol...@gmail.com:
> From: Holly Nichols
>
> Caught by codespell.
>
> Signed-off-by: Holly Nichols
> ---
> - TEST_ASSERT_NULL(cfgfile, "Expected failured did not occur");
> + TEST_ASSERT_NULL(cfgfile, "Expected failure did not occur");
There are 3 more occurrences in this file.
I've completed the fix, added root cause
Fixes: c54e7234bc9e ("test/cfgfile: add basic unit tests")
Cc: sta...@dpdk.org
and added your name in .mailmap
Merged with the suggestion from Vinh Tran, thanks.
Re: [PATCH V1] doc: add tested Intel platforms with Intel NICs
21/03/2024 17:20, Yu Jiang: > Add tested Intel platforms with Intel NICs to v24.03 release note. > > Signed-off-by: Yu Jiang Applied, thanks.
release candidate 24.03-rc4
A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v24.03-rc4 There are 31 new patches in this snapshot. Release notes: https://doc.dpdk.org/guides/rel_notes/release_24_03.html As usual, you can report any issue on https://bugs.dpdk.org You may share some release validation results by replying to this message at dev@dpdk.org and by adding tested hardware in the release notes. The final release should happen in a couple of days. Please think about sharing your roadmap now for DPDK 24.07. Thank you everyone
Re: [PATCH v2 1/6] ethdev: support setting lanes
On 2024/3/22 21:58, Thomas Monjalon wrote: > 22/03/2024 08:09, Dengdui Huang: >> -#define RTE_ETH_LINK_SPEED_10G RTE_BIT32(8) /**< 10 Gbps */ >> -#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< 20 Gbps */ >> -#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< 25 Gbps */ >> -#define RTE_ETH_LINK_SPEED_40G RTE_BIT32(11) /**< 40 Gbps */ >> -#define RTE_ETH_LINK_SPEED_50G RTE_BIT32(12) /**< 50 Gbps */ >> -#define RTE_ETH_LINK_SPEED_56G RTE_BIT32(13) /**< 56 Gbps */ >> -#define RTE_ETH_LINK_SPEED_100GRTE_BIT32(14) /**< 100 Gbps */ >> -#define RTE_ETH_LINK_SPEED_200GRTE_BIT32(15) /**< 200 Gbps */ >> -#define RTE_ETH_LINK_SPEED_400GRTE_BIT32(16) /**< 400 Gbps */ >> +#define RTE_ETH_LINK_SPEED_10GRTE_BIT32(8) /**< 10 Gbps */ >> +#define RTE_ETH_LINK_SPEED_20GRTE_BIT32(9) /**< 20 Gbps 2lanes >> */ >> +#define RTE_ETH_LINK_SPEED_25GRTE_BIT32(10) /**< 25 Gbps */ >> +#define RTE_ETH_LINK_SPEED_40GRTE_BIT32(11) /**< 40 Gbps 4lanes >> */ >> +#define RTE_ETH_LINK_SPEED_50GRTE_BIT32(12) /**< 50 Gbps */ >> +#define RTE_ETH_LINK_SPEED_56GRTE_BIT32(13) /**< 56 Gbps 4lanes >> */ >> +#define RTE_ETH_LINK_SPEED_100G RTE_BIT32(14) /**< 100 Gbps */ >> +#define RTE_ETH_LINK_SPEED_200G RTE_BIT32(15) /**< 200 Gbps >> 4lanes */ >> +#define RTE_ETH_LINK_SPEED_400G RTE_BIT32(16) /**< 400 Gbps >> 4lanes */ >> +#define RTE_ETH_LINK_SPEED_10G_4LANES RTE_BIT32(17) /**< 10 Gbps >> 4lanes */ >> +#define RTE_ETH_LINK_SPEED_50G_2LANES RTE_BIT32(18) /**< 50 Gbps 2 >> lanes */ >> +#define RTE_ETH_LINK_SPEED_100G_2LANESRTE_BIT32(19) /**< 100 Gbps 2 >> lanes */ >> +#define RTE_ETH_LINK_SPEED_100G_4LANESRTE_BIT32(20) /**< 100 Gbps >> 4lanes */ >> +#define RTE_ETH_LINK_SPEED_200G_2LANESRTE_BIT32(21) /**< 200 Gbps >> 2lanes */ >> +#define RTE_ETH_LINK_SPEED_400G_8LANESRTE_BIT32(22) /**< 400 Gbps >> 8lanes */ > > I don't think it is a good idea to make this more complex. > It brings nothing as far as I can see, compared to having speed and lanes > separated. > Can we have lanes information a separate value? no need for bitmask. > Hi,Thomas, Ajit, roretzla, damodharam I also considered the option at the beginning of the design. But this option is not used due to the following reasons: 1. For the user, ethtool couples speed and lanes. The result of querying the NIC capability is as follows: Supported link modes: 10baseSR4/Full 10baseSR2/Full The NIC capability is configured as follows: ethtool -s eth1 speed 10 lanes 4 autoneg off ethtool -s eth1 speed 10 lanes 2 autoneg off Therefore, users are more accustomed to the coupling of speed and lanes. 2. For the PHY, When the physical layer capability is configured through the MDIO, the speed and lanes are also coupled. For example: Table 45–7—PMA/PMD control 2 register bit definitions[1] PMA/PMD type selection 1 0 0 1 0 1 0 = 100GBASE-SR2 PMA/PMD 0 1 0 1 1 1 1 = 100GBASE-SR4 PMA/PMD Therefore, coupling speeds and lanes is easier to understand. And it is easier for the driver to report the support lanes. In addition, the code implementation is compatible with the old version. When the driver does not support the lanes setting, the code does not need to be modified. So I think the speed and lanes coupling is better. [1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9844436
