[dpdk-dev] [PATCH] mem: fix free segment when using huge-unlink option

2021-02-23 Thread Roy Shterman
When using huge_unlink we unlink the segment right
after allocation. Although we unlink the file we keep
the fd in fd_list so file still exist just the path deleted.
When freeing the hugepage we need to close the fd and assign
it with (-1) in fd_list for the page to be released.

The current flow fails rte_malloc in the following flow when working
with --huge-unlink option:
1. alloc_seg() for segment A -
We allocate segment, unlink the path to the segment
and keep the file descriptor in fd_list.
2. free_seg() for segment A -
We clear the segment metadata and return - without closing fd
or assigning (-1) in fd list.
3. alloc_seg() for segment A again -
We find segment A as available, try to allocate it,
find the old fd in fd_list try to unlink it
as part of alloc_seg() but failed because path doesn't exist.

The impact of such error is falsly failing rte_malloc()
although we have hugepages available.

Fixes: d435aad37da7 ("mem: support --huge-unlink mode")

Signed-off-by: Roy Shterman 
---
 lib/librte_eal/linux/eal_memalloc.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/lib/librte_eal/linux/eal_memalloc.c 
b/lib/librte_eal/linux/eal_memalloc.c
index 6dc1b2bae..c590d6043 100644
--- a/lib/librte_eal/linux/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal_memalloc.c
@@ -709,7 +709,6 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi,
uint64_t map_offset;
char path[PATH_MAX];
int fd, ret = 0;
-   bool exit_early;
const struct internal_config *internal_conf =
eal_get_internal_configuration();
 
@@ -725,17 +724,8 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi,
 
eal_mem_set_dump(ms->addr, ms->len, false);
 
-   exit_early = false;
-
/* if we're using anonymous hugepages, nothing to be done */
-   if (internal_conf->in_memory && !memfd_create_supported)
-   exit_early = true;
-
-   /* if we've already unlinked the page, nothing needs to be done */
-   if (!internal_conf->in_memory && internal_conf->hugepage_unlink)
-   exit_early = true;
-
-   if (exit_early) {
+   if (internal_conf->in_memory && !memfd_create_supported) {
memset(ms, 0, sizeof(*ms));
return 0;
}
@@ -761,7 +751,7 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi,
/* if we're able to take out a write lock, we're the last one
 * holding onto this page.
 */
-   if (!internal_conf->in_memory) {
+   if (!internal_conf->in_memory && 
!internal_conf->hugepage_unlink) {
ret = lock(fd, LOCK_EX);
if (ret >= 0) {
/* no one else is using this page */
-- 
2.24.1



[dpdk-dev] Potential bug in QAT PMD code

2021-02-23 Thread Linfeng Li
Hi,



We believe we found a potential bug in the QAT PMD code.



file link: https://github.com/DPDK/dpdk/blob/main/drivers/crypto/qat/qat_sym.c



The undesired behavior happens when:
* symmetric operation
* out-of-place operation
* encryption
* do cipher + do hash
* SGL enabled on either src/dst mbuf chain
* min_ofs is smaller than the length of the first segment of the src 
mbuf chain



behavior: In dst mbuf, payload is ciphered as expected, but mac-i remains plain 
text where it's expected to be ciphered as well.



potential cause:
* When min_ofs is smaller than the length of the first segment of the 
src mbuf chain with the foregoing scenario , auth_param->auth_off is calculated 
by auth_ofs-min_ofs(line 512 in qat_sym.c).
* When SGL enabled + do auth + do cipher, the remaining_off is 
calculated by auth_param->auth_off + auth_param->auth_len + 
alignment_adjustment(line 534 in qat_sym.c). so remaining_off doesn't include 
the offset applied on auth_param->auth_off in this scenario.
* The auth_data_end(line 546 in qat_sym.c) found doesn't seem proper 
since the while loop (line 540 in qat_sym.c) iterates from the very beginning 
of the dst mbuf.



Proposal fix:

add min_ofs in the calculation of remaining_off(line 534 in qat_sym.c)



Please let us know what your thoughts are about this issue and feel free to 
contact us if there are any questions.

Linfeng


Re: [dpdk-dev] [PATCH] net/mlx5: fix hashed list size for tunnel flow groups

2021-02-23 Thread Matan Azrad



From: Viacheslav Ovsiienko
> The hasged list size must be the power of 2, otherwise the adjustment is
> applied and the warning message is emitted.
> This patch provides the correct list size to eliminate the warning.
> 
> Fixes: 4ec6360de37d ("net/mlx5: implement tunnel offload")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Viacheslav Ovsiienko 
Acked-by: Matan Azrad 


Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet per second) on meter

2021-02-23 Thread Morten Brørup
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Li Zhang
> Sent: Tuesday, February 23, 2021 3:07 AM
> 
> Thanks for your comments.
> We changed the struct as below:
> struct rte_mtr_meter_profile {
>  ..
>   /** Items only valid when alg is set to sprTCM. */
>   struct {
>   /** Committed Information Packet Rate (CIPR). */
>   uint64_t cipr;
> 
>   /** Committed Packet Burst Size (CPBS). */
>   uint64_t cpbs;
> 
>   /** Excess Packet Burst Size (EPBS). */
>   uint64_t epbs;
>   } sprtcm;
> }

That is certainly not an improvement! Please stick with the broadly accepted 
industry standard names (CIR, CBS, EBS, etc.). Newly invented names like CIPR 
will only cause confusion. Please note that CIR, CBS, EBS don't say anything 
about their units; it could be bytes, packets, cells, frames, messages or 
anything else. So it is perfectly natural using the same names for packets 
instead of bytes.

I propose the following modifications instead.

For the algorithm, keep the "Single Rate Three Color Marker" name mentioned in 
the RFCs, but indicate that the variant is packet based:

/** Single Rate Three Color Marker, Packet based (srTCMp). */
RTE_MTR_SRTCMP,

Or if you prefer the packet based indicator at the front instead:

/** Packet based Single Rate Three Color Marker (psrTCM). */
RTE_MTR_PSRTCM,

And for the meter profile, keep the industry standard names, but update the 
descriptions:

/** Items only valid when *alg* is set to srTCMp. */
struct {
/** Committed Information Rate (CIR) (packets/second). 
*/
uint64_t cir;
 
/** Committed Burst Size (CBS) (packets). */
uint64_t cbs;
 
/** Excess Burst Size (EBS) (packets). */
uint64_t ebs;
} srtcmp;


Come to think of it: Is the unit packets, or is it actually Ethernet frames? In 
other words: Does a 4 KB TCP packet that the NIC's offload function chops up 
into three Ethernet frames count as one or three in this algorithm?


Med venlig hilsen / kind regards
- Morten Brørup

> 
> Regards,
> Li Zhang
> > -Original Message-
> > From: dev  On Behalf Of Morten Br?rup
> > Sent: Friday, February 12, 2021 3:41 PM
> > To: Ferruh Yigit ; Li Zhang
> ; Dekel
> > Peled ; Ori Kam ; Slava
> Ovsiienko
> > ; Matan Azrad ; Dumitrescu,
> > Cristian 
> > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon ;
> > Raslan Darawsheh 
> > Subject: Re: [dpdk-dev] [PATCH] [RFC, v2]: adds support PPS(packet
> per second)
> > on meter
> >
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> > > Sent: Thursday, January 28, 2021 7:28 PM
> > >
> > > On 1/25/2021 1:20 AM, Li Zhang wrote:
> > > > Currently the flow Meter algorithms in rte_flow only supports
> bytes
> > > > per second(BPS).
> > > > Such as Single Rate Three Color Marker (srTCM rfc2697) This RFC
> adds
> > > > the packet per second definition in Meter algorithms structure,
> to
> > > > support the rte_mtr APIs with type srTCM pps mode.
> > > > The below structure will be extended:
> > > > rte_mtr_algorithm
> > > > rte_mtr_meter_profile
> > > > Signed-off-by: Li Zhang 
> > >
> > > cc'ed Cristian for review/comment.
> > >
> > > > ---
> > > >   lib/librte_ethdev/rte_mtr.h | 28 
> > > >   1 file changed, 28 insertions(+)
> > > >
> > > > diff --git a/lib/librte_ethdev/rte_mtr.h
> > > b/lib/librte_ethdev/rte_mtr.h
> > > > index 916a09c5c3..3e88904faf 100644
> > > > --- a/lib/librte_ethdev/rte_mtr.h
> > > > +++ b/lib/librte_ethdev/rte_mtr.h
> > > > @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
> > > >
> > > > /** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> > > > RTE_MTR_TRTCM_RFC4115,
> > > > +
> > > > +   /** Single Rate Three Color Marker (srTCM) in Packet per
> second
> > > mode */
> > > > +   RTE_MTR_SRTCM_PPS,
> > > >   };
> > > >
> > > >   /**
> > > > @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> > > > /** Excess Burst Size (EBS) (bytes). */
> > > > uint64_t ebs;
> > > > } trtcm_rfc4115;
> > > > +
> > > > +   /** Items only valid when *alg* is set to srTCM -
> PPS. */
> > > > +   struct {
> > > > +   /** Committed Information Rate
> > (CIR)(packets/second).
> > > */
> > > > +   uint64_t cir;
> > > > +
> > > > +   /** Committed Burst Size (CBS) (bytes). */
> > > > +   uint64_t cbs;
> > > > +
> > > > +   /** Excess Burst Size (EBS) (bytes). */
> > > > +   uint64_t ebs;
> > > > +   } srtcm_pps;
> >
> > In PPS mode, the burst sizes (ebs, ebs) mu

Re: [dpdk-dev] [PATCH] net/mlx5: fix UAR allocation diagnostics messages

2021-02-23 Thread Matan Azrad



From: Viacheslav Ovsiienko
> Depending on kernel capabilities and rdma-core version the mapping of UAR
> (User Access Region) of desired memory caching type (non-cached or write
> combining). The PMD implements the flexible strategy of UAR mapping,
> alternating the type of caching to succeed. During this process the failure
> diagnostics messages are emitted. These message are merely diagnostics ones
> and the logging level should be lowered to DEBUG.
> 
> Fixes: a0bfe9d56f74 ("net/mlx5: fix UAR memory mapping type")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Viacheslav Ovsiienko 
Acked-by: Matan Azrad 


[dpdk-dev] [PATCH v3] ci: update arm64 Travis jobs to Graviton2

2021-02-23 Thread Juraj Linkeš
Use only the newer Graviton2 environment in Travis CI instead of using
the older platform, which has intermittent issues:
1. collect2: fatal error: ld terminated with signal 9 [Killed]
2. ticketlock_autotest sometimes times out

These failures hint at resource availability issues in container
environments. The Graviton2 environment is using VMs and these failures
are not observed in it.

Signed-off-by: Juraj Linkeš 
---
 .travis.yml | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 6a2181299f..7ed982ac07 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -122,10 +122,10 @@ jobs:
   - *aarch64_clang_packages
   # aarch64 gcc jobs
   - env: DEF_LIB="static"
-arch: arm64
-compiler: gcc
-  - env: DEF_LIB="shared" RUN_TESTS=true
-arch: arm64
+dist: focal
+arch: arm64-graviton2
+virt: vm
+group: edge
 compiler: gcc
   - env: DEF_LIB="shared" RUN_TESTS=true
 dist: focal
@@ -134,7 +134,10 @@ jobs:
 group: edge
 compiler: gcc
   - env: DEF_LIB="shared" BUILD_DOCS=true
-arch: arm64
+dist: focal
+arch: arm64-graviton2
+virt: vm
+group: edge
 compiler: gcc
 addons:
   apt:
@@ -142,7 +145,10 @@ jobs:
   - *required_packages
   - *doc_packages
   - env: DEF_LIB="shared" ABI_CHECKS=true
-arch: arm64
+dist: focal
+arch: arm64-graviton2
+virt: vm
+group: edge
 compiler: gcc
 addons:
   apt:
@@ -151,10 +157,10 @@ jobs:
   - *libabigail_build_packages
   # aarch64 clang jobs
   - env: DEF_LIB="static"
-arch: arm64
-compiler: clang
-  - env: DEF_LIB="shared" RUN_TESTS=true
-arch: arm64
+dist: focal
+arch: arm64-graviton2
+virt: vm
+group: edge
 compiler: clang
   - env: DEF_LIB="shared" RUN_TESTS=true
 dist: focal
-- 
2.20.1



Re: [dpdk-dev] [RFC PATCH v2] build: add platform meson option

2021-02-23 Thread Juraj Linkeš


> -Original Message-
> From: David Christensen 
> Sent: Monday, February 22, 2021 10:25 PM
> To: Juraj Linkeš ; Bruce Richardson
> 
> Cc: tho...@monjalon.net; honnappa.nagaraha...@arm.com; dev@dpdk.org
> Subject: Re: [RFC PATCH v2] build: add platform meson option
> 
> 
> 
> On 2/19/21 1:11 AM, Juraj Linkeš wrote:
> >
> >
> >> -Original Message-
> >> From: Bruce Richardson 
> >> Sent: Wednesday, January 6, 2021 3:43 PM
> >> To: David Christensen 
> >> Cc: Juraj Linkeš ; tho...@monjalon.net;
> >> honnappa.nagaraha...@arm.com; dev@dpdk.org
> >> Subject: Re: [RFC PATCH v2] build: add platform meson option
> >>
> >> On Tue, Jan 05, 2021 at 02:17:44PM -0800, David Christensen wrote:
> > The current meson option 'machine' should only specify the ISA,
> > which is not sufficient for Arm, where setting ISA implies other
> > setting as
> >> well.
> > Add a new meson option, 'platform', which differentiates the type
> > of the build
> > (native/generic) and sets machine accordingly, unless the user
> > chooses to override it.
> > The 'machine' option also doesn't describe very well what it sets,
> > so introduce a new option 'cpu_instruction_set', but keep
> > 'machine' for backward compatibility.
> > These two new variables, taken together, achieve what 'machine'
> > was setting per architecture - setting the ISA in x86 build and
> > setting native/default 'build type' in aarch64 build - is now
> > properly being set for all architectures in a uniform manner.
> >
> > Signed-off-by: Juraj Linkeš 
> > ---
> >config/arm/meson.build|  4 +--
> >config/meson.build| 47 
> > +--
> >devtools/test-meson-builds.sh |  9 ---
> >meson_options.txt |  8 --
> >4 files changed, 47 insertions(+), 21 deletions(-)
> >
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > 42b4e43c7..6b09a74a7 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -3,10 +3,10 @@
> ># Copyright(c) 2017 Cavium, Inc
> >
> ># for checking defines we need to use the correct compiler
> > flags -march_opt = '-
> > march=@0@'.format(machine)
> > +march_opt = '-march=@0@'.format(cpu_instruction_set)
> >
> >arm_force_native_march = false
> > -arm_force_default_march = (machine == 'default')
> > +arm_force_default_march = (platform == 'generic')
> >
> >flags_common_default = [
> > # Accelarate rte_memcpy. Be sure to run unit test
> > (memcpy_perf_autotest) diff --git a/config/meson.build
> > b/config/meson.build index a3154e29c..647116513 100644
> > --- a/config/meson.build
> > +++ b/config/meson.build
> > @@ -63,42 +63,63 @@ if not is_windows
> > pmd_subdir_opt)
> >endif
> >
> > -# set the machine type and cflags for it
> > +platform = get_option('platform')
> > +
> > +# set the cpu_instruction_set type and cflags for it
> >if meson.is_cross_build()
> > -   machine = host_machine.cpu()
> > +   cpu_instruction_set = host_machine.cpu()
> >else
> > -   machine = get_option('machine')
> > +   cpu_instruction_set = get_option('cpu_instruction_set')
> > +   if get_option('machine') != 'auto'
> > +   warning('The "machine" option is deprecated. ' +
> > +   'Please use "cpu_instruction_set" instead.')
> > +   if cpu_instruction_set != 'auto'
> > +   error('Setting both "machine" and ' +
> > + '"cpu_instruction_set" is unsupported.')
> > +   endif
> > +   cpu_instruction_set = get_option('machine')
> > +   endif
> > +endif
> > +
> > +if platform == 'native'
> > +   if cpu_instruction_set == 'auto'
> > +   cpu_instruction_set = 'native'
> > +   endif
> > +elif platform == 'generic'
> > +   if cpu_instruction_set == 'auto'
> > +   cpu_instruction_set = 'default'
> > +   endif
> >endif
> >
> > -# machine type 'default' is special, it defaults to the per arch
> > agreed common
> > +if cpu_instruction_set == 'default'
> > +# cpu_instruction_set type 'default' is special, it defaults to
> > +the per arch agreed common
> ># minimal baseline needed for DPDK.
> ># That might not be the most optimized, but the most portable
> > version while  # still being able to support the CPU features
> > required for
> >> DPDK.
> ># This can be bumped up by the DPDK project, but it can never
> > be an  # invariant like 'native'
> > -if machine == 'default'
> > if host_machine.cpu_family().startswith('x86')
> >

Re: [dpdk-dev] [PATCH v3] ci: update arm64 Travis jobs to Graviton2

2021-02-23 Thread Ruifeng Wang
> -Original Message-
> From: Juraj Linkeš 
> Sent: Tuesday, February 23, 2021 4:28 PM
> To: tho...@monjalon.net; david.march...@redhat.com;
> acon...@redhat.com; maicolgabr...@hotmail.com
> Cc: dev@dpdk.org; Ruifeng Wang ; Honnappa
> Nagarahalli ; Juraj Linkeš
> 
> Subject: [PATCH v3] ci: update arm64 Travis jobs to Graviton2
> 
> Use only the newer Graviton2 environment in Travis CI instead of using the
> older platform, which has intermittent issues:
> 1. collect2: fatal error: ld terminated with signal 9 [Killed] 2.
> ticketlock_autotest sometimes times out
> 
> These failures hint at resource availability issues in container environments.
> The Graviton2 environment is using VMs and these failures are not observed
> in it.
> 
> Signed-off-by: Juraj Linkeš 

Reviewed-by: Ruifeng Wang 
> ---
>  .travis.yml | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)



[dpdk-dev] DPDK 21.05 Huawei hns3 Roadmap

2021-02-23 Thread oulijun

Hi,

Following are the work items of hns3 PMD planned for 21.05, Some 
features are delayed to the current releases.


 New features:

 【1】 Add PTP(Precise Time Protocol) support

 【2】 Add query optical module info by API

 【3】 Support LSC(Link Status Changed) event

   The LSC reporting function of the PF has been completed in 
21.02. This task involves the LSC reporting function of the VF and


   the LSC capability setting through the 
rte_pci_drvier.drv_flags.


 【4】 Implement tx_done_cleanup API

 【5】 Implement Rx/Tx descriptor status API

 【6】 Support runtime config for selecting Tx/Rx function

 【7】 Kunpeng930 support electrical port

 【8】 Kunpeng930 support flow control auto-negotiation

 【9】 Kunpeng930 support for simple BD mode for Tx checksum

【10】 Kunpeng930 Support link speed configuration for PF

【11】 Support new RAS mechanism for Kunpeng930

 Enhanced functionality:

【11】 Extend the DPDK stats

【12】 Extend the DPDK rte_dev_get_regs API implementation for query
   more common register information

【13】 Extend outer UDP cksum offload

【14】 Rx receive function optimization for improving performance
support rxd advanced layout
support checksum simple computing and ptype optimization

   【15】 Support push mode for Tx queue

 bonding function:
【16】 some bonding modes support prepare API

 testpmd updates:
【17】 testpmd support multi-process test

 Others:

【18】 Extend for hns3 document


Thanks

Lijun Ou



[dpdk-dev] [PATCH] maintainers: update crypto ownership

2021-02-23 Thread Akhil Goyal
Recently joined Marvell, hence change in
email id for crypto sub tree, security API
and ipsec-secgw application maintainers list.

Signed-off-by: Akhil Goyal 
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1962284e9..78e91faf9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -54,7 +54,7 @@ M: Chenbo Xia 
 T: git://dpdk.org/next/dpdk-next-virtio
 
 Next-crypto Tree
-M: Akhil Goyal 
+M: Akhil Goyal 
 T: git://dpdk.org/next/dpdk-next-crypto
 
 Next-eventdev Tree
@@ -424,7 +424,7 @@ F: app/test/test_cryptodev*
 F: examples/l2fwd-crypto/
 
 Security API
-M: Akhil Goyal 
+M: Akhil Goyal 
 M: Declan Doherty 
 T: git://dpdk.org/next/dpdk-next-crypto
 F: lib/librte_security/
@@ -1642,7 +1642,7 @@ F: doc/guides/sample_app_ug/hello_world.rst
 
 IPsec security gateway example
 M: Radu Nicolau 
-M: Akhil Goyal 
+M: Akhil Goyal 
 F: examples/ipsec-secgw/
 F: doc/guides/sample_app_ug/ipsec_secgw.rst
 
-- 
2.25.1



Re: [dpdk-dev] [PATCH] maintainers: update crypto ownership

2021-02-23 Thread Thomas Monjalon
23/02/2021 09:42, Akhil Goyal:
> Recently joined Marvell, hence change in
> email id for crypto sub tree, security API
> and ipsec-secgw application maintainers list.
> 
> Signed-off-by: Akhil Goyal 
> ---
>  MAINTAINERS | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

What about NXP pfe, DPAA_SEC and DPAA2_SEC?
If you don't intend to maintain them anymore,
you should resign from them.





Re: [dpdk-dev] [RFC PATCH v2] build: add platform meson option

2021-02-23 Thread Bruce Richardson
On Tue, Feb 23, 2021 at 08:45:09AM +, Juraj Linkeš wrote:
> 
> 
> > -Original Message-
> > From: David Christensen 
> > Sent: Monday, February 22, 2021 10:25 PM
> > To: Juraj Linkeš ; Bruce Richardson
> > 
> > Cc: tho...@monjalon.net; honnappa.nagaraha...@arm.com; dev@dpdk.org
> > Subject: Re: [RFC PATCH v2] build: add platform meson option
> > 
> > 
> > 
> > On 2/19/21 1:11 AM, Juraj Linkeš wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Bruce Richardson 
> > >> Sent: Wednesday, January 6, 2021 3:43 PM
> > >> To: David Christensen 
> > >> Cc: Juraj Linkeš ; tho...@monjalon.net;
> > >> honnappa.nagaraha...@arm.com; dev@dpdk.org
> > >> Subject: Re: [RFC PATCH v2] build: add platform meson option
> > >>
> > >> On Tue, Jan 05, 2021 at 02:17:44PM -0800, David Christensen wrote:
> > > The current meson option 'machine' should only specify the ISA,
> > > which is not sufficient for Arm, where setting ISA implies other
> > > setting as
> > >> well.
> > > Add a new meson option, 'platform', which differentiates the type
> > > of the build
> > > (native/generic) and sets machine accordingly, unless the user
> > > chooses to override it.
> > > The 'machine' option also doesn't describe very well what it sets,
> > > so introduce a new option 'cpu_instruction_set', but keep
> > > 'machine' for backward compatibility.
> > > These two new variables, taken together, achieve what 'machine'
> > > was setting per architecture - setting the ISA in x86 build and
> > > setting native/default 'build type' in aarch64 build - is now
> > > properly being set for all architectures in a uniform manner.
> > >
> > > Signed-off-by: Juraj Linkeš 
> > > ---
> > >config/arm/meson.build|  4 +--
> > >config/meson.build| 47 
> > > +--
> > >devtools/test-meson-builds.sh |  9 ---
> > >meson_options.txt |  8 --
> > >4 files changed, 47 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > > 42b4e43c7..6b09a74a7 100644
> > > --- a/config/arm/meson.build
> > > +++ b/config/arm/meson.build
> > > @@ -3,10 +3,10 @@
> > ># Copyright(c) 2017 Cavium, Inc
> > >
> > ># for checking defines we need to use the correct compiler
> > > flags -march_opt = '-
> > > march=@0@'.format(machine)
> > > +march_opt = '-march=@0@'.format(cpu_instruction_set)
> > >
> > >arm_force_native_march = false
> > > -arm_force_default_march = (machine == 'default')
> > > +arm_force_default_march = (platform == 'generic')
> > >
> > >flags_common_default = [
> > >   # Accelarate rte_memcpy. Be sure to run unit test
> > > (memcpy_perf_autotest) diff --git a/config/meson.build
> > > b/config/meson.build index a3154e29c..647116513 100644
> > > --- a/config/meson.build
> > > +++ b/config/meson.build
> > > @@ -63,42 +63,63 @@ if not is_windows
> > >   pmd_subdir_opt)
> > >endif
> > >
> > > -# set the machine type and cflags for it
> > > +platform = get_option('platform')
> > > +
> > > +# set the cpu_instruction_set type and cflags for it
> > >if meson.is_cross_build()
> > > - machine = host_machine.cpu()
> > > + cpu_instruction_set = host_machine.cpu()
> > >else
> > > - machine = get_option('machine')
> > > + cpu_instruction_set = get_option('cpu_instruction_set')
> > > + if get_option('machine') != 'auto'
> > > + warning('The "machine" option is deprecated. ' +
> > > + 'Please use "cpu_instruction_set" instead.')
> > > + if cpu_instruction_set != 'auto'
> > > + error('Setting both "machine" and ' +
> > > +   '"cpu_instruction_set" is unsupported.')
> > > + endif
> > > + cpu_instruction_set = get_option('machine')
> > > + endif
> > > +endif
> > > +
> > > +if platform == 'native'
> > > + if cpu_instruction_set == 'auto'
> > > + cpu_instruction_set = 'native'
> > > + endif
> > > +elif platform == 'generic'
> > > + if cpu_instruction_set == 'auto'
> > > + cpu_instruction_set = 'default'
> > > + endif
> > >endif
> > >
> > > -# machine type 'default' is special, it defaults to the per arch
> > > agreed common
> > > +if cpu_instruction_set == 'default'
> > > +# cpu_instruction_set type 'default' is special, it defaults to
> > > +the per arch agreed common
> > ># minimal baseline needed for DPDK.
> > ># That might not be the most optimized, but the most portable
> > > version while  # still being able to support the CPU features
>

Re: [dpdk-dev] [PATCH] maintainers: update crypto ownership

2021-02-23 Thread Akhil Goyal
> 23/02/2021 09:42, Akhil Goyal:
> > Recently joined Marvell, hence change in
> > email id for crypto sub tree, security API
> > and ipsec-secgw application maintainers list.
> >
> > Signed-off-by: Akhil Goyal 
> > ---
> >  MAINTAINERS | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> What about NXP pfe, DPAA_SEC and DPAA2_SEC?
> If you don't intend to maintain them anymore,
> you should resign from them.

Hemant would be sending a separate patch for that with the new maintainer.


Re: [dpdk-dev] [PATCH v2 1/7] eal: add wrappers for POSIX string functions

2021-02-23 Thread Bruce Richardson
On Tue, Feb 23, 2021 at 01:57:50AM +0300, Dmitry Kozlyuk wrote:
> 2021-02-22 14:26, Bruce Richardson:
> > As you say, though, the main issue will be whether we have instances in
> > public header files or not. I would hope that no static inline functions in
> > DPDK use any of the functions in question, but I'm not sure. Perhaps if
> > there are instances in public headers those could be reworked to not use
> > the problematic functions.
> 
> No instances of strdup(), strncasecmp(), or strtok_r() in any DPDK headers.
> 
> > For any functions, such as strdup, which are not in a public header I would
> > suggest the following as a possible start point, based off what was done
> > for strlcpy.
> > 
> > * In DPDK (probably EAL), define an rte_strdup function for use as a
> >   fallback.
> > * Inside the meson build scripts, use "cc.has_function()" to check if the
> >   regular strdup function is available. If not, then add "-DRTE_NO_STRDUP"
> >   to the c_args for DPDK building
> > * Inside our DPDK header (rte_string_fns.h in the strdup case), we can add
> >   a conditional define such as:
> >#ifdef RTE_NO_STRDUP
> >#define strdup(s) rte_strdup(s)
> >#endif
> > 
> > Thoughts on this?
> 
> Looks good to me, I can rework the patchset like so.
> 
> Policy considerations:
> 1. The approach only applies to platform-agnostic functions, like str*().
>Functions like sleep() still belong to librte_eal.
> 2. Deprecated functions, like index(3p), should be replaced
>with alternatives suggested by the standard.
> 3. If a standard C11 alternative is available, it should be used.
>This mostly applies to types, like u_int32 -> uint32_t
>(it's even in DPDK coding style already, isn't it?).
> 
> A nit: RTE_NO_XXX -> RTE_HAS_XXX (for consistency with existing macros)?

Sure, thanks.


Re: [dpdk-dev] [PATCH] maintainers: update crypto ownership

2021-02-23 Thread Hemant Agrawal



> -Original Message-
> From: Thomas Monjalon 
> 
> 23/02/2021 09:42, Akhil Goyal:
> > Recently joined Marvell, hence change in email id for crypto sub tree,
> > security API and ipsec-secgw application maintainers list.
> >
> > Signed-off-by: Akhil Goyal 
> > ---
> >  MAINTAINERS | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> What about NXP pfe, DPAA_SEC and DPAA2_SEC?
> If you don't intend to maintain them anymore, you should resign from them.
> 
> 
[Hemant] Patch is already submitted
https://patchwork.dpdk.org/project/dpdk/patch/20210218131631.5136-1-hemant.agra...@nxp.com/



Re: [dpdk-dev] [PATCH] rte_metrics: unconditionally export rte_metrics_tel_xxx functions

2021-02-23 Thread Bruce Richardson
On Tue, Feb 23, 2021 at 01:24:15AM +0300, Dmitry Kozlyuk wrote:
> + Bruce
> 
> On Mon, 22 Feb 2021 13:25:02 -0800, Jie wrote:
> [...]
> > diff --git a/config/meson.build b/config/meson.build
> > index 3cf560b8a..892bd9677 100644
> > --- a/config/meson.build
> > +++ b/config/meson.build
> > @@ -292,6 +292,11 @@ if is_freebsd
> > add_project_arguments('-D__BSD_VISIBLE', language: 'c')
> >  endif
> >  
> > +jansson = dependency('jansson', required: false, method: 'pkg-config')
> > +if jansson.found()
> > +   dpdk_conf.set('RTE_HAVE_JANSSON', 1)
> > +endif
> 
> DPDK seems to prefer "HAS" for such macros.
> 
> Why not do this in lib/librte_telemetry/meson.build?
> 
> [...]
> > --- a/lib/librte_metrics/meson.build
> > +++ b/lib/librte_metrics/meson.build
> > @@ -4,11 +4,12 @@
> >  sources = files('rte_metrics.c')
> >  headers = files('rte_metrics.h')
> >  
> > -jansson = dependency('jansson', required: false, method: 'pkg-config')
> > -if jansson.found()
> > +if dpdk_conf.has('RTE_HAVE_JANSSON')
> > ext_deps += jansson
> > -   sources += files('rte_metrics_telemetry.c')
> > -   headers += files('rte_metrics_telemetry.h')
> > -   deps += ['ethdev', 'telemetry']
> > -   includes += include_directories('../librte_telemetry')
> >  endif
> > +
> > +sources += files('rte_metrics_telemetry.c')
> > +headers += files('rte_metrics_telemetry.h')
> 
> Can be merged with definitions above.
> 
> [...]
> >  int32_t
> >  rte_metrics_tel_reg_all_ethdev(int *metrics_register_done, int 
> > *reg_index_list)
> >  {
> > +#ifdef JANSSON
> 
> Why not use RTE_HAS_JANSSON everywhere? (One more occurrence below.)
> 

+1 for this suggestion.

Also, since this is essentially stubbing out the functions in this file,
can you reduce the amount of ifdefs by putting either at the start or the
end the full set of stubs, leaving just the one ifdef block covering the
whole file.

/Bruce


Re: [dpdk-dev] [PATCH] maintainers: update for NXP pfe and dpaax_sec

2021-02-23 Thread Thomas Monjalon
18/02/2021 14:16, Hemant Agrawal:
> remove Akhil
> add Gagan
> 
> Signed-off-by: Hemant Agrawal 

Applied, thanks





Re: [dpdk-dev] [PATCH] maintainers: update crypto ownership

2021-02-23 Thread Thomas Monjalon
23/02/2021 09:42, Akhil Goyal:
> Recently joined Marvell, hence change in
> email id for crypto sub tree, security API
> and ipsec-secgw application maintainers list.
> 
> Signed-off-by: Akhil Goyal 

Applied, thanks




Re: [dpdk-dev] [PATCH v6 0/9] ethdev: support SubFunction representor

2021-02-23 Thread Wang, Haiyue
> -Original Message-
> From: dev  On Behalf Of Stephen Hemminger
> Sent: Tuesday, February 23, 2021 09:55
> To: Xueming Li 
> Cc: dev@dpdk.org; Viacheslav Ovsiienko ; Asaf Penso 
> 
> Subject: Re: [dpdk-dev] [PATCH v6 0/9] ethdev: support SubFunction representor
> 
> On Sun, 14 Feb 2021 03:21:30 +
> Xueming Li  wrote:
> 
> > SubFunction [1] is a portion of the PCI device, a SF netdev has its own
> > dedicated queues(txq, rxq). A SF netdev supports E-Switch representation
> > offload similar to existing PF and VF representors. A SF shares PCI
> > level resources with other SFs and/or with its parent PCI function.
> >
> > From SmartNIC perspective, when PCI device is shared for multi-host,
> > representors for host controller and host PF is required.
> >
> > This patch set introduces new representor types in addtion to existing
> > VF representor. Syntax:
> >
> > [[c#]pf#]vf#: VF port representor/s from controller/pf
> > [[c#]pf#]sf#: SF port representor/s from controller/pf
> > #: VF representor - for backwards compatibility
> >
> > "#" is number instance, list or range, valid examples:
> >   1, [1,3,5], [0-3], [0,2-4,6]
> >
> > For backward compatibility, this patch also introduces new netdev
> > capability to indicate the capability of supportting SF representor.
> >
> > Version history:
> >  RFC:
> > initial version [2]
> >  V2:
> > - separate patch for represnetor infrastructure, controller, pf and
> >   sf.
> > - replace representor ID macro with functions:
> >   rte_eth_representor_id_encode()
> >   rte_eth_representor_id_parse()
> > - new patch to allow devargs with same PCI BDF but different
> >   representors.
> > - other minor code updates according to comments, thanks Andrew!
> > - update document
> >  V3:
> > - improve probing of allowed devargs with same name.
> > - parse single word of kvargs as key.
> > - update kvargs test cases.
> >  V4:
> > - split first representor refactor patch into
> >   1: add representor type
> >   2: refector representor list parsing
> > - push the patch supporting multi-devargs for same device.
> >  V5:
> > - add comments for parsing functions
> > - update switch_representation.rst - Thanks Ajit
> >  V6:
> > - split representor types into different patches, move to
> >   rte_ethdev.h
> > - improvements of rte_eth_devargs_process_list() according to
> >   Andrew's suggestion
> > - fixed PF probe failure for Intel i40e
> > - replace ethdev SF capability with rte_eth_representor_info_get()
> > - add new ethdev ops api to get representor info from PMD
> > - replace representor ID encode/decode with conversion from
> >   representor info
> > - change ethdev representor iterator to use new ID encoding
> >
> >
> > Xueming Li (9):
> >   ethdev: introduce representor type
> >   ethdev: support representor port list
> >   ethdev: support new VF representor syntax
> >   ethdev: support sub function representor
> >   ethdev: support PF index in representor
> >   ethdev: support multi-host in representor
> >   ethdev: new API to get representor info
> >   ethdev: representor iterator compare complete info
> >   kvargs: update parser to support lists
> >
> >  app/test/test_kvargs.c|  46 -
> >  config/rte_config.h   |   1 +
> >  doc/guides/prog_guide/poll_mode_drv.rst   |  13 +-
> >  .../prog_guide/switch_representation.rst  |  35 +++-
> >  drivers/net/bnxt/bnxt_ethdev.c|   7 +
> >  drivers/net/enic/enic_ethdev.c|   6 +
> >  drivers/net/i40e/i40e_ethdev.c|   7 +
> >  drivers/net/ixgbe/ixgbe_ethdev.c  |   7 +
> >  drivers/net/mlx5/linux/mlx5_os.c  |  11 ++
> >  lib/librte_ethdev/ethdev_driver.h |  49 -
> >  lib/librte_ethdev/ethdev_private.c| 173 --
> >  lib/librte_ethdev/ethdev_private.h|   3 -
> >  lib/librte_ethdev/rte_class_eth.c |  40 ++--
> >  lib/librte_ethdev/rte_ethdev.c| 102 ++-
> >  lib/librte_ethdev/rte_ethdev.h|  53 ++
> >  lib/librte_ethdev/version.map |   4 +
> >  lib/librte_kvargs/rte_kvargs.c| 101 +++---
> >  17 files changed, 535 insertions(+), 123 deletions(-)
> >
> 
> A couple of higher level design questions:
> 1. How does Linux and other OS handle this in their API?
> 2. This solution seems quite tied into a specific implementation on your 
> hardware.
>Is there a PCI standard for this?

> 3. Maybe a more general solution where these were represented as buses would
>allow for other connection methods in the future?

It should be "auxiliary bus", I think. ;-)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/auxiliary.c

mlx5 subfunction support
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit

Re: [dpdk-dev] [PATCH] net/iavf: fix the VLAN tag extraction handling

2021-02-23 Thread Zhang, Qi Z



> -Original Message-
> From: Xie, WeiX 
> Sent: Tuesday, February 23, 2021 3:18 PM
> To: Rong, Leyi ; Zhang, Qi Z ; Lu,
> Wenzhuo ; Xing, Beilei 
> Cc: dev@dpdk.org; Wang, Haiyue ; Rong, Leyi
> 
> Subject: RE: [dpdk-dev] [PATCH] net/iavf: fix the VLAN tag extraction handling
> 
> Tested-by:  Xie,WeiX < weix@intel.com>
> 
> Regards,
> Xie Wei
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Leyi Rong
> > Sent: Tuesday, February 23, 2021 11:11 AM
> > To: Zhang, Qi Z ; Lu, Wenzhuo
> > ; Xing, Beilei 
> > Cc: dev@dpdk.org; Wang, Haiyue ; Rong, Leyi
> > 
> > Subject: [dpdk-dev] [PATCH] net/iavf: fix the VLAN tag extraction
> > handling
> >
> > From: Haiyue Wang 
> >
> > The new VIRTCHNL_VF_OFFLOAD_VLAN_V2 capability added support that
> > allows the PF to set the location of the RX VLAN tag for stripping offloads.
> >
> > So the VF needs to extract the VLAN tag according to the location flags.
> >
> > Fixes: 1c301e8c3cff ("net/iavf: support new VLAN capabilities")
> >
> > Signed-off-by: Haiyue Wang 
> > Signed-off-by: Leyi Rong 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi


Re: [dpdk-dev] [PATCH V2] kni: fix rtnl deadlocks and race conditions v2

2021-02-23 Thread Ferruh Yigit

On 2/23/2021 12:05 PM, Elad Nachman wrote:

This version 2 of the patch leverages on Stephen Hemminger's 64106
patch from Dec 2019,
and fixes the issues reported by Ferruh and Igor:

A. KNI sync lock is being locked while rtnl is held.
If two threads are calling kni_net_process_request() ,
then the first one will take the sync lock, release rtnl lock then sleep.
The second thread will try to lock sync lock while holding rtnl.
The first thread will wake, and try to lock rtnl, resulting in a deadlock.
The remedy is to release rtnl before locking the KNI sync lock.
Since in between nothing is accessing Linux network-wise,
no rtnl locking is needed.

B. There is a race condition in __dev_close_many() processing the
close_list while the application terminates.
It looks like if two vEth devices are terminating,
and one releases the rtnl lock, the other takes it,
updating the close_list in an unstable state,
causing the close_list to become a circular linked list,
hence list_for_each_entry() will endlessly loop inside
__dev_close_many() .
Since the description for the original patch indicate the
original motivation was bringing the device up,
I have changed kni_net_process_request() to hold the rtnl mutex
in case of bringing the device down since this is the path called
from __dev_close_many() , causing the corruption of the close_list.

Depends-on: patch-64106 ("kni: fix kernel deadlock when using mlx devices")

>

Can you please make new version of the patches on top of latest git head, not 
exiting patches, we don't support incremental updates.




Signed-off-by: Elad Nachman 
---
V2:
* rebuild the patch as increment from patch 64106
* fix comment and blank lines

---
  kernel/linux/kni/kni_net.c | 25 +
  1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index f0b6e9a8d..b41360220 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -110,9 +110,22 @@ kni_net_process_request(struct net_device *dev, struct 
rte_kni_request *req)
void *resp_va;
uint32_t num;
int ret_val;
+   int req_is_dev_stop = 0;
+


One more thing, can you please add comment to code why "stop" request is 
special? You have it in the commit log, but a short description in code also cna 
be helpful.


[dpdk-dev] [PATCH V2] kni: fix rtnl deadlocks and race conditions v2

2021-02-23 Thread Elad Nachman
This version 2 of the patch leverages on Stephen Hemminger's 64106 
patch from Dec 2019, 
and fixes the issues reported by Ferruh and Igor:

A. KNI sync lock is being locked while rtnl is held. 
If two threads are calling kni_net_process_request() ,
then the first one will take the sync lock, release rtnl lock then sleep.
The second thread will try to lock sync lock while holding rtnl.
The first thread will wake, and try to lock rtnl, resulting in a deadlock.
The remedy is to release rtnl before locking the KNI sync lock.
Since in between nothing is accessing Linux network-wise,
no rtnl locking is needed.

B. There is a race condition in __dev_close_many() processing the
close_list while the application terminates.
It looks like if two vEth devices are terminating,
and one releases the rtnl lock, the other takes it,
updating the close_list in an unstable state,
causing the close_list to become a circular linked list,
hence list_for_each_entry() will endlessly loop inside
__dev_close_many() . 
Since the description for the original patch indicate the
original motivation was bringing the device up,
I have changed kni_net_process_request() to hold the rtnl mutex
in case of bringing the device down since this is the path called
from __dev_close_many() , causing the corruption of the close_list. 

Depends-on: patch-64106 ("kni: fix kernel deadlock when using mlx devices")

Signed-off-by: Elad Nachman 
---
V2:
* rebuild the patch as increment from patch 64106
* fix comment and blank lines

---
 kernel/linux/kni/kni_net.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index f0b6e9a8d..b41360220 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -110,9 +110,22 @@ kni_net_process_request(struct net_device *dev, struct 
rte_kni_request *req)
void *resp_va;
uint32_t num;
int ret_val;
+   int req_is_dev_stop = 0;
+
+   if (req->req_id == RTE_KNI_REQ_CFG_NETWORK_IF &&
+   req->if_up == 0)
+   req_is_dev_stop = 1;
 
ASSERT_RTNL();
 
+   /* Since we need to wait and RTNL mutex is held
+* drop the mutex and hold reference to keep device
+*/
+   if (!req_is_dev_stop) {
+   dev_hold(dev);
+   rtnl_unlock();
+   }
+
mutex_lock(&kni->sync_lock);
 
/* Construct data */
@@ -124,16 +137,8 @@ kni_net_process_request(struct net_device *dev, struct 
rte_kni_request *req)
goto fail;
}
 
-   /* Since we need to wait and RTNL mutex is held
-* drop the mutex and hold refernce to keep device
-*/
-   dev_hold(dev);
-   rtnl_unlock();
-
ret_val = wait_event_interruptible_timeout(kni->wq,
kni_fifo_count(kni->resp_q), 3 * HZ);
-   rtnl_lock();
-   dev_put(dev);
 
if (signal_pending(current) || ret_val <= 0) {
ret = -ETIME;
@@ -152,6 +157,10 @@ kni_net_process_request(struct net_device *dev, struct 
rte_kni_request *req)
 
 fail:
mutex_unlock(&kni->sync_lock);
+   if (!req_is_dev_stop) {
+   rtnl_lock();
+   dev_put(dev);
+   }
return ret;
 }
 
-- 
2.17.1



[dpdk-dev] [PATCH 1/2] kni: fix rtnl deadlocks and race conditions v3

2021-02-23 Thread Elad Nachman
This first part of v3 of the patch re-introduces Stephen Hemminger's
patch 64106 . This part changes the parameter kni_net_process_request()
gets and introduces the initial rtnl unlocking mechanism.

Signed-off-by: Elad Nachman 
---
v3: 
* Include original patch and new patch as a series of patch, added a 
  comment to the new patch
v2:
* rebuild the patch as increment from patch 64106
* fix comment and blank lines

---
 kernel/linux/kni/kni_net.c | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index 4b752083d..f0b6e9a8d 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -102,17 +103,15 @@ get_data_kva(struct kni_dev *kni, void *pkt_kva)
  * It can be called to process the request.
  */
 static int
-kni_net_process_request(struct kni_dev *kni, struct rte_kni_request *req)
+kni_net_process_request(struct net_device *dev, struct rte_kni_request *req)
 {
+   struct kni_dev *kni = netdev_priv(dev);
int ret = -1;
void *resp_va;
uint32_t num;
int ret_val;
 
-   if (!kni || !req) {
-   pr_err("No kni instance or request\n");
-   return -EINVAL;
-   }
+   ASSERT_RTNL();
 
mutex_lock(&kni->sync_lock);
 
@@ -125,8 +124,17 @@ kni_net_process_request(struct kni_dev *kni, struct 
rte_kni_request *req)
goto fail;
}
 
+   /* Since we need to wait and RTNL mutex is held
+* drop the mutex and hold reference to keep device
+*/
+   dev_hold(dev);
+   rtnl_unlock();
+
ret_val = wait_event_interruptible_timeout(kni->wq,
kni_fifo_count(kni->resp_q), 3 * HZ);
+   rtnl_lock();
+   dev_put(dev);
+
if (signal_pending(current) || ret_val <= 0) {
ret = -ETIME;
goto fail;
@@ -155,7 +163,6 @@ kni_net_open(struct net_device *dev)
 {
int ret;
struct rte_kni_request req;
-   struct kni_dev *kni = netdev_priv(dev);
 
netif_start_queue(dev);
if (kni_dflt_carrier == 1)
@@ -168,7 +175,7 @@ kni_net_open(struct net_device *dev)
 
/* Setting if_up to non-zero means up */
req.if_up = 1;
-   ret = kni_net_process_request(kni, &req);
+   ret = kni_net_process_request(dev, &req);
 
return (ret == 0) ? req.result : ret;
 }
@@ -178,7 +185,6 @@ kni_net_release(struct net_device *dev)
 {
int ret;
struct rte_kni_request req;
-   struct kni_dev *kni = netdev_priv(dev);
 
netif_stop_queue(dev); /* can't transmit any more */
netif_carrier_off(dev);
@@ -188,7 +194,7 @@ kni_net_release(struct net_device *dev)
 
/* Setting if_up to 0 means down */
req.if_up = 0;
-   ret = kni_net_process_request(kni, &req);
+   ret = kni_net_process_request(dev, &req);
 
return (ret == 0) ? req.result : ret;
 }
@@ -643,14 +649,13 @@ kni_net_change_mtu(struct net_device *dev, int new_mtu)
 {
int ret;
struct rte_kni_request req;
-   struct kni_dev *kni = netdev_priv(dev);
 
pr_debug("kni_net_change_mtu new mtu %d to be set\n", new_mtu);
 
memset(&req, 0, sizeof(req));
req.req_id = RTE_KNI_REQ_CHANGE_MTU;
req.new_mtu = new_mtu;
-   ret = kni_net_process_request(kni, &req);
+   ret = kni_net_process_request(dev, &req);
if (ret == 0 && req.result == 0)
dev->mtu = new_mtu;
 
@@ -661,7 +666,6 @@ static void
 kni_net_change_rx_flags(struct net_device *netdev, int flags)
 {
struct rte_kni_request req;
-   struct kni_dev *kni = netdev_priv(netdev);
 
memset(&req, 0, sizeof(req));
 
@@ -683,7 +687,7 @@ kni_net_change_rx_flags(struct net_device *netdev, int 
flags)
req.promiscusity = 0;
}
 
-   kni_net_process_request(kni, &req);
+   kni_net_process_request(netdev, &req);
 }
 
 /*
@@ -742,7 +746,6 @@ kni_net_set_mac(struct net_device *netdev, void *p)
 {
int ret;
struct rte_kni_request req;
-   struct kni_dev *kni;
struct sockaddr *addr = p;
 
memset(&req, 0, sizeof(req));
@@ -754,8 +757,7 @@ kni_net_set_mac(struct net_device *netdev, void *p)
memcpy(req.mac_addr, addr->sa_data, netdev->addr_len);
memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
 
-   kni = netdev_priv(netdev);
-   ret = kni_net_process_request(kni, &req);
+   ret = kni_net_process_request(netdev, &req);
 
return (ret == 0 ? req.result : ret);
 }
-- 
2.17.1



[dpdk-dev] [PATCH 2/2] kni: fix rtnl deadlocks and race conditions v3

2021-02-23 Thread Elad Nachman
This part of the series includes my fixes for the issues reported
by Ferruh and Igor on top of part 1 of the patch series:

A. KNI sync lock is being locked while rtnl is held.
If two threads are calling kni_net_process_request() ,
then the first one will take the sync lock, release rtnl lock then sleep.
The second thread will try to lock sync lock while holding rtnl.
The first thread will wake, and try to lock rtnl, resulting in a deadlock.
The remedy is to release rtnl before locking the KNI sync lock.
Since in between nothing is accessing Linux network-wise,
no rtnl locking is needed.

B. There is a race condition in __dev_close_many() processing the
close_list while the application terminates.
It looks like if two vEth devices are terminating,
and one releases the rtnl lock, the other takes it,
updating the close_list in an unstable state,
causing the close_list to become a circular linked list,
hence list_for_each_entry() will endlessly loop inside
__dev_close_many() .
Since the description for the original patch indicate the
original motivation was bringing the device up,
I have changed kni_net_process_request() to hold the rtnl mutex
in case of bringing the device down since this is the path called
from __dev_close_many() , causing the corruption of the close_list. 

Signed-off-by: Elad Nachman 
---
v3: 
* Include original patch and new patch as a series of patch, added a
  comment to the new patch
v2:
* rebuild the patch as increment from patch 64106
* fix comment and blank lines
---
 kernel/linux/kni/kni_net.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index f0b6e9a8d..017e44812 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -110,9 +110,26 @@ kni_net_process_request(struct net_device *dev, struct 
rte_kni_request *req)
void *resp_va;
uint32_t num;
int ret_val;
+   int req_is_dev_stop = 0;
+
+   /* For configuring the interface to down,
+* rtnl must be held all the way to prevent race condition
+* inside __dev_close_many() between two netdev instances of KNI
+*/
+   if (req->req_id == RTE_KNI_REQ_CFG_NETWORK_IF &&
+   req->if_up == 0)
+   req_is_dev_stop = 1;
 
ASSERT_RTNL();
 
+   /* Since we need to wait and RTNL mutex is held
+* drop the mutex and hold reference to keep device
+*/
+   if (!req_is_dev_stop) {
+   dev_hold(dev);
+   rtnl_unlock();
+   }
+
mutex_lock(&kni->sync_lock);
 
/* Construct data */
@@ -124,16 +141,8 @@ kni_net_process_request(struct net_device *dev, struct 
rte_kni_request *req)
goto fail;
}
 
-   /* Since we need to wait and RTNL mutex is held
-* drop the mutex and hold refernce to keep device
-*/
-   dev_hold(dev);
-   rtnl_unlock();
-
ret_val = wait_event_interruptible_timeout(kni->wq,
kni_fifo_count(kni->resp_q), 3 * HZ);
-   rtnl_lock();
-   dev_put(dev);
 
if (signal_pending(current) || ret_val <= 0) {
ret = -ETIME;
@@ -152,6 +161,10 @@ kni_net_process_request(struct net_device *dev, struct 
rte_kni_request *req)
 
 fail:
mutex_unlock(&kni->sync_lock);
+   if (!req_is_dev_stop) {
+   rtnl_lock();
+   dev_put(dev);
+   }
return ret;
 }
 
-- 
2.17.1



Re: [dpdk-dev] [PATCH v7 2/2] bus/pci: support MMIO in PCI ioport accessors

2021-02-23 Thread 谢华伟(此时此刻)



On 2021/2/23 1:25, Ferruh Yigit wrote:

On 2/22/2021 5:15 PM, 谢华伟(此时此刻) wrote:

From: "huawei.xhw" 

With IO BAR, we get PIO(programmed IO) address.
With MMIO BAR, we get mapped virtual address.
We distinguish PIO(Programmed IO) and MMIO(memory mapped IO) by their 
address like how kernel does.

ioread/write8/16/32 is provided to access PIO/MMIO.
By the way, for virtio on arch other than x86, BAR flag indicates PIO 
but is mapped.


Signed-off-by: huawei xie 
Reviewed-by: Maxime Coquelin 


<...>


+
+static inline void iowrite8(uint8_t val, void *addr)
+{
+    (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+    *(volatile uint8_t *)addr = val :
+    outb(val, (unsigned long)addr);


//copying question from previous version:

Is the 'outb_p' to 'outb' conversion intentional? And if so why?

Same of the all 'outb_p', 'outw_p', 'outl_p'.


There is no need to delay for virtio device, as we can see in virtio 
legacy driver.


IMO, the delay is for ugly old device. The device itself should assure 
the previous IO completes when the subsequent IO instruction arrives.





Re: [dpdk-dev] [PATCH v3] ci: update arm64 Travis jobs to Graviton2

2021-02-23 Thread Aaron Conole
Juraj Linkeš  writes:

> Use only the newer Graviton2 environment in Travis CI instead of using
> the older platform, which has intermittent issues:
> 1. collect2: fatal error: ld terminated with signal 9 [Killed]
> 2. ticketlock_autotest sometimes times out
>
> These failures hint at resource availability issues in container
> environments. The Graviton2 environment is using VMs and these failures
> are not observed in it.
>
> Signed-off-by: Juraj Linkeš 
> ---

Acked-by: Aaron Conole 



[dpdk-dev] dpdk-graph-crypto-perf on ARM platform

2021-02-23 Thread Nipun Gupta
Has anyone tried using 'dpdk-graph-crypto-perf' on any of the ARM platform?
There seems to be some dependencies on tools/utilities orca and plotly which 
seems missing for ARM.

Regards,
Nipun


[dpdk-dev] [PATCH v2] dpdk-kmods: nvme support for netuio on Windows

2021-02-23 Thread Nick Connolly
Enable the netuio driver for an NVMe storage controller on Windows.
Add the class ID 010802 and identify the device as
 'netuio NVM Express Controller'.

Signed-off-by: Nick Connolly 
---
v2:
* rebase to latest netuio.inf

 windows/netuio/netuio.inf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/windows/netuio/netuio.inf b/windows/netuio/netuio.inf
index 666a69c..64872de 100644
--- a/windows/netuio/netuio.inf
+++ b/windows/netuio/netuio.inf
@@ -28,6 +28,7 @@ HKR,,Icon,,-5
 
 [Standard.NT$ARCH$]
 %netuio.DeviceDesc%=netuio_Device, Root\netuio
+%netuio.nvme.DeviceDesc%=netuio_Device, PCI\CC_010802
 %Intel.F1572.Description%=netuio_Device, PCI\VEN_8086&DEV_1572
 %Intel.F1580.Description%=netuio_Device, PCI\VEN_8086&DEV_1580
 %Intel.F1581.Description%=netuio_Device, PCI\VEN_8086&DEV_1581
@@ -85,6 +86,7 @@ Provider = "Vendor"
 ClassName = "Windows UIO"
 DiskName = "DPDK netUIO Installation Disk"
 netuio.DeviceDesc = "netuio Device"
+netuio.nvme.DeviceDesc = "netuio NVM Express Controller"
 Intel.F1572.Description = "Intel(R) Ethernet Controller X710 for 10GbE SFP+"
 Intel.F1580.Description = "Intel(R) Ethernet Controller XL710 for 40GbE 
backplane"
 Intel.F1581.Description = "Intel(R) Ethernet Controller X710 for 10GbE 
backplane"
-- 
2.25.1



[dpdk-dev] [PATCH v6] bus/pci: nvme on Windows requires class id and bus

2021-02-23 Thread Nick Connolly
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set device.bus.

Signed-off-by: Nick Connolly 
Acked-by: Tal Shnaiderman 
---
v6:
* no changes - resending to resolve spurious iol-testing failure

v5:
* Add missing version history

v4:
* Use #define to determine length of Class ID

v3:
* Put version history at top - v2 mistakenly had it after the diffs

v2:
* If only a 4-digit class ID is available, convert it to 6-digit format

 drivers/bus/pci/windows/pci.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/pci/windows/pci.c b/drivers/bus/pci/windows/pci.c
index f66258452..dceb0f4b2 100644
--- a/drivers/bus/pci/windows/pci.c
+++ b/drivers/bus/pci/windows/pci.c
@@ -23,6 +23,9 @@ DEFINE_DEVPROPKEY(DEVPKEY_Device_Numa_Node, 0x540b947e, 
0x8b40, 0x45bc,
  * the registry hive for PCI devices.
  */
 
+/* Class ID consists of hexadecimal digits */
+#define RTE_PCI_DRV_CLASSID_DIGIT  "0123456789abcdefABCDEF"
+
 /* The functions below are not implemented on Windows,
  * but need to be defined for compilation purposes
  */
@@ -280,17 +283,29 @@ parse_pci_hardware_id(const char *buf, struct rte_pci_id 
*pci_id)
 {
int ids = 0;
uint16_t vendor_id, device_id;
-   uint32_t subvendor_id = 0;
+   uint32_t subvendor_id = 0, class_id = 0;
+   const char *cp;
 
ids = sscanf_s(buf, "PCI\\VEN_%" PRIx16 "&DEV_%" PRIx16 "&SUBSYS_%"
PRIx32, &vendor_id, &device_id, &subvendor_id);
if (ids != 3)
return -1;
 
+   /* Try and find PCI class ID */
+   for (cp = buf; !(cp[0] == 0 && cp[1] == 0); cp++)
+   if (*cp == '&' && sscanf_s(cp,
+   "&CC_%" PRIx32, &class_id) == 1) {
+   /* Convert 4-digit class IDs to 6-digit format */
+   if (strspn(cp + 4, RTE_PCI_DRV_CLASSID_DIGIT) == 4)
+   class_id <<= 8;
+   break;
+   }
+
pci_id->vendor_id = vendor_id;
pci_id->device_id = device_id;
pci_id->subsystem_device_id = subvendor_id >> 16;
pci_id->subsystem_vendor_id = subvendor_id & 0x;
+   pci_id->class_id = class_id;
return 0;
 }
 
@@ -339,6 +354,7 @@ pci_scan_one(HDEVINFO dev_info, PSP_DEVINFO_DATA 
device_info_data)
if (ret != 0)
goto end;
 
+   dev->device.bus = &rte_pci_bus.bus;
dev->addr = addr;
dev->id = pci_id;
dev->max_vfs = 0; /* TODO: get max_vfs */
-- 
2.25.1



[dpdk-dev] [PATCH] examples/l3fwd: fix TX burst queue drain edge case

2021-02-23 Thread Kathleen Capella
Initialize prev_tsc to cur_tsc. This avoids running the TX queue drain
in the first iteration of the packet processing loop.

Fixes: af75078fece3 ("first public release")

Signed-off-by: Kathleen Capella 
Reviewed-by: Honnappa Nagarahalli 
---
 examples/l3fwd/l3fwd_em.c  | 9 +
 examples/l3fwd/l3fwd_lpm.c | 9 +
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 9996bfba3..01f8dff48 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -629,8 +629,6 @@ em_main_loop(__rte_unused void *dummy)
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) /
US_PER_S * BURST_TX_DRAIN_US;
 
-   prev_tsc = 0;
-
lcore_id = rte_lcore_id();
qconf = &lcore_conf[lcore_id];
 
@@ -650,9 +648,10 @@ em_main_loop(__rte_unused void *dummy)
lcore_id, portid, queueid);
}
 
-   while (!force_quit) {
+   cur_tsc = rte_rdtsc();
+   prev_tsc = cur_tsc;
 
-   cur_tsc = rte_rdtsc();
+   while (!force_quit) {
 
/*
 * TX burst queue drain
@@ -692,6 +691,8 @@ em_main_loop(__rte_unused void *dummy)
portid, qconf);
 #endif
}
+
+   cur_tsc = rte_rdtsc();
}
 
return 0;
diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index 3dcf1fef1..375746fef 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -185,8 +185,6 @@ lpm_main_loop(__rte_unused void *dummy)
const uint64_t drain_tsc = (rte_get_tsc_hz() + US_PER_S - 1) /
US_PER_S * BURST_TX_DRAIN_US;
 
-   prev_tsc = 0;
-
lcore_id = rte_lcore_id();
qconf = &lcore_conf[lcore_id];
 
@@ -206,9 +204,10 @@ lpm_main_loop(__rte_unused void *dummy)
lcore_id, portid, queueid);
}
 
-   while (!force_quit) {
+   cur_tsc = rte_rdtsc();
+   prev_tsc = cur_tsc;
 
-   cur_tsc = rte_rdtsc();
+   while (!force_quit) {
 
/*
 * TX burst queue drain
@@ -249,6 +248,8 @@ lpm_main_loop(__rte_unused void *dummy)
portid, qconf);
 #endif /* X86 */
}
+
+   cur_tsc = rte_rdtsc();
}
 
return 0;
-- 
2.17.1



Re: [dpdk-dev] [PATCH 21.05] app/testpmd: count outer IP checksum errors

2021-02-23 Thread Ferruh Yigit

On 1/31/2021 11:53 AM, Wisam Monther wrote:

Hi,


-Original Message-
From: dev  On Behalf Of Lance Richardson
Sent: Saturday, January 30, 2021 12:36 AM
To: Wenzhuo Lu ; Xiaoyun Li
; Bernard Iremonger

Cc: dev@dpdk.org; Ajit Kumar Khaparde ;
Kalesh Anakkur Purayil 
Subject: [dpdk-dev] [PATCH 21.05] app/testpmd: count outer IP checksum
errors

Count and display outer IP checksum errors in the checksum forwarder.

Example forwarder stats output:
   RX-packets: 158RX-dropped: 0 RX-total: 158
   Bad-ipcsum: 48 Bad-l4csum: 48Bad-outer-l4csum: 6
   Bad-outer-ipcsum: 40
   TX-packets: 0  TX-dropped: 0 TX-total: 0

Signed-off-by: Lance Richardson 
Reviewed-by: Ajit Kumar Khaparde 
Reviewed-by: Kalesh Anakkur Purayil 


Acked-by: Wisam Jaddo 



Reviewed-by: Ferruh Yigit 
Applied to dpdk-next-net/main, thanks.



'PKT_RX_EIP_CKSUM_BAD' is documented in mbuf header as:
"/** External IP header checksum error. */"

I think	'External' wording is confusing, as well as 'EIP' abbreviation, what do 
you think to create another macro alias to existing one, and mark the old one as 
deprecated?




Re: [dpdk-dev] [PATCH 21.05] app/testpmd: count outer IP checksum errors

2021-02-23 Thread Thomas Monjalon
23/02/2021 19:39, Ajit Khaparde:
> On Tue, Feb 23, 2021 at 10:36 AM Ferruh Yigit  wrote:
> >
> > On 1/31/2021 11:53 AM, Wisam Monther wrote:
> > > Hi,
> > >
> > >> -Original Message-
> > >> From: dev  On Behalf Of Lance Richardson
> > >> Sent: Saturday, January 30, 2021 12:36 AM
> > >> To: Wenzhuo Lu ; Xiaoyun Li
> > >> ; Bernard Iremonger
> > >> 
> > >> Cc: dev@dpdk.org; Ajit Kumar Khaparde ;
> > >> Kalesh Anakkur Purayil 
> > >> Subject: [dpdk-dev] [PATCH 21.05] app/testpmd: count outer IP checksum
> > >> errors
> > >>
> > >> Count and display outer IP checksum errors in the checksum forwarder.
> > >>
> > >> Example forwarder stats output:
> > >>RX-packets: 158RX-dropped: 0 RX-total: 158
> > >>Bad-ipcsum: 48 Bad-l4csum: 48
> > >> Bad-outer-l4csum: 6
> > >>Bad-outer-ipcsum: 40
> > >>TX-packets: 0  TX-dropped: 0 TX-total: 0
> > >>
> > >> Signed-off-by: Lance Richardson 
> > >> Reviewed-by: Ajit Kumar Khaparde 
> > >> Reviewed-by: Kalesh Anakkur Purayil  > >> anakkur.pura...@broadcom.com>
> > >
> > > Acked-by: Wisam Jaddo 
> > >
> >
> > Reviewed-by: Ferruh Yigit 
> > Applied to dpdk-next-net/main, thanks.
> >
> >
> >
> > 'PKT_RX_EIP_CKSUM_BAD' is documented in mbuf header as:
> > "/** External IP header checksum error. */"
> >
> > I think 'External' wording is confusing, as well as 'EIP' abbreviation, 
> > what do
> > you think to create another macro alias to existing one, and mark the old 
> > one as
> > deprecated?
> +1

+1




Re: [dpdk-dev] [PATCH v3 1/7] eal: add wrappers for POSIX string functions

2021-02-23 Thread Nick Connolly




Allocating memory using rte_strdup() I'd use rte_free()
to release it. I guess it will fail badly.
So, I think that a different, more specific prefix is
required for POSIX wrappers.


Andrew: my understanding of Bruce's proposal is that the strdup() name 
will now be kept (in this case through an inline definition), so I think 
this will be ok.  However, your comment reminded me of something else 
that it's probably worth mentioning as an aside:


As a general guideline on Windows, memory allocated within a shared 
library is best freed within the same DLL to ensure it goes back to the 
correct heap.  So we'd want to avoid calling strdup and then returning 
the value to the application for it to free (hopefully this doesn't 
happen). With an inline definition there's no change in behaviour, but 
adding rte_strdup (or anything else that calls malloc) into librte_eal 
might be an issue.


Regards,
Nick



Re: [dpdk-dev] [PATCH v3 3/7] eal: add sleep API

2021-02-23 Thread Nick Connolly

Hi Dmitry,

+void
+rte_thread_sleep(unsigned int sec)
+{
+   return Sleep(MS_PER_S * sec);
+}
There's probably no benefit in returning the 'void' value - I'd suggest 
just call Sleep().


Regards,
Nick


Re: [dpdk-dev] [PATCH 21.05] app/testpmd: count outer IP checksum errors

2021-02-23 Thread Ajit Khaparde
On Tue, Feb 23, 2021 at 10:36 AM Ferruh Yigit  wrote:
>
> On 1/31/2021 11:53 AM, Wisam Monther wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: dev  On Behalf Of Lance Richardson
> >> Sent: Saturday, January 30, 2021 12:36 AM
> >> To: Wenzhuo Lu ; Xiaoyun Li
> >> ; Bernard Iremonger
> >> 
> >> Cc: dev@dpdk.org; Ajit Kumar Khaparde ;
> >> Kalesh Anakkur Purayil 
> >> Subject: [dpdk-dev] [PATCH 21.05] app/testpmd: count outer IP checksum
> >> errors
> >>
> >> Count and display outer IP checksum errors in the checksum forwarder.
> >>
> >> Example forwarder stats output:
> >>RX-packets: 158RX-dropped: 0 RX-total: 158
> >>Bad-ipcsum: 48 Bad-l4csum: 48Bad-outer-l4csum: 6
> >>Bad-outer-ipcsum: 40
> >>TX-packets: 0  TX-dropped: 0 TX-total: 0
> >>
> >> Signed-off-by: Lance Richardson 
> >> Reviewed-by: Ajit Kumar Khaparde 
> >> Reviewed-by: Kalesh Anakkur Purayil  >> anakkur.pura...@broadcom.com>
> >
> > Acked-by: Wisam Jaddo 
> >
>
> Reviewed-by: Ferruh Yigit 
> Applied to dpdk-next-net/main, thanks.
>
>
>
> 'PKT_RX_EIP_CKSUM_BAD' is documented in mbuf header as:
> "/** External IP header checksum error. */"
>
> I think 'External' wording is confusing, as well as 'EIP' abbreviation, what 
> do
> you think to create another macro alias to existing one, and mark the old one 
> as
> deprecated?
+1

>


[dpdk-dev] [PATCH v2] rte_metrics: unconditionally exports rte_metrics_tel_xxx functions

2021-02-23 Thread Jie Zhou
From: Jie Zhou 

This patch allows the same set of rte_metrics_tel_* functions to be
exported no matter JANSSON is available or not, by doing following:
1.  Leverage dpdk_conf to set configuration flag RTE_HAVE_JANSSON
when Jansson dependency is found.
2.  In rte_metrics_telemetry.c, leverage RTE_HAVE_JANSSON to handle the
case when JANSSON is not available by adding stubs for all the instances.
3.  In meson.build, per dpdk\doc\guides\rel_notes\release_20_05.rst,
it is claimed that "Telemetry library is no longer dependent on the
external Jansson library, which allows Telemetry be enabled by default.",
thus make the deps and includes of Telemetry as not conditional anymore.

V2 changes:
Address comments from Dmitry Kozlyuk  and
Bruce Richardson :
- Set dpdk.conf RTE_HAS_JANSSON in metrics meson.build
- Reduce #ifdef RTE_HAS_JANSSON blocks

Signed-off-by: Jie Zhou 
---
 lib/librte_metrics/meson.build | 12 ++---
 lib/librte_metrics/rte_metrics_telemetry.c | 60 +-
 lib/librte_metrics/rte_metrics_telemetry.h |  2 +-
 3 files changed, 65 insertions(+), 9 deletions(-)

diff --git a/lib/librte_metrics/meson.build b/lib/librte_metrics/meson.build
index 28a8cc115..e543e4cdd 100644
--- a/lib/librte_metrics/meson.build
+++ b/lib/librte_metrics/meson.build
@@ -1,14 +1,14 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2017 Intel Corporation
 
-sources = files('rte_metrics.c')
-headers = files('rte_metrics.h')
+sources = files('rte_metrics.c', 'rte_metrics_telemetry.c')
+headers = files('rte_metrics.h', 'rte_metrics_telemetry.h')
 
 jansson = dependency('jansson', required: false, method: 'pkg-config')
 if jansson.found()
+   dpdk_conf.set('RTE_HAS_JANSSON', 1)
ext_deps += jansson
-   sources += files('rte_metrics_telemetry.c')
-   headers += files('rte_metrics_telemetry.h')
-   deps += ['ethdev', 'telemetry']
-   includes += include_directories('../librte_telemetry')
 endif
+
+deps += ['ethdev', 'telemetry']
+includes += include_directories('../librte_telemetry')
diff --git a/lib/librte_metrics/rte_metrics_telemetry.c 
b/lib/librte_metrics/rte_metrics_telemetry.c
index b8ee56ef0..305ee271f 100644
--- a/lib/librte_metrics/rte_metrics_telemetry.c
+++ b/lib/librte_metrics/rte_metrics_telemetry.c
@@ -2,8 +2,6 @@
  * Copyright(c) 2020 Intel Corporation
  */
 
-#include 
-
 #include 
 #include 
 #ifdef RTE_LIB_TELEMETRY
@@ -13,6 +11,7 @@
 #include "rte_metrics.h"
 #include "rte_metrics_telemetry.h"
 
+#ifdef RTE_HAS_JANSSON
 struct telemetry_metrics_data tel_met_data;
 
 int metrics_log_level;
@@ -541,3 +540,60 @@ RTE_INIT(metrics_ctor)
handle_ports_stats_values_by_name);
 #endif
 }
+#else
+int32_t
+rte_metrics_tel_reg_all_ethdev(int *metrics_register_done, int *reg_index_list)
+{
+   RTE_SET_USED(metrics_register_done);
+   RTE_SET_USED(reg_index_list);
+
+   return -ENOTSUP;
+}
+
+int32_t
+rte_metrics_tel_encode_json_format(struct telemetry_encode_param *ep,
+   char **json_buffer)
+{
+   RTE_SET_USED(ep);
+   RTE_SET_USED(json_buffer);
+
+   return -ENOTSUP;
+}
+
+int32_t
+rte_metrics_tel_get_ports_stats_json(struct telemetry_encode_param *ep,
+   int *reg_index, char **json_buffer)
+{
+   RTE_SET_USED(ep);
+   RTE_SET_USED(reg_index);
+   RTE_SET_USED(json_buffer);
+
+   return -ENOTSUP;
+}
+
+int32_t
+rte_metrics_tel_get_port_stats_ids(struct telemetry_encode_param *ep)
+{
+   RTE_SET_USED(ep);
+
+   return -ENOTSUP;
+}
+
+int32_t
+rte_metrics_tel_extract_data(struct telemetry_encode_param *ep, json_t *data)
+{
+   RTE_SET_USED(ep);
+   RTE_SET_USED(data);
+
+   return -ENOTSUP;
+}
+
+int32_t
+rte_metrics_tel_get_global_stats(struct telemetry_encode_param *ep)
+{
+   RTE_SET_USED(ep);
+
+   return -ENOTSUP;
+}
+
+#endif
diff --git a/lib/librte_metrics/rte_metrics_telemetry.h 
b/lib/librte_metrics/rte_metrics_telemetry.h
index 5dbb32ca0..2b6eb1ccc 100644
--- a/lib/librte_metrics/rte_metrics_telemetry.h
+++ b/lib/librte_metrics/rte_metrics_telemetry.h
@@ -2,7 +2,7 @@
  * Copyright(c) 2020 Intel Corporation
  */
 
-#ifdef RTE_LIB_TELEMETRY
+#ifdef RTE_HAS_JANSSON
 #include 
 #else
 #define json_t void *
-- 
2.30.0.vfs.0.2



[dpdk-dev] [PATCH 11/13] net/hns3: fix memory leakage for mbuf

2021-02-23 Thread Lijun Ou
From: Huisong Li 

The mbufs of rx queue will be allocated in "hns3_do_start" function.
But these mbufs are not released when "hns3_dev_start" executes
failed.

Fixes: c4ae39b2cfc5 ("net/hns3: fix Rx interrupt after reset")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_ethdev.c| 45 ---
 drivers/net/hns3/hns3_ethdev_vf.c | 43 ++---
 2 files changed, 54 insertions(+), 34 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 21c3c59..8300fea 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -102,6 +102,7 @@ static int hns3_remove_mc_addr(struct hns3_hw *hw,
struct rte_ether_addr *mac_addr);
 static int hns3_restore_fec(struct hns3_hw *hw);
 static int hns3_query_dev_fec_info(struct hns3_hw *hw);
+static int hns3_do_stop(struct hns3_adapter *hns);
 
 void hns3_ether_format_addr(char *buf, uint16_t size,
const struct rte_ether_addr *ether_addr)
@@ -5133,11 +5134,8 @@ hns3_dev_start(struct rte_eth_dev *dev)
return ret;
}
ret = hns3_map_rx_interrupt(dev);
-   if (ret) {
-   hw->adapter_state = HNS3_NIC_CONFIGURED;
-   rte_spinlock_unlock(&hw->lock);
-   return ret;
-   }
+   if (ret)
+   goto map_rx_inter_err;
 
/*
 * There are three register used to control the status of a TQP
@@ -5151,19 +5149,12 @@ hns3_dev_start(struct rte_eth_dev *dev)
 * status of queue in the dpdk framework.
 */
ret = hns3_start_all_txqs(dev);
-   if (ret) {
-   hw->adapter_state = HNS3_NIC_CONFIGURED;
-   rte_spinlock_unlock(&hw->lock);
-   return ret;
-   }
+   if (ret)
+   goto map_rx_inter_err;
 
ret = hns3_start_all_rxqs(dev);
-   if (ret) {
-   hns3_stop_all_txqs(dev);
-   hw->adapter_state = HNS3_NIC_CONFIGURED;
-   rte_spinlock_unlock(&hw->lock);
-   return ret;
-   }
+   if (ret)
+   goto start_all_rxqs_fail;
 
hw->adapter_state = HNS3_NIC_STARTED;
rte_spinlock_unlock(&hw->lock);
@@ -5187,7 +5178,17 @@ hns3_dev_start(struct rte_eth_dev *dev)
hns3_tm_dev_start_proc(hw);
 
hns3_info(hw, "hns3 dev start successful!");
+
return 0;
+
+start_all_rxqs_fail:
+   hns3_stop_all_txqs(dev);
+map_rx_inter_err:
+   (void)hns3_do_stop(hns);
+   hw->adapter_state = HNS3_NIC_CONFIGURED;
+   rte_spinlock_unlock(&hw->lock);
+
+   return ret;
 }
 
 static int
@@ -5196,6 +5197,17 @@ hns3_do_stop(struct hns3_adapter *hns)
struct hns3_hw *hw = &hns->hw;
int ret;
 
+   /*
+* The "hns3_do_stop" function will also be called by .stop_service to
+* prepare reset. At the time of global or IMP reset, the command cannot
+* be sent to stop the tx/rx queues. The mbuf in Tx/Rx queues may be
+* accessed during the reset process. So the mbuf can not be released
+* during reset and is required to be released after the reset is
+* completed.
+*/
+   if (__atomic_load_n(&hw->reset.resetting,  __ATOMIC_RELAXED) == 0)
+   hns3_dev_release_mbufs(hns);
+
ret = hns3_cfg_mac_mode(hw, false);
if (ret)
return ret;
@@ -5273,7 +5285,6 @@ hns3_dev_stop(struct rte_eth_dev *dev)
hns3_stop_tqps(hw);
hns3_do_stop(hns);
hns3_unmap_rx_interrupt(dev);
-   hns3_dev_release_mbufs(hns);
hw->adapter_state = HNS3_NIC_CONFIGURED;
}
hns3_rx_scattered_reset(dev);
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c 
b/drivers/net/hns3/hns3_ethdev_vf.c
index e7f6974..fd20c52 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -1941,6 +1941,17 @@ hns3vf_do_stop(struct hns3_adapter *hns)
 
hw->mac.link_status = ETH_LINK_DOWN;
 
+   /*
+* The "hns3vf_do_stop" function will also be called by .stop_service to
+* prepare reset. At the time of global or IMP reset, the command cannot
+* be sent to stop the tx/rx queues. The mbuf in Tx/Rx queues may be
+* accessed during the reset process. So the mbuf can not be released
+* during reset and is required to be released after the reset is
+* completed.
+*/
+   if (__atomic_load_n(&hw->reset.resetting,  __ATOMIC_RELAXED) == 0)
+   hns3_dev_release_mbufs(hns);
+
if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED) == 0) {
hns3vf_configure_mac_addr(hns, true);
ret = hns3_reset_all_tqps(hns);
@@ -2010,7 +2021,6 @@ hns3vf_dev_stop(struct rte_eth_dev *dev)
hns3_stop_tqps(hw);
hn

[dpdk-dev] [PATCH 10/13] net/hns3: remove unused parameter from func declaration

2021-02-23 Thread Lijun Ou
From: Huisong Li 

All input parameters in the "hns3_dev_xstats_get_by_id" API are used,
so the rte_unused flag of some variables should be deleted.

Fixes: 3213d584b698 ("net/hns3: fix xstats with id and names")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_stats.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hns3/hns3_stats.h b/drivers/net/hns3/hns3_stats.h
index 01b4f36..70a9c5b 100644
--- a/drivers/net/hns3/hns3_stats.h
+++ b/drivers/net/hns3/hns3_stats.h
@@ -156,8 +156,8 @@ int hns3_dev_xstats_get_names(struct rte_eth_dev *dev,
  struct rte_eth_xstat_name *xstats_names,
  __rte_unused unsigned int size);
 int hns3_dev_xstats_get_by_id(struct rte_eth_dev *dev,
- __rte_unused const uint64_t *ids,
- __rte_unused uint64_t *values,
+ const uint64_t *ids,
+ uint64_t *values,
  uint32_t size);
 int hns3_dev_xstats_get_names_by_id(struct rte_eth_dev *dev,
struct rte_eth_xstat_name *xstats_names,
-- 
2.7.4



[dpdk-dev] [PATCH 09/13] net/hns3: fix maximum frame size update after buffer alloc

2021-02-23 Thread Lijun Ou
From: Chengchang Tang 

After MTU changed, the buffer used to store packets in HW should be
reallocated. And buffer size is allocated based on the maximum frame
size in the PF struct. However, the value of maximum frame size  is
not updated in time when MTU is changed. This would lead to a packet
loss for not enough buffer.

This patch update the maximum frame size before reallocating the HW
buffer. And a rollback operation is added to avoid the side effects
of buffer reallocation failures.

Fixes: 1f5ca0b460cd ("net/hns3: support some device operations")
Fixes: d51867db65c1 ("net/hns3: add initialization")
Cc: sta...@dpdk.org

Signed-off-by: Chengchang Tang 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_ethdev.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index b3fd331..21c3c59 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2460,17 +2460,33 @@ hns3_set_mac_mtu(struct hns3_hw *hw, uint16_t new_mps)
 static int
 hns3_config_mtu(struct hns3_hw *hw, uint16_t mps)
 {
+   struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
+   uint16_t original_mps = hns->pf.mps;
+   int err;
int ret;
 
ret = hns3_set_mac_mtu(hw, mps);
if (ret) {
-   hns3_err(hw, "Failed to set mtu, ret = %d", ret);
+   hns3_err(hw, "failed to set mtu, ret = %d", ret);
return ret;
}
 
+   hns->pf.mps = mps;
ret = hns3_buffer_alloc(hw);
-   if (ret)
-   hns3_err(hw, "Failed to allocate buffer, ret = %d", ret);
+   if (ret) {
+   hns3_err(hw, "failed to allocate buffer, ret = %d", ret);
+   goto rollback;
+   }
+
+   return 0;
+
+rollback:
+   err = hns3_set_mac_mtu(hw, original_mps);
+   if (err) {
+   hns3_err(hw, "fail to rollback MTU, err = %d", err);
+   return ret;
+   }
+   hns->pf.mps = original_mps;
 
return ret;
 }
@@ -2505,7 +2521,7 @@ hns3_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
 dev->data->port_id, mtu, ret);
return ret;
}
-   hns->pf.mps = (uint16_t)frame_size;
+
if (is_jumbo_frame)
dev->data->dev_conf.rxmode.offloads |=
DEV_RX_OFFLOAD_JUMBO_FRAME;
-- 
2.7.4



[dpdk-dev] [PATCH 00/13] Features and bugfixes for hns3

2021-02-23 Thread Lijun Ou
This series add three features according to the
21.05 roadmap as well as fix some bugs.

Chengchang Tang (4):
  net/hns3: support module EEPROM dump
  net/hns3: add more registers to dump
  net/hns3: fix maximum frame size update after buffer alloc
  net/hns3: fix imprecise statistics

Chengwen Feng (2):
  net/hns3: implement cleanup for Tx done
  net/hns3: support RXD advanced layout

Hongbo Zheng (1):
  net/hns3: add process for MAC interrupt

Huisong Li (4):
  net/hns3: encapsulate a port shaping interface
  net/hns3: support PF on electrical net device
  net/hns3: remove unused parameter from func declaration
  net/hns3: fix memory leakage for mbuf

Min Hu (Connor) (2):
  net/hns3: add Rx and Tx bytes stats
  net/hns3: add imissed packet stats

 doc/guides/nics/features/hns3.ini  |   1 +
 doc/guides/nics/features/hns3_vf.ini   |   1 +
 doc/guides/rel_notes/release_21_05.rst |   5 +
 drivers/net/hns3/hns3_cmd.c|   8 +-
 drivers/net/hns3/hns3_cmd.h|  81 +++
 drivers/net/hns3/hns3_dcb.c|  22 +-
 drivers/net/hns3/hns3_dcb.h|   2 +-
 drivers/net/hns3/hns3_ethdev.c | 420 +
 drivers/net/hns3/hns3_ethdev.h |  22 ++
 drivers/net/hns3/hns3_ethdev_vf.c  |  46 ++--
 drivers/net/hns3/hns3_intr.c   |  20 ++
 drivers/net/hns3/hns3_intr.h   |   4 +
 drivers/net/hns3/hns3_regs.c   | 171 +-
 drivers/net/hns3/hns3_regs.h   |   1 +
 drivers/net/hns3/hns3_rxtx.c   | 283 ++
 drivers/net/hns3/hns3_rxtx.h   |  12 +
 drivers/net/hns3/hns3_rxtx_vec_neon.h  |  15 ++
 drivers/net/hns3/hns3_rxtx_vec_sve.c   |  11 +
 drivers/net/hns3/hns3_stats.c  | 293 +--
 drivers/net/hns3/hns3_stats.h  |  12 +-
 20 files changed, 1232 insertions(+), 198 deletions(-)

-- 
2.7.4



[dpdk-dev] [PATCH 06/13] net/hns3: encapsulate a port shaping interface

2021-02-23 Thread Lijun Ou
From: Huisong Li 

When rate of port changes, the rate limit of the port needs to
be updated. So it is necessary to encapsulate an interface that
configures the rate limit based on the rate.

Signed-off-by: Huisong Li 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_dcb.c| 22 +-
 drivers/net/hns3/hns3_dcb.h|  2 +-
 drivers/net/hns3/hns3_ethdev.c | 10 +++---
 3 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/net/hns3/hns3_dcb.c b/drivers/net/hns3/hns3_dcb.c
index 7fc6ac9..ebfc240 100644
--- a/drivers/net/hns3/hns3_dcb.c
+++ b/drivers/net/hns3/hns3_dcb.c
@@ -330,8 +330,8 @@ hns3_dcb_get_shapping_para(uint8_t ir_b, uint8_t ir_u, 
uint8_t ir_s,
return shapping_para;
 }
 
-int
-hns3_dcb_port_shaper_cfg(struct hns3_hw *hw)
+static int
+hns3_dcb_port_shaper_cfg(struct hns3_hw *hw, uint32_t speed)
 {
struct hns3_port_shapping_cmd *shap_cfg_cmd;
struct hns3_shaper_parameter shaper_parameter;
@@ -340,7 +340,7 @@ hns3_dcb_port_shaper_cfg(struct hns3_hw *hw)
struct hns3_cmd_desc desc;
int ret;
 
-   ret = hns3_shaper_para_calc(hw, hw->mac.link_speed,
+   ret = hns3_shaper_para_calc(hw, speed,
HNS3_SHAPER_LVL_PORT, &shaper_parameter);
if (ret) {
hns3_err(hw, "calculate shaper parameter failed: %d", ret);
@@ -366,12 +366,24 @@ hns3_dcb_port_shaper_cfg(struct hns3_hw *hw)
 * depends on the firmware version. But driver still needs to
 * calculate it and configure to firmware for better compatibility.
 */
-   shap_cfg_cmd->port_rate = rte_cpu_to_le_32(hw->mac.link_speed);
+   shap_cfg_cmd->port_rate = rte_cpu_to_le_32(speed);
hns3_set_bit(shap_cfg_cmd->flag, HNS3_TM_RATE_VLD_B, 1);
 
return hns3_cmd_send(hw, &desc, 1);
 }
 
+int
+hns3_port_shaper_update(struct hns3_hw *hw, uint32_t speed)
+{
+   int ret;
+
+   ret = hns3_dcb_port_shaper_cfg(hw, speed);
+   if (ret)
+   hns3_err(hw, "configure port shappering failed: ret = %d", ret);
+
+   return ret;
+}
+
 static int
 hns3_dcb_pg_shapping_cfg(struct hns3_hw *hw, enum hns3_shap_bucket bucket,
 uint8_t pg_id, uint32_t shapping_para, uint32_t rate)
@@ -961,7 +973,7 @@ hns3_dcb_shaper_cfg(struct hns3_hw *hw)
 {
int ret;
 
-   ret = hns3_dcb_port_shaper_cfg(hw);
+   ret = hns3_dcb_port_shaper_cfg(hw, hw->mac.link_speed);
if (ret) {
hns3_err(hw, "config port shaper failed: %d", ret);
return ret;
diff --git a/drivers/net/hns3/hns3_dcb.h b/drivers/net/hns3/hns3_dcb.h
index 8248434..0d25d3b 100644
--- a/drivers/net/hns3/hns3_dcb.h
+++ b/drivers/net/hns3/hns3_dcb.h
@@ -208,7 +208,7 @@ int hns3_queue_to_tc_mapping(struct hns3_hw *hw, uint16_t 
nb_rx_q,
 uint16_t nb_tx_q);
 
 int hns3_dcb_cfg_update(struct hns3_adapter *hns);
-int hns3_dcb_port_shaper_cfg(struct hns3_hw *hw);
+int hns3_port_shaper_update(struct hns3_hw *hw, uint32_t speed);
 int hns3_pg_shaper_rate_cfg(struct hns3_hw *hw, uint8_t pg_id, uint32_t rate);
 int hns3_pri_shaper_rate_cfg(struct hns3_hw *hw, uint8_t tc_no, uint32_t rate);
 uint8_t hns3_txq_mapped_tc_get(struct hns3_hw *hw, uint16_t txq_no);
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 34cd038..4320695 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -4384,7 +4384,6 @@ static int
 hns3_cfg_mac_speed_dup(struct hns3_hw *hw, uint32_t speed, uint8_t duplex)
 {
struct hns3_mac *mac = &hw->mac;
-   uint32_t cur_speed = mac->link_speed;
int ret;
 
duplex = hns3_check_speed_dup(duplex, speed);
@@ -4395,14 +4394,11 @@ hns3_cfg_mac_speed_dup(struct hns3_hw *hw, uint32_t 
speed, uint8_t duplex)
if (ret)
return ret;
 
-   mac->link_speed = speed;
-   ret = hns3_dcb_port_shaper_cfg(hw);
-   if (ret) {
-   hns3_err(hw, "failed to configure port shaper, ret = %d.", ret);
-   mac->link_speed = cur_speed;
+   ret = hns3_port_shaper_update(hw, speed);
+   if (ret)
return ret;
-   }
 
+   mac->link_speed = speed;
mac->link_duplex = duplex;
 
return 0;
-- 
2.7.4



[dpdk-dev] [PATCH 13/13] net/hns3: fix imprecise statistics

2021-02-23 Thread Lijun Ou
From: Chengchang Tang 

Currently, the hns3 statistics may be inaccurate due to the
following two problems:

1. Queue-level statistics are read from the firmware, and only
one Rx or Tx can be read at a time. This results in a large
time interval between reading multiple queues statistics in a
stress scenario, such as 1280 queues used by a PF or 256 functions
used at the same time. Especially when the 256 functions are used
at the same time, the interval between every two firmware commands
in a function can be huge, because the scheduling mechanism of the
firmware is similar to RR.

2. The current statistics are read by type. The HW statistics are
read first, and then the software statistics are read. Due to
preceding reasons, HW reading may be time-consuming, which cause
a synchronization problem between SW and HW statistics of the same
queue.

In this patch, queue-level statistics are directly read from the bar
instead of the firmware, and all the statistics of a queue include HW
and SW are read at a time to reduce inconsistency.

Fixes: 8839c5e202f3 ("net/hns3: support device stats")
Cc: sta...@dpdk.org

Signed-off-by: Chengchang Tang 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_stats.c | 227 ++
 1 file changed, 76 insertions(+), 151 deletions(-)

diff --git a/drivers/net/hns3/hns3_stats.c b/drivers/net/hns3/hns3_stats.c
index 365a3eb..a0fd5bb 100644
--- a/drivers/net/hns3/hns3_stats.c
+++ b/drivers/net/hns3/hns3_stats.c
@@ -367,7 +367,6 @@ static const struct hns3_xstats_name_offset 
hns3_imissed_stats_strings[] = {
HNS3_NUM_RESET_XSTATS + HNS3_NUM_IMISSED_XSTATS)
 
 static void hns3_tqp_stats_clear(struct hns3_hw *hw);
-static void hns3_tqp_basic_stats_clear(struct rte_eth_dev *dev);
 
 /*
  * Query all the MAC statistics data of Network ICL command ,opcode id: 0x0034.
@@ -481,49 +480,6 @@ hns3_query_update_mac_stats(struct rte_eth_dev *dev)
return ret;
 }
 
-/* Get tqp stats from register */
-static int
-hns3_update_tqp_stats(struct hns3_hw *hw)
-{
-   struct hns3_tqp_stats *stats = &hw->tqp_stats;
-   struct hns3_cmd_desc desc;
-   uint64_t cnt;
-   uint16_t i;
-   int ret;
-
-   for (i = 0; i < hw->tqps_num; i++) {
-   hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_QUERY_RX_STATUS,
- true);
-
-   desc.data[0] = rte_cpu_to_le_32((uint32_t)i);
-   ret = hns3_cmd_send(hw, &desc, 1);
-   if (ret) {
-   hns3_err(hw, "Failed to query RX No.%u queue stat: %d",
-i, ret);
-   return ret;
-   }
-   cnt = rte_le_to_cpu_32(desc.data[1]);
-   stats->rcb_rx_ring_pktnum_rcd += cnt;
-   stats->rcb_rx_ring_pktnum[i] += cnt;
-
-   hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_QUERY_TX_STATUS,
- true);
-
-   desc.data[0] = rte_cpu_to_le_32((uint32_t)i);
-   ret = hns3_cmd_send(hw, &desc, 1);
-   if (ret) {
-   hns3_err(hw, "Failed to query TX No.%u queue stat: %d",
-i, ret);
-   return ret;
-   }
-   cnt = rte_le_to_cpu_32(desc.data[1]);
-   stats->rcb_tx_ring_pktnum_rcd += cnt;
-   stats->rcb_tx_ring_pktnum[i] += cnt;
-   }
-
-   return 0;
-}
-
 static int
 hns3_update_rpu_drop_stats(struct hns3_hw *hw)
 {
@@ -589,17 +545,11 @@ hns3_stats_get(struct rte_eth_dev *eth_dev, struct 
rte_eth_stats *rte_stats)
struct hns3_rx_missed_stats *imissed_stats = &hw->imissed_stats;
struct hns3_tqp_stats *stats = &hw->tqp_stats;
struct hns3_rx_queue *rxq;
+   struct hns3_tx_queue *txq;
uint64_t cnt;
uint16_t i;
int ret;
 
-   /* Update tqp stats by read register */
-   ret = hns3_update_tqp_stats(hw);
-   if (ret) {
-   hns3_err(hw, "Update tqp stats fail : %d", ret);
-   return ret;
-   }
-
if (!hns->is_vf) {
/* Update imissed stats */
ret = hns3_update_imissed_stats(hw, false);
@@ -612,29 +562,41 @@ hns3_stats_get(struct rte_eth_dev *eth_dev, struct 
rte_eth_stats *rte_stats)
rte_stats->imissed = imissed_stats->rpu_rx_drop_cnt;
}
 
-   /* Get the error stats and bytes of received packets */
+   /* Reads all the stats of a rxq in a loop to keep them synchronized */
for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
rxq = eth_dev->data->rx_queues[i];
-   if (rxq) {
-   cnt = rxq->err_stats.l2_errors +
-   rxq->err_stats.pkt_len_errors;
-   rte_stats->ierrors += cnt;
+   if (rxq == NULL)
+   continue;
+
+   cnt =

[dpdk-dev] [PATCH 07/13] net/hns3: support PF on electrical net device

2021-02-23 Thread Lijun Ou
From: Huisong Li 

The normal operation of electrical interface devices depends on the
initialization and configuration of the PHY chip. The task of driving
the PHY chip is implemented in some firmware versions. If firmware
supports the phy driver, it will report a capability flag to driver
in probing process. The driver determines whether to support electrical
device based on the capability bit. If supported, the driver set a flag
indicating that the firmware takes over the PHY, and then the firmware
intializes the PHY.

This patch supports the query of link status and link info, and existing
basic features for electrical device.

Signed-off-by: Huisong Li 
Signed-off-by: Lijun Ou 
---
 doc/guides/rel_notes/release_21_05.rst |   1 +
 drivers/net/hns3/hns3_cmd.h|  37 +++
 drivers/net/hns3/hns3_ethdev.c | 115 +++--
 drivers/net/hns3/hns3_ethdev.h |   5 ++
 4 files changed, 152 insertions(+), 6 deletions(-)

diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst
index 13e3633..07a61aa 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -64,6 +64,7 @@ New Features
 
   * Added support for module EEPROM dumping.
   * Added support for freeing Tx mbuf on demand.
+  * Added support for electrical port in Kunpeng930.
 
 Removed Items
 -
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 93bfa74..7f567cb 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -222,6 +222,8 @@ enum hns3_opcode_type {
 
/* Firmware stats command */
HNS3_OPC_FIRMWARE_COMPAT_CFG= 0x701A,
+   /* Firmware control phy command */
+   HNS3_OPC_PHY_PARAM_CFG  = 0x7025,
 
/* SFP command */
HNS3_OPC_GET_SFP_EEPROM = 0x7100,
@@ -659,11 +661,46 @@ enum hns3_promisc_type {
 
 #define HNS3_LINK_EVENT_REPORT_EN_B0
 #define HNS3_NCSI_ERROR_REPORT_EN_B1
+#define HNS3_FIRMWARE_PHY_DRIVER_EN_B  2
 struct hns3_firmware_compat_cmd {
uint32_t compat;
uint8_t rsv[20];
 };
 
+/* Bitmap flags in supported, advertising and lp_advertising */
+#define HNS3_PHY_LINK_SPEED_10M_HD_BIT BIT(0)
+#define HNS3_PHY_LINK_SPEED_10M_BITBIT(1)
+#define HNS3_PHY_LINK_SPEED_100M_HD_BITBIT(2)
+#define HNS3_PHY_LINK_SPEED_100M_BIT   BIT(3)
+#define HNS3_PHY_LINK_MODE_AUTONEG_BIT BIT(6)
+#define HNS3_PHY_LINK_MODE_PAUSE_BIT   BIT(13)
+#define HNS3_PHY_LINK_MODE_ASYM_PAUSE_BIT  BIT(14)
+
+#define HNS3_PHY_PARAM_CFG_BD_NUM  2
+struct hns3_phy_params_bd0_cmd {
+   uint32_t speed;
+#define HNS3_PHY_DUPLEX_CFG_B  0
+   uint8_t duplex;
+#define HNS3_PHY_AUTONEG_CFG_B 0
+   uint8_t autoneg;
+   uint8_t eth_tp_mdix;
+   uint8_t eth_tp_mdix_ctrl;
+   uint8_t port;
+   uint8_t transceiver;
+   uint8_t phy_address;
+   uint8_t rsv;
+   uint32_t supported;
+   uint32_t advertising;
+   uint32_t lp_advertising;
+};
+
+struct hns3_phy_params_bd1_cmd {
+   uint8_t master_slave_cfg;
+   uint8_t master_slave_state;
+   uint8_t rsv1[2];
+   uint32_t rsv2[5];
+};
+
 #define HNS3_MAC_TX_EN_B   6
 #define HNS3_MAC_RX_EN_B   7
 #define HNS3_MAC_PAD_TX_B  11
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 4320695..a97dee4 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -3090,6 +3090,37 @@ hns3_get_capability(struct hns3_hw *hw)
 }
 
 static int
+hns3_check_media_type(struct hns3_hw *hw, uint8_t media_type)
+{
+   int ret;
+
+   switch (media_type) {
+   case HNS3_MEDIA_TYPE_COPPER:
+   if (!hns3_dev_copper_supported(hw)) {
+   PMD_INIT_LOG(ERR,
+"Media type is copper, not supported.");
+   ret = -EOPNOTSUPP;
+   } else {
+   ret = 0;
+   }
+   break;
+   case HNS3_MEDIA_TYPE_FIBER:
+   ret = 0;
+   break;
+   case HNS3_MEDIA_TYPE_BACKPLANE:
+   PMD_INIT_LOG(ERR, "Media type is Backplane, not supported.");
+   ret = -EOPNOTSUPP;
+   break;
+   default:
+   PMD_INIT_LOG(ERR, "Unknown media type = %u!", media_type);
+   ret = -EINVAL;
+   break;
+   }
+
+   return ret;
+}
+
+static int
 hns3_get_board_configuration(struct hns3_hw *hw)
 {
struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
@@ -3103,11 +3134,9 @@ hns3_get_board_configuration(struct hns3_hw *hw)
return ret;
}
 
-   if (cfg.media_type == HNS3_MEDIA_TYPE_COPPER &&
-   !hns3_dev_copper_supported(hw)) {
-   PMD_INIT_LOG(ERR, "media type is copper, not supported.");
-   return

[dpdk-dev] [PATCH 05/13] net/hns3: add imissed packet stats

2021-02-23 Thread Lijun Ou
From: "Min Hu (Connor)" 

This patch implement Rx imissed stats by querying cmdq.

Signed-off-by: Min Hu (Connor) 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_cmd.h|   7 +++
 drivers/net/hns3/hns3_ethdev.c |   7 +++
 drivers/net/hns3/hns3_ethdev.h |   1 +
 drivers/net/hns3/hns3_stats.c  | 106 -
 drivers/net/hns3/hns3_stats.h  |   8 
 5 files changed, 128 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 2e23f99..93bfa74 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -905,6 +905,13 @@ struct hns3_dev_specs_0_cmd {
uint32_t max_tm_rate;
 };
 
+struct hns3_query_rpu_cmd {
+   uint32_t tc_queue_num;
+   uint32_t rsv1[2];
+   uint32_t rpu_rx_pkt_drop_cnt;
+   uint32_t rsv2[2];
+};
+
 #define HNS3_MAX_TQP_NUM_HIP08_PF  64
 #define HNS3_DEFAULT_TX_BUF0x4000/* 16k  bytes */
 #define HNS3_TOTAL_PKT_BUF 0x108000  /* 1.03125M bytes */
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 91d720a..34cd038 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -4742,6 +4742,13 @@ hns3_init_pf(struct rte_eth_dev *eth_dev)
goto err_cmd_init;
}
 
+   /* Hardware statistics of imissed registers cleared. */
+   ret = hns3_update_imissed_stats(hw, true);
+   if (ret) {
+   hns3_err(hw, "clear imissed stats failed, ret = %d", ret);
+   return ret;
+   }
+
hns3_config_all_msix_error(hw, true);
 
ret = rte_intr_callback_register(&pci_dev->intr_handle,
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index 3a592c0..5299dd8 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -434,6 +434,7 @@ struct hns3_hw {
struct hns3_tqp_stats tqp_stats;
/* Include Mac stats | Rx stats | Tx stats */
struct hns3_mac_stats mac_stats;
+   struct hns3_rx_missed_stats imissed_stats;
uint32_t fw_version;
 
uint16_t num_msi;
diff --git a/drivers/net/hns3/hns3_stats.c b/drivers/net/hns3/hns3_stats.c
index 7796585..365a3eb 100644
--- a/drivers/net/hns3/hns3_stats.c
+++ b/drivers/net/hns3/hns3_stats.c
@@ -324,6 +324,12 @@ static const struct hns3_xstats_name_offset 
hns3_tx_queue_strings[] = {
{"TX_QUEUE_FBD", HNS3_RING_TX_FBDNUM_REG}
 };
 
+/* The statistic of imissed packet */
+static const struct hns3_xstats_name_offset hns3_imissed_stats_strings[] = {
+   {"RPU_DROP_CNT",
+   HNS3_IMISSED_STATS_FIELD_OFFSET(rpu_rx_drop_cnt)},
+};
+
 #define HNS3_NUM_MAC_STATS (sizeof(hns3_mac_strings) / \
sizeof(hns3_mac_strings[0]))
 
@@ -354,8 +360,11 @@ static const struct hns3_xstats_name_offset 
hns3_tx_queue_strings[] = {
 #define HNS3_NUM_TXQ_BASIC_STATS (sizeof(hns3_txq_basic_stats_strings) / \
sizeof(hns3_txq_basic_stats_strings[0]))
 
+#define HNS3_NUM_IMISSED_XSTATS (sizeof(hns3_imissed_stats_strings) / \
+   sizeof(hns3_imissed_stats_strings[0]))
+
 #define HNS3_FIX_NUM_STATS (HNS3_NUM_MAC_STATS + HNS3_NUM_ERROR_INT_XSTATS + \
-   HNS3_NUM_RESET_XSTATS)
+   HNS3_NUM_RESET_XSTATS + HNS3_NUM_IMISSED_XSTATS)
 
 static void hns3_tqp_stats_clear(struct hns3_hw *hw);
 static void hns3_tqp_basic_stats_clear(struct rte_eth_dev *dev);
@@ -515,6 +524,52 @@ hns3_update_tqp_stats(struct hns3_hw *hw)
return 0;
 }
 
+static int
+hns3_update_rpu_drop_stats(struct hns3_hw *hw)
+{
+   struct hns3_rx_missed_stats *stats = &hw->imissed_stats;
+   struct hns3_query_rpu_cmd *req;
+   struct hns3_cmd_desc desc;
+   uint64_t cnt;
+   uint32_t tc_num;
+   int ret;
+
+   hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_DFX_RPU_REG_0, true);
+   req = (struct hns3_query_rpu_cmd *)desc.data;
+
+   /*
+* tc_num is 0, means rpu stats of all TC channels will be
+* get from firmware
+*/
+   tc_num = 0;
+   req->tc_queue_num = rte_cpu_to_le_32(tc_num);
+   ret = hns3_cmd_send(hw, &desc, 1);
+   if (ret) {
+   hns3_err(hw, "failed to query RPU stats: %d", ret);
+   return ret;
+   }
+
+   cnt = rte_le_to_cpu_32(req->rpu_rx_pkt_drop_cnt);
+   stats->rpu_rx_drop_cnt += cnt;
+
+   return 0;
+}
+
+int
+hns3_update_imissed_stats(struct hns3_hw *hw, bool is_clear)
+{
+   int ret;
+
+   ret = hns3_update_rpu_drop_stats(hw);
+   if (ret)
+   return ret;
+
+   if (is_clear)
+   memset(&hw->imissed_stats, 0, sizeof(hw->imissed_stats));
+
+   return 0;
+}
+
 /*
  * Query tqp tx queue statistics ,opcode id: 0x0B03.
  * Query tqp rx queue statistics ,opcode id: 0x0B13.
@@ -531,6 +586,7 @@ hns3_stats_get(struct rte_eth_dev *eth_dev, struct 
rte_eth_stats *rte_stats)
 {
struct hns3_adapter *hns = eth_dev->data->

[dpdk-dev] [PATCH 12/13] net/hns3: add process for MAC interrupt

2021-02-23 Thread Lijun Ou
From: Hongbo Zheng 

Enable the interrupt report of MAC when MAC state changes
and log the hardware MAC state value.

Signed-off-by: Hongbo Zheng 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_cmd.h|  3 +++
 drivers/net/hns3/hns3_ethdev.c | 57 --
 drivers/net/hns3/hns3_intr.c   | 20 +++
 drivers/net/hns3/hns3_intr.h   |  4 +++
 4 files changed, 76 insertions(+), 8 deletions(-)

diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 6ceb655..094bf7e 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -116,6 +116,9 @@ enum hns3_opcode_type {
HNS3_OPC_QUERY_LINK_STATUS  = 0x0307,
HNS3_OPC_CONFIG_MAX_FRM_SIZE= 0x0308,
HNS3_OPC_CONFIG_SPEED_DUP   = 0x0309,
+   HNS3_OPC_QUERY_MAC_TNL_INT  = 0x0310,
+   HNS3_OPC_MAC_TNL_INT_EN = 0x0311,
+   HNS3_OPC_CLEAR_MAC_TNL_INT  = 0x0312,
HNS3_OPC_CONFIG_FEC_MODE= 0x031A,
 
/* PFC/Pause commands */
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 8300fea..9cbcc13 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -217,9 +217,6 @@ hns3_check_event_cause(struct hns3_adapter *hns, uint32_t 
*clearval)
goto out;
}
 
-   if (clearval && (vector0_int_stats || cmdq_src_val || hw_err_src_reg))
-   hns3_warn(hw, "vector0_int_stats:0x%x cmdq_src_val:0x%x 
hw_err_src_reg:0x%x",
- vector0_int_stats, cmdq_src_val, hw_err_src_reg);
val = vector0_int_stats;
ret = HNS3_VECTOR0_EVENT_OTHER;
 out:
@@ -258,6 +255,34 @@ hns3_clear_all_event_cause(struct hns3_hw *hw)
 }
 
 static void
+hns3_handle_mac_tnl(struct hns3_hw *hw)
+{
+   struct hns3_cmd_desc desc;
+   uint32_t status;
+   int ret;
+
+   /* query and clear mac tnl interruptions */
+   hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_QUERY_MAC_TNL_INT, true);
+   ret = hns3_cmd_send(hw, &desc, 1);
+   if (ret) {
+   hns3_err(hw, "failed to query mac tnl int, ret = %d.", ret);
+   return;
+   }
+
+   status = rte_le_to_cpu_32(desc.data[0]);
+   if (status) {
+   hns3_warn(hw, "mac tnl int occurs, status = 0x%x.", status);
+   hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_CLEAR_MAC_TNL_INT,
+ false);
+   desc.data[0] = rte_cpu_to_le_32(HNS3_MAC_TNL_INT_CLR);
+   ret = hns3_cmd_send(hw, &desc, 1);
+   if (ret)
+   hns3_err(hw, "failed to clear mac tnl int, ret = %d.",
+ret);
+   }
+}
+
+static void
 hns3_interrupt_handler(void *param)
 {
struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
@@ -265,24 +290,36 @@ hns3_interrupt_handler(void *param)
struct hns3_hw *hw = &hns->hw;
enum hns3_evt_cause event_cause;
uint32_t clearval = 0;
+   uint32_t vector0_int;
+   uint32_t ras_int;
+   uint32_t cmdq_int;
 
/* Disable interrupt */
hns3_pf_disable_irq0(hw);
 
event_cause = hns3_check_event_cause(hns, &clearval);
+   vector0_int = hns3_read_dev(hw, HNS3_VECTOR0_OTHER_INT_STS_REG);
+   ras_int = hns3_read_dev(hw, HNS3_RAS_PF_OTHER_INT_STS_REG);
+   cmdq_int = hns3_read_dev(hw, HNS3_VECTOR0_CMDQ_SRC_REG);
/* vector 0 interrupt is shared with reset and mailbox source events. */
if (event_cause == HNS3_VECTOR0_EVENT_ERR) {
-   hns3_warn(hw, "Received err interrupt");
+   hns3_warn(hw, "received interrupt: vector0_int_stat:0x%x "
+ "ras_int_stat:0x%x cmdq_int_stat:0x%x",
+ vector0_int, ras_int, cmdq_int);
hns3_handle_msix_error(hns, &hw->reset.request);
hns3_handle_ras_error(hns, &hw->reset.request);
+   hns3_handle_mac_tnl(hw);
hns3_schedule_reset(hns);
} else if (event_cause == HNS3_VECTOR0_EVENT_RST) {
-   hns3_warn(hw, "Received reset interrupt");
+   hns3_warn(hw, "received reset interrupt");
hns3_schedule_reset(hns);
-   } else if (event_cause == HNS3_VECTOR0_EVENT_MBX)
+   } else if (event_cause == HNS3_VECTOR0_EVENT_MBX) {
hns3_dev_handle_mbx_msg(hw);
-   else
-   hns3_err(hw, "Received unknown event");
+   } else {
+   hns3_warn(hw, "received unknown event: vector0_int_stat:0x%x "
+ "ras_int_stat:0x%x cmdq_int_stat:0x%x",
+ vector0_int, ras_int, cmdq_int);
+   }
 
hns3_clear_event_cause(hw, event_cause, clearval);
/* Enable interrupt if it is not cause by reset */
@@ -4639,6 +4676,8 @@ hns3_update_link_status(struct hns3_hw *hw)
if (state != hw->mac.link_status) {
hw->mac.link_st

[dpdk-dev] [PATCH 04/13] net/hns3: add Rx and Tx bytes stats

2021-02-23 Thread Lijun Ou
From: "Min Hu (Connor)" 

In current HNS3 PMD, Rx/Tx bytes from packet stats are not
implemented.

This patch implemented Rx/Tx bytes using soft counters.
Rx/Tx bytes stats will be enabled if the macro
RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS is defined.

Signed-off-by: Min Hu (Connor) 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_rxtx.c  | 24 
 drivers/net/hns3/hns3_rxtx_vec_neon.h | 15 +++
 drivers/net/hns3/hns3_rxtx_vec_sve.c  | 11 +++
 drivers/net/hns3/hns3_stats.c | 22 ++
 4 files changed, 68 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 5e79177..a8bd2cc 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2181,6 +2181,10 @@ hns3_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts)
   cksum_err);
hns3_rxd_to_vlan_tci(rxq, rxm, l234_info, &rxd);
 
+#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS
+   /* Increment bytes counter  */
+   rxq->basic_stats.bytes += rxm->pkt_len;
+#endif
rx_pkts[nb_rx++] = rxm;
continue;
 pkt_err:
@@ -2401,6 +2405,10 @@ hns3_recv_scattered_pkts(void *rx_queue,
   cksum_err);
hns3_rxd_to_vlan_tci(rxq, first_seg, l234_info, &rxd);
 
+#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS
+   /* Increment bytes counter */
+   rxq->basic_stats.bytes += first_seg->pkt_len;
+#endif
rx_pkts[nb_rx++] = first_seg;
first_seg = NULL;
continue;
@@ -3516,6 +3524,13 @@ hns3_tx_fill_hw_ring(struct hns3_tx_queue *txq,
for (i = 0; i < mainpart; i += PER_LOOP_NUM) {
hns3_tx_backup_4mbuf(tx_entry + i, pkts + i);
hns3_tx_setup_4bd(txdp + i, pkts + i);
+
+#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS
+   /* Increment bytes counter */
+   uint32_t j;
+   for (j = 0; j < PER_LOOP_NUM; j++)
+   txq->basic_stats.bytes += pkts[i + j]->pkt_len;
+#endif
}
if (unlikely(leftover > 0)) {
for (i = 0; i < leftover; i++) {
@@ -3523,6 +3538,11 @@ hns3_tx_fill_hw_ring(struct hns3_tx_queue *txq,
 pkts + mainpart + i);
hns3_tx_setup_1bd(txdp + mainpart + i,
  pkts + mainpart + i);
+
+#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS
+   /* Increment bytes counter */
+   txq->basic_stats.bytes += pkts[mainpart + i]->pkt_len;
+#endif
}
}
 }
@@ -3661,6 +3681,10 @@ hns3_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)
desc->tx.tp_fe_sc_vld_ra_ri |=
 rte_cpu_to_le_16(BIT(HNS3_TXD_FE_B));
 
+#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS
+   /* Increment bytes counter */
+   txq->basic_stats.bytes += tx_pkt->pkt_len;
+#endif
nb_hold += i;
txq->next_to_use = tx_next_use;
txq->tx_bd_ready -= i;
diff --git a/drivers/net/hns3/hns3_rxtx_vec_neon.h 
b/drivers/net/hns3/hns3_rxtx_vec_neon.h
index a693b4b..54d358d 100644
--- a/drivers/net/hns3/hns3_rxtx_vec_neon.h
+++ b/drivers/net/hns3/hns3_rxtx_vec_neon.h
@@ -61,6 +61,11 @@ hns3_xmit_fixed_burst_vec(void *__restrict tx_queue,
for (i = 0; i < n; i++, tx_pkts++, tx_desc++) {
hns3_vec_tx(tx_desc, *tx_pkts);
tx_entry[i].mbuf = *tx_pkts;
+
+#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS
+   /* Increment bytes counter */
+   txq->basic_stats.bytes += (*tx_pkts)->pkt_len;
+#endif
}
 
nb_commit -= n;
@@ -72,6 +77,11 @@ hns3_xmit_fixed_burst_vec(void *__restrict tx_queue,
for (i = 0; i < nb_commit; i++, tx_pkts++, tx_desc++) {
hns3_vec_tx(tx_desc, *tx_pkts);
tx_entry[i].mbuf = *tx_pkts;
+
+#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS
+   /* Increment bytes counter */
+   txq->basic_stats.bytes += (*tx_pkts)->pkt_len;
+#endif
}
 
next_to_use += nb_commit;
@@ -116,6 +126,11 @@ hns3_desc_parse_field(struct hns3_rx_queue *rxq,
if (likely(bd_base_info & BIT(HNS3_RXD_L3L4P_B)))
hns3_rx_set_cksum_flag(pkt, pkt->packet_type,
   cksum_err);
+
+#ifdef RTE_LIBRTE_HNS3_PMD_SOFT_COUNTERS
+   /* Increment bytes counter */
+   rxq->basic_stats.bytes += pkt->pkt_len;
+#endif
}
 
return retcode;
diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c 
b/drivers/net/hns3/hns3_rxtx_vec_sve.c
index b02bae7..8b9172a 100644
--- a/drivers/net/hns3/hns3_rxtx_vec_sve

[dpdk-dev] [PATCH 03/13] net/hns3: implement cleanup for Tx done

2021-02-23 Thread Lijun Ou
From: Chengwen Feng 

This patch add support tx_done_cleanup ops, which could support for
the API rte_eth_tx_done_cleanup to free consumed mbufs on Tx ring.

Signed-off-by: Chengwen Feng 
Signed-off-by: Lijun Ou 
---
 doc/guides/nics/features/hns3.ini  |  1 +
 doc/guides/nics/features/hns3_vf.ini   |  1 +
 doc/guides/rel_notes/release_21_05.rst |  2 +-
 drivers/net/hns3/hns3_ethdev.c |  1 +
 drivers/net/hns3/hns3_ethdev_vf.c  |  1 +
 drivers/net/hns3/hns3_rxtx.c   | 59 ++
 drivers/net/hns3/hns3_rxtx.h   |  1 +
 7 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/features/hns3.ini 
b/doc/guides/nics/features/hns3.ini
index ef432af..8e82d68 100644
--- a/doc/guides/nics/features/hns3.ini
+++ b/doc/guides/nics/features/hns3.ini
@@ -10,6 +10,7 @@ Queue start/stop = Y
 Runtime Rx queue setup = Y
 Runtime Tx queue setup = Y
 Burst mode info  = Y
+Free Tx mbuf on demand = Y
 MTU update   = Y
 Jumbo frame  = Y
 Scattered Rx = Y
diff --git a/doc/guides/nics/features/hns3_vf.ini 
b/doc/guides/nics/features/hns3_vf.ini
index 99a0bf0..c796cd5 100644
--- a/doc/guides/nics/features/hns3_vf.ini
+++ b/doc/guides/nics/features/hns3_vf.ini
@@ -10,6 +10,7 @@ Queue start/stop = Y
 Runtime Rx queue setup = Y
 Runtime Tx queue setup = Y
 Burst mode info  = Y
+Free Tx mbuf on demand = Y
 MTU update   = Y
 Jumbo frame  = Y
 Scattered Rx = Y
diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst
index eb0508b..13e3633 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -63,7 +63,7 @@ New Features
 * **Updated Hisilicon hns3 driver.**
 
   * Added support for module EEPROM dumping.
-
+  * Added support for freeing Tx mbuf on demand.
 
 Removed Items
 -
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index e02a7ec..91d720a 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -6388,6 +6388,7 @@ static const struct eth_dev_ops hns3_eth_dev_ops = {
.fec_get= hns3_fec_get,
.fec_set= hns3_fec_set,
.tm_ops_get = hns3_tm_ops_get,
+   .tx_done_cleanup= hns3_tx_done_cleanup,
 };
 
 static const struct hns3_reset_ops hns3_reset_ops = {
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c 
b/drivers/net/hns3/hns3_ethdev_vf.c
index 3f9f328..1b8c029 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -2763,6 +2763,7 @@ static const struct eth_dev_ops hns3vf_eth_dev_ops = {
.vlan_offload_set   = hns3vf_vlan_offload_set,
.get_reg= hns3_get_regs,
.dev_supported_ptypes_get = hns3_dev_supported_ptypes_get,
+   .tx_done_cleanup= hns3_tx_done_cleanup,
 };
 
 static const struct hns3_reset_ops hns3vf_reset_ops = {
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 222cf8a..5e79177 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -3913,6 +3913,65 @@ hns3_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t 
tx_queue_id)
return 0;
 }
 
+static int
+hns3_tx_done_cleanup_full(struct hns3_tx_queue *txq, uint32_t free_cnt)
+{
+   uint16_t next_to_clean = txq->next_to_clean;
+   uint16_t next_to_use   = txq->next_to_use;
+   uint16_t tx_bd_ready   = txq->tx_bd_ready;
+   struct hns3_entry *tx_pkt = &txq->sw_ring[next_to_clean];
+   struct hns3_desc *desc = &txq->tx_ring[next_to_clean];
+   uint32_t idx;
+
+   if (free_cnt == 0 || free_cnt > txq->nb_tx_desc)
+   free_cnt = txq->nb_tx_desc;
+
+   for (idx = 0; idx < free_cnt; idx++) {
+   if (next_to_clean == next_to_use)
+   break;
+
+   if (desc->tx.tp_fe_sc_vld_ra_ri &
+   rte_cpu_to_le_16(BIT(HNS3_TXD_VLD_B)))
+   break;
+
+   if (tx_pkt->mbuf != NULL) {
+   rte_pktmbuf_free_seg(tx_pkt->mbuf);
+   tx_pkt->mbuf = NULL;
+   }
+
+   next_to_clean++;
+   tx_bd_ready++;
+   tx_pkt++;
+   desc++;
+   if (next_to_clean == txq->nb_tx_desc) {
+   tx_pkt = txq->sw_ring;
+   desc = txq->tx_ring;
+   next_to_clean = 0;
+   }
+   }
+
+   if (idx > 0) {
+   txq->next_to_clean = next_to_clean;
+   txq->tx_bd_ready = tx_bd_ready;
+   }
+
+   return (int)idx;
+}
+
+int
+hns3_tx_done_cleanup(void *txq, uint32_t free_cnt)
+{
+   struct hns3_tx_queue *q = (struct hns3_tx_queue *)txq;
+   struct rte_eth_dev *dev = &rte_eth_devices[q->port_id];
+
+   if (dev->tx_pkt_burst == hns3_xmit_pkts)
+   return hns3_tx_done_cleanup_full(q

[dpdk-dev] [PATCH 02/13] net/hns3: add more registers to dump

2021-02-23 Thread Lijun Ou
From: Chengchang Tang 

This patch makes more registers dumped in the dump_reg API to help
loacte the fault.

Signed-off-by: Chengchang Tang 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_cmd.h  |  13 
 drivers/net/hns3/hns3_regs.c | 171 ++-
 2 files changed, 180 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index ff424a0..2e23f99 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -95,6 +95,19 @@ enum hns3_opcode_type {
HNS3_OPC_QUERY_REG_NUM  = 0x0040,
HNS3_OPC_QUERY_32_BIT_REG   = 0x0041,
HNS3_OPC_QUERY_64_BIT_REG   = 0x0042,
+   HNS3_OPC_DFX_BD_NUM = 0x0043,
+   HNS3_OPC_DFX_BIOS_COMMON_REG= 0x0044,
+   HNS3_OPC_DFX_SSU_REG_0  = 0x0045,
+   HNS3_OPC_DFX_SSU_REG_1  = 0x0046,
+   HNS3_OPC_DFX_IGU_EGU_REG= 0x0047,
+   HNS3_OPC_DFX_RPU_REG_0  = 0x0048,
+   HNS3_OPC_DFX_RPU_REG_1  = 0x0049,
+   HNS3_OPC_DFX_NCSI_REG   = 0x004A,
+   HNS3_OPC_DFX_RTC_REG= 0x004B,
+   HNS3_OPC_DFX_PPP_REG= 0x004C,
+   HNS3_OPC_DFX_RCB_REG= 0x004D,
+   HNS3_OPC_DFX_TQP_REG= 0x004E,
+   HNS3_OPC_DFX_SSU_REG_2  = 0x004F,
 
HNS3_OPC_QUERY_DEV_SPECS= 0x0050,
 
diff --git a/drivers/net/hns3/hns3_regs.c b/drivers/net/hns3/hns3_regs.c
index 84f3157..4022bb9 100644
--- a/drivers/net/hns3/hns3_regs.c
+++ b/drivers/net/hns3/hns3_regs.c
@@ -15,6 +15,8 @@
 #define REG_NUM_PER_LINE   4
 #define REG_LEN_PER_LINE   (REG_NUM_PER_LINE * sizeof(uint32_t))
 
+static int hns3_get_dfx_reg_line(struct hns3_hw *hw, uint32_t *length);
+
 static const uint32_t cmdq_reg_addrs[] = {HNS3_CMDQ_TX_ADDR_L_REG,
  HNS3_CMDQ_TX_ADDR_H_REG,
  HNS3_CMDQ_TX_DEPTH_REG,
@@ -77,6 +79,21 @@ static const uint32_t tqp_intr_reg_addrs[] = 
{HNS3_TQP_INTR_CTRL_REG,
  HNS3_TQP_INTR_GL2_REG,
  HNS3_TQP_INTR_RL_REG};
 
+static const uint32_t hns3_dfx_reg_opcode_list[] = {
+   HNS3_OPC_DFX_BIOS_COMMON_REG,
+   HNS3_OPC_DFX_SSU_REG_0,
+   HNS3_OPC_DFX_SSU_REG_1,
+   HNS3_OPC_DFX_IGU_EGU_REG,
+   HNS3_OPC_DFX_RPU_REG_0,
+   HNS3_OPC_DFX_RPU_REG_1,
+   HNS3_OPC_DFX_NCSI_REG,
+   HNS3_OPC_DFX_RTC_REG,
+   HNS3_OPC_DFX_PPP_REG,
+   HNS3_OPC_DFX_RCB_REG,
+   HNS3_OPC_DFX_TQP_REG,
+   HNS3_OPC_DFX_SSU_REG_2
+};
+
 static int
 hns3_get_regs_num(struct hns3_hw *hw, uint32_t *regs_num_32_bit,
  uint32_t *regs_num_64_bit)
@@ -123,14 +140,21 @@ hns3_get_regs_length(struct hns3_hw *hw, uint32_t *length)
if (!hns->is_vf) {
ret = hns3_get_regs_num(hw, ®s_num_32_bit, ®s_num_64_bit);
if (ret) {
-   hns3_err(hw, "Get register number failed, ret = %d.",
-ret);
-   return -ENOTSUP;
+   hns3_err(hw, "fail to get the number of registers, "
+"ret = %d.", ret);
+   return ret;
}
dfx_reg_lines = regs_num_32_bit * sizeof(uint32_t) /
REG_LEN_PER_LINE + 1;
dfx_reg_lines += regs_num_64_bit * sizeof(uint64_t) /
REG_LEN_PER_LINE + 1;
+
+   ret = hns3_get_dfx_reg_line(hw, &dfx_reg_lines);
+   if (ret) {
+   hns3_err(hw, "fail to get the number of dfx registers, "
+"ret = %d.", ret);
+   return ret;
+   }
len += dfx_reg_lines * REG_NUM_PER_LINE;
}
 
@@ -310,6 +334,144 @@ hns3_direct_access_regs(struct hns3_hw *hw, uint32_t 
*data)
return data - origin_data_ptr;
 }
 
+static int
+hns3_get_dfx_reg_bd_num(struct hns3_hw *hw, uint32_t *bd_num_list,
+   uint32_t list_size)
+{
+#define HNS3_GET_DFX_REG_BD_NUM_SIZE   4
+   struct hns3_cmd_desc desc[HNS3_GET_DFX_REG_BD_NUM_SIZE];
+   uint32_t index, desc_index;
+   uint32_t bd_num;
+   uint32_t i;
+   int ret;
+
+   for (i = 0; i < HNS3_GET_DFX_REG_BD_NUM_SIZE - 1; i++) {
+   hns3_cmd_setup_basic_desc(&desc[i], HNS3_OPC_DFX_BD_NUM, true);
+   desc[i].flag |= rte_cpu_to_le_16(HNS3_CMD_FLAG_NEXT);
+   }
+   /* The last BD does not need a next flag */
+   hns3_cmd_setup_basic_desc(&desc[i], HNS3_OPC_DFX_BD_NUM, true);
+
+   ret = hns3_cmd_send(hw, desc, HNS3_GET_DFX_REG_BD_NUM_SIZE);
+   if (ret) {
+   hns3_err(hw, "fail to get dfx bd num, ret = %d.\n", ret);
+   return ret;
+   }
+
+   /* The first data in the first BD 

[dpdk-dev] [PATCH 08/13] net/hns3: support RXD advanced layout

2021-02-23 Thread Lijun Ou
From: Chengwen Feng 

Currently, the driver get packet type by parse the
L3_ID/L4_ID/OL3_ID/OL4_ID from Rx descriptor and then lookup multiple
tables, it's time consuming.

Now Kunpeng930 support advanced RXD layout, which:
1. Combine OL3_ID/OL4_ID to 8bit PTYPE filed, so the driver get packet
type by lookup only one table.
Note: L3_ID/L4_ID become reserved fileds.
2. The 1588 timestamp located at Rx descriptor instead of query from
firmware.
3. The L3E/L4E/OL3E/OL4E will be zero when L3L4P is zero, so driver
could optimize the good checksum calculations (when L3E/L4E is zero
then mark PKT_RX_IP_CKSUM_GOOD/PKT_RX_L4_CKSUM_GOOD).

Considering compatibility, the firmware will report capability of
RXD advanced layout, the driver will identify and enable it by default.

This patch only provides basic function: identify and enable the RXD
advanced layout, and lookup ptype table if supported.

Signed-off-by: Chengwen Feng 
Signed-off-by: Lijun Ou 
---
 drivers/net/hns3/hns3_cmd.c   |   8 +-
 drivers/net/hns3/hns3_cmd.h   |   5 +
 drivers/net/hns3/hns3_ethdev.c|   2 +
 drivers/net/hns3/hns3_ethdev.h|  16 +++
 drivers/net/hns3/hns3_ethdev_vf.c |   2 +
 drivers/net/hns3/hns3_regs.h  |   1 +
 drivers/net/hns3/hns3_rxtx.c  | 200 ++
 drivers/net/hns3/hns3_rxtx.h  |  11 +++
 8 files changed, 243 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 32cd56b..8b9f075 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -409,8 +409,9 @@ hns3_cmd_send(struct hns3_hw *hw, struct hns3_cmd_desc 
*desc, int num)
return retval;
 }
 
-static void hns3_parse_capability(struct hns3_hw *hw,
- struct hns3_query_version_cmd *cmd)
+static void
+hns3_parse_capability(struct hns3_hw *hw,
+ struct hns3_query_version_cmd *cmd)
 {
uint32_t caps = rte_le_to_cpu_32(cmd->caps[0]);
 
@@ -429,6 +430,9 @@ static void hns3_parse_capability(struct hns3_hw *hw,
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_INDEP_TXRX_B, 1);
if (hns3_get_bit(caps, HNS3_CAPS_STASH_B))
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_STASH_B, 1);
+   if (hns3_get_bit(caps, HNS3_CAPS_RXD_ADV_LAYOUT_B))
+   hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_RXD_ADV_LAYOUT_B,
+1);
 }
 
 static uint32_t
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 7f567cb..6ceb655 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -312,6 +312,11 @@ enum HNS3_CAPS_BITS {
HNS3_CAPS_TQP_TXRX_INDEP_B,
HNS3_CAPS_HW_PAD_B,
HNS3_CAPS_STASH_B,
+   HNS3_CAPS_UDP_TUNNEL_CSUM_B,
+   HNS3_CAPS_RAS_IMP_B,
+   HNS3_CAPS_FEC_B,
+   HNS3_CAPS_PAUSE_B,
+   HNS3_CAPS_RXD_ADV_LAYOUT_B,
 };
 
 enum HNS3_API_CAP_BITS {
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index a97dee4..b3fd331 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -4970,6 +4970,8 @@ hns3_do_start(struct hns3_adapter *hns, bool reset_queue)
return ret;
}
 
+   hns3_enable_rxd_adv_layout(hw);
+
ret = hns3_init_queues(hns, reset_queue);
if (ret) {
PMD_INIT_LOG(ERR, "failed to init queues, ret = %d.", ret);
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index c495802..932600d 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -667,8 +667,13 @@ struct hns3_mp_param {
 #define HNS3_OL2TBL_NUM4
 #define HNS3_OL3TBL_NUM16
 #define HNS3_OL4TBL_NUM16
+#define HNS3_PTYPE_NUM 256
 
 struct hns3_ptype_table {
+   /*
+* The next fields used to calc packet-type by the
+* L3_ID/L4_ID/OL3_ID/OL4_ID from the Rx descriptor.
+*/
uint32_t l2l3table[HNS3_L2TBL_NUM][HNS3_L3TBL_NUM];
uint32_t l4table[HNS3_L4TBL_NUM];
uint32_t inner_l2table[HNS3_L2TBL_NUM];
@@ -677,6 +682,13 @@ struct hns3_ptype_table {
uint32_t ol2table[HNS3_OL2TBL_NUM];
uint32_t ol3table[HNS3_OL3TBL_NUM];
uint32_t ol4table[HNS3_OL4TBL_NUM];
+
+   /*
+* The next field used to calc packet-type by the PTYPE from the Rx
+* descriptor, it functions only when firmware report the capability of
+* HNS3_CAPS_RXD_ADV_LAYOUT_B and driver enabled it.
+*/
+   uint32_t ptype[HNS3_PTYPE_NUM] __rte_cache_min_aligned;
 };
 
 #define HNS3_FIXED_MAX_TQP_NUM_MODE0
@@ -771,6 +783,7 @@ struct hns3_adapter {
 #define HNS3_DEV_SUPPORT_TX_PUSH_B 0x5
 #define HNS3_DEV_SUPPORT_INDEP_TXRX_B  0x6
 #define HNS3_DEV_SUPPORT_STASH_B   0x7
+#define HNS3_DEV_SUPPORT_RXD_ADV_LAYOUT_B  0x9
 
 #define hns3_dev_dcb_supported(hw) \
hns3_get_bit((hw)->capability, HNS3_DEV_S

[dpdk-dev] [PATCH 01/13] net/hns3: support module EEPROM dump

2021-02-23 Thread Lijun Ou
From: Chengchang Tang 

This patch add support for dumping module EEPROM.

Signed-off-by: Chengchang Tang 
Signed-off-by: Lijun Ou 
---
 doc/guides/rel_notes/release_21_05.rst |   4 +
 drivers/net/hns3/hns3_cmd.h|  16 
 drivers/net/hns3/hns3_ethdev.c | 159 +
 3 files changed, 179 insertions(+)

diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst
index 2d7ceda..eb0508b 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -60,6 +60,10 @@ New Features
   * Added command to display Rx queue used descriptor count.
 ``show port (port_id) rxq (queue_id) desc used count``
 
+* **Updated Hisilicon hns3 driver.**
+
+  * Added support for module EEPROM dumping.
+
 
 Removed Items
 -
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 5010278..ff424a0 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -211,6 +211,8 @@ enum hns3_opcode_type {
HNS3_OPC_FIRMWARE_COMPAT_CFG= 0x701A,
 
/* SFP command */
+   HNS3_OPC_GET_SFP_EEPROM = 0x7100,
+   HNS3_OPC_GET_SFP_EXIST  = 0x7101,
HNS3_OPC_SFP_GET_SPEED  = 0x7104,
 
/* Interrupts commands */
@@ -714,6 +716,20 @@ struct hns3_config_auto_neg_cmd {
 #define HNS3_MAC_FEC_BASER 1
 #define HNS3_MAC_FEC_RS2
 
+#define HNS3_SFP_INFO_BD0_LEN  20UL
+#define HNS3_SFP_INFO_BDX_LEN  24UL
+
+struct hns3_sfp_info_bd0_cmd {
+   uint16_t offset;
+   uint16_t read_len;
+   uint8_t data[HNS3_SFP_INFO_BD0_LEN];
+};
+
+struct hns3_sfp_type {
+   uint8_t type;
+   uint8_t ext_type;
+};
+
 struct hns3_sfp_speed_cmd {
uint32_t  sfp_speed;
uint8_t   query_type; /* 0: sfp speed, 1: active fec */
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index dbd48de..e02a7ec 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -6172,6 +6172,163 @@ hns3_query_dev_fec_info(struct hns3_hw *hw)
return ret;
 }
 
+static bool
+hns3_optical_module_existed(struct hns3_hw *hw)
+{
+   struct hns3_cmd_desc desc;
+   bool existed;
+   int ret;
+
+   hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_GET_SFP_EXIST, true);
+   ret = hns3_cmd_send(hw, &desc, 1);
+   if (ret) {
+   hns3_err(hw,
+"fail to get optical module exist state, ret = %d.\n",
+ret);
+   return false;
+   }
+   existed = !!desc.data[0];
+
+   return existed;
+}
+
+static int
+hns3_get_module_eeprom_data(struct hns3_hw *hw, uint32_t offset,
+   uint32_t len, uint8_t *data)
+{
+#define HNS3_SFP_INFO_CMD_NUM 6
+#define HNS3_SFP_INFO_MAX_LEN \
+   (HNS3_SFP_INFO_BD0_LEN + \
+   (HNS3_SFP_INFO_CMD_NUM - 1) * HNS3_SFP_INFO_BDX_LEN)
+   struct hns3_cmd_desc desc[HNS3_SFP_INFO_CMD_NUM];
+   struct hns3_sfp_info_bd0_cmd *sfp_info_bd0;
+   uint16_t read_len;
+   uint16_t copy_len;
+   int ret;
+   int i;
+
+   for (i = 0; i < HNS3_SFP_INFO_CMD_NUM; i++) {
+   hns3_cmd_setup_basic_desc(&desc[i], HNS3_OPC_GET_SFP_EEPROM,
+ true);
+   if (i < HNS3_SFP_INFO_CMD_NUM - 1)
+   desc[i].flag |= rte_cpu_to_le_16(HNS3_CMD_FLAG_NEXT);
+   }
+
+   sfp_info_bd0 = (struct hns3_sfp_info_bd0_cmd *)desc[0].data;
+   sfp_info_bd0->offset = rte_cpu_to_le_16((uint16_t)offset);
+   read_len = RTE_MIN(len, HNS3_SFP_INFO_MAX_LEN);
+   sfp_info_bd0->read_len = rte_cpu_to_le_16((uint16_t)read_len);
+
+   ret = hns3_cmd_send(hw, desc, HNS3_SFP_INFO_CMD_NUM);
+   if (ret) {
+   hns3_err(hw, "fail to get module EEPROM info, ret = %d.\n",
+   ret);
+   return ret;
+   }
+
+   /* The data format in BD0 is different with the others. */
+   copy_len = RTE_MIN(len, HNS3_SFP_INFO_BD0_LEN);
+   memcpy(data, sfp_info_bd0->data, copy_len);
+   read_len = copy_len;
+
+   for (i = 1; i < HNS3_SFP_INFO_CMD_NUM; i++) {
+   if (read_len >= len)
+   break;
+
+   copy_len = RTE_MIN(len - read_len, HNS3_SFP_INFO_BDX_LEN);
+   memcpy(data + read_len, desc[i].data, copy_len);
+   read_len += copy_len;
+   }
+
+   return (int)read_len;
+}
+
+static int
+hns3_get_module_eeprom(struct rte_eth_dev *dev,
+  struct rte_dev_eeprom_info *info)
+{
+   struct hns3_adapter *hns = dev->data->dev_private;
+   struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(hns);
+   uint32_t offset = info->offset;
+   uint32_t len = info->length;
+   uint8_t *data = info->data;
+   uint32_t read_len = 0;
+
+   if (hw->mac.media_type != HNS3_MEDIA_TYPE_FIBER)
+  

Re: [dpdk-dev] [PATCH 1/2] config/arm: fix Hisilicon kunpeng920 SoC build

2021-02-23 Thread oulijun




在 2021/2/10 17:41, Thomas Monjalon 写道:

03/02/2021 13:46, Lijun Ou:

From: Chengchang Tang 

Because of the '9ca2f16' have merged, the current hns3
pmd driver can not be directly complied on the kunpeng920
server board. Therefore, we need to fix the meson build.
Besides, add kunpeng 920 SoC meson cross compile target.

Fixes: 9ca2f16faa7f ("config/arm: isolate generic build")


Why do you think this patch is fixing the one above?
It looks just a new config, not a fix. Am I missing something?

I'm sorry to see you so late. In the meantime, we are celebrating the 
Spring Festival. This patch fixes the problem. If the patch is not 
added, the latest version cannot be directly compiled on the Kunpeng 930 
server board.In addition, the cross compilation configuration file is added.


.



Re: [dpdk-dev] [PATCH v4] log: support custom log function

2021-02-23 Thread Feng Li
Hi Dmitry,
Thanks for your comments. I will submit the next patch to address your concern.

On Fri, Feb 19, 2021 at 4:11 PM Dmitry Kozlyuk  wrote:
>
> On Thu, 18 Feb 2021 14:12:53 +0800, Li Feng wrote:
> > By default, the dpdk log is out to stdout/stderr and syslog.
> > The rte_openlog_stream could set an external FILE* stream, but it
> > asks the consumer to give it a FILE* pointer.
> > For C++ or other languages, it's hard to get a libc FILE*.
> >
> > Support to set a hook is another choice for this scenario.
> >
> > Signed-off-by: Li Feng 
> > ---
> > v4: Fix the code style.
> > v3: Rename the func, change the comments, add funcs in version.map.
> > v2: Simplify the code.
>
> While I support the feature in general, its current design is imperfect both
> at interface level (documentation, corner cases) and at interaction with the
> rest of EAL logging subsystem (hijacking Linux EAL internals). IMO, proper
> implementation would rework rte_vlog() to print to buffer, then pass it to
> current logging function. But rte_openlog_stream() has to be supported still.
> What do others think?
OK, I have reworked on rte_vlog, it looks more reasonable.
>
> > +/**
> > + * Define a logging write function.
> > + */
> > +typedef ssize_t rte_log_write_function(void *cookie, const char *buf,
> > + size_t size);
>
> You're supposed to document callback parameters and behavior here.
> What about its thread-safety?
> It's not obvious what "cookie" means (suggesting "context").
Acked.
>
> > +
> > +/**
> > + * Change the default stream's write action that will be used by the 
> > logging
> > + * system.
> > + *
> > + * This should be done before the 'rte_eal_init' call. And the
> > + * 'rte_openlog_stream' call will override this action.
> > + *
> > + * @param logf
> > + *   Pointer to the log write function.
> > + */
> > +__rte_experimental
> > +void
> > +rte_log_sink_set(rte_log_write_function *logf);
>
> Since this API is currently Linux-only, it must report lack of support for
> FreeBSD and Windows, presumably via return value.
Acked.

>
> > +
> > +/**
> > + * Retrieve the log function used by the logging system (see 
> > rte_log_sink_set()
> > + * to change it).
> > + *
> > + * @return
> > + *   Pointer to the log function.
> > + */
> > +__rte_experimental
> > +rte_log_write_function*
> > +rte_log_sink_get(void);
>
> Doesn't checkpatch complain about "ret_type*" vs "ret_type *"?
Actually, checkpatch treats it ok.

>
> [...]
> > +/**
> > + * Change the default stream's write action that will be used by the 
> > logging
> > + * system.
> > + *
> > + * This should be done before the 'rte_eal_init' call. And the
> > + * 'rte_openlog_stream' call will override this action.
> > + */
>
> It's not very helpful to repeat public documnetation.
> Here is a good place to explain implementation, if required.
Acked.

>
> > +void
> > +rte_log_sink_set(rte_log_write_function *logf)
> > +{
> > + console_log_func.write = logf;
> > +}
>
> 1. What if NULL is passed? An app will likely crash far from the culprit.
> 2. This breaks EAL writing to syslog. It's probably intended, but please at
> least document such behavior.

OK, I think that if the logf is NULL, then keep the original function.

>
> [...]
> > +/*
> > + * Retrieve the default log write function.
> > + */
> > +rte_log_write_function*
> > +rte_log_sink_get(void)
> > +{
> > + return NULL;
> > +}
>
> I'd say it's an API inconsistency that you can write logs but sink is not
> callable.
I have rewritten this patch, it will be safe.


[dpdk-dev] [PATCH] net/i40evf: fix packet loss issue for X722

2021-02-23 Thread beilei . xing
From: Beilei Xing 

When Tx queue number is more than Rx queue number, and RSS is
enabled, there'll be packet loss with X722.
The root cause is the lookup table is not configured correctly,
since it uses VF's queue pair number but not Rx queue number.

Fixes: 2da3ba746795 ("net/i40e: fix VF runtime queues RSS config")
Cc: sta...@dpdk.org

Signed-off-by: Beilei Xing 
Signed-off-by: Hengjian Zhang 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 2909b4d894..0c9bd8d2c6 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2746,7 +2746,7 @@ i40evf_config_rss(struct i40e_vf *vf)
}
 
for (i = 0; i < rss_lut_size; i++)
-   lut_info[i] = i % vf->num_queue_pairs;
+   lut_info[i] = i % num;
 
ret = i40evf_set_rss_lut(&vf->vsi, lut_info,
 rss_lut_size);
-- 
2.26.2



Re: [dpdk-dev] [PATCH] net/i40evf: fix packet loss issue for X722

2021-02-23 Thread Guo, Jia
Acked-by: Jeff Guo 

> -Original Message-
> From: Xing, Beilei 
> Sent: Wednesday, February 24, 2021 10:09 AM
> To: Guo, Jia 
> Cc: dev@dpdk.org; Xing, Beilei ; sta...@dpdk.org;
> Zhang, HengjianX 
> Subject: [PATCH] net/i40evf: fix packet loss issue for X722
> 
> From: Beilei Xing 
> 
> When Tx queue number is more than Rx queue number, and RSS is enabled,
> there'll be packet loss with X722.
> The root cause is the lookup table is not configured correctly, since it uses
> VF's queue pair number but not Rx queue number.
> 
> Fixes: 2da3ba746795 ("net/i40e: fix VF runtime queues RSS config")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Beilei Xing 
> Signed-off-by: Hengjian Zhang 
> ---
>  drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> index 2909b4d894..0c9bd8d2c6 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -2746,7 +2746,7 @@ i40evf_config_rss(struct i40e_vf *vf)
>   }
> 
>   for (i = 0; i < rss_lut_size; i++)
> - lut_info[i] = i % vf->num_queue_pairs;
> + lut_info[i] = i % num;
> 
>   ret = i40evf_set_rss_lut(&vf->vsi, lut_info,
>rss_lut_size);
> --
> 2.26.2



Re: [dpdk-dev] [PATCH] net/e1000: remove MTU setting limitation

2021-02-23 Thread Guo, Jia
Seems that this is align with the fixing process of the other pmds(ixgbe/txgbe) 
and it is not bad. Thanks.

Acked-by: Jeff Guo 

> -Original Message-
> From: Yu, DapengX 
> Sent: Friday, February 19, 2021 6:03 PM
> To: Guo, Jia ; Wang, Haiyue 
> Cc: dev@dpdk.org; Yu, DapengX ; sta...@dpdk.org
> Subject: [PATCH] net/e1000: remove MTU setting limitation
> 
> From: Dapeng Yu 
> 
> Currently, if requested MTU is bigger than mbuf size and scattered receive is
> not enabled, setting MTU to that value fails.
> 
> This patch allows setting this special MTU when device is stopped, because
> scattered_rx will be re-configured during next port start and driver may
> enable scattered receive according new MTU value.
> 
> After this patch, driver may select different receive function automatically
> after MTU set, according MTU values selected.
> 
> Fixes: 59d0ecdbf0e1 ("ethdev: MTU accessors")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dapeng Yu 
> ---
>  drivers/net/e1000/em_ethdev.c  | 12 
> drivers/net/e1000/igb_ethdev.c | 12 
>  2 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/e1000/em_ethdev.c
> b/drivers/net/e1000/em_ethdev.c index 9b8c4a7de..3c6f643c1 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -1805,11 +1805,15 @@ eth_em_mtu_set(struct rte_eth_dev *dev,
> uint16_t mtu)
>   if (mtu < RTE_ETHER_MIN_MTU || frame_size >
> dev_info.max_rx_pktlen)
>   return -EINVAL;
> 
> - /* refuse mtu that requires the support of scattered packets when
> this
> -  * feature has not been enabled before. */
> - if (!dev->data->scattered_rx &&
> - frame_size > dev->data->min_rx_buf_size -
> RTE_PKTMBUF_HEADROOM)
> + /*
> +  * If device is started, refuse mtu that requires the support of
> +  * scattered packets when this feature has not been enabled before.
> +  */
> + if (dev->data->dev_started && !dev->data->scattered_rx &&
> + frame_size > dev->data->min_rx_buf_size -
> RTE_PKTMBUF_HEADROOM) {
> + PMD_INIT_LOG(ERR, "Stop port first.");
>   return -EINVAL;
> + }
> 
>   hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>   rctl = E1000_READ_REG(hw, E1000_RCTL); diff --git
> a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c index
> 5323504e9..1716d6b90 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -4394,11 +4394,15 @@ eth_igb_mtu_set(struct rte_eth_dev *dev,
> uint16_t mtu)
>   frame_size > dev_info.max_rx_pktlen)
>   return -EINVAL;
> 
> - /* refuse mtu that requires the support of scattered packets when
> this
> -  * feature has not been enabled before. */
> - if (!dev->data->scattered_rx &&
> - frame_size > dev->data->min_rx_buf_size -
> RTE_PKTMBUF_HEADROOM)
> + /*
> +  * If device is started, refuse mtu that requires the support of
> +  * scattered packets when this feature has not been enabled before.
> +  */
> + if (dev->data->dev_started && !dev->data->scattered_rx &&
> + frame_size > dev->data->min_rx_buf_size -
> RTE_PKTMBUF_HEADROOM) {
> + PMD_INIT_LOG(ERR, "Stop port first.");
>   return -EINVAL;
> + }
> 
>   rctl = E1000_READ_REG(hw, E1000_RCTL);
> 
> --
> 2.27.0



Re: [dpdk-dev] [PATCH v2] net/igc: remove MTU setting limitation

2021-02-23 Thread Guo, Jia
Seems that v2 is the same as v1, but v1 exposure the coding style issue. 
Anyway please add the change when update new version. Thanks.

Acked-by: Jeff Guo 

> -Original Message-
> From: Yu, DapengX 
> Sent: Friday, February 19, 2021 6:01 PM
> To: Guo, Jia ; Wang, Haiyue 
> Cc: dev@dpdk.org; Yu, DapengX ; sta...@dpdk.org
> Subject: [PATCH v2] net/igc: remove MTU setting limitation
> 
> From: Dapeng Yu 
> 
> Currently, if requested MTU is bigger than mbuf size and scattered receive is
> not enabled, setting MTU to that value fails.
> 
> This patch allows setting this special MTU when device is stopped, because
> scattered_rx will be re-configured during next port start and driver may
> enable scattered receive according new MTU value.
> 
> After this patch, driver may select different receive function automatically
> after MTU set, according MTU values selected.
> 
> Fixes: a5aeb2b9e225 ("net/igc: support Rx and Tx")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dapeng Yu 
> ---
>  drivers/net/igc/igc_ethdev.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/igc/igc_ethdev.c b/drivers/net/igc/igc_ethdev.c index
> dbaa7a83e..0ea6e2a04 100644
> --- a/drivers/net/igc/igc_ethdev.c
> +++ b/drivers/net/igc/igc_ethdev.c
> @@ -1590,12 +1590,14 @@ eth_igc_mtu_set(struct rte_eth_dev *dev,
> uint16_t mtu)
>   return -EINVAL;
> 
>   /*
> -  * refuse mtu that requires the support of scattered packets when
> -  * this feature has not been enabled before.
> +  * If device is started, refuse mtu that requires the support of
> +  * scattered packets when this feature has not been enabled before.
>*/
> - if (!dev->data->scattered_rx &&
> - frame_size > dev->data->min_rx_buf_size -
> RTE_PKTMBUF_HEADROOM)
> + if (dev->data->dev_started && !dev->data->scattered_rx &&
> + frame_size > dev->data->min_rx_buf_size -
> RTE_PKTMBUF_HEADROOM) {
> + PMD_INIT_LOG(ERR, "Stop port first.");
>   return -EINVAL;
> + }
> 
>   rctl = IGC_READ_REG(hw, IGC_RCTL);
> 
> --
> 2.27.0



Re: [dpdk-dev] [PATCH v3 1/7] eal: add wrappers for POSIX string functions

2021-02-23 Thread Andrew Rybchenko
On 2/24/21 12:53 AM, Nick Connolly wrote:
> 
>> Allocating memory using rte_strdup() I'd use rte_free()
>> to release it. I guess it will fail badly.
>> So, I think that a different, more specific prefix is
>> required for POSIX wrappers.
> 
> Andrew: my understanding of Bruce's proposal is that the strdup() name
> will now be kept (in this case through an inline definition), so I think
> this will be ok. 

Very good, glad to hear it. Thanks.

> However, your comment reminded me of something else
> that it's probably worth mentioning as an aside:
> 
> As a general guideline on Windows, memory allocated within a shared
> library is best freed within the same DLL to ensure it goes back to the
> correct heap.  So we'd want to avoid calling strdup and then returning
> the value to the application for it to free (hopefully this doesn't
> happen). With an inline definition there's no change in behaviour, but
> adding rte_strdup (or anything else that calls malloc) into librte_eal
> might be an issue.
> 
> Regards,
> Nick



Re: [dpdk-dev] [PATCH 1/2] config/arm: fix Hisilicon kunpeng920 SoC build

2021-02-23 Thread Thomas Monjalon
24/02/2021 02:34, oulijun:
> 
> 在 2021/2/10 17:41, Thomas Monjalon 写道:
> > 03/02/2021 13:46, Lijun Ou:
> >> From: Chengchang Tang 
> >>
> >> Because of the '9ca2f16' have merged, the current hns3
> >> pmd driver can not be directly complied on the kunpeng920
> >> server board. Therefore, we need to fix the meson build.
> >> Besides, add kunpeng 920 SoC meson cross compile target.
> >>
> >> Fixes: 9ca2f16faa7f ("config/arm: isolate generic build")
> > 
> > Why do you think this patch is fixing the one above?
> > It looks just a new config, not a fix. Am I missing something?
> > 
> I'm sorry to see you so late. In the meantime, we are celebrating the 
> Spring Festival. This patch fixes the problem. If the patch is not 
> added, the latest version cannot be directly compiled on the Kunpeng 930 
> server board.In addition, the cross compilation configuration file is added.

Please can you explain what was removed which breaks your compilation?