RE: [PATCH v2 1/4] doc: arm64 cross build CFLAGS/LDFLAGS alternatives
> -Original Message- > From: Juraj Linkeš > Sent: Tuesday, December 7, 2021 7:05 PM > To: tho...@monjalon.net; david.march...@redhat.com; Honnappa > Nagarahalli ; Ruifeng Wang > ; ferruh.yi...@intel.com; jerinjac...@gmail.com > Cc: dev@dpdk.org; Juraj Linkeš > Subject: [PATCH v2 1/4] doc: arm64 cross build CFLAGS/LDFLAGS alternatives > > Remove CFLAGS and LDFLAGS since Meson doesn't support them well > enough. > Add Meson alternatives: -Dc_args and -Dc_link_args on the command line > and in cross files. > > Signed-off-by: Juraj Linkeš > --- > .../linux_gsg/cross_build_dpdk_for_arm64.rst | 25 --- > 1 file changed, 21 insertions(+), 4 deletions(-) > > diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > index d59af58235..51075bd4a9 100644 > --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > @@ -98,10 +98,6 @@ For aarch32:: > Augment the GNU toolchain with NUMA support > ~~~ > > -.. note:: > - > - This way is optional, an alternative is to use extra CFLAGS and LDFLAGS. > - > Copy the NUMA header files and lib to the cross compiler's directories: > > .. code-block:: console > @@ -110,6 +106,27 @@ Copy the NUMA header files and lib to the cross > compiler's directories: > cp /lib/libnuma.a /gcc-arm-9.2- > 2019.12-x86_64-aarch64-none-linux-gnu/lib/gcc/aarch64-none-linux- > gnu/9.2.1/ > cp /lib/libnuma.so /gcc-arm-9.2- > 2019.12-x86_64-aarch64-none-linux-gnu/lib/gcc/aarch64-none-linux- > gnu/9.2.1/ > > +.. note:: > + > + Using LDFLAGS and CFLAGS is not a viable alternative to copying the files. > + The Meson docs say it is not recommended, as there are many caveats to > their > + use with Meson, especially when rebuilding the project. A viable > alternative > + would be to use the ``c_args`` and ``c_link_args`` options with Meson > 0.51.0 > + and higher: > + > +.. code-block:: console > + > + -Dc_args=-I/include > + -Dc_link_args=-L/lib > + > + For Meson versions lower than 0.51.0, the ``c_args`` and ``c_link_args`` > + options don't apply to cross compilation. However, the compiler/linker > flags > + may be added to cross files under [properties]: These 3 lines need no indent, otherwise they will be rendered in code-block. With suggested change: Acked-by: Ruifeng Wang > + > +.. code-block:: console > + > + c_args = ['-I/include'] > + c_link_args = ['-L/lib'] > + > Cross Compiling DPDK with GNU toolchain using Meson > ~~~ > > -- > 2.20.1
Re: [PATCH] ring: fix overflow in memory size calcuation
On Tue, Dec 14, 2021 at 11:30:16AM +0800, Zhihong Wang wrote:
> Parameters count and esize are both unsigned int, and their product can
> legally exceed unsigned int and lead to runtime access violation.
>
> Fixes: cc4b218790f6 ("ring: support configurable element size")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Zhihong Wang
> ---
> lib/ring/rte_ring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
> index f17bd966be..d1b80597af 100644
> --- a/lib/ring/rte_ring.c
> +++ b/lib/ring/rte_ring.c
> @@ -75,7 +75,7 @@ rte_ring_get_memsize_elem(unsigned int esize, unsigned int
> count)
> return -EINVAL;
> }
>
> - sz = sizeof(struct rte_ring) + count * esize;
> + sz = sizeof(struct rte_ring) + (ssize_t)count * esize;
> sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> return sz;
> }
> --
> 2.11.0
>
Reviewed-by Liang Ma
RE: [PATCH v2 2/4] doc: arm64 cross build binary names update
> -Original Message- > From: Juraj Linkeš > Sent: Tuesday, December 7, 2021 7:05 PM > To: tho...@monjalon.net; david.march...@redhat.com; Honnappa > Nagarahalli ; Ruifeng Wang > ; ferruh.yi...@intel.com; jerinjac...@gmail.com > Cc: dev@dpdk.org; Juraj Linkeš > Subject: [PATCH v2 2/4] doc: arm64 cross build binary names update > > The newer version have an extra -none- in the name. > > Signed-off-by: Juraj Linkeš > --- > doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > index 51075bd4a9..af159bbf93 100644 > --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > @@ -130,6 +130,12 @@ Copy the NUMA header files and lib to the cross > compiler's directories: > Cross Compiling DPDK with GNU toolchain using Meson > ~~~ > > +.. note:: > + > + The names of gcc binaries in cross files differ from the downloaded > + ones, which have an extra "-none-" in their name. Please modify the cross > + file binaries accordingly when using the downloaded cross compilers. > + > To cross-compile DPDK on a desired target machine we can use the following > command:: > > @@ -137,12 +143,13 @@ command:: > ninja -C cross-build > > For example if the target machine is aarch64 we can use the following > -command:: > +command, provided the cross file has been modified accordingly:: > > meson aarch64-build-gcc --cross-file config/arm/arm64_armv8_linux_gcc > ninja -C aarch64-build-gcc > > -If the target machine is aarch32 we can use the following command:: > +If the target machine is aarch32 we can use the following command, > +provided the cross file has been modified accordingly:: > > meson aarch32-build --cross-file config/arm/arm32_armv8_linux_gcc > ninja -C aarch32-build > -- > 2.20.1 Acked-by: Ruifeng Wang
Re: [PATCH v3] net/ixgbe: add vector Rx parameter check
On Fri, Dec 10, 2021 at 04:22:09PM +0800, Bin Zheng wrote:
> Under the circumstance that `rx_tail` wrap back to zero
> and the advance speed of `rx_tail` is greater than `rxrearm_start`,
> `rx_tail` will catch up with `rxrearm_start` and surpass it.
> This may cause some mbufs be reused by application.
>
> So we need to make some restrictions to ensure that
> `rx_tail` will not exceed `rxrearm_start`.
>
> e.g.
>
> RDH: 972 RDT: 991 rxrearm_nb: 991 rxrearm_start: 992 rx_tail: 959
> RDH: 1004 RDT: 1023 rxrearm_nb: 991 rxrearm_start: 0 rx_tail: 991
> RDH: 12 RDT: 31 rxrearm_nb: 991 rxrearm_start: 32 rx_tail: 1023
> RDH: 31 RDT: 63 rxrearm_nb: 960 rxrearm_start: 64 rx_tail: 0
> RDH: 95 RDT: 95 rxrearm_nb: 1016 rxrearm_start: 96 rx_tail: 88
> RDH: 95 RDT: 127 rxrearm_nb: 991 rxrearm_start: 128 rx_tail: 95
> ...
> RDH: 908 RDT: 927 rxrearm_nb: 991 rxrearm_start: 928 rx_tail: 895
> RDH: 940 RDT: 959 rxrearm_nb: 991 rxrearm_start: 960 rx_tail: 927
> RDH: 980 RDT: 991 rxrearm_nb: 991 rxrearm_start: 992 rx_tail: 959
> RDH: 991 RDT: 991 rxrearm_nb: 1026 rxrearm_start: 992 rx_tail: 994
>
> when `rx_tail` catches up with `rxrearm_start`,
> 2(994 - 992) mbufs be reused by application !
>
> Bugzilla ID: 882
> Fixes: 5a3cca342417 ("net/ixgbe: fix vector Rx")
> Cc: jia@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bin Zheng
> ---
> drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> index 1eed949495..4654d0adec 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c
> @@ -364,6 +364,17 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
> rte_mbuf **rx_pkts,
> uint8_t vlan_flags;
> uint16_t udp_p_flag = 0; /* Rx Descriptor UDP header present */
>
> + /*
> + * Under the circumstance that `rx_tail` wrap back to zero
> + * and the advance speed of `rx_tail` is greater than `rxrearm_start`,
> + * `rx_tail` will catch up with `rxrearm_start` and surpass it.
> + * This may cause some mbufs be reused by application.
> + *
> + * So we need to make some restrictions to ensure that
> + * `rx_tail` will not exceed `rxrearm_start`.
> + */
> + nb_pkts = RTE_MIN(nb_pkts, RTE_IXGBE_RXQ_REARM_THRESH);
> +
> /* nb_pkts has to be floor-aligned to RTE_IXGBE_DESCS_PER_LOOP */
> nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_IXGBE_DESCS_PER_LOOP);
>
> --
> 2.25.1
>
Reviewed-by Liang Ma
[Bug 910] [build] meson build not support some c_args
https://bugs.dpdk.org/show_bug.cgi?id=910 Bug ID: 910 Summary: [build] meson build not support some c_args Product: DPDK Version: 21.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: meson Assignee: dev@dpdk.org Reporter: junx.d...@intel.com Target Milestone: --- 1.DPDK version: version: 21.11.0-rc0 2.OS version: OS: Ubuntu 20.04.3 LTS/5.8.0-48-generic gcc version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 3. Config meson build command, contain c_args parameter DRTE_MBUF_DEFAULT_MEMPOOL_OPS, as follow: CC=gcc meson -Denable_kmods=True -Dlibdir=lib -Dc_args=-DRTE_MBUF_DEFAULT_ MEMPOOL_OPS=stack --default-library=static x86 _64-native-linuxapp-gcc 4. Check the build output. There is warning information of redefined parameter 171149 [6/2720] Compiling C object lib/librte_eal.a.p/eal_common_eal_common_ hypervisor.c.o^M 171150 In file included from :^M ./config/rte_config.h:52: warning: "RTE_MBUF_DEFAULT_MEMPOOL_OPS" redefined^M #define RTE_MBUF_DEFAULT_MEMPOOL_OPS "ring_mp_mc"^M 5. The list of othe c_args parameters having same issues: RTE_LIBRTE_IP_FRAG_MAX_FRAG RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC 6. About RTE_LIBRTE_I40E_16BYTE_RX_DESC, it was undefined in config/rte_config.h, if i defined it in meson build command, it is also cancel, please also analysis this parameter. thanks. -- You are receiving this mail because: You are the assignee for the bug.
RE: [PATCH] ring: fix overflow in memory size calcuation
> From: Liang Ma [mailto:lian...@liangbit.com]
> Sent: Wednesday, 15 December 2021 09.01
>
> On Tue, Dec 14, 2021 at 11:30:16AM +0800, Zhihong Wang wrote:
> > Parameters count and esize are both unsigned int, and their product
> can
> > legally exceed unsigned int and lead to runtime access violation.
> >
> > Fixes: cc4b218790f6 ("ring: support configurable element size")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Zhihong Wang
> > ---
> > lib/ring/rte_ring.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
> > index f17bd966be..d1b80597af 100644
> > --- a/lib/ring/rte_ring.c
> > +++ b/lib/ring/rte_ring.c
> > @@ -75,7 +75,7 @@ rte_ring_get_memsize_elem(unsigned int esize,
> unsigned int count)
> > return -EINVAL;
> > }
> >
> > - sz = sizeof(struct rte_ring) + count * esize;
> > + sz = sizeof(struct rte_ring) + (ssize_t)count * esize;
> > sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> > return sz;
> > }
> > --
> > 2.11.0
> >
> Reviewed-by Liang Ma
I was wondering about the type conversion to signed (instead of unsigned), but
sz is ssize_t, so the conversion to ssize_t is correct. Otherwise, sz should be
changed from ssize_t to size_t too.
No need for further changes.
Reviewed-by: Morten Brørup
RE: [PATCH v2 3/4] doc: arm64 cross build numactl compilers
> -Original Message- > From: Juraj Linkeš > Sent: Tuesday, December 7, 2021 7:05 PM > To: tho...@monjalon.net; david.march...@redhat.com; Honnappa > Nagarahalli ; Ruifeng Wang > ; ferruh.yi...@intel.com; jerinjac...@gmail.com > Cc: dev@dpdk.org; Juraj Linkeš > Subject: [PATCH v2 3/4] doc: arm64 cross build numactl compilers > > Numactl cross compilation doesn't work with clang, remove it and fix the gcc > cross compiler executable name. > > Signed-off-by: Juraj Linkeš > --- > doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > index af159bbf93..6153bc5b77 100644 > --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > @@ -35,13 +35,14 @@ NUMA is required by most modern machines, not > needed for non-NUMA architectures. > git checkout v2.0.13 -b v2.0.13 > ./autogen.sh > autoconf -i > - ./configure --host=aarch64-linux-gnu CC= --prefix= install dir> > + ./configure --host=aarch64-linux-gnu CC=aarch64-none-linux-gnu-gcc > + --prefix= > make install > > .. note:: > > - The compiler above can be either aarch64-linux-gnu-gcc or clang. > - See below for information on how to get specific compilers. > + The compiler is aarch64-none-linux-gnu-gcc if you download gcc using the > + below guide. If you're using a different compiler, make sure you're using > + the proper executable name. > > The numa header files and lib file is generated in the include and lib folder > respectively under . > -- > 2.20.1 Acked-by: Ruifeng Wang
RE: [PATCH v2 4/4] docs: add an example arm64 cross file
> -Original Message- > From: Juraj Linkeš > Sent: Tuesday, December 7, 2021 7:05 PM > To: tho...@monjalon.net; david.march...@redhat.com; Honnappa > Nagarahalli ; Ruifeng Wang > ; ferruh.yi...@intel.com; jerinjac...@gmail.com > Cc: dev@dpdk.org; Juraj Linkeš > Subject: [PATCH v2 4/4] docs: add an example arm64 cross file > > The docs mention modifications and additions to the cross file, but there is > no demonstration of how those should look like. > > Signed-off-by: Juraj Linkeš > --- > .../linux_gsg/cross_build_dpdk_for_arm64.rst | 26 +++ > 1 file changed, 26 insertions(+) > > diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > index 6153bc5b77..78bf19882e 100644 > --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > @@ -137,6 +137,32 @@ Cross Compiling DPDK with GNU toolchain using > Meson > ones, which have an extra "-none-" in their name. Please modify the cross > file binaries accordingly when using the downloaded cross compilers. > > + An example cross file with modified names and added numa paths would > look > + like this: > + > +.. code-block:: console > + > + [binaries] > + c = 'aarch64-none-linux-gnu-gcc' > + cpp = 'aarch64-none-linux-gnu-cpp' > + ar = 'aarch64-none-linux-gnu-gcc-ar' > + strip = 'aarch64-none-linux-gnu-strip' > + pkgconfig = 'aarch64-linux-gnu-pkg-config' # the downloaded binaries > + # don't contain a pkgconfig binary, so it's not modified > + pcap-config = '' > + > + [host_machine] > + system = 'linux' > + cpu_family = 'aarch64' > + cpu = 'armv8-a' > + endian = 'little' > + > + [properties] > + # Generate binaries that are portable across all Armv8 machines > + platform = 'generic' > + c_args = ['-I/include'] # replace > + c_link_args = ['-L/lib'] # with your path > + > To cross-compile DPDK on a desired target machine we can use the following > command:: > > -- > 2.20.1 Acked-by: Ruifeng Wang
Re: [PATCH 01/12] net: add string to IPv4 parse function
On Tue, Dec 14, 2021 at 06:31:06PM +0100, Morten Brørup wrote: > > From: Ronan Randles [mailto:ronan.rand...@intel.com] > > Sent: Tuesday, 14 December 2021 15.13 > > > > Added function that accepts ip string as a parameter and returns an ip > > address represented by a uint32_t. Relevant unit test for this function > > is also included. > > > > Signed-off-by: Harry van Haaren > > Signed-off-by: Ronan Randles > > --- > > [snip] > > > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h > > index c575250852..188054fda4 100644 > > --- a/lib/net/rte_ip.h > > +++ b/lib/net/rte_ip.h > > @@ -426,6 +426,24 @@ rte_ipv4_udptcp_cksum_verify(const struct > > rte_ipv4_hdr *ipv4_hdr, > > return 0; > > } > > > > +/** > > + * IP address parser. > > + * > > + * @param src_ip > > + * The IP address to be parsed. > > + * @param output_addr > > + * The array in which the parsed digits will be saved. > > + * > > + * @retval 0 > > + * Success. > > + * @retval -1 > > + * Failure due to invalid input arguments. > > + */ > > + > > +__rte_experimental > > +int32_t > > +rte_ip_parse_addr(const char *src_ip, uint32_t *output_addr); > > + > > Good initiative! > > This should set a precedent for to/from string functions, so be careful about > names and calling conventions. > > I have a few suggestions: > > The function should take a parameter to tell if the input string must be > zero-terminated or not. This is highly useful for parsing subnet strings > (e.g. "192.0.2.0/24") and IP range strings (e.g. "192.0.2.2-192.0.2.253"). > > The return value should be the number of characters read from the input > string, and still -1 on error. With this modification, also consider using > the return type ssize_t instead of int32_t. > Interesting point on the "must be zero-terminated" parameter. However, if the return value is the number of characters read, then the user can check for null-termination very easily after the call, and not need the parameter. Therefore, I would suggest having the function always assume chars after the address and let the user check for null if needed afterwards, to keep function simpler. /Bruce
RE: [PATCH 01/12] net: add string to IPv4 parse function
> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Wednesday, 15 December 2021 10.27 > > On Tue, Dec 14, 2021 at 06:31:06PM +0100, Morten Brørup wrote: > > > From: Ronan Randles [mailto:ronan.rand...@intel.com] > > > Sent: Tuesday, 14 December 2021 15.13 > > > > > > Added function that accepts ip string as a parameter and returns an > ip > > > address represented by a uint32_t. Relevant unit test for this > function > > > is also included. > > > > > > Signed-off-by: Harry van Haaren > > > Signed-off-by: Ronan Randles > > > --- > > > > [snip] > > > > > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h > > > index c575250852..188054fda4 100644 > > > --- a/lib/net/rte_ip.h > > > +++ b/lib/net/rte_ip.h > > > @@ -426,6 +426,24 @@ rte_ipv4_udptcp_cksum_verify(const struct > > > rte_ipv4_hdr *ipv4_hdr, > > > return 0; > > > } > > > > > > +/** > > > + * IP address parser. > > > + * > > > + * @param src_ip > > > + * The IP address to be parsed. > > > + * @param output_addr > > > + * The array in which the parsed digits will be saved. > > > + * > > > + * @retval 0 > > > + * Success. > > > + * @retval -1 > > > + * Failure due to invalid input arguments. > > > + */ > > > + > > > +__rte_experimental > > > +int32_t > > > +rte_ip_parse_addr(const char *src_ip, uint32_t *output_addr); > > > + > > > > Good initiative! > > > > This should set a precedent for to/from string functions, so be > careful about names and calling conventions. > > > > I have a few suggestions: > > > > The function should take a parameter to tell if the input string must > be zero-terminated or not. This is highly useful for parsing subnet > strings (e.g. "192.0.2.0/24") and IP range strings (e.g. "192.0.2.2- > 192.0.2.253"). > > > > The return value should be the number of characters read from the > input string, and still -1 on error. With this modification, also > consider using the return type ssize_t instead of int32_t. > > > Interesting point on the "must be zero-terminated" parameter. However, > if > the return value is the number of characters read, then the user can > check > for null-termination very easily after the call, and not need the > parameter. Therefore, I would suggest having the function always assume > chars after the address and let the user check for null if needed > afterwards, to keep function simpler. That would require additional lines of code in the application. I would rather have that additional code inside the utility function. There is no need to keep the function simple.
Re: [PATCH 01/12] net: add string to IPv4 parse function
On Wed, Dec 15, 2021 at 10:35:44AM +0100, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > Sent: Wednesday, 15 December 2021 10.27 > > > > On Tue, Dec 14, 2021 at 06:31:06PM +0100, Morten Brørup wrote: > > > > From: Ronan Randles [mailto:ronan.rand...@intel.com] > > > > Sent: Tuesday, 14 December 2021 15.13 > > > > > > > > Added function that accepts ip string as a parameter and returns an > > ip > > > > address represented by a uint32_t. Relevant unit test for this > > function > > > > is also included. > > > > > > > > Signed-off-by: Harry van Haaren > > > > Signed-off-by: Ronan Randles > > > > --- > > > > > > [snip] > > > > > > > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h > > > > index c575250852..188054fda4 100644 > > > > --- a/lib/net/rte_ip.h > > > > +++ b/lib/net/rte_ip.h > > > > @@ -426,6 +426,24 @@ rte_ipv4_udptcp_cksum_verify(const struct > > > > rte_ipv4_hdr *ipv4_hdr, > > > > return 0; > > > > } > > > > > > > > +/** > > > > + * IP address parser. > > > > + * > > > > + * @param src_ip > > > > + * The IP address to be parsed. > > > > + * @param output_addr > > > > + * The array in which the parsed digits will be saved. > > > > + * > > > > + * @retval 0 > > > > + * Success. > > > > + * @retval -1 > > > > + * Failure due to invalid input arguments. > > > > + */ > > > > + > > > > +__rte_experimental > > > > +int32_t > > > > +rte_ip_parse_addr(const char *src_ip, uint32_t *output_addr); > > > > + > > > > > > Good initiative! > > > > > > This should set a precedent for to/from string functions, so be > > careful about names and calling conventions. > > > > > > I have a few suggestions: > > > > > > The function should take a parameter to tell if the input string must > > be zero-terminated or not. This is highly useful for parsing subnet > > strings (e.g. "192.0.2.0/24") and IP range strings (e.g. "192.0.2.2- > > 192.0.2.253"). > > > > > > The return value should be the number of characters read from the > > input string, and still -1 on error. With this modification, also > > consider using the return type ssize_t instead of int32_t. > > > > > Interesting point on the "must be zero-terminated" parameter. However, > > if > > the return value is the number of characters read, then the user can > > check > > for null-termination very easily after the call, and not need the > > parameter. Therefore, I would suggest having the function always assume > > chars after the address and let the user check for null if needed > > afterwards, to keep function simpler. > > That would require additional lines of code in the application. I would > rather have that additional code inside the utility function. There is no > need to keep the function simple. > Well, it's only an extra item in the error-check conditional, but point taken. I have no strong opinion here.
RE: 19.11.11 patches review and test
> -Original Message- > From: Jiang, YuX > Sent: Tuesday, December 14, 2021 3:14 PM > To: christian.ehrha...@canonical.com; sta...@dpdk.org > Cc: dev@dpdk.org; Abhishek Marathe ; > Akhil Goyal ; Ali Alnubani ; > Walker, Benjamin ; David Christensen > ; Govindharajan, Hariprasad > ; Hemant Agrawal > ; Stokes, Ian ; Jerin > Jacob ; Mcnamara, John ; > Ju-Hyoung Lee ; Kevin Traynor > ; Luca Boccassi ; Pei Zhang > ; pingx...@intel.com; Xu, Qian Q > ; Raslan Darawsheh ; Thomas > Monjalon ; Peng, Yuan ; > Chen, Zhaoyan > Subject: RE: 19.11.11 patches review and test > > > -Original Message- > > From: christian.ehrha...@canonical.com > > > > Sent: Thursday, December 9, 2021 10:43 PM > > To: sta...@dpdk.org > > Cc: dev@dpdk.org; Abhishek Marathe > ; > > Akhil Goyal ; Ali Alnubani ; > > Walker, Benjamin ; David Christensen > > ; Govindharajan, Hariprasad > > ; Hemant Agrawal > > ; Stokes, Ian ; Jerin > > Jacob ; Mcnamara, John > ; > > Ju-Hyoung Lee ; Kevin Traynor > > ; Luca Boccassi ; Pei Zhang > > ; pingx...@intel.com; Xu, Qian Q > > ; Raslan Darawsheh ; Thomas > > Monjalon ; Peng, Yuan ; > > Chen, Zhaoyan > > Subject: 19.11.11 patches review and test > > > > Hi all, > > > > Here is a list of patches targeted for stable release 19.11.11. > > > > The planned date for the final release is 7th January 2021. > > > > Please help with testing and validation of your use cases and report > > any issues/results with reply-all to this mail. For the final release > > the fixes and reported validations will be added to the release notes. > > > > A release candidate tarball can be found at: > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v19.11.11-rc1 > > > > These patches are located at branch 19.11 of dpdk-stable repo: > > https://dpdk.org/browse/dpdk-stable/ > > > > Thanks. > > > > Christian Ehrhardt > > > > --- > Hi Christian, > > We find many build issues on LTS19.11. But all of them have no fix yet. > https://bugs.dpdk.org/show_bug.cgi?id=744 DPDKcoredev UNCO > --- [dpdk-19.11.9-rc3] make build failed on Fedora34 with GCC11 > and build failed on Fedora35 with gcc11.2.1&clang13.0.0 > https://bugs.dpdk.org/show_bug.cgi?id=747 DPDKcoredev UNCO > --- [dpdk-19.11.9-rc3] Meson build failed with ICC-19.1.1 > https://bugs.dpdk.org/show_bug.cgi?id=900 DPDKethdev dev UNCO > --- [19.11.11-rc1] net/nfp build failure with clang 13 > https://bugs.dpdk.org/show_bug.cgi?id=901 DPDKethdev dev UNCO > --- [19.11.11-rc1] net/i40e build failure with make and clang 13 > https://bugs.dpdk.org/show_bug.cgi?id=902 DPDKethdev dev UNCO > --- [19.11.11-rc1] net/ice build failure with make and clang 13 > https://bugs.dpdk.org/show_bug.cgi?id=903 DPDKethdev dev UNCO > --- [19.11.11-rc1] net/ixgbe build failure with make and clang 13 > https://bugs.dpdk.org/show_bug.cgi?id=904 DPDKmeson dev UNCO > --- [dpdk-19.11.11] Meson build has some failures on Fedora35 > with clang 13.0.0 > https://bugs.dpdk.org/show_bug.cgi?id=905 DPDKmeson dev UNCO > --- [dpdk-19.11.11-rc1]Meson&Makefile build failed on > Freebsd13 with gcc10.3.0&clang11.0.1 Update the test status for Intel part. Till now dpdk19.11.11-rc1 test is almost finished. Totally find three bugs for Build test from Intel. # Basic Intel(R) NIC testing * Build: cover the build test combination with latest GCC/Clang/ICC version and the popular OS revision such as Ubuntu20.04, Fedora34, RHEL8.4, etc. - All test done. - Tree bugs are found. https://bugs.dpdk.org/show_bug.cgi?id=904 https://bugs.dpdk.org/show_bug.cgi?id=905 dpdk-19.11.11-rc]KNI build failed used makefile on OpenSuse15.3 with gcc7.5.0&clang11.0.1, has fix. * PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test done. No new issue is found. * VF(i40e, ixgbe): test scenarios including VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test done. No new issue is found. * PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx, etc. - All test done. No new issue is found. * Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test etc. - All test done. No big performance drop. * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc. - All passed. # Basic cryptodev and virtio testing * Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing, etc. - All test done. No new issue is found. * Cryptodev: * Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/ etc. - All test done. * Performance test: test scenarios including Thoughput Performance
[Bug 795] [dpdk-19.11] unit_tests_power/power_cpufreq: unit test failed
https://bugs.dpdk.org/show_bug.cgi?id=795 jiang,yu (yux.ji...@intel.com) changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from jiang,yu (yux.ji...@intel.com) --- Verify passed on dpdk-19.11.11-rc1 commit 928100dd6d30e733be411380fdb78c68a061936c (HEAD, tag: v19.11.11-rc1, origin/19.11) Author: Christian Ehrhardt Date: Thu Dec 9 15:33:57 2021 +0100 version: 19.11.11-rc1 Signed-off-by: Christian Ehrhardt -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH v4 1/2] net: add functions to calculate UDP/TCP cksum in mbuf
On 12/3/2021 5:08 PM, Xiaoyun Li wrote:
Add functions to call rte_raw_cksum_mbuf() to calculate IPv4/6
UDP/TCP checksum in mbuf which can be over multi-segments.
Signed-off-by: Xiaoyun Li
---
doc/guides/rel_notes/release_22_03.rst | 10 ++
lib/net/rte_ip.h | 186 +
lib/net/version.map| 10 ++
3 files changed, 206 insertions(+)
diff --git a/doc/guides/rel_notes/release_22_03.rst
b/doc/guides/rel_notes/release_22_03.rst
index 6d99d1eaa9..7a082c4427 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -55,6 +55,13 @@ New Features
Also, make sure to start the actual text at the margin.
===
+* **Added functions to calculate UDP/TCP checksum in mbuf.**
+ * Added the following functions to calculate UDP/TCP checksum of packets
+which can be over multi-segments:
+- ``rte_ipv4_udptcp_cksum_mbuf()``
+- ``rte_ipv4_udptcp_cksum_mbuf_verify()``
+- ``rte_ipv6_udptcp_cksum_mbuf()``
+- ``rte_ipv6_udptcp_cksum_mbuf_verify()``
Removed Items
-
@@ -84,6 +91,9 @@ API Changes
Also, make sure to start the actual text at the margin.
===
+* net: added experimental functions ``rte_ipv4_udptcp_cksum_mbuf()``,
+ ``rte_ipv4_udptcp_cksum_mbuf_verify()``, ``rte_ipv6_udptcp_cksum_mbuf()``,
+ ``rte_ipv6_udptcp_cksum_mbuf_verify()``
ABI Changes
---
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index c575250852..534f401d26 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -400,6 +400,65 @@ rte_ipv4_udptcp_cksum(const struct rte_ipv4_hdr *ipv4_hdr,
const void *l4_hdr)
return cksum;
}
+/**
+ * @internal Calculate the non-complemented IPv4 L4 checksum of a packet
+ */
+static inline uint16_t
+__rte_ipv4_udptcp_cksum_mbuf(const struct rte_mbuf *m,
+const struct rte_ipv4_hdr *ipv4_hdr,
+uint16_t l4_off)
+{
+ uint16_t raw_cksum;
+ uint32_t cksum;
+
+ if (l4_off > m->pkt_len)
+ return 0;
+
+ if (rte_raw_cksum_mbuf(m, l4_off, m->pkt_len - l4_off, &raw_cksum))
+ return 0;
+
+ cksum = raw_cksum + rte_ipv4_phdr_cksum(ipv4_hdr, 0);
+
+ cksum = ((cksum & 0x) >> 16) + (cksum & 0x);
At times, even after above operation "cksum" might stay above 16-bits,
ex "cksum = 0x1" to start with.
Can we consider using "return __rte_raw_cksum_reduce(cksum);"
+
+ return (uint16_t)cksum;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Compute the IPv4 UDP/TCP checksum of a packet.
+ *
+ * @param m
+ * The pointer to the mbuf.
+ * @param ipv4_hdr
+ * The pointer to the contiguous IPv4 header.
+ * @param l4_off
+ * The offset in bytes to start L4 checksum.
+ * @return
+ * The complemented checksum to set in the L4 header.
+ */
+__rte_experimental
+static inline uint16_t
+rte_ipv4_udptcp_cksum_mbuf(const struct rte_mbuf *m,
+ const struct rte_ipv4_hdr *ipv4_hdr, uint16_t l4_off)
+{
+ uint16_t cksum = __rte_ipv4_udptcp_cksum_mbuf(m, ipv4_hdr, l4_off);
+
+ cksum = ~cksum;
+
+ /*
+* Per RFC 768: If the computed checksum is zero for UDP,
+* it is transmitted as all ones
+* (the equivalent in one's complement arithmetic).
+*/
+ if (cksum == 0 && ipv4_hdr->next_proto_id == IPPROTO_UDP)
+ cksum = 0x;
+
+ return cksum;
+}
+
/**
* Validate the IPv4 UDP or TCP checksum.
*
@@ -426,6 +485,38 @@ rte_ipv4_udptcp_cksum_verify(const struct rte_ipv4_hdr
*ipv4_hdr,
return 0;
}
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Verify the IPv4 UDP/TCP checksum of a packet.
+ *
+ * In case of UDP, the caller must first check if udp_hdr->dgram_cksum is 0
+ * (i.e. no checksum).
+ *
+ * @param m
+ * The pointer to the mbuf.
+ * @param ipv4_hdr
+ * The pointer to the contiguous IPv4 header.
+ * @param l4_off
+ * The offset in bytes to start L4 checksum.
+ * @return
+ * Return 0 if the checksum is correct, else -1.
+ */
+__rte_experimental
+static inline uint16_t
+rte_ipv4_udptcp_cksum_mbuf_verify(const struct rte_mbuf *m,
+ const struct rte_ipv4_hdr *ipv4_hdr,
+ uint16_t l4_off)
+{
+ uint16_t cksum = __rte_ipv4_udptcp_cksum_mbuf(m, ipv4_hdr, l4_off);
+
+ if (cksum != 0x)
+ return -1;
cksum other than 0x, should return error. Is that the intent or I am
missing something obvious.
+
+ return 0;
+}
+
/**
* IPv6 Header
*/
@@ -538,6 +629,68 @@ rte_ipv6_udptcp_cksum(const struct rte_ipv6_hdr *ipv6_hdr,
const void *l4_hdr)
return cksum;
}
+/**
+ * @internal Calculate the
Re: [PATCH v3] eal: allow to exclude memseg from core dump
On Tue, Dec 14, 2021 at 8:49 PM Gaoxiang Liu wrote:
>
> Some DPDK application is allocated storage partition of 8G(or smaller)
> If coredump happens, the application doesn't work because of
> insufficient storage space.
> The patch provides a config that means whether the memseg memory
> is allowed to exclude from core dump.
> The DPDK application can choose to open it according to the actual
> situation.
>
> Fixes: d72e4042c5eb ("mem: exclude unused memory from core dump")
This is patch is a feature, not a fix. So you can remove this
> Cc: sta...@dpdk.org
This is patch is a feature, not a fix. So you can remove this
>
> Signed-off-by: Gaoxiang Liu
>
> ---
> v2:
> * Fixed compile issues.
>
> v3:
> * Fixed review issues. madvise is replaced by eal_mem_set_dump(),
> * and The type of huge_dont_dump_flag has been changed to bool.
> ---
> doc/guides/linux_gsg/linux_eal_parameters.rst | 4
> lib/eal/common/eal_internal_cfg.h | 1 +
> lib/eal/common/eal_options.h | 3 ++-
> lib/eal/linux/eal.c | 4
> lib/eal/linux/eal_memalloc.c | 3 +++
> lib/eal/unix/eal_unix_memory.c| 7 +--
> 6 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst
> b/doc/guides/linux_gsg/linux_eal_parameters.rst
Since you are adding it in unix/eal_unix_memory.c it is applicable for
freebsd too.
Please update options and documentation for freebsd.
> index 74df2611b5..b6805bc6df 100644
> --- a/doc/guides/linux_gsg/linux_eal_parameters.rst
> +++ b/doc/guides/linux_gsg/linux_eal_parameters.rst
> @@ -93,6 +93,10 @@ Memory-related options
>
> Free hugepages back to system exactly as they were originally allocated.
>
> +* ``--memseg-dont-dump``
> +
> +Allow to exclude memseg from core dump.
> +
> Other options
> ~
>
> diff --git a/lib/eal/common/eal_internal_cfg.h
> b/lib/eal/common/eal_internal_cfg.h
> index d6c0470eb8..a7c34b88db 100644
> --- a/lib/eal/common/eal_internal_cfg.h
> +++ b/lib/eal/common/eal_internal_cfg.h
> @@ -87,6 +87,7 @@ struct internal_config {
> /**< user defined mbuf pool ops name */
> unsigned num_hugepage_sizes; /**< how many sizes on this system
> */
> struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES];
> + bool memseg_dont_dump_flag;
> enum rte_iova_mode iova_mode ;/**< Set IOVA mode on this system
> */
> rte_cpuset_t ctrl_cpuset; /**< cpuset for ctrl threads */
> volatile unsigned int init_complete;
> diff --git a/lib/eal/common/eal_options.h b/lib/eal/common/eal_options.h
> index 8e4f7202a2..013aad4cfc 100644
> --- a/lib/eal/common/eal_options.h
> +++ b/lib/eal/common/eal_options.h
> @@ -87,7 +87,8 @@ enum {
> OPT_NO_TELEMETRY_NUM,
> #define OPT_FORCE_MAX_SIMD_BITWIDTH "force-max-simd-bitwidth"
> OPT_FORCE_MAX_SIMD_BITWIDTH_NUM,
> -
> +#define OPT_MEMSEG_DONT_DUMP "memseg-dont-dump"
> + OPT_MEMSEG_DONT_DUMP_NUM,
> OPT_LONG_MAX_NUM
> };
>
> diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
> index 60b4924838..8a47bf758a 100644
> --- a/lib/eal/linux/eal.c
> +++ b/lib/eal/linux/eal.c
> @@ -817,6 +817,10 @@ eal_parse_args(int argc, char **argv)
> internal_conf->match_allocations = 1;
> break;
>
> + case OPT_MEMSEG_DONT_DUMP_NUM:
> + internal_conf->memseg_dont_dump_flag = 1;
> + break;
> +
> default:
> if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
> RTE_LOG(ERR, EAL, "Option %c is not supported
> "
> diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
> index 337f2bc739..8e41537355 100644
> --- a/lib/eal/linux/eal_memalloc.c
> +++ b/lib/eal/linux/eal_memalloc.c
> @@ -663,6 +663,9 @@ alloc_seg(struct rte_memseg *ms, void *addr, int
> socket_id,
> ms->iova = iova;
> ms->socket_id = socket_id;
>
> + if (internal_conf->memseg_dont_dump_flag)
> + eal_mem_set_dump(addr, alloc_sz, false);
> +
> return 0;
>
> mapped:
> diff --git a/lib/eal/unix/eal_unix_memory.c b/lib/eal/unix/eal_unix_memory.c
> index 68ae93bd6e..44227aee95 100644
> --- a/lib/eal/unix/eal_unix_memory.c
> +++ b/lib/eal/unix/eal_unix_memory.c
> @@ -83,10 +83,13 @@ eal_mem_set_dump(void *virt, size_t size, bool dump)
> int flags = dump ? EAL_DODUMP : EAL_DONTDUMP;
> int ret = madvise(virt, size, flags);
> if (ret) {
> - RTE_LOG(DEBUG, EAL, "madvise(%p, %#zx, %d) failed: %s\n",
> + RTE_LOG(INFO, EAL, "madvise(%p, %#zx, %d) failed: %s\n",
> virt, size, flags, strerror(rte_errno));
probably ERR instead of INFO.
> rte_errno = errno;
> - }
> + } else
> + RTE_LOG(INFO, EAL, "madv
Re: [PATCH 00/12] add packet generator library and example app
On Tue, Dec 14, 2021 at 7:42 PM Ronan Randles wrote: > > This patchset introduces a Gen library for DPDK. This library provides an easy > way to generate traffic in order to test software based network components. > > This library enables the basic functionality required in the traffic > generator. > This includes: raw data setting, packet Tx and Rx, creation and destruction > of a > Gen instance and various types of data parsing. > This functionality is implemented in "lib/gen/rte_gen.c". IPv4 parsing > functionality is also added in "lib/net/rte_ip.c", this is then used in the > gen > library. > > A sample app is included in "examples/generator" which shows the use of the > gen > library in making a traffic generator. This can be used to generate traffic by > running the dpdk-generator generator executable. This sample app supports > runtime stats reporting (/gen/stats) and line rate limiting > (/gen/mpps,) through telemetry.py. > > > lib/gen/rte_gen.h | 114 +++ Please check Doxygen syntax across the file. rte_gen_create(), rte_gen_destroy(), rte_gen_packet_parse_string() etc missing proper doxygen synax.
Re: [PATCH 05/12] gen: add raw packet data API and tests
On Tue, Dec 14, 2021 at 7:43 PM Ronan Randles wrote:
>
> From: Harry van Haaren
>
> This commit adds a new API to gen, allowing the caller to set
> raw packet data with a size. Tests are added to test the new
> API with randomized packet data.
>
> Signed-off-by: Harry van Haaren
> ---
> }
>
> @@ -32,9 +53,37 @@ rte_gen_create(struct rte_mempool *mempool)
> void
> rte_gen_destroy(struct rte_gen *gen)
> {
> + rte_pktmbuf_free(gen->base_pkt);
> rte_free(gen);
> }
>
> +
> uint16_t
> rte_gen_rx_burst(struct rte_gen *gen,
> struct rte_mbuf **rx_pkts,
> @@ -45,17 +94,20 @@ rte_gen_rx_burst(struct rte_gen *gen,
> if (err)
> return 0;
>
> - const uint32_t pkt_len = 64;
> + if (!gen->base_pkt)
> + return 0;
> +
> + const uint32_t base_size = gen->base_pkt->pkt_len;
> + const uint8_t *base_data = rte_pktmbuf_mtod(gen->base_pkt, uint8_t *);
I think, the very next feature will be generating packets for
incrementing IP addresses or so. In this case, one packet-based
template will not work.
May we worth consider that use case into API framework first and add support
later for implementation as it may change the complete land space of API to have
better performance. Options like struct rte_gen logical object can have
N templates instead of one is an option on the table. :-)
>
> uint32_t i;
> for (i = 0; i < nb_pkts; i++) {
> struct rte_mbuf *m = rx_pkts[i];
> uint8_t *pkt_data = rte_pktmbuf_mtod(m, uint8_t *);
>
> - memset(pkt_data, 0, pkt_len);
> -
> - m->pkt_len = pkt_len;
> - m->data_len = pkt_len;
> + rte_memcpy(pkt_data, base_data, base_size);
> + m->pkt_len = base_size;
> + m->data_len = base_size;
> }
>
RE: [PATCH 02/12] net: add function to pretty print IPv4
> > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Wednesday, 15 December 2021 04.21 > > > > On Wed, 15 Dec 2021 01:06:14 + > > "Ananyev, Konstantin" wrote: > > > > > > -Original Message- > > > > From: Morten Brørup > > > > Sent: Tuesday, December 14, 2021 5:31 PM > > > > To: Randles, Ronan ; dev@dpdk.org > > > > Cc: Van Haaren, Harry > > > > Subject: RE: [PATCH 02/12] net: add function to pretty print IPv4 > > > > > > > > > From: Ronan Randles [mailto:ronan.rand...@intel.com] > > > > > Sent: Tuesday, 14 December 2021 15.13 > > > > > > > > > > This function accepts an uint32_t representation of an IP address > > and > > > > > produces a string representation stored in a char * buffer. > > Realavent > > > > > unit tests also included. > > > > > > > > > > Signed-off-by: Ronan Randles > > > > > > > > [snip] > > > > > > > > > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h > > > > > index 188054fda4..e46f0b41ba 100644 > > > > > --- a/lib/net/rte_ip.h > > > > > +++ b/lib/net/rte_ip.h > > > > > @@ -444,6 +444,26 @@ __rte_experimental > > > > > int32_t > > > > > rte_ip_parse_addr(const char *src_ip, uint32_t *output_addr); > > > > > > > > > > + > > > > > +/** > > > > > + * Print IP address from 32 bit int into char * buffer. > > > > > + * > > > > > + * @param ip_addr > > > > > + * ip address to be printed. > > > > > + * @param buffer > > > > > + * The buffer the string will be saved into. > > > > > + * @param buffer_size > > > > > + * size of buffer to be used. > > > > > + * > > > > > + * @retval 0 > > > > > + * Success. > > > > > + * @retval -1 > > > > > + * Failure due to invalid input arguments. > > > > > + */ > > > > > +__rte_experimental > > > > > +int32_t > > > > > +rte_ip_print_addr(uint32_t ip_addr, char *buffer, uint32_t > > > > > buffer_size); > > > > > + > > > > > > > > In continuation of my email reply about the IPv4 parse function... > > > > > > > > I have a few suggestions to the IPv4 print function too: > > > > > > > > The return value should be the number of characters written to the > > output string, and still -1 on error. With this modification, you could > > > > use the return type ssize_t instead of int32_t. > > > > > > > > Furthermore, I would prefer having the parameters in the same order > > as snprintf(): char *str, size_t size, const uint32_t ip_addr. Please > > > > also notice the suggested changed type for the size, and the const > > added to the ip_addr. > > > > > > > Honestly, I don't understand why we need to introduce such functions > > > inside DPDK at all. > > > What's wrong with existing standard ones: inet_ntop() and > > inet_pton()? > > > > Agreed, I see no added value in reinventing here > > I think that DPDK functions for converting all sorts of types to/from strings > would be useful; not only IP addresses, but also MAC addresses, > TCP/UDP port numbers and VLAN IDs. For MACs we already have: rte_ether_format_addr()/rte_ether_unformat_addr() > > If you don't like IP address string conversion functions in the net library, > DPDK could have a string conversions library. That library could > expose a multitude of APIs for the same purpose, so the application can use > the API that best fits each application use. I don’t mind to add new functions into net lib, if they are useful ones. But for that particular case, I just don't see what is the reason to develop and maintain our own functions while existing analogues: - are well known, widely adopted and field proven - do provide the same or even more comprehensive functionality
Re: 19.11.11 patches review and test
On Wed, Dec 15, 2021 at 12:04 PM Jiang, YuX wrote: > > > -Original Message- > > From: Jiang, YuX > > Sent: Tuesday, December 14, 2021 3:14 PM > > To: christian.ehrha...@canonical.com; sta...@dpdk.org > > Cc: dev@dpdk.org; Abhishek Marathe ; > > Akhil Goyal ; Ali Alnubani ; > > Walker, Benjamin ; David Christensen > > ; Govindharajan, Hariprasad > > ; Hemant Agrawal > > ; Stokes, Ian ; Jerin > > Jacob ; Mcnamara, John ; > > Ju-Hyoung Lee ; Kevin Traynor > > ; Luca Boccassi ; Pei Zhang > > ; pingx...@intel.com; Xu, Qian Q > > ; Raslan Darawsheh ; Thomas > > Monjalon ; Peng, Yuan ; > > Chen, Zhaoyan > > Subject: RE: 19.11.11 patches review and test > > > > > -Original Message- > > > From: christian.ehrha...@canonical.com > > > > > > Sent: Thursday, December 9, 2021 10:43 PM > > > To: sta...@dpdk.org > > > Cc: dev@dpdk.org; Abhishek Marathe > > ; > > > Akhil Goyal ; Ali Alnubani ; > > > Walker, Benjamin ; David Christensen > > > ; Govindharajan, Hariprasad > > > ; Hemant Agrawal > > > ; Stokes, Ian ; Jerin > > > Jacob ; Mcnamara, John > > ; > > > Ju-Hyoung Lee ; Kevin Traynor > > > ; Luca Boccassi ; Pei Zhang > > > ; pingx...@intel.com; Xu, Qian Q > > > ; Raslan Darawsheh ; Thomas > > > Monjalon ; Peng, Yuan ; > > > Chen, Zhaoyan > > > Subject: 19.11.11 patches review and test > > > > > > Hi all, > > > > > > Here is a list of patches targeted for stable release 19.11.11. > > > > > > The planned date for the final release is 7th January 2021. > > > > > > Please help with testing and validation of your use cases and report > > > any issues/results with reply-all to this mail. For the final release > > > the fixes and reported validations will be added to the release notes. > > > > > > A release candidate tarball can be found at: > > > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v19.11.11-rc1 > > > > > > These patches are located at branch 19.11 of dpdk-stable repo: > > > https://dpdk.org/browse/dpdk-stable/ > > > > > > Thanks. > > > > > > Christian Ehrhardt > > > > > > --- > > Hi Christian, > > > > We find many build issues on LTS19.11. But all of them have no fix yet. > > https://bugs.dpdk.org/show_bug.cgi?id=744 DPDKcoredev UNCO > > --- [dpdk-19.11.9-rc3] make build failed on Fedora34 with GCC11 > > and build failed on Fedora35 with gcc11.2.1&clang13.0.0 > > https://bugs.dpdk.org/show_bug.cgi?id=747 DPDKcoredev UNCO > > --- [dpdk-19.11.9-rc3] Meson build failed with ICC-19.1.1 > > https://bugs.dpdk.org/show_bug.cgi?id=900 DPDKethdev dev UNCO > > --- [19.11.11-rc1] net/nfp build failure with clang 13 > > https://bugs.dpdk.org/show_bug.cgi?id=901 DPDKethdev dev UNCO > > --- [19.11.11-rc1] net/i40e build failure with make and clang 13 > > https://bugs.dpdk.org/show_bug.cgi?id=902 DPDKethdev dev UNCO > > --- [19.11.11-rc1] net/ice build failure with make and clang 13 > > https://bugs.dpdk.org/show_bug.cgi?id=903 DPDKethdev dev UNCO > > --- [19.11.11-rc1] net/ixgbe build failure with make and clang 13 > > https://bugs.dpdk.org/show_bug.cgi?id=904 DPDKmeson dev UNCO > > --- [dpdk-19.11.11] Meson build has some failures on Fedora35 > > with clang 13.0.0 > > https://bugs.dpdk.org/show_bug.cgi?id=905 DPDKmeson dev UNCO > > --- [dpdk-19.11.11-rc1]Meson&Makefile build failed on > > Freebsd13 with gcc10.3.0&clang11.0.1 > > Update the test status for Intel part. Till now dpdk19.11.11-rc1 test is > almost finished. Thank you, the new bugs are all with new toolchains. An effort to fix those is ongoing right now. So far it seems no other issues got identified by you or anyone else. \o/ > Totally find three bugs for Build test from Intel. > # Basic Intel(R) NIC testing > * Build: cover the build test combination with latest GCC/Clang/ICC version > and the popular OS revision such as Ubuntu20.04, Fedora34, RHEL8.4, etc. > - All test done. > - Tree bugs are found. > https://bugs.dpdk.org/show_bug.cgi?id=904 > https://bugs.dpdk.org/show_bug.cgi?id=905 > dpdk-19.11.11-rc]KNI build failed used makefile on OpenSuse15.3 with > gcc7.5.0&clang11.0.1, has fix. > * PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum > offload/VLAN/VXLAN, etc. > - All test done. No new issue is found. > * VF(i40e, ixgbe): test scenarios including > VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > - All test done. No new issue is found. > * PF/VF(ice): test scenarios including Switch features/Package > Management/Flow Director/Advanced Tx, etc. > - All test done. No new issue is found. > * Intel NIC single core/NIC performance: test scenarios including PF/VF > single core performance test etc. > - All test done. No big performance drop. > * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - > QAT&SW/FIB library, etc. > - All passed. > # Basic cryptodev and
Re: 19.11.11 patches review and test
On Tue, Dec 14, 2021 at 3:52 PM Ferruh Yigit wrote: > > On 12/14/2021 2:46 PM, Christian Ehrhardt wrote: > > On Tue, Dec 14, 2021 at 2:58 PM Christian Ehrhardt > > wrote: > >> > >> On Tue, Dec 14, 2021 at 2:10 PM Ferruh Yigit > >> wrote: > >>> > >>> On 12/14/2021 11:39 AM, Christian Ehrhardt wrote: > On Tue, Dec 14, 2021 at 11:13 AM Ferruh Yigit > wrote: > > > > On 12/14/2021 7:44 AM, Christian Ehrhardt wrote: > >> On Tue, Dec 14, 2021 at 6:49 AM Kalesh Anakkur Purayil > >> wrote: > >> > >> [snip] > >> > > [Kalesh] Yes, i am seeing the same error. I used make command to > > build dpdk, not meson. > > The back ported commit you mentioned takes care of meson build only > > I think. > > > > I see, make build is failing, and yes the fix is only for the meson. > I will check the make build and will send a fix for it. > >>> > >>> [Kalesh]: looks like the below changes fixes the issue. I tried only > >>> on SLES15 SP3 and not on other SLES flavors. > >>> > >>> diff --git a/kernel/linux/kni/Makefile b/kernel/linux/kni/Makefile > >>> index 595bac2..bf0efab 100644 > >>> --- a/kernel/linux/kni/Makefile > >>> +++ b/kernel/linux/kni/Makefile > >>> @@ -16,6 +16,16 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include > >>> MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h > >>> MODULE_CFLAGS += -Wall -Werror > >>> > >>> +# > >>> +# Use explicit 'source' folder for header path. In SUSE 'source' is > >>> not linked to 'build' folder. > >>> +# > >>> +ifdef CONFIG_SUSE_KERNEL > >>> + KSRC = /lib/modules/$(shell uname -r)/source > >>> + ifneq ($(shell grep -A 1 "ndo_tx_timeout" > >>> $(KSRC)/include/linux/netdevice.h | grep -o txqueue),) > >>> + MODULE_CFLAGS += -DHAVE_TX_TIMEOUT_TXQUEUE > >>> + endif > >>> +endif > >> > >> Back in the day we tried various "is Suse and kernel version x.y" > >> approaches, but they failed as there was no clear version throughout > >> all of the Suse streams (leap, tumbleweed, sles) that worked well for > >> all. > >> This change here follows the upstream approach of "just check if it is > >> there". > >> > >> I've applied this to 19.11 and did test builds across various > >> distributions: > >> 1. no non-suse build changed > >> 2. suse builds stayed as-is or improved > >> Formerly failing: > >> openSUSE_Factory_ARM aarch64 > >> SLE_15 x86_64 -> now working > >> openSUSE_Leap_15.3 x86_64 -> now working > >> openSUSE_Tumbleweed x86_64 -> still failing > >> Formerly working: > >> SLE_12_SP4 x86_64 ppc64le -> still fine > >> openSUSE_Factory_ARM armv7l -> still fine > >> openSUSE_Leap_15.2 x86_64 -> still fine > >> > > > > Thanks Kalesh for the fix, and thanks Christian for testing. > > > > I was expecting this approach will fix all builds, after patch only > > 'openSUSE_Tumbleweed' is failing, right? I will check it. > > As just discussed on IRC, yes and the log for that is at > https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/openSUSE_Tumbleweed/x86_64 > > It also is affected by an issue around -Werror=implicit-fallthrough, > so even with KNI fixed it likely is going to fail. > > > And I think you need the fix as a patch anyway, @Kalesh are you > > planning to send the patch? > > I don't need it, as I have already grabbed and preliminary added it: > https://github.com/cpaelzer/dpdk-stable-queue/commit/d43fa3e198c08a3a76d70f4565b31ad3ab5f29c4 > > But surely, once/If you come up with a full patch that also includes > tumbleweed I can replace it with yours. > > >>> > >>> 'tumbleweed' error is odd, it complains about macro being redefined, > >>> not sure why only in this platform we are getting an error. > >>> > >>> Macro is only defined in one place, but indeed header file included > >>> multiple times, one direct and one indirect, so macro defined multiple > >>> times but without value, so it should be OK and it is OK for other > >>> platforms, it is defined as: > >>> #define HAVE_TX_TIMEOUT_TXQUEUE > >>> > >>> Another option is that macro is defined in some other header file, > >>> although I think that is very unlikely, can you please test with > >>> below change to rule out that option: > >> > >> I'm testing that and will let you know in a bit ... > > > > Hi Ferruh, > > with your change the build now works. > > So indeed the symbol might have been defined elsewhere. > > > > Interesting, this is self note to prefix 'RTE_' future macros. While generally an interesting Idea I do not know what I saw yesterday. I have rebuilt it three times today and must say that other than I said before - i
RE: [PATCH] ring: fix overflow in memory size calcuation
> Parameters count and esize are both unsigned int, and their product can
> legally exceed unsigned int and lead to runtime access violation.
>
> Fixes: cc4b218790f6 ("ring: support configurable element size")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Zhihong Wang
> ---
> lib/ring/rte_ring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
> index f17bd966be..d1b80597af 100644
> --- a/lib/ring/rte_ring.c
> +++ b/lib/ring/rte_ring.c
> @@ -75,7 +75,7 @@ rte_ring_get_memsize_elem(unsigned int esize, unsigned int
> count)
> return -EINVAL;
> }
>
> - sz = sizeof(struct rte_ring) + count * esize;
> + sz = sizeof(struct rte_ring) + (ssize_t)count * esize;
> sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> return sz;
> }
> --
Acked-by: Konstantin Ananyev
> 2.11.0
Re: [PATCH 00/12] add packet generator library and example app
On Wed, Dec 15, 2021 at 06:01:23PM +0530, Jerin Jacob wrote: > On Tue, Dec 14, 2021 at 7:42 PM Ronan Randles wrote: > > > > This patchset introduces a Gen library for DPDK. This library provides an > > easy > > way to generate traffic in order to test software based network components. > > > > This library enables the basic functionality required in the traffic > > generator. > > This includes: raw data setting, packet Tx and Rx, creation and destruction > > of a > > Gen instance and various types of data parsing. > > This functionality is implemented in "lib/gen/rte_gen.c". IPv4 parsing > > functionality is also added in "lib/net/rte_ip.c", this is then used in the > > gen > > library. > > > > A sample app is included in "examples/generator" which shows the use of the > > gen > > library in making a traffic generator. This can be used to generate traffic > > by > > running the dpdk-generator generator executable. This sample app supports > > runtime stats reporting (/gen/stats) and line rate limiting > > (/gen/mpps,) through telemetry.py. > > > > > > lib/gen/rte_gen.h | 114 +++ > > Please check Doxygen syntax across the file. rte_gen_create(), > rte_gen_destroy(), > rte_gen_packet_parse_string() etc missing proper doxygen synax. If you do a build with "-Denable_docs=true -Dwerror" meson options set, these should all be flagged on build. [If they aren't, we should fix!] /Bruce
Re: [PATCH v3] eal: allow to exclude memseg from core dump
2021-12-15 17:36 (UTC+0530), Jerin Jacob:
[...]
> > diff --git a/lib/eal/unix/eal_unix_memory.c b/lib/eal/unix/eal_unix_memory.c
> > index 68ae93bd6e..44227aee95 100644
> > --- a/lib/eal/unix/eal_unix_memory.c
> > +++ b/lib/eal/unix/eal_unix_memory.c
> > @@ -83,10 +83,13 @@ eal_mem_set_dump(void *virt, size_t size, bool dump)
> > int flags = dump ? EAL_DODUMP : EAL_DONTDUMP;
> > int ret = madvise(virt, size, flags);
> > if (ret) {
> > - RTE_LOG(DEBUG, EAL, "madvise(%p, %#zx, %d) failed: %s\n",
> > + RTE_LOG(INFO, EAL, "madvise(%p, %#zx, %d) failed: %s\n",
> > virt, size, flags, strerror(rte_errno));
>
> probably ERR instead of INFO.
>
>
> > rte_errno = errno;
> > - }
> > + } else
> > + RTE_LOG(INFO, EAL, "madvise(%p, %#zx, %d) success: %s\n",
> > + virt, size, flags, __func__);
>
> This should be DEBUG. Not INFO.
Usually errors from OS API are reported as DEBUG in EAL,
so the first one should also remain DEBUG.
Re: 19.11.11 patches review and test
On 12/15/2021 1:17 PM, Christian Ehrhardt wrote: On Tue, Dec 14, 2021 at 3:52 PM Ferruh Yigit wrote: On 12/14/2021 2:46 PM, Christian Ehrhardt wrote: On Tue, Dec 14, 2021 at 2:58 PM Christian Ehrhardt wrote: On Tue, Dec 14, 2021 at 2:10 PM Ferruh Yigit wrote: On 12/14/2021 11:39 AM, Christian Ehrhardt wrote: On Tue, Dec 14, 2021 at 11:13 AM Ferruh Yigit wrote: On 12/14/2021 7:44 AM, Christian Ehrhardt wrote: On Tue, Dec 14, 2021 at 6:49 AM Kalesh Anakkur Purayil wrote: [snip] [Kalesh] Yes, i am seeing the same error. I used make command to build dpdk, not meson. The back ported commit you mentioned takes care of meson build only I think. I see, make build is failing, and yes the fix is only for the meson. I will check the make build and will send a fix for it. [Kalesh]: looks like the below changes fixes the issue. I tried only on SLES15 SP3 and not on other SLES flavors. diff --git a/kernel/linux/kni/Makefile b/kernel/linux/kni/Makefile index 595bac2..bf0efab 100644 --- a/kernel/linux/kni/Makefile +++ b/kernel/linux/kni/Makefile @@ -16,6 +16,16 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h MODULE_CFLAGS += -Wall -Werror +# +# Use explicit 'source' folder for header path. In SUSE 'source' is not linked to 'build' folder. +# +ifdef CONFIG_SUSE_KERNEL + KSRC = /lib/modules/$(shell uname -r)/source + ifneq ($(shell grep -A 1 "ndo_tx_timeout" $(KSRC)/include/linux/netdevice.h | grep -o txqueue),) + MODULE_CFLAGS += -DHAVE_TX_TIMEOUT_TXQUEUE + endif +endif Back in the day we tried various "is Suse and kernel version x.y" approaches, but they failed as there was no clear version throughout all of the Suse streams (leap, tumbleweed, sles) that worked well for all. This change here follows the upstream approach of "just check if it is there". I've applied this to 19.11 and did test builds across various distributions: 1. no non-suse build changed 2. suse builds stayed as-is or improved Formerly failing: openSUSE_Factory_ARM aarch64 SLE_15 x86_64 -> now working openSUSE_Leap_15.3 x86_64 -> now working openSUSE_Tumbleweed x86_64 -> still failing Formerly working: SLE_12_SP4 x86_64 ppc64le -> still fine openSUSE_Factory_ARM armv7l -> still fine openSUSE_Leap_15.2 x86_64 -> still fine Thanks Kalesh for the fix, and thanks Christian for testing. I was expecting this approach will fix all builds, after patch only 'openSUSE_Tumbleweed' is failing, right? I will check it. As just discussed on IRC, yes and the log for that is at https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/openSUSE_Tumbleweed/x86_64 It also is affected by an issue around -Werror=implicit-fallthrough, so even with KNI fixed it likely is going to fail. And I think you need the fix as a patch anyway, @Kalesh are you planning to send the patch? I don't need it, as I have already grabbed and preliminary added it: https://github.com/cpaelzer/dpdk-stable-queue/commit/d43fa3e198c08a3a76d70f4565b31ad3ab5f29c4 But surely, once/If you come up with a full patch that also includes tumbleweed I can replace it with yours. 'tumbleweed' error is odd, it complains about macro being redefined, not sure why only in this platform we are getting an error. Macro is only defined in one place, but indeed header file included multiple times, one direct and one indirect, so macro defined multiple times but without value, so it should be OK and it is OK for other platforms, it is defined as: #define HAVE_TX_TIMEOUT_TXQUEUE Another option is that macro is defined in some other header file, although I think that is very unlikely, can you please test with below change to rule out that option: I'm testing that and will let you know in a bit ... Hi Ferruh, with your change the build now works. So indeed the symbol might have been defined elsewhere. Interesting, this is self note to prefix 'RTE_' future macros. While generally an interesting Idea I do not know what I saw yesterday. I have rebuilt it three times today and must say that other than I said before - it does not work with RTE_*. This was more expected result :) Is there a way to debug that environment? Actually even worse than before, with RTE_.. even opensuse_leap15.3 and SLES15 fail again :-/ https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/openSUSE_Tumbleweed/x86_64 It still fails later with the "-Werror=implicit-fallthrough=" but that is a different problem => https://bugs.dpdk.org/show_bug.cgi?id=907 Yep, this is igb_uio error, I assigned the bug to myself and will look at it. Ferruh - are you ok if I merge your suggestion with the backport I got from Kalesh? Sure. But would you mind sending the final patch to the stable mail list as record? Or I can do the same if you prefer? diff --git a/kernel/linux/kni/com
Re: 20.11.4 patches review and test
On Fri, 2021-12-10 at 11:35 +, Jiang, YuX wrote: > > -Original Message- > > From: Jiang, YuX > > Sent: Thursday, December 9, 2021 6:01 PM > > To: Xueming Li ; sta...@dpdk.org; Lin, Xueqin > > > > Cc: dev@dpdk.org; Abhishek Marathe > > ; > > Ali Alnubani ; Walker, Benjamin > > ; David Christensen > > ; Govindharajan, Hariprasad > > ; Hemant Agrawal > > ; Stokes, Ian ; Jerin > > Jacob ; Mcnamara, John > > ; > > Ju-Hyoung Lee ; Kevin Traynor > > ; Luca Boccassi ; Pei Zhang > > ; Xu, Qian Q ; Raslan > > Darawsheh ; Thomas Monjalon > > ; Peng, Yuan ; Chen, > > Zhaoyan > > Subject: RE: 20.11.4 patches review and test > > > > > -Original Message- > > > From: Xueming Li > > > Sent: Tuesday, December 7, 2021 12:15 AM > > > To: sta...@dpdk.org > > > Cc: xuemi...@nvidia.com; dev@dpdk.org; Abhishek Marathe > > > ; Ali Alnubani > > > ; > > > Walker, Benjamin ; David Christensen > > > ; Govindharajan, Hariprasad > > > ; Hemant Agrawal > > > ; Stokes, Ian ; > > > Jerin > > > Jacob ; Mcnamara, John > > ; > > > Ju-Hyoung Lee ; Kevin Traynor > > > ; Luca Boccassi ; Pei > > > Zhang > > > ; Xu, Qian Q ; Raslan > > > Darawsheh ; Thomas Monjalon > > ; > > > Peng, Yuan ; Chen, Zhaoyan > > > > > > Subject: 20.11.4 patches review and test > > > > > > Hi all, > > > > > > Here is a list of patches targeted for stable release 20.11.4. > > > > > > The planned date for the final release is 31th December. > > > > > > Please help with testing and validation of your use cases and > > > report > > > any issues/results with reply-all to this mail. For the final > > > release > > > the fixes and reported validations will be added to the release > > > notes. > > > > > > A release candidate tarball can be found at: > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A% > > > 2F%2Fdpdk.org%2Fbrowse%2Fdpdk-stable%2Ftag%2F%3Fid%3Dv20.11.4- > > > rc1&data=04%7C01%7Cxuemingl%40nvidia.com%7Cc9cdc823fce64be118 > > > 0908d9bbd13e8a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63774 > > > 7329661244261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > > > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DtlL0BYV > > > vWm7JE9JV%2BliWzq6R%2FHmKRSNKbc10nmF81Q%3D&reserved=0 > > > > > > These patches are located at branch 20.11 of dpdk-stable repo: > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A% > > > 2F%2Fdpdk.org%2Fbrowse%2Fdpdk- > > > stable%2F&data=04%7C01%7Cxuemingl%40nvidia.com%7Cc9cdc823fce6 > > > 4be1180908d9bbd13e8a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7 > > > C637747329661244261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > > > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KO > > > 3YKk3gXS%2B73gMdQf9MFohT9q55YiDW8df%2F12ZepMs%3D&reserved=0 > > > > > > Thanks. > > > > > > Xueming Li > > > > > Update the test status for Intel part. Till now dpdk20.11.4-rc1 > > test execution > > rate is 80%. Currently, find three bugs, two bugs have fix now. > > # Basic Intel(R) NIC testing > > * Build or compile: > > *Build: cover the build test combination with latest > > GCC/Clang/ICC > > version and the popular OS revision such as Ubuntu20.04, Fedora34, > > RHEL8.4, > > etc. > > - All test done. > > - Two bugs are found in 20.11.4-rc1. > > - dpdk-20.11.4]kernel/linux/kni/rte_kni.ko > > build > > failed on OpenSuse15.3 with gcc7.5.0&clang11.0.1 > > - fix link: > > http://inbox.dpdk.org/stable/20211208103410.835542-1- > > ferruh.yi...@intel.com/T/#u , verify passed by Intel > > - > > https://bugs.dpdk.org/show_bug.cgi?id=894 > > [dpdk-20.11.4] > > lib/librte_eal.a.p/librte_eal_common_rte_random.c.obj build > > failed on WIN10 with clang8.0.0 > > - fix link: > > http://inbox.dpdk.org/stable/20211207141644.369624-1- > > dmitry.kozl...@gmail.com/T/#u, verify passed by Intel > > * PF(i40e, ixgbe): test scenarios including > > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > > - All test done. No new issue is found. > > * VF(i40e, ixgbe): test scenarios including VF- > > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > > > > - All test done. No new issue is found. > > * PF/VF(ice): test scenarios including Switch > > features/Package > > Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Share > > code update/Flexible Descriptor, etc. > > - Execution rate is 80%. No new issue is found. > > * Intel NIC single core/NIC performance: test scenarios > > including > > PF/VF single core performance test, RFC2544 Zero packet loss > > performance > > test, etc. > > - Execution rate is 50%. No big performance drop. > > * IPsec: test scenarios including ipsec/ipsec-gw/ipsec > > library basic > > test - QAT&SW/FIB library, etc. > > - All passed. > > # Basic cryptodev and virtio testing > > * Virtio: both function and performance test
Re: 20.11.4 patches review and test
Hi Pei, Appreciate you and Redhat contribution! On Mon, 2021-12-13 at 22:27 +0800, Pei Zhang wrote: > Hello Xueming, > > The testing with dpdk 20.11.4-rc1 from Red Hat looks good. We tested > below 20 scenarios and all got PASS on RHEL8: > > (1)Guest with device assignment(PF) throughput testing(1G hugepage > size): PASS > (2)Guest with device assignment(PF) throughput testing(2M hugepage > size) : PASS > (3)Guest with device assignment(VF) throughput testing: PASS > (4)PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS > (5)PVP vhost-user 2Q throughput testing: PASS > (6)PVP vhost-user 1Q - cross numa node throughput testing: PASS > (7)Guest with vhost-user 2Q throughput testing: PASS > (8)vhost-user reconnect with dpdk-client, qemu-server: qemu > reconnect: PASS > (9)vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: > PASS > (10)PVP 1Q live migration testing: PASS > (11)PVP 1Q post copy live migration testing: PASS > (12)PVP 1Q cross numa node live migration testing: PASS > (13)Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS > (14)Guest with ovs+dpdk+vhost-user 1Q post copy live migration > testing: PASS > (15)Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): > PASS > (16)Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS > (17)Guest with ovs+dpdk+vhost-user 2Q post copy live migration > testing: PASS > (18)Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS > (19)Host PF + DPDK testing: PASS > (20)Host VF + DPDK testing: PASS > > Versions: > kernel 4.18 > qemu 6.1 > > dpdk: git://dpdk.org/dpdk-stable > branch: remotes/origin/20.11 > # git log -1 > commit bab4318634e0d2276e8bae5ea18789cfda813c70 (HEAD, tag: v20.11.4- > rc1, origin/20.11) > Author: Xueming Li > Date: Tue Dec 7 00:02:07 2021 +0800 > > version: 20.11.4-rc1 > > Signed-off-by: Xueming Li > > > NICs: X540-AT2 NIC(ixgbe, 10G) > > Best regards, > > Pei > > > > On Tue, Dec 7, 2021 at 12:16 AM Xueming Li > wrote: > > Hi all, > > > > Here is a list of patches targeted for stable release 20.11.4. > > > > The planned date for the final release is 31th December. > > > > Please help with testing and validation of your use cases and > > report > > any issues/results with reply-all to this mail. For the final > > release > > the fixes and reported validations will be added to the release > > notes. > > > > A release candidate tarball can be found at: > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.4-rc1 > > > > These patches are located at branch 20.11 of dpdk-stable repo: > > https://dpdk.org/browse/dpdk-stable/ > > > > Thanks. > > > > Xueming Li > > > > --- > > Ajit Khaparde (5): > > net/bnxt: update ring group after ring stop start > > net/bnxt: fix Tx queue startup state > > net/bnxt: fix memzone free for Tx and Rx rings > > net/bnxt: fix tunnel port accounting > > doc: update NIC feature matrix for bnxt > > > > Alexander Bechikov (1): > > mbuf: fix dump of dynamic fields and flags > > > > Alexander Kozyrev (3): > > net/mlx5: fix mbuf replenishment check for zipped CQE > > net/mlx5: fix GRE flow item matching > > net/mlx5: fix GENEVE and VXLAN-GPE flow item matching > > > > Alvin Zhang (4): > > app/testpmd: update forward engine beginning > > app/testpmd: fix txonly forwarding > > net/i40e: fix Rx packet statistics > > net/iavf: fix pointer of meta data > > > > Anatoly Burakov (3): > > vfio: fix FreeBSD clear group stub > > vfio: fix FreeBSD documentation > > vfio: set errno on unsupported OS > > > > Andrew Rybchenko (4): > > mempool: deprecate unused physical page defines > > drivers/net: remove queue xstats auto-fill flag > > ethdev: forbid closing started device > > common/sfc_efx: fix debug compilation control > > > > Anoob Joseph (4): > > examples/ipsec-secgw: fix parsing of flow queue > > test/crypto: skip plain text compare for null cipher > > test/crypto: fix missing return checks > > common/cpt: fix KASUMI input length > > > > Arek Kusztal (2): > > crypto/qat: fix status in RSA decryption > > crypto/qat: fix uncleared cookies after operation > > > > Baruch Siach (1): > > net/af_xdp: fix zero-copy Tx queue drain > > > > Ben Magistro (2): > > doc: fix bonding driver name > > net/i40e: fix i40evf device initialization > > > > Ben Pfaff (1): > > doc: fix numbers power of 2 in LPM6 guide > > > > Bing Zhao (3): > > net/mlx5: fix flow tables double release > > net/mlx5: fix RETA update without stopping device > > vdpa/mlx5: fix mkey creation check > > > > Bruce Richardson (5): > > usertools: fix handling EOF for telemetry input pipe > > eal/freebsd: lock memory device to prevent conflicts > > test/mem: fix memory autotests on FreeBSD > > eal/freebsd: ignore in-memory option > >
Re: [PATCH v3] eal: allow to exclude memseg from core dump
2021-12-14 23:18 (UTC+0800), Gaoxiang Liu: > Some DPDK application is allocated storage partition of 8G(or smaller) > If coredump happens, the application doesn't work because of > insufficient storage space. > The patch provides a config that means whether the memseg memory > is allowed to exclude from core dump. > The DPDK application can choose to open it according to the actual > situation. Does it need to be a DPDK option? If eal_mem_set_dump() is exposed as rte_mem_set_dump(), this feature can be implemented by the application using rte_mem_event_callback_register(). On Linux only and for all hugepages (not only DPDK ones), administrator can reset bits 5 and 6 of /proc/[pid]/core_filter to solve the task without any programming at all. https://man7.org/linux/man-pages/man5/core.5.html [...] > diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst > b/doc/guides/linux_gsg/linux_eal_parameters.rst > index 74df2611b5..b6805bc6df 100644 > --- a/doc/guides/linux_gsg/linux_eal_parameters.rst > +++ b/doc/guides/linux_gsg/linux_eal_parameters.rst > @@ -93,6 +93,10 @@ Memory-related options > > Free hugepages back to system exactly as they were originally allocated. > > +* ``--memseg-dont-dump`` > + > +Allow to exclude memseg from core dump. > + "Memory segment" is something that is understood by programmers, not users. Suggesting --no-huge-dump, in line with --no-huge and --huge-unlink.
[PATCH 0/7] net/bonding: fixes and LACP short timeout
This patchset makes the following changes to net/bonding: - Clean up minor errors in spelling, whitespace, C++ wrappers, and comments. - Replace directly overwriting of slave port's rte_eth_conf by copying it, but only updating it via rte_eth_dev_configure(). - Make minor changes to allocation of mbuf pool and rx/tx rings. - Add support for enabling LACP short timeout, i.e., link partner can use fast periodic time interval between transmits. - Add LACP short timeout to tests. - Include bond_8023ad and bond_alb in doxygen. Robert Sanford (7): net/bonding: fix typos and whitespace net/bonding: fix bonded dev configuring slave dev net/bonding: change mbuf pool and ring allocation net/bonding: support enabling LACP short timeout net/bonding: add LACP short timeout to tests net/bonding: add bond_8023ad and bond_alb to doc Remove self from Timers maintainers. MAINTAINERS | 1 - app/test-pmd/cmdline.c| 81 ++- app/test/test_link_bonding_mode4.c| 93 +++ doc/api/doxy-api-index.md | 2 + drivers/net/bonding/eth_bond_8023ad_private.h | 13 ++-- drivers/net/bonding/rte_eth_bond_8023ad.c | 64 -- drivers/net/bonding/rte_eth_bond_8023ad.h | 18 -- drivers/net/bonding/rte_eth_bond_pmd.c| 43 +++-- 8 files changed, 245 insertions(+), 70 deletions(-) -- 2.7.4
[PATCH 1/7] net/bonding: fix typos and whitespace
- Clean up minor typos in comments, strings, and private names.
- Fix whitespace in log messages and function formatting (open brace
after a new line).
- Move closing C++ wrapper to the end of rte_eth_bond_8023ad.h.
Signed-off-by: Robert Sanford
---
app/test-pmd/cmdline.c| 4 ++--
app/test/test_link_bonding_mode4.c| 28 +--
drivers/net/bonding/eth_bond_8023ad_private.h | 10 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 22 ++---
drivers/net/bonding/rte_eth_bond_8023ad.h | 15 +++---
drivers/net/bonding/rte_eth_bond_pmd.c| 13 -
6 files changed, 48 insertions(+), 44 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6e10afe..9fd2c2a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -630,8 +630,8 @@ static void cmd_help_long_parsed(void *parsed_result,
"set bonding mac_addr (port_id) (address)\n"
" Set the MAC address of a bonded device.\n\n"
- "set bonding mode IEEE802.3AD aggregator policy
(port_id) (agg_name)"
- " Set Aggregation mode for IEEE802.3AD (mode 4)"
+ "set bonding mode IEEE802.3AD aggregator policy
(port_id) (agg_name)\n"
+ " Set Aggregation mode for IEEE802.3AD (mode
4)\n\n"
"set bonding balance_xmit_policy (port_id)
(l2|l23|l34)\n"
" Set the transmit balance policy for bonded
device running in balance mode.\n\n"
diff --git a/app/test/test_link_bonding_mode4.c
b/app/test/test_link_bonding_mode4.c
index 351129d..2be86d5 100644
--- a/app/test/test_link_bonding_mode4.c
+++ b/app/test/test_link_bonding_mode4.c
@@ -58,11 +58,11 @@ static const struct rte_ether_addr slave_mac_default = {
{ 0x00, 0xFF, 0x00, 0xFF, 0x00, 0x00 }
};
-static const struct rte_ether_addr parnter_mac_default = {
+static const struct rte_ether_addr partner_mac_default = {
{ 0x22, 0xBB, 0xFF, 0xBB, 0x00, 0x00 }
};
-static const struct rte_ether_addr parnter_system = {
+static const struct rte_ether_addr partner_system = {
{ 0x33, 0xFF, 0xBB, 0xFF, 0x00, 0x00 }
};
@@ -76,7 +76,7 @@ struct slave_conf {
uint16_t port_id;
uint8_t bonded : 1;
- uint8_t lacp_parnter_state;
+ uint8_t lacp_partner_state;
};
struct ether_vlan_hdr {
@@ -258,7 +258,7 @@ add_slave(struct slave_conf *slave, uint8_t start)
TEST_ASSERT_EQUAL(rte_is_same_ether_addr(&addr, &addr_check), 1,
"Slave MAC address is not as expected");
- RTE_VERIFY(slave->lacp_parnter_state == 0);
+ RTE_VERIFY(slave->lacp_partner_state == 0);
return 0;
}
@@ -288,7 +288,7 @@ remove_slave(struct slave_conf *slave)
test_params.bonded_port_id);
slave->bonded = 0;
- slave->lacp_parnter_state = 0;
+ slave->lacp_partner_state = 0;
return 0;
}
@@ -501,20 +501,20 @@ make_lacp_reply(struct slave_conf *slave, struct rte_mbuf
*pkt)
slow_hdr = rte_pktmbuf_mtod(pkt, struct slow_protocol_frame *);
/* Change source address to partner address */
- rte_ether_addr_copy(&parnter_mac_default, &slow_hdr->eth_hdr.src_addr);
+ rte_ether_addr_copy(&partner_mac_default, &slow_hdr->eth_hdr.src_addr);
slow_hdr->eth_hdr.src_addr.addr_bytes[RTE_ETHER_ADDR_LEN - 1] =
slave->port_id;
lacp = (struct lacpdu *) &slow_hdr->slow_protocol;
/* Save last received state */
- slave->lacp_parnter_state = lacp->actor.state;
+ slave->lacp_partner_state = lacp->actor.state;
/* Change it into LACP replay by matching parameters. */
memcpy(&lacp->partner.port_params, &lacp->actor.port_params,
sizeof(struct port_params));
lacp->partner.state = lacp->actor.state;
- rte_ether_addr_copy(&parnter_system, &lacp->actor.port_params.system);
+ rte_ether_addr_copy(&partner_system, &lacp->actor.port_params.system);
lacp->actor.state = STATE_LACP_ACTIVE |
STATE_SYNCHRONIZATION |
STATE_AGGREGATION |
@@ -580,7 +580,7 @@ bond_handshake_done(struct slave_conf *slave)
const uint8_t expected_state = STATE_LACP_ACTIVE |
STATE_SYNCHRONIZATION |
STATE_AGGREGATION | STATE_COLLECTING |
STATE_DISTRIBUTING;
- return slave->lacp_parnter_state == expected_state;
+ return slave->lacp_partner_state == expected_state;
}
static unsigned
@@ -1165,7 +1165,7 @@ init_marker(struct rte_mbuf *pkt, struct slave_conf
*slave)
&marker_hdr->eth_hdr.dst_addr);
/* Init source address */
- rte_ether_addr_copy(&parnter_mac_default,
+ rte_ether_addr_copy(&partner_mac_default
[PATCH 2/7] net/bonding: fix bonded dev configuring slave dev
- Replace directly overwriting of slave port's private rte_eth_conf
by copying it, and then updating it via rte_eth_dev_configure().
Signed-off-by: Robert Sanford
---
drivers/net/bonding/rte_eth_bond_pmd.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index f6003b0..8cce0aa 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1691,6 +1691,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
struct rte_flow_error flow_error;
struct bond_dev_private *internals = bonded_eth_dev->data->dev_private;
+ struct rte_eth_conf dev_conf;
/* Stop slave */
errval = rte_eth_dev_stop(slave_eth_dev->data->port_id);
@@ -1698,34 +1699,36 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
RTE_BOND_LOG(ERR, "rte_eth_dev_stop: port %u, err (%d)",
slave_eth_dev->data->port_id, errval);
+ /* Start with a copy of slave's current rte_eth_conf. */
+ dev_conf = slave_eth_dev->data->dev_conf;
+ dev_conf.rx_adv_conf.rss_conf.rss_key = NULL;
+
/* Enable interrupts on slave device if supported */
- if (slave_eth_dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC)
- slave_eth_dev->data->dev_conf.intr_conf.lsc = 1;
+ dev_conf.intr_conf.lsc =
+ (slave_eth_dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC) ? 1 : 0;
/* If RSS is enabled for bonding, try to enable it for slaves */
if (bonded_eth_dev->data->dev_conf.rxmode.mq_mode &
RTE_ETH_MQ_RX_RSS_FLAG) {
/* rss_key won't be empty if RSS is configured in bonded dev */
- slave_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_key_len =
- internals->rss_key_len;
- slave_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_key =
- internals->rss_key;
+ dev_conf.rx_adv_conf.rss_conf.rss_key_len =
+ internals->rss_key_len;
+ dev_conf.rx_adv_conf.rss_conf.rss_key = internals->rss_key;
- slave_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf =
+ dev_conf.rx_adv_conf.rss_conf.rss_hf =
bonded_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf;
- slave_eth_dev->data->dev_conf.rxmode.mq_mode =
+ dev_conf.rxmode.mq_mode =
bonded_eth_dev->data->dev_conf.rxmode.mq_mode;
}
if (bonded_eth_dev->data->dev_conf.rxmode.offloads &
RTE_ETH_RX_OFFLOAD_VLAN_FILTER)
- slave_eth_dev->data->dev_conf.rxmode.offloads |=
+ dev_conf.rxmode.offloads |=
RTE_ETH_RX_OFFLOAD_VLAN_FILTER;
else
- slave_eth_dev->data->dev_conf.rxmode.offloads &=
+ dev_conf.rxmode.offloads &=
~RTE_ETH_RX_OFFLOAD_VLAN_FILTER;
- slave_eth_dev->data->dev_conf.rxmode.mtu =
- bonded_eth_dev->data->dev_conf.rxmode.mtu;
+ dev_conf.rxmode.mtu = bonded_eth_dev->data->dev_conf.rxmode.mtu;
nb_rx_queues = bonded_eth_dev->data->nb_rx_queues;
nb_tx_queues = bonded_eth_dev->data->nb_tx_queues;
@@ -1747,8 +1750,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
/* Configure device */
errval = rte_eth_dev_configure(slave_eth_dev->data->port_id,
- nb_rx_queues, nb_tx_queues,
- &(slave_eth_dev->data->dev_conf));
+ nb_rx_queues, nb_tx_queues, &dev_conf);
if (errval != 0) {
RTE_BOND_LOG(ERR, "Cannot configure slave device: port %u, err
(%d)",
slave_eth_dev->data->port_id, errval);
--
2.7.4
[PATCH 3/7] net/bonding: change mbuf pool and ring allocation
- Turn off mbuf pool caching to avoid mbufs lingering in pool caches.
At most, we transmit one LACPDU per second, per port.
- Fix calculation of ring sizes, taking into account that a ring of
size N holds up to N-1 items.
Signed-off-by: Robert Sanford
---
drivers/net/bonding/rte_eth_bond_8023ad.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index 43231bc..83d3938 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -1101,9 +1101,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev,
}
snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id);
- port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc,
- RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ?
- 32 : RTE_MEMPOOL_CACHE_MAX_SIZE,
+ port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, 0,
0, element_size, socket_id);
/* Any memory allocation failure in initialization is critical because
@@ -1113,19 +,23 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev,
slave_id, mem_name, rte_strerror(rte_errno));
}
+ /* Add one extra because ring reserves one. */
snprintf(mem_name, RTE_DIM(mem_name), "slave_%u_rx", slave_id);
port->rx_ring = rte_ring_create(mem_name,
- rte_align32pow2(BOND_MODE_8023AX_SLAVE_RX_PKTS),
socket_id, 0);
+ rte_align32pow2(BOND_MODE_8023AX_SLAVE_RX_PKTS + 1),
+ socket_id, 0);
if (port->rx_ring == NULL) {
rte_panic("Slave %u: Failed to create rx ring '%s': %s\n",
slave_id,
mem_name, rte_strerror(rte_errno));
}
- /* TX ring is at least one pkt longer to make room for marker packet. */
+ /* TX ring is at least one pkt longer to make room for marker packet.
+* Add one extra because ring reserves one. */
snprintf(mem_name, RTE_DIM(mem_name), "slave_%u_tx", slave_id);
port->tx_ring = rte_ring_create(mem_name,
- rte_align32pow2(BOND_MODE_8023AX_SLAVE_TX_PKTS + 1),
socket_id, 0);
+ rte_align32pow2(BOND_MODE_8023AX_SLAVE_TX_PKTS + 2),
+ socket_id, 0);
if (port->tx_ring == NULL) {
rte_panic("Slave %u: Failed to create tx ring '%s': %s\n",
slave_id,
--
2.7.4
[PATCH 4/7] net/bonding: support enabling LACP short timeout
- Add support for enabling LACP short timeout, i.e., link partner can
use fast periodic time interval between transmits.
Signed-off-by: Robert Sanford
---
drivers/net/bonding/eth_bond_8023ad_private.h | 3 ++-
drivers/net/bonding/rte_eth_bond_8023ad.c | 28 +++
drivers/net/bonding/rte_eth_bond_8023ad.h | 3 +++
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bonding/eth_bond_8023ad_private.h
b/drivers/net/bonding/eth_bond_8023ad_private.h
index e415f2f..e1a7207 100644
--- a/drivers/net/bonding/eth_bond_8023ad_private.h
+++ b/drivers/net/bonding/eth_bond_8023ad_private.h
@@ -159,7 +159,6 @@ struct mode8023ad_private {
uint64_t rx_marker_timeout;
uint64_t update_timeout_us;
rte_eth_bond_8023ad_ext_slowrx_fn slowrx_cb;
- uint8_t external_sm;
struct rte_ether_addr mac_addr;
struct rte_eth_link slave_link;
@@ -178,6 +177,8 @@ struct mode8023ad_private {
uint16_t tx_qid;
} dedicated_queues;
enum rte_bond_8023ad_agg_selection agg_selection;
+ uint8_t short_timeout_enabled : 1;
+ uint8_t short_timeout_updated : 1;
};
/**
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index 83d3938..93fbf39 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -868,10 +868,10 @@ bond_mode_8023ad_periodic_cb(void *arg)
struct rte_eth_link link_info;
struct rte_ether_addr slave_addr;
struct rte_mbuf *lacp_pkt = NULL;
+ uint8_t short_timeout_updated = internals->mode4.short_timeout_updated;
uint16_t slave_id;
uint16_t i;
-
/* Update link status on each port */
for (i = 0; i < internals->active_slave_count; i++) {
uint16_t key;
@@ -916,6 +916,13 @@ bond_mode_8023ad_periodic_cb(void *arg)
slave_id = internals->active_slaves[i];
port = &bond_mode_8023ad_ports[slave_id];
+ if (short_timeout_updated) {
+ if (internals->mode4.short_timeout_enabled)
+ ACTOR_STATE_SET(port, LACP_SHORT_TIMEOUT);
+ else
+ ACTOR_STATE_CLR(port, LACP_SHORT_TIMEOUT);
+ }
+
if ((port->actor.key &
rte_cpu_to_be_16(BOND_LINK_FULL_DUPLEX_KEY)) ==
0) {
@@ -960,6 +967,9 @@ bond_mode_8023ad_periodic_cb(void *arg)
show_warnings(slave_id);
}
+ if (short_timeout_updated)
+ internals->mode4.short_timeout_updated = 0;
+
rte_eal_alarm_set(internals->mode4.update_timeout_us,
bond_mode_8023ad_periodic_cb, arg);
}
@@ -1054,7 +1064,6 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev,
/* Given slave must not be in active list. */
RTE_ASSERT(find_slave_by_id(internals->active_slaves,
internals->active_slave_count, slave_id) ==
internals->active_slave_count);
- RTE_SET_USED(internals); /* used only for assert when enabled */
memcpy(&port->actor, &initial, sizeof(struct port_params));
/* Standard requires that port ID must be greater than 0.
@@ -1065,7 +1074,9 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev,
memcpy(&port->partner_admin, &initial, sizeof(struct port_params));
/* default states */
- port->actor_state = STATE_AGGREGATION | STATE_LACP_ACTIVE |
STATE_DEFAULTED;
+ port->actor_state = STATE_AGGREGATION | STATE_LACP_ACTIVE |
+ STATE_DEFAULTED | (internals->mode4.short_timeout_enabled ?
+ STATE_LACP_SHORT_TIMEOUT : 0);
port->partner_state = STATE_LACP_ACTIVE | STATE_AGGREGATION;
port->sm_flags = SM_FLAGS_BEGIN;
@@ -1213,6 +1224,7 @@ bond_mode_8023ad_conf_get(struct rte_eth_dev *dev,
struct mode8023ad_private *mode4 = &internals->mode4;
uint64_t ms_ticks = rte_get_tsc_hz() / 1000;
+ memset(conf, 0, sizeof(*conf));
conf->fast_periodic_ms = mode4->fast_periodic_timeout / ms_ticks;
conf->slow_periodic_ms = mode4->slow_periodic_timeout / ms_ticks;
conf->short_timeout_ms = mode4->short_timeout / ms_ticks;
@@ -1223,6 +1235,7 @@ bond_mode_8023ad_conf_get(struct rte_eth_dev *dev,
conf->rx_marker_period_ms = mode4->rx_marker_timeout / ms_ticks;
conf->slowrx_cb = mode4->slowrx_cb;
conf->agg_selection = mode4->agg_selection;
+ conf->lacp_timeout_control = mode4->short_timeout_enabled;
}
static void
@@ -1238,6 +1251,7 @@ bond_mode_8023ad_conf_get_default(struct
rte_eth_bond_8023ad_conf *conf)
conf->update_timeout_ms = BOND_MODE_8023AX_UPDATE_TIMEOUT_MS;
conf->slowrx_cb = NULL;
conf->agg_selection = AGG_STABLE;
+ conf->lacp_timeout_control = 0;
}
static void
@@ -1278,6 +1292,11 @@ bond_mo
[PATCH 5/7] net/bonding: add LACP short timeout to tests
- Add "set bonding lacp timeout_ctrl on|off" to testpmd.
- Add "test_mode4_lacp_timeout_control" to app/test.
Signed-off-by: Robert Sanford
---
app/test-pmd/cmdline.c | 77 ++
app/test/test_link_bonding_mode4.c | 65
2 files changed, 142 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 9fd2c2a..b0c2fb4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -633,6 +633,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"set bonding mode IEEE802.3AD aggregator policy
(port_id) (agg_name)\n"
" Set Aggregation mode for IEEE802.3AD (mode
4)\n\n"
+ "set bonding lacp timeout_ctrl (port_id) (on|off)\n"
+ "Configure LACP partner to use fast|slow
periodic tx interval.\n\n"
+
"set bonding balance_xmit_policy (port_id)
(l2|l23|l34)\n"
" Set the transmit balance policy for bonded
device running in balance mode.\n\n"
@@ -6192,6 +6195,7 @@ static void lacp_conf_show(struct
rte_eth_bond_8023ad_conf *conf)
printf("\taggregation mode: invalid\n");
break;
}
+ printf("\tlacp timeout control: %u\n", conf->lacp_timeout_control);
printf("\n");
}
@@ -6863,6 +6867,78 @@ cmdline_parse_inst_t cmd_set_bonding_agg_mode_policy = {
};
+/* *** SET LACP TIMEOUT CONTROL ON BONDED DEVICE *** */
+struct cmd_set_lacp_timeout_control_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t bonding;
+ cmdline_fixed_string_t lacp;
+ cmdline_fixed_string_t timeout_ctrl;
+ uint16_t port_id;
+ cmdline_fixed_string_t on_off;
+};
+
+static void
+cmd_set_lacp_timeout_control_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_set_lacp_timeout_control_result *res = parsed_result;
+ struct rte_eth_bond_8023ad_conf port_conf;
+ uint8_t on_off = 0;
+ int ret;
+
+ if (!strcmp(res->on_off, "on"))
+ on_off = 1;
+
+ ret = rte_eth_bond_8023ad_conf_get(res->port_id, &port_conf);
+ if (ret != 0) {
+ fprintf(stderr, "\tGet bonded device %u lacp conf failed\n",
+ res->port_id);
+ return;
+ }
+
+ port_conf.lacp_timeout_control = on_off;
+ ret = rte_eth_bond_8023ad_setup(res->port_id, &port_conf);
+ if (ret != 0)
+ fprintf(stderr, "\tSetup bonded device %u lacp conf failed\n",
+ res->port_id);
+}
+
+cmdline_parse_token_string_t cmd_set_lacp_timeout_control_set =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_lacp_timeout_control_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_set_lacp_timeout_control_bonding =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_lacp_timeout_control_result,
+ bonding, "bonding");
+cmdline_parse_token_string_t cmd_set_lacp_timeout_control_lacp =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_lacp_timeout_control_result,
+ lacp, "lacp");
+cmdline_parse_token_string_t cmd_set_lacp_timeout_control_timeout_ctrl =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_lacp_timeout_control_result,
+ timeout_ctrl, "timeout_ctrl");
+cmdline_parse_token_num_t cmd_set_lacp_timeout_control_port_id =
+ TOKEN_NUM_INITIALIZER(struct cmd_set_lacp_timeout_control_result,
+ port_id, RTE_UINT16);
+cmdline_parse_token_string_t cmd_set_lacp_timeout_control_on_off =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_lacp_timeout_control_result,
+ on_off, "on#off");
+
+cmdline_parse_inst_t cmd_set_lacp_timeout_control = {
+ .f = cmd_set_lacp_timeout_control_parsed,
+ .data = (void *) 0,
+ .help_str = "set bonding lacp timeout_ctrl on|off: "
+ "Configure partner to use fast|slow periodic tx interval",
+ .tokens = {
+ (void *)&cmd_set_lacp_timeout_control_set,
+ (void *)&cmd_set_lacp_timeout_control_bonding,
+ (void *)&cmd_set_lacp_timeout_control_lacp,
+ (void *)&cmd_set_lacp_timeout_control_timeout_ctrl,
+ (void *)&cmd_set_lacp_timeout_control_port_id,
+ (void *)&cmd_set_lacp_timeout_control_on_off,
+ NULL
+ }
+};
+
#endif /* RTE_NET_BOND */
/* *** SET FORWARDING MODE *** */
@@ -17728,6 +17804,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *) &cmd_set_bond_mon_period,
(cmdline_parse_inst_t *) &cmd_set_lacp_dedicated_queues,
(cmdline_parse_inst_t *) &cmd_set_bonding_agg_mode_policy,
+ (cmdline_parse_inst_t *) &cmd_set_lacp_timeout_control,
[PATCH 6/7] net/bonding: add bond_8023ad and bond_alb to doc
- Add bond_8023ad and bond_alb to API documentation. Signed-off-by: Robert Sanford --- doc/api/doxy-api-index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index 4245b96..830235c 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -39,6 +39,8 @@ The public API headers are grouped by topics: - **device specific**: [softnic](@ref rte_eth_softnic.h), [bond] (@ref rte_eth_bond.h), + [bond_8023ad](@ref rte_eth_bond_8023ad.h), + [bond_alb] (@ref rte_eth_bond_alb.h), [vhost] (@ref rte_vhost.h), [vdpa] (@ref rte_vdpa.h), [KNI](@ref rte_kni.h), -- 2.7.4
[PATCH 7/7] Remove self from Timers maintainers.
Signed-off-by: Robert Sanford --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 18d9eda..32663b0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1613,7 +1613,6 @@ F: examples/vm_power_manager/ F: doc/guides/sample_app_ug/vm_power_management.rst Timers -M: Robert Sanford M: Erik Gabriel Carrillo F: lib/timer/ F: doc/guides/prog_guide/timer_lib.rst -- 2.7.4
[dpdk-kmods] linux/igb_uio: fix build for switch fall through
Linux is using '-Wimplicit-fallthrough=5' compiler option, which doesn't
take any fall through comments into account but only uses compiler
'fallthrough' attribute to document fall through action is intended.
"falls through" comment was used in the code which is causing a build
error now, this patch converts comment to the 'fallthrough' macro
defined in the Linux.
To cover the case where Linux version doesn't have the macro, defined it
in the compatibility header too.
Signed-off-by: Ferruh Yigit
---
linux/igb_uio/compat.h | 4
linux/igb_uio/igb_uio.c | 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/linux/igb_uio/compat.h b/linux/igb_uio/compat.h
index 8dbb896ae118..04ff7f60031f 100644
--- a/linux/igb_uio/compat.h
+++ b/linux/igb_uio/compat.h
@@ -152,3 +152,7 @@ static inline bool igbuio_kernel_is_locked_down(void)
return false;
#endif
}
+
+#ifndef fallthrough
+#define fallthroughdo {} while (0) /* fallthrough */
+#endif
diff --git a/linux/igb_uio/igb_uio.c b/linux/igb_uio/igb_uio.c
index ea439d131de1..33e0e0286b69 100644
--- a/linux/igb_uio/igb_uio.c
+++ b/linux/igb_uio/igb_uio.c
@@ -250,7 +250,7 @@ igbuio_pci_enable_interrupts(struct rte_uio_pci_dev *udev)
}
#endif
- /* falls through - to MSI */
+ fallthrough;
case RTE_INTR_MODE_MSI:
#ifndef HAVE_ALLOC_IRQ_VECTORS
if (pci_enable_msi(udev->pdev) == 0) {
@@ -269,7 +269,7 @@ igbuio_pci_enable_interrupts(struct rte_uio_pci_dev *udev)
break;
}
#endif
- /* falls through - to INTX */
+ fallthrough;
case RTE_INTR_MODE_LEGACY:
if (pci_intx_mask_supported(udev->pdev)) {
dev_dbg(&udev->pdev->dev, "using INTX");
@@ -279,7 +279,7 @@ igbuio_pci_enable_interrupts(struct rte_uio_pci_dev *udev)
break;
}
dev_notice(&udev->pdev->dev, "PCI INTX mask not supported\n");
- /* falls through - to no IRQ */
+ fallthrough;
case RTE_INTR_MODE_NONE:
udev->mode = RTE_INTR_MODE_NONE;
udev->info.irq = UIO_IRQ_NONE;
--
2.33.1
Re: [dpdk-kmods] linux/igb_uio: fix build for switch fall through
On Wed, 15 Dec 2021 18:48:59 + Ferruh Yigit wrote: > Linux is using '-Wimplicit-fallthrough=5' compiler option, which doesn't > take any fall through comments into account but only uses compiler > 'fallthrough' attribute to document fall through action is intended. > > "falls through" comment was used in the code which is causing a build > error now, this patch converts comment to the 'fallthrough' macro > defined in the Linux. > > To cover the case where Linux version doesn't have the macro, defined it > in the compatibility header too. > > Signed-off-by: Ferruh Yigit Are you sure that fixes it? because the comment in the macro is typically not visible in a macro expansion. Since in most case Linux uses gcc why not use the gcc attribute __attribute__ ((fallthrough))
Re: [dpdk-kmods] linux/igb_uio: fix build for switch fall through
On 12/15/2021 7:20 PM, Stephen Hemminger wrote:
On Wed, 15 Dec 2021 18:48:59 +
Ferruh Yigit wrote:
Linux is using '-Wimplicit-fallthrough=5' compiler option, which doesn't
take any fall through comments into account but only uses compiler
'fallthrough' attribute to document fall through action is intended.
"falls through" comment was used in the code which is causing a build
error now, this patch converts comment to the 'fallthrough' macro
defined in the Linux.
To cover the case where Linux version doesn't have the macro, defined it
in the compatibility header too.
Signed-off-by: Ferruh Yigit
Are you sure that fixes it? because the comment in the macro is typically
not visible in a macro expansion.
Since in most case Linux uses gcc why not use the gcc attribute
__attribute__ ((fallthrough))
Hi Stephen,
That is the intention already.
Patch is using the Linux kernel defined macro:
#if __has_attribute(__fallthrough__)
# define fallthrough__attribute__((__fallthrough__))
#else
# define fallthroughdo {} while (0) /* fallthrough */
#endif
And it builds fine without the macro in the 'compat.h'.
I added the define in the 'compat.h' for old kernels which doesn't
define the macro. For that case I expect default '-Wimplicit-fallthrough'
option is used which accepts 'fallthrough;' as a regex hit.
Re: [dpdk-kmods] linux/igb_uio: fix build for switch fall through
On Wed, 15 Dec 2021 21:04:30 +
Ferruh Yigit wrote:
> On 12/15/2021 7:20 PM, Stephen Hemminger wrote:
> > On Wed, 15 Dec 2021 18:48:59 +
> > Ferruh Yigit wrote:
> >
> >> Linux is using '-Wimplicit-fallthrough=5' compiler option, which doesn't
> >> take any fall through comments into account but only uses compiler
> >> 'fallthrough' attribute to document fall through action is intended.
> >>
> >> "falls through" comment was used in the code which is causing a build
> >> error now, this patch converts comment to the 'fallthrough' macro
> >> defined in the Linux.
> >>
> >> To cover the case where Linux version doesn't have the macro, defined it
> >> in the compatibility header too.
> >>
> >> Signed-off-by: Ferruh Yigit
> >
> > Are you sure that fixes it? because the comment in the macro is typically
> > not visible in a macro expansion.
> >Since in most case Linux uses gcc why not use the gcc attribute
> >
> > __attribute__ ((fallthrough))
>
> Hi Stephen,
>
> That is the intention already.
>
> Patch is using the Linux kernel defined macro:
> #if __has_attribute(__fallthrough__)
> # define fallthrough__attribute__((__fallthrough__))
> #else
> # define fallthroughdo {} while (0) /* fallthrough */
> #endif
>
> And it builds fine without the macro in the 'compat.h'.
>
>
> I added the define in the 'compat.h' for old kernels which doesn't
> define the macro. For that case I expect default '-Wimplicit-fallthrough'
> option is used which accepts 'fallthrough;' as a regex hit.
Your right, on older kernels it really is just a dummy statement.
The regex can't work, you can take (or leave the comment) it has no effect
because implicit-fallthrough won't see it in a macro.
[PATCH v1] net/iavf: remove the extra symbol '+'
This extra symbol '+' should be added when patch was reapplied, and the
compiler treats it as unsigned type, so the code still runs well.
Fixes: 84108425054a ("net/iavf: support asynchronous virtual channel message")
Cc: sta...@dpdk.org
Signed-off-by: Haiyue Wang
---
drivers/net/iavf/iavf_vchnl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index 145b059837..8fdd6f6d91 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -502,7 +502,7 @@ iavf_get_vf_resource(struct iavf_adapter *adapter)
VIRTCHNL_VF_OFFLOAD_VLAN_V2 |
VIRTCHNL_VF_LARGE_NUM_QPAIRS |
VIRTCHNL_VF_OFFLOAD_QOS |
-+ VIRTCHNL_VF_OFFLOAD_INLINE_IPSEC_CRYPTO;
+ VIRTCHNL_VF_OFFLOAD_INLINE_IPSEC_CRYPTO;
args.in_args = (uint8_t *)∩︀
args.in_args_size = sizeof(caps);
--
2.34.1
RE: [PATCH v1] net/iavf: remove the extra symbol '+'
> -Original Message-
> From: Wang, Haiyue
> Sent: Thursday, December 16, 2021 12:44 PM
> To: dev@dpdk.org
> Cc: Wang, Haiyue ; sta...@dpdk.org; Wu, Jingjing
> ; Xing, Beilei ; Sinha, Abhijit
> ; Doherty, Declan ;
> Nicolau, Radu
> Subject: [PATCH v1] net/iavf: remove the extra symbol '+'
>
> This extra symbol '+' should be added when patch was reapplied, and the
> compiler treats it as unsigned type, so the code still runs well.
>
> Fixes: 84108425054a ("net/iavf: support asynchronous virtual channel
> message")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Haiyue Wang
> ---
> drivers/net/iavf/iavf_vchnl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
> index
> 145b059837..8fdd6f6d91 100644
> --- a/drivers/net/iavf/iavf_vchnl.c
> +++ b/drivers/net/iavf/iavf_vchnl.c
> @@ -502,7 +502,7 @@ iavf_get_vf_resource(struct iavf_adapter *adapter)
> VIRTCHNL_VF_OFFLOAD_VLAN_V2 |
> VIRTCHNL_VF_LARGE_NUM_QPAIRS |
> VIRTCHNL_VF_OFFLOAD_QOS |
> -+VIRTCHNL_VF_OFFLOAD_INLINE_IPSEC_CRYPTO;
> + VIRTCHNL_VF_OFFLOAD_INLINE_IPSEC_CRYPTO;
>
> args.in_args = (uint8_t *)∩︀
> args.in_args_size = sizeof(caps);
> --
> 2.34.1
Acked-by: Beilei Xing
RE: 20.11.4 patches review and test
> -Original Message- > From: Xueming(Steven) Li > Sent: Wednesday, December 15, 2021 10:45 PM > To: Lin, Xueqin ; Jiang, YuX ; > sta...@dpdk.org > Cc: Stokes, Ian ; dev@dpdk.org; > ktray...@redhat.com; abhishek.mara...@microsoft.com; > d...@linux.vnet.ibm.com; NBU-Contact-Thomas Monjalon (EXTERNAL) > ; Peng, Yuan ; > jer...@marvell.com; Walker, Benjamin ; > bl...@debian.org; Raslan Darawsheh ; Mcnamara, > John ; Chen, Zhaoyan > ; Govindharajan, Hariprasad > ; Ali Alnubani ; > hemant.agra...@nxp.com; pezh...@redhat.com; juh...@microsoft.com; > Xu, Qian Q > Subject: Re: 20.11.4 patches review and test > > On Fri, 2021-12-10 at 11:35 +, Jiang, YuX wrote: > > > -Original Message- > > > From: Jiang, YuX > > > Sent: Thursday, December 9, 2021 6:01 PM > > > To: Xueming Li ; sta...@dpdk.org; Lin, Xueqin > > > > > > Cc: dev@dpdk.org; Abhishek Marathe > > > ; > > > Ali Alnubani ; Walker, Benjamin > > > ; David Christensen > > > ; Govindharajan, Hariprasad > > > ; Hemant Agrawal > > > ; Stokes, Ian ; Jerin > > > Jacob ; Mcnamara, John > > > ; Ju-Hyoung Lee ; > > > Kevin Traynor ; Luca Boccassi > > > ; Pei Zhang ; Xu, Qian Q > > > ; Raslan Darawsheh ; > Thomas > > > Monjalon ; Peng, Yuan > ; > > > Chen, Zhaoyan > > > Subject: RE: 20.11.4 patches review and test > > > > > > > -Original Message- > > > > From: Xueming Li > > > > Sent: Tuesday, December 7, 2021 12:15 AM > > > > To: sta...@dpdk.org > > > > Cc: xuemi...@nvidia.com; dev@dpdk.org; Abhishek Marathe > > > > ; Ali Alnubani > > > > ; Walker, Benjamin > > > > ; David Christensen > > > > ; Govindharajan, Hariprasad > > > > ; Hemant Agrawal > > > > ; Stokes, Ian ; > > > > Jerin Jacob ; Mcnamara, John > > > ; > > > > Ju-Hyoung Lee ; Kevin Traynor > > > > ; Luca Boccassi ; Pei Zhang > > > > ; Xu, Qian Q ; Raslan > > > > Darawsheh ; Thomas Monjalon > > > ; > > > > Peng, Yuan ; Chen, Zhaoyan > > > > > > > > Subject: 20.11.4 patches review and test > > > > > > > > Hi all, > > > > > > > > Here is a list of patches targeted for stable release 20.11.4. > > > > > > > > The planned date for the final release is 31th December. > > > > > > > > Please help with testing and validation of your use cases and > > > > report any issues/results with reply-all to this mail. For the > > > > final release the fixes and reported validations will be added to > > > > the release notes. > > > > > > > > A release candidate tarball can be found at: > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A% > > > > 2F%2Fdpdk.org%2Fbrowse%2Fdpdk- > stable%2Ftag%2F%3Fid%3Dv20.11.4- > > > > > rc1&data=04%7C01%7Cxuemingl%40nvidia.com%7Cc9cdc823fce64be11 > 8 > > > > > 0908d9bbd13e8a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637 > 74 > > > > > 7329661244261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > JQIjo > > > > > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DtlL0BYV > > > > > vWm7JE9JV%2BliWzq6R%2FHmKRSNKbc10nmF81Q%3D&reserved=0 > > > > > > > > These patches are located at branch 20.11 of dpdk-stable repo: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A% > > > > 2F%2Fdpdk.org%2Fbrowse%2Fdpdk- > > > > > stable%2F&data=04%7C01%7Cxuemingl%40nvidia.com%7Cc9cdc823fce > 6 > > > > > 4be1180908d9bbd13e8a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0 > %7 > > > > > C637747329661244261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiL > > > > > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KO > > > > > 3YKk3gXS%2B73gMdQf9MFohT9q55YiDW8df%2F12ZepMs%3D&reserve > d=0 > > > > > > > > Thanks. > > > > > > > > Xueming Li > > > > > > > Update the test status for Intel part. Till now dpdk20.11.4-rc1 test > > > execution rate is 80%. Currently, find three bugs, two bugs have fix > > > now. > > > # Basic Intel(R) NIC testing > > > * Build or compile: > > > *Build: cover the build test combination with latest GCC/Clang/ICC > > > version and the popular OS revision such as Ubuntu20.04, Fedora34, > > > RHEL8.4, etc. > > > - All test done. > > > - Two bugs are found in 20.11.4-rc1. > > > - dpdk-20.11.4]kernel/linux/kni/rte_kni.ko > > > build > > > failed on OpenSuse15.3 with gcc7.5.0&clang11.0.1 > > > - fix link: > > > http://inbox.dpdk.org/stable/20211208103410.835542-1- > > > ferruh.yi...@intel.com/T/#u , verify passed by Intel > > > - > > > https://bugs.dpdk.org/show_bug.cgi?id=894 > > > [dpdk-20.11.4] > > > lib/librte_eal.a.p/librte_eal_common_rte_random.c.obj build failed > > > on WIN10 with clang8.0.0 > > > - fix link: > > > http://inbox.dpdk.org/stable/20211207141644.369624-1- > > > dmitry.kozl...@gmail.com/T/#u, verify passed by Intel > > > * PF(i40e, ixgbe): test scenarios including > > > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > > > - All test done. No new issue is found. > > > * VF(i40e, ixgbe): test scenarios including VF- > > > RTE_FLOW/TSO/Jumboframe/checksum o
NVIDIA roadmap for 22.03
Please find below NVIDIA roadmap for 22.03 release: rte_flow new APIs: [1] Support for template API (item and action) to optimize the insertion rate. The combination of item and action templates along with shared flow rule attributes allows the PMD/HW to prepare all the resources needed for efficient flow rules creation in the datapath. [2] Support for asynchronous queue-based flow rules management mechanism for applications. A flow rule creation/destruction is enqueued on the specified flow queue and offloaded asynchronously to the hardware. mlx5 PMD updates: == [3] Support the rte_flow changes listed above. rte_mempool updates: === [4] Optimize the hugepage initialization to speed up the application start-up time. testpmd updates: [5] Support the changes in rte_flow listed above.
Re: 19.11.11 patches review and test
On Wed, Dec 15, 2021 at 3:44 PM Ferruh Yigit wrote: > > On 12/15/2021 1:17 PM, Christian Ehrhardt wrote: > > On Tue, Dec 14, 2021 at 3:52 PM Ferruh Yigit wrote: > >> > >> On 12/14/2021 2:46 PM, Christian Ehrhardt wrote: > >>> On Tue, Dec 14, 2021 at 2:58 PM Christian Ehrhardt > >>> wrote: > > On Tue, Dec 14, 2021 at 2:10 PM Ferruh Yigit > wrote: > > > > On 12/14/2021 11:39 AM, Christian Ehrhardt wrote: > >> On Tue, Dec 14, 2021 at 11:13 AM Ferruh Yigit > >> wrote: > >>> > >>> On 12/14/2021 7:44 AM, Christian Ehrhardt wrote: > On Tue, Dec 14, 2021 at 6:49 AM Kalesh Anakkur Purayil > wrote: > > [snip] > > >>> [Kalesh] Yes, i am seeing the same error. I used make command to > >>> build dpdk, not meson. > >>> The back ported commit you mentioned takes care of meson build > >>> only I think. > >>> > >> > >> I see, make build is failing, and yes the fix is only for the > >> meson. > >> I will check the make build and will send a fix for it. > > > > [Kalesh]: looks like the below changes fixes the issue. I tried > > only on SLES15 SP3 and not on other SLES flavors. > > > > diff --git a/kernel/linux/kni/Makefile b/kernel/linux/kni/Makefile > > index 595bac2..bf0efab 100644 > > --- a/kernel/linux/kni/Makefile > > +++ b/kernel/linux/kni/Makefile > > @@ -16,6 +16,16 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include > > MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h > > MODULE_CFLAGS += -Wall -Werror > > > > +# > > +# Use explicit 'source' folder for header path. In SUSE 'source' > > is not linked to 'build' folder. > > +# > > +ifdef CONFIG_SUSE_KERNEL > > + KSRC = /lib/modules/$(shell uname -r)/source > > + ifneq ($(shell grep -A 1 "ndo_tx_timeout" > > $(KSRC)/include/linux/netdevice.h | grep -o txqueue),) > > + MODULE_CFLAGS += -DHAVE_TX_TIMEOUT_TXQUEUE > > + endif > > +endif > > Back in the day we tried various "is Suse and kernel version x.y" > approaches, but they failed as there was no clear version throughout > all of the Suse streams (leap, tumbleweed, sles) that worked well for > all. > This change here follows the upstream approach of "just check if it > is there". > > I've applied this to 19.11 and did test builds across various > distributions: > 1. no non-suse build changed > 2. suse builds stayed as-is or improved > Formerly failing: > openSUSE_Factory_ARM aarch64 > SLE_15 x86_64 -> now working > openSUSE_Leap_15.3 x86_64 -> now working > openSUSE_Tumbleweed x86_64 -> still failing > Formerly working: > SLE_12_SP4 x86_64 ppc64le -> still fine > openSUSE_Factory_ARM armv7l -> still fine > openSUSE_Leap_15.2 x86_64 -> still fine > > >>> > >>> Thanks Kalesh for the fix, and thanks Christian for testing. > >>> > >>> I was expecting this approach will fix all builds, after patch only > >>> 'openSUSE_Tumbleweed' is failing, right? I will check it. > >> > >> As just discussed on IRC, yes and the log for that is at > >> https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/openSUSE_Tumbleweed/x86_64 > >> > >> It also is affected by an issue around -Werror=implicit-fallthrough, > >> so even with KNI fixed it likely is going to fail. > >> > >>> And I think you need the fix as a patch anyway, @Kalesh are you > >>> planning to send the patch? > >> > >> I don't need it, as I have already grabbed and preliminary added it: > >> https://github.com/cpaelzer/dpdk-stable-queue/commit/d43fa3e198c08a3a76d70f4565b31ad3ab5f29c4 > >> > >> But surely, once/If you come up with a full patch that also includes > >> tumbleweed I can replace it with yours. > >> > > > > 'tumbleweed' error is odd, it complains about macro being redefined, > > not sure why only in this platform we are getting an error. > > > > Macro is only defined in one place, but indeed header file included > > multiple times, one direct and one indirect, so macro defined multiple > > times but without value, so it should be OK and it is OK for other > > platforms, it is defined as: > > #define HAVE_TX_TIMEOUT_TXQUEUE > > > > Another option is that macro is defined in some other header file, > > although I think that is very unlikely, can you please test with > > below change to rule out that option: > > I'm testing that and will let you know in a bit ..
