[dpdk-dev] [PATCH v2] net/ice: fix wrong RSS hash update

[Wenjun Wu]

This patch change redundant judgment statements to disable RSS
when users need to disable RSS or RSS hash function configured
is not supported.

Fixes: 4717a12cfaf1 ("net/ice: initialize and update RSS based on user config")
Cc: sta...@dpdk.org

Signed-off-by: Wenjun Wu 

---
v2: do pf->rss_hf = 0 when rss_conf->rss_hf == 0 instead of direct
removal to avoid unnecessary judgment.
---
 drivers/net/ice/ice_ethdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index f43b2e0b2..299162286 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -4461,8 +4461,10 @@ ice_rss_hash_update(struct rte_eth_dev *dev,
if (status)
return status;
 
-   if (rss_conf->rss_hf == 0)
+   if (rss_conf->rss_hf == 0) {
+   pf->rss_hf = 0;
return 0;
+   }
 
/* RSS hash configuration */
ice_rss_hash_set(pf, rss_conf->rss_hf);
-- 
2.25.1

Re: [dpdk-dev] [PATCH] fbarray: fix uninitialized variable usage

[David Marchand]

On Fri, Feb 19, 2021 at 6:55 PM Anatoly Burakov
 wrote:
>
> When file truncation fails, the log message attempts to print a path of
> file we failed to truncate, but this path was never set to anything and,
> what's worse, was uninitialized. Fix it by passing path from the caller.
>
> Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
> Cc: sta...@dpdk.org
> Coverity ID: 366122
>
> Signed-off-by: Anatoly Burakov 

Andrew had reported it too, and proposed something close:
http://patchwork.dpdk.org/project/dpdk/patch/20201211170615.32827-1-abo...@pensando.io/

I prefer Anatoly's version.
If no one objects, I'll proceed with this one.


-- 
David Marchand

Re: [dpdk-dev] [PATCH] fbarray: fix uninitialized variable usage

[Andrew Rybchenko]

On 3/3/21 11:17 AM, David Marchand wrote:
> On Fri, Feb 19, 2021 at 6:55 PM Anatoly Burakov
>  wrote:
>>
>> When file truncation fails, the log message attempts to print a path of
>> file we failed to truncate, but this path was never set to anything and,
>> what's worse, was uninitialized. Fix it by passing path from the caller.
>>
>> Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
>> Cc: sta...@dpdk.org
>> Coverity ID: 366122
>>
>> Signed-off-by: Anatoly Burakov 
> 
> Andrew had reported it too, and proposed something close:
> http://patchwork.dpdk.org/project/dpdk/patch/20201211170615.32827-1-abo...@pensando.io/

Not me, adding Andrew B. to recipients list

> I prefer Anatoly's version.
> If no one objects, I'll proceed with this one.

Re: [dpdk-dev] [PATCH] fbarray: fix uninitialized variable usage

[David Marchand]

On Wed, Mar 3, 2021 at 9:31 AM Andrew Rybchenko
 wrote:
>
> On 3/3/21 11:17 AM, David Marchand wrote:
> > On Fri, Feb 19, 2021 at 6:55 PM Anatoly Burakov
> >  wrote:
> >>
> >> When file truncation fails, the log message attempts to print a path of
> >> file we failed to truncate, but this path was never set to anything and,
> >> what's worse, was uninitialized. Fix it by passing path from the caller.
> >>
> >> Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
> >> Cc: sta...@dpdk.org
> >> Coverity ID: 366122
> >>
> >> Signed-off-by: Anatoly Burakov 
> >
> > Andrew had reported it too, and proposed something close:
> > http://patchwork.dpdk.org/project/dpdk/patch/20201211170615.32827-1-abo...@pensando.io/
>
> Not me, adding Andrew B. to recipients list

That's gmail completion fault!
/me hides

Thanks Andrew R.


-- 
David Marchand

Re: [dpdk-dev] [PATCH] eal/ppc: add ppc specific TSC frequency value

[David Marchand]

On Wed, Feb 3, 2021 at 10:54 PM David Christensen
 wrote:
>
> Return a PPC specific value for get_tsc_freq_arch() rather than
> depending on the EAL framework to estimate the frequency.
>
> Signed-off-by: David Christensen 

Applied, thanks.


-- 
David Marchand

Re: [dpdk-dev] [PATCH] eal: fix return value comment

[David Marchand]

On Tue, Feb 9, 2021 at 2:52 PM Burakov, Anatoly
 wrote:
> On 06-Jun-20 10:17 AM, wangyunjian wrote:
> > From: Yunjian Wang 
> >
> > Fix few comments and add detailed comments for return value.
> >
> > Fixes: 279b581c897d ("vfio: expose functions")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Yunjian Wang 
>
> Acked-by: Anatoly Burakov 

Applied, thanks.

-- 
David Marchand

Re: [dpdk-dev] Potential bug in QAT PMD code

[Doherty, Declan]

H

On 23/02/2021 12:34 AM, Linfeng Li wrote:

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



Hey Linfeng, thanks we're looking into this now, and will address in 
this release cycle.


Thanks
Declan

Re: [dpdk-dev] [PATCH v2] ci: catch coredumps

[David Marchand]

On Mon, Jan 25, 2021 at 4:06 PM David Marchand
 wrote:
>
> Parts of the unit tests code rely on forked/secondary processes
> (expectedly) failing.
> A crash in those situations could be missed so add a check on coredumps
> presence after unit tests have run.
> When unit tests fail, it can also help checking for coredumps as it
> could give more insights on what happened.
>
> In some situations (like explicit call to rte_panic), coredump generation
> must be disabled to avoid false positives.
>

As suggested by Luca, marking for backport.
Cc: sta...@dpdk.org

> Signed-off-by: David Marchand 
Acked-by: Luca Boccassi 
Acked-by: Aaron Conole 


-- 
David Marchand

Re: [dpdk-dev] [PATCH v4] eal: detach memsegs on cleanup

[David Marchand]

On Mon, Sep 14, 2020 at 3:06 PM Anatoly Burakov
 wrote:
>
> Currently, we don't detach the shared memory on EAL cleanup, which
> leaves the page table descriptors still holding on to the file
> descriptors as well as memory space occupied by them. Fix it by adding
> another detach stage that closes the internal memory allocator resource
> references, detaches shared fbarrays and unmaps the shared mem config.
>
> Bugzilla ID: 380
> Bugzilla ID: 381
>
> Signed-off-by: Anatoly Burakov 
Acked-by: Stephen Hemminger 

Applied, thanks.


-- 
David Marchand

Re: [dpdk-dev] [PATCH v2 1/2] eal: error number enhancement for thread TLS API

[Tal Shnaiderman]

> Subject: Re: [PATCH v2 1/2] eal: error number enhancement for thread TLS
> API
> 
> External email: Use caution opening links or attachments
> 
> 
> 2021-03-02 17:26, Tal Shnaiderman:
> > add error number reporting to rte_errno in all functions in the
> > rte_thread_tls_* API.
> >
> > Suggested-by: Anatoly Burakov 
> > Signed-off-by: Tal Shnaiderman 
> > ---
> >  lib/librte_eal/include/rte_thread.h | 6 +++---
> >  lib/librte_eal/unix/rte_thread.c| 6 ++
> >  lib/librte_eal/windows/rte_thread.c | 8 +++-
> >  3 files changed, 16 insertions(+), 4 deletions(-)
> 
> Using OS error codes for rte_errno isn't the right thing to do: this way 
> callers
> cannot write a portable check of rte_thread_*() result. Consider returning
> some suitable stable values. OS-specific error info can be logged at debug
> level, as it is already is some places.

In Linux the error codes return are not OS specific (namely EAGAIN, ENOMEM and 
EINVAL).

The problem is that documentation on Windows doesn't publish which error code 
can be returned from GetLastError() for the TLS functions.

Or do we want to use the same errno for both OSs in case the functions fail 
regardless to the failure reason?

[dpdk-dev] [PATCH v4] event/sw: add xstats to expose progress details

[Harry van Haaren]

Today it is difficult to know if the SW Eventdev PMD is making
forward progress when it runs an iteration of its service. This
commit adds two xstats to give better visibility to the application.

The new xstats provide an application with which Eventdev ports
recieved work in the last iteration of scheduling, as well if
forward progress was made by the scheduler.

This patch implements an xstat for the SW PMD that exposes a
bitmask of ports that were scheduled to. In the unlikely case
that the SW PMD instance has 64 or more ports, return UINT64_MAX.

Signed-off-by: Harry van Haaren 

---

v3:
- Simplify all metrics to Event SW PMD

v2:
- Fixup printf() %ld to PRIu64

Note most of the changes here are unit-test changes to add
a statistic to the PMD. The actual "useful code" is a mere
handful of lines in a lot of noise.

---
 drivers/event/sw/sw_evdev.h   |  2 ++
 drivers/event/sw/sw_evdev_scheduler.c | 15 ++
 drivers/event/sw/sw_evdev_selftest.c  | 28 ++-
 drivers/event/sw/sw_evdev_xstats.c|  9 -
 4 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
index 5ab6465c83..33645bd1df 100644
--- a/drivers/event/sw/sw_evdev.h
+++ b/drivers/event/sw/sw_evdev.h
@@ -259,6 +259,8 @@ struct sw_evdev {
uint64_t sched_no_iq_enqueues;
uint64_t sched_no_cq_enqueues;
uint64_t sched_cq_qid_called;
+   uint64_t sched_last_iter_bitmask;
+   uint8_t sched_progress_last_iter;
 
uint8_t started;
uint32_t credit_update_quanta;
diff --git a/drivers/event/sw/sw_evdev_scheduler.c 
b/drivers/event/sw/sw_evdev_scheduler.c
index f747b3c6d4..d3a6bd5cda 100644
--- a/drivers/event/sw/sw_evdev_scheduler.c
+++ b/drivers/event/sw/sw_evdev_scheduler.c
@@ -559,6 +559,11 @@ sw_event_schedule(struct rte_eventdev *dev)
sw->sched_no_iq_enqueues += (in_pkts_total == 0);
sw->sched_no_cq_enqueues += (out_pkts_total == 0);
 
+   uint64_t work_done = (in_pkts_total + out_pkts_total) != 0;
+   sw->sched_progress_last_iter = work_done;
+
+   uint64_t cqs_scheds_last_iter = 0;
+
/* push all the internal buffered QEs in port->cq_ring to the
 * worker cores: aka, do the ring transfers batched.
 */
@@ -578,6 +583,7 @@ sw_event_schedule(struct rte_eventdev *dev)
&sw->cq_ring_space[i]);
port->cq_buf_count = 0;
no_enq = 0;
+   cqs_scheds_last_iter |= (1ULL << i);
} else {
sw->cq_ring_space[i] =
rte_event_ring_free_count(worker) -
@@ -597,4 +603,13 @@ sw_event_schedule(struct rte_eventdev *dev)
sw->sched_min_burst = sw->sched_min_burst_size;
}
 
+   /* Provide stats on what eventdev ports were scheduled to this
+* iteration. If more than 64 ports are active, always report that
+* all Eventdev ports have been scheduled events.
+*/
+   if (likely(sw->port_count < 64)) {
+   sw->sched_last_iter_bitmask = cqs_scheds_last_iter;
+   } else {
+   sw->sched_last_iter_bitmask = UINT64_MAX;
+   }
 }
diff --git a/drivers/event/sw/sw_evdev_selftest.c 
b/drivers/event/sw/sw_evdev_selftest.c
index e4bfb3a0f1..d53e903129 100644
--- a/drivers/event/sw/sw_evdev_selftest.c
+++ b/drivers/event/sw/sw_evdev_selftest.c
@@ -873,15 +873,15 @@ xstats_tests(struct test *t)
int ret = rte_event_dev_xstats_names_get(evdev,
RTE_EVENT_DEV_XSTATS_DEVICE,
0, xstats_names, ids, XSTATS_MAX);
-   if (ret != 6) {
-   printf("%d: expected 6 stats, got return %d\n", __LINE__, ret);
+   if (ret != 8) {
+   printf("%d: expected 8 stats, got return %d\n", __LINE__, ret);
return -1;
}
ret = rte_event_dev_xstats_get(evdev,
RTE_EVENT_DEV_XSTATS_DEVICE,
0, ids, values, ret);
-   if (ret != 6) {
-   printf("%d: expected 6 stats, got return %d\n", __LINE__, ret);
+   if (ret != 8) {
+   printf("%d: expected 8 stats, got return %d\n", __LINE__, ret);
return -1;
}
 
@@ -959,7 +959,7 @@ xstats_tests(struct test *t)
ret = rte_event_dev_xstats_get(evdev,
RTE_EVENT_DEV_XSTATS_DEVICE,
0, ids, values, num_stats);
-   static const uint64_t expected[] = {3, 3, 0, 1, 0, 0};
+   static const uint64_t expected[] = {3, 3, 0, 1, 0, 0, 4, 1};
for (i = 0; (signed int)i < ret; i++) {
if (expected[i] != values[i]) {
printf(
@@ -975,7 +975,7 @@ xstats_tests(struct test *t)
 

Re: [dpdk-dev] [PATCH v2 1/2] eal: error number enhancement for thread TLS API

[Dmitry Kozlyuk]

2021-03-03 10:37, Tal Shnaiderman:
> > Subject: Re: [PATCH v2 1/2] eal: error number enhancement for thread TLS
> > API
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > 2021-03-02 17:26, Tal Shnaiderman:  
> > > add error number reporting to rte_errno in all functions in the
> > > rte_thread_tls_* API.
> > >
> > > Suggested-by: Anatoly Burakov 
> > > Signed-off-by: Tal Shnaiderman 
> > > ---
> > >  lib/librte_eal/include/rte_thread.h | 6 +++---
> > >  lib/librte_eal/unix/rte_thread.c| 6 ++
> > >  lib/librte_eal/windows/rte_thread.c | 8 +++-
> > >  3 files changed, 16 insertions(+), 4 deletions(-)  
> > 
> > Using OS error codes for rte_errno isn't the right thing to do: this way 
> > callers
> > cannot write a portable check of rte_thread_*() result. Consider returning
> > some suitable stable values. OS-specific error info can be logged at debug
> > level, as it is already is some places.  
> 
> In Linux the error codes return are not OS specific (namely EAGAIN, ENOMEM 
> and EINVAL).
> 
> The problem is that documentation on Windows doesn't publish which error code 
> can be returned from GetLastError() for the TLS functions.
> 
> Or do we want to use the same errno for both OSs in case the functions fail 
> regardless to the failure reason?

Yes, so that callers know which codes to check against regardless of the OS.

Re: [dpdk-dev] [PATCH v3 3/5] examples/l3fwd: add FIB infrastructure

[Burakov, Anatoly]

On 19-Feb-21 3:09 PM, Conor Walsh wrote:

The purpose of this commit is to add the necessary function calls
and supporting infrastructure to allow the Forwarding Information Base
(FIB) library to be integrated into the l3fwd sample app.
The flag '-F' has been added to the applications options to allow
the user to specify that l3fwd uses FIB as its lookup method.

Signed-off-by: Conor Walsh 
---
  examples/l3fwd/Makefile  |  2 +-
  examples/l3fwd/l3fwd.h   | 27 ++--
  examples/l3fwd/l3fwd_event.c |  9 ++
  examples/l3fwd/l3fwd_event.h |  1 +
  examples/l3fwd/l3fwd_fib.c   | 60 
  examples/l3fwd/main.c| 43 +++---
  examples/l3fwd/meson.build   |  4 +--
  7 files changed, 129 insertions(+), 17 deletions(-)
  create mode 100644 examples/l3fwd/l3fwd_fib.c

diff --git a/examples/l3fwd/Makefile b/examples/l3fwd/Makefile
index 7e70bbd826..5f7baffbf7 100644
--- a/examples/l3fwd/Makefile
+++ b/examples/l3fwd/Makefile
@@ -5,7 +5,7 @@
  APP = l3fwd
  
  # all source are stored in SRCS-y

-SRCS-y := main.c l3fwd_lpm.c l3fwd_em.c l3fwd_event.c
+SRCS-y := main.c l3fwd_lpm.c l3fwd_fib.c l3fwd_em.c l3fwd_event.c
  SRCS-y += l3fwd_event_generic.c l3fwd_event_internal_port.c
  
  # Build using pkg-config variables if possible

diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 2cf06099e0..a808d60247 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -1,5 +1,5 @@
  /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2010-2016 Intel Corporation
+ * Copyright(c) 2010-2021 Intel Corporation
   */
  
  #ifndef __L3_FWD_H__

@@ -180,13 +180,16 @@ is_valid_ipv4_pkt(struct rte_ipv4_hdr *pkt, uint32_t 
link_len)
  int
  init_mem(uint16_t portid, unsigned int nb_mbuf);
  
-/* Function pointers for LPM or EM functionality. */

+/* Function pointers for LPM, EM or FIB functionality. */
  void
  setup_lpm(const int socketid);
  
  void

  setup_hash(const int socketid);
  
+void

+setup_fib(const int socketid);
+
  int
  em_check_ptype(int portid);
  
@@ -207,6 +210,9 @@ em_main_loop(__rte_unused void *dummy);

  int
  lpm_main_loop(__rte_unused void *dummy);
  
+int

+fib_main_loop(__rte_unused void *dummy);
+
  int
  lpm_event_main_loop_tx_d(__rte_unused void *dummy);
  int
@@ -225,8 +231,17 @@ em_event_main_loop_tx_q(__rte_unused void *dummy);
  int
  em_event_main_loop_tx_q_burst(__rte_unused void *dummy);
  
+int

+fib_event_main_loop_tx_d(__rte_unused void *dummy);
+int
+fib_event_main_loop_tx_d_burst(__rte_unused void *dummy);
+int
+fib_event_main_loop_tx_q(__rte_unused void *dummy);
+int
+fib_event_main_loop_tx_q_burst(__rte_unused void *dummy);
+
  
-/* Return ipv4/ipv6 fwd lookup struct for LPM or EM. */

+/* Return ipv4/ipv6 fwd lookup struct for LPM, EM or FIB. */
  void *
  em_get_ipv4_l3fwd_lookup_struct(const int socketid);
  
@@ -239,4 +254,10 @@ lpm_get_ipv4_l3fwd_lookup_struct(const int socketid);

  void *
  lpm_get_ipv6_l3fwd_lookup_struct(const int socketid);
  
+void *

+fib_get_ipv4_l3fwd_lookup_struct(const int socketid);
+
+void *
+fib_get_ipv6_l3fwd_lookup_struct(const int socketid);
+
  #endif  /* __L3_FWD_H__ */
diff --git a/examples/l3fwd/l3fwd_event.c b/examples/l3fwd/l3fwd_event.c
index 4d31593a0a..961860ea18 100644
--- a/examples/l3fwd/l3fwd_event.c
+++ b/examples/l3fwd/l3fwd_event.c
@@ -227,6 +227,12 @@ l3fwd_event_resource_setup(struct rte_eth_conf *port_conf)
[1][0] = em_event_main_loop_tx_q,
[1][1] = em_event_main_loop_tx_q_burst,
};
+   const event_loop_cb fib_event_loop[2][2] = {
+   [0][0] = fib_event_main_loop_tx_d,
+   [0][1] = fib_event_main_loop_tx_d_burst,
+   [1][0] = fib_event_main_loop_tx_q,
+   [1][1] = fib_event_main_loop_tx_q_burst,
+   };
uint32_t event_queue_cfg;
int ret;
  
@@ -264,4 +270,7 @@ l3fwd_event_resource_setup(struct rte_eth_conf *port_conf)
  
  	evt_rsrc->ops.em_event_loop = em_event_loop[evt_rsrc->tx_mode_q]

   [evt_rsrc->has_burst];
+
+   evt_rsrc->ops.fib_event_loop = fib_event_loop[evt_rsrc->tx_mode_q]
+  [evt_rsrc->has_burst];
  }
diff --git a/examples/l3fwd/l3fwd_event.h b/examples/l3fwd/l3fwd_event.h
index 0e46164170..3ad1902ab5 100644
--- a/examples/l3fwd/l3fwd_event.h
+++ b/examples/l3fwd/l3fwd_event.h
@@ -55,6 +55,7 @@ struct l3fwd_event_setup_ops {
adapter_setup_cb adapter_setup;
event_loop_cb lpm_event_loop;
event_loop_cb em_event_loop;
+   event_loop_cb fib_event_loop;
  };
  
  struct l3fwd_event_resources {

diff --git a/examples/l3fwd/l3fwd_fib.c b/examples/l3fwd/l3fwd_fib.c
new file mode 100644
index 00..0a2d02db2f
--- /dev/null
+++ b/examples/l3fwd/l3fwd_fib.c
@@ -0,0 +1,60 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include 
+#i

Re: [dpdk-dev] [PATCH v3 4/5] examples/l3fwd: implement FIB lookup method

[Burakov, Anatoly]

On 19-Feb-21 3:09 PM, Conor Walsh wrote:

This patch implements the Forwarding Information Base (FIB) library
in l3fwd using the function calls and infrastructure introduced in
the previous patch.

Signed-off-by: Conor Walsh 
---





+|| defined RTE_ARCH_PPC_64
+#define FIB_SEND_MULTI
+#endif
+
+static struct rte_fib *ipv4_l3fwd_fib_lookup_struct[NB_SOCKETS];
+static struct rte_fib6 *ipv6_l3fwd_fib_lookup_struct[NB_SOCKETS];
+
+/* Parse packet type and ip address. */
+static inline void
+fib_parse_packet(struct rte_mbuf *mbuf,
+  uint32_t *ipv4, uint32_t *ipv4_cnt,
+  uint8_t ipv6[RTE_FIB6_IPV6_ADDR_SIZE],
+  uint32_t *ipv6_cnt, uint8_t *ip_type)


Nitpicking, but here and in a bunch of other places, the indentation is 
quite odd :)





+
+/* Bulk parse, fib lookup and send. */
+static inline void
+fib_send_packets(int nb_rx, struct rte_mbuf **pkts_burst,
+   uint16_t portid, struct lcore_conf *qconf)
+{
+   uint32_t ipv4_arr[nb_rx];
+   uint8_t ipv6_arr[nb_rx][RTE_FIB6_IPV6_ADDR_SIZE];
+   uint16_t hops[nb_rx];
+   uint64_t hopsv4[nb_rx], hopsv6[nb_rx];
+   uint8_t type_arr[nb_rx];
+   uint32_t ipv4_cnt = 0, ipv6_cnt = 0;
+   uint32_t ipv4_reassem = 0, ipv6_reassem = 0;


I don't quite follow the naming here - this looks like it's 
"reassembling" something but i don't see any IP reassembly going on? 
Artifacts of copy-paste?



+   int32_t i;
+
+   /* Prefetch first packets. */
+   for (i = 0; i < FIB_PREFETCH_OFFSET && i < nb_rx; i++)
+   rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[i], void *));
+
+   /* Parse packet info and prefetch. */
+   for (i = 0; i < (nb_rx - FIB_PREFETCH_OFFSET); i++) {
+   /* Prefetch packet. */
+   rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[
+  i + FIB_PREFETCH_OFFSET],
+  void *));
+   fib_parse_packet(pkts_burst[i],
+  &ipv4_arr[ipv4_cnt], &ipv4_cnt,
+  ipv6_arr[ipv6_cnt], &ipv6_cnt,
+  &type_arr[i]);
+   }
+
+   /* Parse remaining packet info. */
+   for (; i < nb_rx; i++)
+   fib_parse_packet(pkts_burst[i],
+  &ipv4_arr[ipv4_cnt], &ipv4_cnt,
+  ipv6_arr[ipv6_cnt], &ipv6_cnt,
+  &type_arr[i]);
+
+   /* Lookup IPv4 hops if IPv4 packets are present. */
+   if (likely(ipv4_cnt > 0))
+   rte_fib_lookup_bulk(qconf->ipv4_lookup_struct,
+   ipv4_arr, hopsv4, ipv4_cnt);
+
+   /* Lookup IPv6 hops if IPv6 packets are present. */
+   if (ipv6_cnt > 0)
+   rte_fib6_lookup_bulk(qconf->ipv6_lookup_struct,
+ipv6_arr, hopsv6, ipv6_cnt);
+
+   /* Add IPv4 and IPv6 hops to one array depending on type. */
+   for (i = 0; i < nb_rx; i++) {
+   if (type_arr[i]) {
+   if (hopsv4[ipv4_reassem] != FIB_DEFAULT_HOP)
+   hops[i] = (uint16_t)hopsv4[ipv4_reassem];
+   else
+   hops[i] = portid;
+   ipv4_reassem++;


Nitpicking, but could be made slightly more concise and readable:

const uint16_t nh = (uint16_t)hopsv4[ipv4_reassem++];
hops[i] = nh != FIB_DEFAULT_HOP ? nh : portid;

Same for IPv6.

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH v2 1/2] eal: error number enhancement for thread TLS API

[Tal Shnaiderman]

> Subject: Re: [PATCH v2 1/2] eal: error number enhancement for thread TLS
> API
> 
> External email: Use caution opening links or attachments
> 
> 
> 2021-03-03 10:37, Tal Shnaiderman:
> > > Subject: Re: [PATCH v2 1/2] eal: error number enhancement for thread
> > > TLS API
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > 2021-03-02 17:26, Tal Shnaiderman:
> > > > add error number reporting to rte_errno in all functions in the
> > > > rte_thread_tls_* API.
> > > >
> > > > Suggested-by: Anatoly Burakov 
> > > > Signed-off-by: Tal Shnaiderman 
> > > > ---
> > > >  lib/librte_eal/include/rte_thread.h | 6 +++---
> > > >  lib/librte_eal/unix/rte_thread.c| 6 ++
> > > >  lib/librte_eal/windows/rte_thread.c | 8 +++-
> > > >  3 files changed, 16 insertions(+), 4 deletions(-)
> > >
> > > Using OS error codes for rte_errno isn't the right thing to do: this
> > > way callers cannot write a portable check of rte_thread_*() result.
> > > Consider returning some suitable stable values. OS-specific error
> > > info can be logged at debug level, as it is already is some places.
> >
> > In Linux the error codes return are not OS specific (namely EAGAIN,
> ENOMEM and EINVAL).
> >
> > The problem is that documentation on Windows doesn't publish which
> error code can be returned from GetLastError() for the TLS functions.
> >
> > Or do we want to use the same errno for both OSs in case the functions fail
> regardless to the failure reason?
> 
> Yes, so that callers know which codes to check against regardless of the OS.

This is different from Anatoly's original suggestion that values would be 
potentially different on different OS's.

Anatoly, is the approach suggested by Dmitry fine with you?

[dpdk-dev] [PATCH 1/2] doc: add power intrinsics to doxygen API index

[Anatoly Burakov]

Currently, the header `rte_power_intrinsics.h` is missing from the
doxygen API index. Add it.

Fixes: cda57d9388c0 ("eal: add power management intrinsics")
Cc: sta...@dpdk.org

Signed-off-by: Anatoly Burakov 
---
 doc/api/doxy-api-index.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 748514e243..41eefb7b2d 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -86,6 +86,7 @@ The public API headers are grouped by topics:
   [CPU flags]  (@ref rte_cpuflags.h),
   [CPU pause]  (@ref rte_pause.h),
   [I/O access] (@ref rte_io.h)
+  [power management]   (@ref rte_power_intrinsics.h)
 
 - **CPU multicore**:
   [interrupts] (@ref rte_interrupts.h),
-- 
2.25.1

[dpdk-dev] [PATCH 2/2] doc: add PMD power management to doxygen API index

[Anatoly Burakov]

Currently, the PMD power management API header is missing from the API
index generated by doxygen. Add it.

Fixes: 682a645438c5 ("power: add ethdev power management")

Signed-off-by: Anatoly Burakov 
---
 doc/api/doxy-api-index.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 41eefb7b2d..6886b6f47d 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -96,6 +96,7 @@ The public API headers are grouped by topics:
   [service cores]  (@ref rte_service.h),
   [keepalive]  (@ref rte_keepalive.h),
   [power/freq] (@ref rte_power.h)
+  [PMD power]  (@ref rte_power_pmd_mgmt.h)
 
 - **layers**:
   [ethernet]   (@ref rte_ether.h),
-- 
2.25.1

Re: [dpdk-dev] [PATCH V2 01/14] net/hns3: support module EEPROM dump

[Ferruh Yigit]

On 3/2/2021 1:58 PM, Lijun Ou wrote:

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(+)


Can you please add "Module EEPROM dump" feature to .ini file?



diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst
index ca28d05..67a0daa 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -64,6 +64,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.
+


The order in the release notes is documented in the section comment, and within 
the PMDs we are trying to keep in the vendor alphabetical order, can you please 
order accordingly.


With current release notes, "Hisilicon hns3" updates should go as first item in 
the section.

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

[Ferruh Yigit]

On 3/2/2021 1:58 PM, Lijun Ou wrote:

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.



dev_ops name is 'tx_done_cleanup' but I think better to have
more descriptive patch title, what do you think something like:
net/hns3: implement Tx mbuf free on demand

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

[Ferruh Yigit]

On 2/24/2021 1:28 AM, Lijun Ou wrote:

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 


After the previous 'before/after' confusion, what do you think to update the 
patch title as:

net/hns3: fix HW buffer size on MTU update

Re: [dpdk-dev] [PATCH V2 07/14] net/hns3: fix device capabilities for copper media type

[Ferruh Yigit]

On 3/2/2021 1:58 PM, Lijun Ou wrote:

From: Huisong Li 

The configuration operation for PHY is implemented by firmware. And
a capability flag will be report to driver, which means the firmware
supports the PHY driver.  However, the current implementation only
supports obtaining the capability bit, but some basic functions of
copper ports in driver, such as, the query of link status and link
info, are not supported.

Therefore, it is necessary for driver to set the copper capability
bit to zero when the firmware supports the configuration of the PHY.

Fixes: 438752358158 ("net/hns3: get device capability from firmware")
Fixes: 95e50325864c ("net/hns3: support copper media type")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
  drivers/net/hns3/hns3_cmd.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 32cd56b..ec34615 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -423,8 +423,14 @@ static void hns3_parse_capability(struct hns3_hw *hw,
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_PTP_B, 1);
if (hns3_get_bit(caps, HNS3_CAPS_TX_PUSH_B))
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_TX_PUSH_B, 1);
+   /*
+* Currently, the query of link status and link info on copper ports
+* are not supported. So it is necessary for driver to set the copper
+* capability bit to zero when the firmware supports the configuration
+* of the PHY.
+*/
if (hns3_get_bit(caps, HNS3_CAPS_PHY_IMP_B))
-   hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 1);
+   hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 0);
if (hns3_get_bit(caps, HNS3_CAPS_TQP_TXRX_INDEP_B))
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_INDEP_TXRX_B, 1);
if (hns3_get_bit(caps, HNS3_CAPS_STASH_B))



Hi Lijun,

I see this patch is to be accurate, but in next patch the link status is 
implemented and this patch practically reverted back completely, so I guess this 
patch can be dropped, what do you think?

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

[Ferruh Yigit]

On 3/2/2021 1:58 PM, Lijun Ou wrote:

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


copy/paste from previous version:

Why statistics enabled only with macro?
It is not common to use macro to enable the stats, what do you think to remove 
it, to be consistent with rest of the PMDs?

Re: [dpdk-dev] [PATCH V2 01/14] net/hns3: support module EEPROM dump

[oulijun]

在 2021/3/3 21:26, Ferruh Yigit 写道:

On 3/2/2021 1:58 PM, Lijun Ou wrote:

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(+)


Can you please add "Module EEPROM dump" feature to .ini file?


thanks. I will fix it


diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst

index ca28d05..67a0daa 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -64,6 +64,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.
+


The order in the release notes is documented in the section comment, and 
within the PMDs we are trying to keep in the vendor alphabetical order, 
can you please order accordingly.


With current release notes, "Hisilicon hns3" updates should go as first 
item in the section.

.

OK, thanks.

Re: [dpdk-dev] [PATCH V2 07/14] net/hns3: fix device capabilities for copper media type

[oulijun]

在 2021/3/3 21:27, Ferruh Yigit 写道:

On 3/2/2021 1:58 PM, Lijun Ou wrote:

From: Huisong Li 

The configuration operation for PHY is implemented by firmware. And
a capability flag will be report to driver, which means the firmware
supports the PHY driver.  However, the current implementation only
supports obtaining the capability bit, but some basic functions of
copper ports in driver, such as, the query of link status and link
info, are not supported.

Therefore, it is necessary for driver to set the copper capability
bit to zero when the firmware supports the configuration of the PHY.

Fixes: 438752358158 ("net/hns3: get device capability from firmware")
Fixes: 95e50325864c ("net/hns3: support copper media type")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
  drivers/net/hns3/hns3_cmd.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 32cd56b..ec34615 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -423,8 +423,14 @@ static void hns3_parse_capability(struct hns3_hw 
*hw,

  hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_PTP_B, 1);
  if (hns3_get_bit(caps, HNS3_CAPS_TX_PUSH_B))
  hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_TX_PUSH_B, 1);
+/*
+ * Currently, the query of link status and link info on copper ports
+ * are not supported. So it is necessary for driver to set the 
copper
+ * capability bit to zero when the firmware supports the 
configuration

+ * of the PHY.
+ */
  if (hns3_get_bit(caps, HNS3_CAPS_PHY_IMP_B))
-hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 1);
+hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 0);
  if (hns3_get_bit(caps, HNS3_CAPS_TQP_TXRX_INDEP_B))
  hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_INDEP_TXRX_B, 1);
  if (hns3_get_bit(caps, HNS3_CAPS_STASH_B))



Hi Lijun,

I see this patch is to be accurate, but in next patch the link status is 
implemented and this patch practically reverted back completely, so I 
guess this patch can be dropped, what do you think?
Yes, I am.  I split up on purpose. We find that if patch [8/14] is not 
integrated, the COPPER function should not be supported in 
hw->capability.That is, in 20.11 and 21.02, hw->capability should not 
support copper,this patch needs to be backported to 20.11 and 21.02.

For the above reasons, we'll split it up.

.

Re: [dpdk-dev] [PATCH V2 07/14] net/hns3: fix device capabilities for copper media type

[Ferruh Yigit]

On 3/3/2021 1:51 PM, oulijun wrote:



在 2021/3/3 21:27, Ferruh Yigit 写道:

On 3/2/2021 1:58 PM, Lijun Ou wrote:

From: Huisong Li 

The configuration operation for PHY is implemented by firmware. And
a capability flag will be report to driver, which means the firmware
supports the PHY driver.  However, the current implementation only
supports obtaining the capability bit, but some basic functions of
copper ports in driver, such as, the query of link status and link
info, are not supported.

Therefore, it is necessary for driver to set the copper capability
bit to zero when the firmware supports the configuration of the PHY.

Fixes: 438752358158 ("net/hns3: get device capability from firmware")
Fixes: 95e50325864c ("net/hns3: support copper media type")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
  drivers/net/hns3/hns3_cmd.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 32cd56b..ec34615 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -423,8 +423,14 @@ static void hns3_parse_capability(struct hns3_hw *hw,
  hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_PTP_B, 1);
  if (hns3_get_bit(caps, HNS3_CAPS_TX_PUSH_B))
  hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_TX_PUSH_B, 1);
+    /*
+ * Currently, the query of link status and link info on copper ports
+ * are not supported. So it is necessary for driver to set the copper
+ * capability bit to zero when the firmware supports the configuration
+ * of the PHY.
+ */
  if (hns3_get_bit(caps, HNS3_CAPS_PHY_IMP_B))
-    hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 1);
+    hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 0);
  if (hns3_get_bit(caps, HNS3_CAPS_TQP_TXRX_INDEP_B))
  hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_INDEP_TXRX_B, 1);
  if (hns3_get_bit(caps, HNS3_CAPS_STASH_B))



Hi Lijun,

I see this patch is to be accurate, but in next patch the link status is 
implemented and this patch practically reverted back completely, so I guess 
this patch can be dropped, what do you think?
Yes, I am.  I split up on purpose. We find that if patch [8/14] is not 
integrated, the COPPER function should not be supported in hw->capability.That 
is, in 20.11 and 21.02, hw->capability should not support copper,this patch 
needs to be backported to 20.11 and 21.02.

For the above reasons, we'll split it up.


make sense from backporting point of view, OK to continue as it is.

Re: [dpdk-dev] [PATCH 1/4] common/mlx5/linux: add glue function to query WQ

[Slava Ovsiienko]

> -Original Message-
> From: Matan Azrad 
> Sent: Thursday, February 25, 2021 12:45
> To: dev@dpdk.org
> Cc: Slava Ovsiienko ; sta...@dpdk.org
> Subject: [PATCH 1/4] common/mlx5/linux: add glue function to query WQ
> 
> When Rx queue is created by VERBS API ibv_create_wq there is a dedicated
> rdma-core API to query an information about this WQ(Work Queue).
> 
> VERBS WQ querying is needed for PMD cases which combine VERBS objects
> with DevX objects.
> 
> Next feature to use this glue function is the HW queue counters.
> 
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Matan Azrad 
Acked-by: Viacheslav Ovsiienko 

Re: [dpdk-dev] [PATCH 2/4] common/mlx5: add DevX command to query WQ

[Slava Ovsiienko]

> -Original Message-
> From: Matan Azrad 
> Sent: Thursday, February 25, 2021 12:45
> To: dev@dpdk.org
> Cc: Slava Ovsiienko ; sta...@dpdk.org
> Subject: [PATCH 2/4] common/mlx5: add DevX command to query WQ
> 
> Add a DevX command to query Rx queues attributes created by VERBS.
> 
> Currently support only counter_set_id attribute.
> 
> This counter ID is managed by the kernel driver and being assigned to any
> queue created by the kernel.
> 
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Matan Azrad 
Acked-by: Viacheslav Ovsiienko 

Re: [dpdk-dev] [PATCH 3/4] common/mlx5: add DevX commands for queue counters

[Slava Ovsiienko]

> -Original Message-
> From: Matan Azrad 
> Sent: Thursday, February 25, 2021 12:45
> To: dev@dpdk.org
> Cc: Slava Ovsiienko ; sta...@dpdk.org
> Subject: [PATCH 3/4] common/mlx5: add DevX commands for queue counters
> 
> A queue counter set is an HW object that can be assigned to any RQ\QP and it
> counts HW events on the assigned QPs\RQs.
> 
> Add DevX API to allocate and query queue counter set object.
> 
> The only used counter event is the "out of buffer" where the queue drops
> packets when no SW buffer is available to receive it.
> 
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Matan Azrad 
Acked-by: Viacheslav Ovsiienko 

Re: [dpdk-dev] [PATCH 4/4] net/mlx5: fix imissed statistics

[Slava Ovsiienko]

> -Original Message-
> From: Matan Azrad 
> Sent: Thursday, February 25, 2021 12:45
> To: dev@dpdk.org
> Cc: Slava Ovsiienko ; sta...@dpdk.org
> Subject: [PATCH 4/4] net/mlx5: fix imissed statistics
> 
> The imissed port statistic counts packets that were dropped by the device Rx
> queues.
> 
> In mlx5, the imissed counter summarizes 2 counters:
>   - packets dropped by the SW queue handling counted by SW.
>   - packets dropped by the HW queues due to "out of buffer" events
> detected when no SW buffer is available for the incoming
> packets.
> 
> There is HW counter object that should be created per device, and all the Rx
> queues should be assigned to this counter in configuration time.
> 
> This part was missed when the Rx queues were created by DevX what
> remained the "out of buffer" counter clean forever in this case.
> 
> Add 2 options to assign the DevX Rx queues to queue counter:
>   - Create queue counter per device by DevX and assign all the
> queues to it.
>   - Query the kernel counter and assign all the queues to it.
> 
> Use the first option by default and if it is failed, fallback to the second 
> option.
> 
> Fixes: e79c9be91515 ("net/mlx5: support Rx hairpin queues")
> Fixes: dc9ceff73c99 ("net/mlx5: create advanced RxQ via DevX")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Matan Azrad 
Acked-by: Viacheslav Ovsiienko 

Re: [dpdk-dev] [PATCH v8 2/3] ethdev: tunnel offload model

[Ivan Malov]

Hi,

Could someone please also clarify the meaning (from PMD standpoint and 
from application's standpoint) of the 64-bit field "tun_id" in 
"rte_flow_tunnel"? The current comment reads: "Tunnel identification", 
which is quite ambiguous, not to mention the fact that it simply expands 
the field's name. Does this ID have anything to do with VXLAN's VNI 
(which is 24-bit field)?


As far as I can learn from the testpmd patch series, this field gets 
printed only if it's non-zero. Hmm. A special value of sorts? Maybe 
clarify this, too?


Thank you.

On 02/03/2021 12:42, Thomas Monjalon wrote:

02/03/2021 10:22, Ivan Malov:

Hi Gregory, Eli,

On 16/10/2020 15:51, Gregory Etelson wrote:
  > Applications wishing to offload tunneled traffic are required to use
  > the rte_flow primitives, such as group, meta, mark, tag, and others to
  > model their high-level objects.  The hardware model design for

As far as I understand, the model is an abstraction of sorts, and the
quoted lines provide examples of primitives which applications would
have to use if the model did not exist.

Looking at the implementation, I don't quite discern any means to let
the application query PMD-specific values of "rte_flow_attr". In
example, the PMD may need to enforce "transfer=1" both for the "tunnel
set" rule and for "tunnel match" one. What if "group" and "priority"
values also need to be implicitly controlled by the PMD for the tunnel
offload rules?

Have you considered adding an abstraction for "rte_flow_attr" in terms
of this model?

  > The first VXLAN packet that arrives matches the rule in group 0 and
  > jumps to group 3.  In group 3 the packet will miss since there is no

This example considers jumping from group 0 to group 3. First of all,
it's unclear whether this model intentionally lets the application
choose group values freely (see my question above) or simply lacks an
interface to let the application use values enforced by the PMD (if
any). Secondly, given the fact that existing description of
"rte_flow_attr" does not shed any light on how groups are ordered by
default, when no JUMPs are configured (it only explains how priority
levels are ordered within the given group but not how groups are
ordered), it's unclear whether the model intentionally permits the
application to jump between arbitrary groups (in example, from 0 to 3)
and not necessarily between, say, 0 to 1. More to that, it's unclear
whether the model lets the application jump from, say, group 0 to the
very same group, 0 ("recirculation") or not. Or is the "recirculation"
is in fact the main scenario in the model? Could you please elaborate on
the model's expectations of groups?

Thank you.


Given the questions, I think the discussion should be concluded
(when done) with a patch updating the API description.
Thanks for the questions and clarifications to come :)





--
Ivan M

Re: [dpdk-dev] [Linuxarm] Re: [PATCH V2 04/14] net/hns3: add Rx and Tx bytes stats

[oulijun]

在 2021/3/3 21:28, Ferruh Yigit 写道:

On 3/2/2021 1:58 PM, Lijun Ou wrote:

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


copy/paste from previous version:

Why statistics enabled only with macro?
It is not common to use macro to enable the stats, what do you think to 
remove it, to be consistent with rest of the PMDs?

I'm sorry. I thought it was a success.
 Firstly, the macro is used to control the statistics to ensure 
performance and facilitate flexible usage. For example, the macro needs 
to be disabled when high performance is required.
secondly the byte statistics of other vendors are implemented by reading 
and writing registers. Therefore, macros are not used.By the way, the 
MLX driver has a precedent (code snippets can be intercepted here).

___
Linuxarm mailing list -- linux...@openeuler.org
To unsubscribe send an email to linuxarm-le...@openeuler.org

Re: [dpdk-dev] [Linuxarm] Re: [PATCH V2 04/14] net/hns3: add Rx and Tx bytes stats

[Ferruh Yigit]

On 3/3/2021 2:08 PM, oulijun wrote:



在 2021/3/3 21:28, Ferruh Yigit 写道:

On 3/2/2021 1:58 PM, Lijun Ou wrote:

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


copy/paste from previous version:

Why statistics enabled only with macro?
It is not common to use macro to enable the stats, what do you think to remove 
it, to be consistent with rest of the PMDs?

I'm sorry. I thought it was a success.
  Firstly, the macro is used to control the statistics to ensure performance and 
facilitate flexible usage. For example, the macro needs to be disabled when high 
performance is required.
secondly the byte statistics of other vendors are implemented by reading and 
writing registers. Therefore, macros are not used.By the way, the MLX driver has 
a precedent (code snippets can be intercepted here).


It is not convenient for a user re-compile the DPDK to be able to get the ethdev 
byte statistics, stats are not developer/debug information, end user may need 
them. And this recompilation may not be an option for the distributed software.


How much performance affect it has if you enable it always?

And just to double check, isn't there a way to get this information from HW 
without calculating it in the driver?


The compile time flags, specially after meson switch, hard to enable and a 
little hidden, it is very easy to have broken code there, that is why it better 
to prevent compile time flags as much as possible.

Re: [dpdk-dev] [PATCH] net/pcap: fix fd leak on uninit

[Ferruh Yigit]

On 3/2/2021 4:51 PM, Tengfei Zhang wrote:

pcap fd was opend when vdev probed,
but not closed when vdev removed.

Fixes: c956caa6eabf ("pcap: support port hotplug")
Cc: sta...@dpdk.org

Signed-off-by: Tengfei Zhang 


Acked-by: Ferruh Yigit 

Applied to dpdk-next-net/main, thanks.

Re: [dpdk-dev] [PATCH] fbarray: fix uninitialized variable usage

[Andrew Boyer]

> On Mar 3, 2021, at 3:17 AM, David Marchand  wrote:
> 
> On Fri, Feb 19, 2021 at 6:55 PM Anatoly Burakov
>  wrote:
>> 
>> When file truncation fails, the log message attempts to print a path of
>> file we failed to truncate, but this path was never set to anything and,
>> what's worse, was uninitialized. Fix it by passing path from the caller.
>> 
>> Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
>> Cc: sta...@dpdk.org
>> Coverity ID: 366122
>> 
>> Signed-off-by: Anatoly Burakov 
> 
> Andrew had reported it too, and proposed something close:
> http://patchwork.dpdk.org/project/dpdk/patch/20201211170615.32827-1-abo...@pensando.io/
> 
> I prefer Anatoly's version.
> If no one objects, I'll proceed with this one.
> 
> 
> -- 
> David Marchand
> 

Fine with me

Re: [dpdk-dev] [PATCH 1/3] net/af_xdp: Increase max batch size to 512

[Loftus, Ciara]

> 
> On 2/24/2021 11:18 AM, Ciara Loftus wrote:
> > Prior to this the max size was 32 which was unnecessarily
> > small.
> 
> Can you please describe the impact? Why changed from 32 to 512?
> I assume this is to improve the performance but can you please explicitly
> document it in the commit log?

Indeed - improved performance due to bulk operations and fewer ring accesses 
and syscalls.
The value 512 was arbitrary. I will change this to the default ring size as 
defined by libbpf (2048) in v2.
Will update the commit log with this info.

> 
> > Also enforce the max batch size for TX for both
> > copy and zero copy modes. Prior to this only copy mode
> > enforced the max size.
> >
> 
> By enforcing, the PMD ignores the user provided burst value if it is more than
> PMS supported MAX, and this ignoring is done in silent. Also there is no way
> to
> discover this MAX value without checking the code.
> 
> Overall, why this max values are required at all? After quick check I can see
> they are used for some bulk operations, which I assume can be eliminated,
> what
> do you think?

We need to size some arrays at compile time with this max value.

Instead of removing the bulk operations which may impact performance, how about 
taking an approach where we split batches that are > 2048 into smaller batches 
and still handle all the packets instead of discarding those > 2048. Something 
like what's done in ixgbe for example:
http://code.dpdk.org/dpdk/v21.02/source/drivers/net/ixgbe/ixgbe_rxtx.c#L318

Thanks,
Ciara

> 
> > Signed-off-by: Ciara Loftus 
> 
> <...>

Re: [dpdk-dev] [PATCH 1/3] net/af_xdp: Increase max batch size to 512

[Ferruh Yigit]

On 3/3/2021 3:07 PM, Loftus, Ciara wrote:


On 2/24/2021 11:18 AM, Ciara Loftus wrote:

Prior to this the max size was 32 which was unnecessarily
small.


Can you please describe the impact? Why changed from 32 to 512?
I assume this is to improve the performance but can you please explicitly
document it in the commit log?


Indeed - improved performance due to bulk operations and fewer ring accesses 
and syscalls.
The value 512 was arbitrary. I will change this to the default ring size as 
defined by libbpf (2048) in v2.
Will update the commit log with this info.




Also enforce the max batch size for TX for both
copy and zero copy modes. Prior to this only copy mode
enforced the max size.



By enforcing, the PMD ignores the user provided burst value if it is more than
PMS supported MAX, and this ignoring is done in silent. Also there is no way
to
discover this MAX value without checking the code.

Overall, why this max values are required at all? After quick check I can see
they are used for some bulk operations, which I assume can be eliminated,
what
do you think?


We need to size some arrays at compile time with this max value.

Instead of removing the bulk operations which may impact performance, how about 
taking an approach where we split batches that are > 2048 into smaller batches and 
still handle all the packets instead of discarding those > 2048. Something like 
what's done in ixgbe for example:
http://code.dpdk.org/dpdk/v21.02/source/drivers/net/ixgbe/ixgbe_rxtx.c#L318
` 


If there is no reasonable way to eliminate the fix sized arrays, above 
suggestion looks good.


Thanks,
ferruh

Re: [dpdk-dev] [PATCH 0/4] net/mlx5: fix imissed statistic

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: dev  On Behalf Of Matan Azrad
> Sent: Thursday, February 25, 2021 12:45 PM
> To: dev@dpdk.org
> Cc: Slava Ovsiienko 
> Subject: [dpdk-dev] [PATCH 0/4] net/mlx5: fix imissed statistic
> 
> The imissed port statistic counts packets that were dropped
> by the device Rx queues.
> 
> In mlx5, the imissed counter summarizes 2 counters:
>   - packets dropped by the SW queue handling counted by SW.
>   - packets dropped by the HW queues due to "out of buffer" events
> detected when no SW buffer is available for the incoming
> packets.
> 
> There is HW counter object that should be created per device, and all
> the Rx queues should be assigned to this counter in configuration time.
> 
> This part was missed when the Rx queues were created by DevX what
> remained the "out of buffer" counter clean forever in this case.
> 
> Add 2 options to assign the DevX Rx queues to queue counter:
>   - Create queue counter per device by DevX and assign all the
> queues to it.
>   - Query the kernel counter and assign all the queues to it.
> 
> Use the first option by default and if it is failed, fallback to the
> second option.
> 
> Matan Azrad (4):
>   common/mlx5/linux: add glue function to query WQ
>   common/mlx5: add DevX command to query WQ
>   common/mlx5: add DevX commands for queue counters
>   net/mlx5: fix imissed statistics
> 
> Series-acked-by: Viacheslav Ovsiienko 
> 
> 
>  drivers/common/mlx5/linux/mlx5_glue.c |  18 ++
>  drivers/common/mlx5/linux/mlx5_glue.h |   2 +
>  drivers/common/mlx5/mlx5_devx_cmds.c  | 100
> ++
>  drivers/common/mlx5/mlx5_devx_cmds.h  |   9 +++
>  drivers/common/mlx5/mlx5_prm.h| 100
> ++
>  drivers/common/mlx5/version.map   |   5 +-
>  drivers/net/mlx5/linux/mlx5_os.c  |  52 ++
>  drivers/net/mlx5/mlx5.c   |   4 ++
>  drivers/net/mlx5/mlx5.h   |   2 +
>  drivers/net/mlx5/mlx5_devx.c  |   2 +
>  10 files changed, 293 insertions(+), 1 deletion(-)
> 
> --
> 1.8.3.1

Series applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

Re: [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers

[Dmitry Kozlyuk]

2021-03-02 11:22, Nick Connolly:
> > Is posix_memalign() used more extensively in SPDK? In DPDK, it's 2 PMDs:  
> Yes, there are about 80 references. A lot are in ISA-L where they are 
> #defined to _aligned_malloc and can be ignored, but there still several 
> in the rest of the code.

I think portable code should try sticking to C11 aligned_malloc().
BTW, _aligned_malloc (with "_") only supports power-of-2 alignment.

There's a related passage in MSVC blog:

Due to the nature of the Windows heap, aligned_alloc support is
missing. The alternative is to use _aligned_malloc.

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/

> >>* Sockets are unfortunately specified as using close(). This is
> >>  probably easy to address by rte_ wrapping all socket calls.  
> > Which public DPDK APIs operate on sockets?
> > I don't like the idea of wrapping APIs like sockets or files.  
> I'm not sure about use in public APIs - I'd hope none do. I was thinking 
> about 'internal' use.

This is important (even more so for SPDK, I suspect), however, I'd like to
focus on public API first.

> > I drafted what I was talking about: adding address types and removing shims:
> >
> > * librte_net/rte_ip.h then includes  or 
> >conditionally for AF_xxx, IPPROTO_xxx, and a few other constants.
> >That's probably OK, there are similar places for Linux/FreeBSD 
> > differences,
> >e.g. in .
> >
> > * Some IPPROTO_xxx constants are missing on Windows, so rte_ip.h has to
> >provide them. I hope Mirosoft will add them to system headers one day.
> >
> > * It affects cmdline (mostly), ethdev, security, crypto/dpaax.  
> Sounds good - well done!

...or not :)

If we can't help including / from public headers,
might as well use `struct in_addr`, just replace `#include `
with `#include ` everywhere.

The only remaining issue will be `s_addr` macro on Windows that conflicts with
`struct rte_ether_addr` field `s_addr`. I don't know a better solution than
renaming `s_addr` to `src_addr` in DPDK (OTOH, it will be consistent with
`struct rte_ipvX_hdr` field naming).

Ferruh, what do you think?

Re: [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers

[Ferruh Yigit]

On 3/3/2021 4:32 PM, Dmitry Kozlyuk wrote:

2021-03-02 11:22, Nick Connolly:

Is posix_memalign() used more extensively in SPDK? In DPDK, it's 2 PMDs:

Yes, there are about 80 references. A lot are in ISA-L where they are
#defined to _aligned_malloc and can be ignored, but there still several
in the rest of the code.


I think portable code should try sticking to C11 aligned_malloc().
BTW, _aligned_malloc (with "_") only supports power-of-2 alignment.

There's a related passage in MSVC blog:

Due to the nature of the Windows heap, aligned_alloc support is
missing. The alternative is to use _aligned_malloc.

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/


* Sockets are unfortunately specified as using close(). This is
  probably easy to address by rte_ wrapping all socket calls.

Which public DPDK APIs operate on sockets?
I don't like the idea of wrapping APIs like sockets or files.

I'm not sure about use in public APIs - I'd hope none do. I was thinking
about 'internal' use.


This is important (even more so for SPDK, I suspect), however, I'd like to
focus on public API first.


I drafted what I was talking about: adding address types and removing shims:

* librte_net/rte_ip.h then includes  or 
conditionally for AF_xxx, IPPROTO_xxx, and a few other constants.
That's probably OK, there are similar places for Linux/FreeBSD differences,
e.g. in .

* Some IPPROTO_xxx constants are missing on Windows, so rte_ip.h has to
provide them. I hope Mirosoft will add them to system headers one day.

* It affects cmdline (mostly), ethdev, security, crypto/dpaax.

Sounds good - well done!


...or not :)

If we can't help including / from public headers,
might as well use `struct in_addr`, just replace `#include `
with `#include ` everywhere.

The only remaining issue will be `s_addr` macro on Windows that conflicts with
`struct rte_ether_addr` field `s_addr`. I don't know a better solution than
renaming `s_addr` to `src_addr` in DPDK (OTOH, it will be consistent with
`struct rte_ipvX_hdr` field naming).

Ferruh, what do you think?



No problem on the chosen name, that will work fine, but the 'struct 
rte_eth_addr' is public struct, we can't rename it without breaking the user 
applications.


Still it is possible to rename public struct, but it is a long process, need to 
send a deprecation notice and wait for next LTS, 21.11.


Ethernet header already has following, doesn't it help:
#undef s_addr /* Defined in winsock2.h included in windows.h. */

[dpdk-dev] [PATCH v9 0/2] support both PIO and MMIO BAR for legacy device in virtio PMD

[谢华伟(此时此刻）]

virtio PMD assumes legacy device only supports PIO BAR resource. This is wrong.
As we need to create lots of devices, as PIO resource on x86 is very limited, 
we expose MMIO(memory IO) BAR.

Kernel supports both PIO and MMIO BAR for legacy virtio-pci device, and for all
other pci devices. This patchset handles different type of BAR in the similar 
way.

In previous implementation, under igb_uio driver we get PIO address from igb_uio
sysfs entry; with uio_pci_generic, we get PIO address from /proc/ioports for 
x86,
and for other ARCHs, we get PIO address from standard PCI sysfs entry.
For PIO/MMIO RW, there is different path for different drivers and arch.


All of the above is too much twisted.
This patchset unifies the way to get both PIO and MMIO address for different 
driver
and ARCHs, all from standard resource attr under pci sysfs. This is most 
generic.

We distinguish PIO and MMIO by their address like how kernel does. It is ugly 
but works.

v2 changes:
- add more explanation in the commit message

v3 changes:
- fix patch format issues

v4 changes:
- fixes for RTE_KDRV_UIO_GENERIC -> RTE_PCI_KDRV_UIO_GENERIC

v5 changes:
- split into three seperate patches

v6 changes:
- change to DEBUG level for IO bar detection in pci_uio_ioport_map
- rework the code in iobar branch
- fixes commit message format issue
- temporarily remove the 3rd patch for vfio path, leave it for future 
discusssion
- rework against virtio_pmd_rework_v2

v7 changes:
- fix compilation issues of in/out instruction on non X86 archs

v8 changes:
- change the word fix to refactor in patch 1's commit message

v9 changes:
- keep pause version in in/out instructions

huawei.xhw (2):
  bus/pci: use PCI standard sysfs entry to get PIO address
  bus/pci: support MMIO in PCI ioport accessors

 drivers/bus/pci/linux/pci.c |  81 
 drivers/bus/pci/linux/pci_uio.c | 202 +---
 2 files changed, 150 insertions(+), 133 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [PATCH v9 1/2] bus/pci: use PCI standard sysfs entry to get PIO address

[谢华伟(此时此刻）]

From: "huawei.xhw" 

Currently virtio PMD asssumes legacy device uses PIO bar.
There are three ways to get PIO(PortIO) address for virtio legacy device.
under igb_uio, get pio address from uio/uio# sysfs attribute
under uio_pci_generic:
for X86, get PIO address from /proc/ioport
for other ARCH, get PIO address from standard PCI sysfs attribute

Actually, igb_uio sysfs attribute exports exactly the same thing as standard 
PCI sysfs, i.e,
pci_dev->resource[] in kernel source code

This patch refactors these messy things, and uses standard PCI sysfs attribute.

Signed-off-by: huawei xie 
Reviewed-by: Maxime Coquelin 
---
 drivers/bus/pci/linux/pci.c | 77 -
 drivers/bus/pci/linux/pci_uio.c | 64 --
 2 files changed, 46 insertions(+), 95 deletions(-)

diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 2e1808b..0f38abf 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -677,71 +677,6 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
}
 }
 
-#if defined(RTE_ARCH_X86)
-static int
-pci_ioport_map(struct rte_pci_device *dev, int bar __rte_unused,
-   struct rte_pci_ioport *p)
-{
-   uint16_t start, end;
-   FILE *fp;
-   char *line = NULL;
-   char pci_id[16];
-   int found = 0;
-   size_t linesz;
-
-   if (rte_eal_iopl_init() != 0) {
-   RTE_LOG(ERR, EAL, "%s(): insufficient ioport permissions for 
PCI device %s\n",
-   __func__, dev->name);
-   return -1;
-   }
-
-   snprintf(pci_id, sizeof(pci_id), PCI_PRI_FMT,
-dev->addr.domain, dev->addr.bus,
-dev->addr.devid, dev->addr.function);
-
-   fp = fopen("/proc/ioports", "r");
-   if (fp == NULL) {
-   RTE_LOG(ERR, EAL, "%s(): can't open ioports\n", __func__);
-   return -1;
-   }
-
-   while (getdelim(&line, &linesz, '\n', fp) > 0) {
-   char *ptr = line;
-   char *left;
-   int n;
-
-   n = strcspn(ptr, ":");
-   ptr[n] = 0;
-   left = &ptr[n + 1];
-
-   while (*left && isspace(*left))
-   left++;
-
-   if (!strncmp(left, pci_id, strlen(pci_id))) {
-   found = 1;
-
-   while (*ptr && isspace(*ptr))
-   ptr++;
-
-   sscanf(ptr, "%04hx-%04hx", &start, &end);
-
-   break;
-   }
-   }
-
-   free(line);
-   fclose(fp);
-
-   if (!found)
-   return -1;
-
-   p->base = start;
-   RTE_LOG(DEBUG, EAL, "PCI Port IO found start=0x%x\n", start);
-
-   return 0;
-}
-#endif
-
 int
 rte_pci_ioport_map(struct rte_pci_device *dev, int bar,
struct rte_pci_ioport *p)
@@ -756,14 +691,8 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
break;
 #endif
case RTE_PCI_KDRV_IGB_UIO:
-   ret = pci_uio_ioport_map(dev, bar, p);
-   break;
case RTE_PCI_KDRV_UIO_GENERIC:
-#if defined(RTE_ARCH_X86)
-   ret = pci_ioport_map(dev, bar, p);
-#else
ret = pci_uio_ioport_map(dev, bar, p);
-#endif
break;
default:
break;
@@ -830,14 +759,8 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
break;
 #endif
case RTE_PCI_KDRV_IGB_UIO:
-   ret = pci_uio_ioport_unmap(p);
-   break;
case RTE_PCI_KDRV_UIO_GENERIC:
-#if defined(RTE_ARCH_X86)
-   ret = 0;
-#else
ret = pci_uio_ioport_unmap(p);
-#endif
break;
default:
break;
diff --git a/drivers/bus/pci/linux/pci_uio.c b/drivers/bus/pci/linux/pci_uio.c
index f3305a2..01f2a40 100644
--- a/drivers/bus/pci/linux/pci_uio.c
+++ b/drivers/bus/pci/linux/pci_uio.c
@@ -373,10 +373,13 @@
 pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
   struct rte_pci_ioport *p)
 {
+   FILE *f = NULL;
char dirname[PATH_MAX];
char filename[PATH_MAX];
-   int uio_num;
-   unsigned long start;
+   char buf[BUFSIZ];
+   uint64_t phys_addr, end_addr, flags;
+   unsigned long base;
+   int i;
 
if (rte_eal_iopl_init() != 0) {
RTE_LOG(ERR, EAL, "%s(): insufficient ioport permissions for 
PCI device %s\n",
@@ -384,41 +387,66 @@
return -1;
}
 
-   uio_num = pci_get_uio_dev(dev, dirname, sizeof(dirname), 0);
-   if (uio_num < 0)
+   /* open and read addresses of the corresponding resource in sysfs */
+   snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT "/resource",
+   rte_pci_get_sysfs_path(), dev->addr.domain, dev->addr.bus,
+   dev->addr.devid, 

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

[谢华伟(此时此刻）]

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 
---
 drivers/bus/pci/linux/pci.c |   4 --
 drivers/bus/pci/linux/pci_uio.c | 156 +---
 2 files changed, 113 insertions(+), 47 deletions(-)

diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 0f38abf..0dc99e9 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -715,8 +715,6 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
break;
 #endif
case RTE_PCI_KDRV_IGB_UIO:
-   pci_uio_ioport_read(p, data, len, offset);
-   break;
case RTE_PCI_KDRV_UIO_GENERIC:
pci_uio_ioport_read(p, data, len, offset);
break;
@@ -736,8 +734,6 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
break;
 #endif
case RTE_PCI_KDRV_IGB_UIO:
-   pci_uio_ioport_write(p, data, len, offset);
-   break;
case RTE_PCI_KDRV_UIO_GENERIC:
pci_uio_ioport_write(p, data, len, offset);
break;
diff --git a/drivers/bus/pci/linux/pci_uio.c b/drivers/bus/pci/linux/pci_uio.c
index 01f2a40..0907051 100644
--- a/drivers/bus/pci/linux/pci_uio.c
+++ b/drivers/bus/pci/linux/pci_uio.c
@@ -368,6 +368,8 @@
return -1;
 }
 
+#define PIO_MAX 0x1
+
 #if defined(RTE_ARCH_X86)
 int
 pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
@@ -381,12 +383,6 @@
unsigned long base;
int i;
 
-   if (rte_eal_iopl_init() != 0) {
-   RTE_LOG(ERR, EAL, "%s(): insufficient ioport permissions for 
PCI device %s\n",
-   __func__, dev->name);
-   return -1;
-   }
-
/* open and read addresses of the corresponding resource in sysfs */
snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT "/resource",
rte_pci_get_sysfs_path(), dev->addr.domain, dev->addr.bus,
@@ -408,15 +404,27 @@
&end_addr, &flags) < 0)
goto error;
 
-   if (!(flags & IORESOURCE_IO)) {
-   RTE_LOG(ERR, EAL, "%s(): bar resource other than IO is not 
supported\n", __func__);
-   goto error;
-   }
-   base = (unsigned long)phys_addr;
-   RTE_LOG(INFO, EAL, "%s(): PIO BAR %08lx detected\n", __func__, base);
+   if (flags & IORESOURCE_IO) {
+   if (rte_eal_iopl_init()) {
+   RTE_LOG(ERR, EAL, "%s(): insufficient ioport 
permissions for PCI device %s\n",
+   __func__, dev->name);
+   goto error;
+   }
 
-   if (base > UINT16_MAX)
+   base = (unsigned long)phys_addr;
+   if (base > PIO_MAX) {
+   RTE_LOG(ERR, EAL, "%s(): %08lx too large PIO 
resource\n", __func__, base);
+   goto error;
+   }
+
+   RTE_LOG(DEBUG, EAL, "%s(): PIO BAR %08lx detected\n", __func__, 
base);
+   } else if (flags & IORESOURCE_MEM) {
+   base = (unsigned long)dev->mem_resource[bar].addr;
+   RTE_LOG(DEBUG, EAL, "%s(): MMIO BAR %08lx detected\n", 
__func__, base);
+   } else {
+   RTE_LOG(ERR, EAL, "%s(): unknown BAR type\n", __func__);
goto error;
+   }
 
/* FIXME only for primary process ? */
if (dev->intr_handle.type == RTE_INTR_HANDLE_UNKNOWN) {
@@ -517,6 +525,92 @@
 }
 #endif
 
+#if defined(RTE_ARCH_X86)
+static inline uint8_t ioread8(void *addr)
+{
+   uint8_t val;
+
+   val = (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint8_t *)addr :
+   inb_p((unsigned long)addr);
+
+   return val;
+}
+
+static inline uint16_t ioread16(void *addr)
+{
+   uint16_t val;
+
+   val = (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint16_t *)addr :
+   inw_p((unsigned long)addr);
+
+   return val;
+}
+
+static inline uint32_t ioread32(void *addr)
+{
+   uint32_t val;
+
+   val = (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint32_t *)addr :
+   inl_p((unsigned long)addr);
+
+   return val;
+}
+
+static inline void iowrite8(uint8_t val, void *addr)
+{
+   (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint8_t *)addr = val :
+   outb_p(val, (unsigned long)addr);
+}
+
+static inline void iowrite16(uint16_t val, void *addr)
+{
+   (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint16_t *)addr = val :
+   outw_p(val, (unsigned 

Re: [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers

[Dmitry Kozlyuk]

2021-03-03 16:47, Ferruh Yigit:
> On 3/3/2021 4:32 PM, Dmitry Kozlyuk wrote:
[...]
> > If we can't help including / from public headers,
> > might as well use `struct in_addr`, just replace `#include `
> > with `#include ` everywhere.
> > 
> > The only remaining issue will be `s_addr` macro on Windows that conflicts 
> > with
> > `struct rte_ether_addr` field `s_addr`. I don't know a better solution than
> > renaming `s_addr` to `src_addr` in DPDK (OTOH, it will be consistent with
> > `struct rte_ipvX_hdr` field naming).
> > 
> > Ferruh, what do you think?
> >   
> 
> No problem on the chosen name, that will work fine, but the 'struct 
> rte_eth_addr' is public struct, we can't rename it without breaking the user 
> applications.
> 
> Still it is possible to rename public struct, but it is a long process, need 
> to 
> send a deprecation notice and wait for next LTS, 21.11.
> 
> Ethernet header already has following, doesn't it help:
> #undef s_addr /* Defined in winsock2.h included in windows.h. */

It helps until you do the following:

#include/* #define s_addr S_un.S_addr */
#include   /* #undef s_addr */

struct in_addr a;
a.s_addr = 0; /* ERROR, `s_addr` has been defined to do that */

Or the following:

#include 
#include 

struct rte_ether_hdr eh;
eh.s_addr.addr_bytes[0] = 0;/* ERROR: `addr_s` is a macro */

If you swap include order in each case, it compiles, i.e . code is fragile.
Shims redefine `struct in_addr` and we're trying to get rid of them anyway.


Here's a solution that always works, however ugly it looks. It defines
`struct rte_ether_hdr` for Windows such that `s_addr` macro works for it if
defined. We can keep it until 21.11, then remove it and rename fields. In
return, we can remove networking shims and workarounds immediately.

`S_un.S_addr` part of `struct in_addr` is documented, and thus is unlikely to
ever change:


https://docs.microsoft.com/en-us/windows/win32/api/winsock2/ns-winsock2-in_addr


diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index 060b63fc9..67d340bb2 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -23,10 +23,6 @@ extern "C" {
 #include 
 #include 
 
-#ifdef RTE_EXEC_ENV_WINDOWS /* Workaround conflict with rte_ether_hdr. */
-#undef s_addr /* Defined in winsock2.h included in windows.h. */
-#endif
-
 #define RTE_ETHER_ADDR_LEN  6 /**< Length of Ethernet address. */
 #define RTE_ETHER_TYPE_LEN  2 /**< Length of Ethernet type field. */
 #define RTE_ETHER_CRC_LEN   4 /**< Length of Ethernet CRC. */
@@ -257,6 +253,8 @@ __rte_experimental
 int
 rte_ether_unformat_addr(const char *str, struct rte_ether_addr *eth_addr);
 
+#if !defined RTE_EXEC_ENV_WINDOWS || defined __DOXYGEN__
+
 /**
  * Ethernet header: Contains the destination address, source address
  * and frame type.
@@ -267,6 +265,28 @@ struct rte_ether_hdr {
uint16_t ether_type;  /**< Frame type. */
 } __rte_aligned(2);
 
+#else
+
+#pragma push_macro("s_addr")
+#ifdef s_addr
+#undef s_addr
+#endif
+
+struct rte_ether_hdr {
+   struct rte_ether_addr d_addr; /**< Destination address. */
+   RTE_STD_C11
+   union {
+   struct rte_ether_addr s_addr; /**< Source address. */
+   struct {
+   struct rte_ether_addr S_un;
+   } S_addr;
+   };
+   uint16_t ether_type; /**< Frame type. */
+} __rte_aligned(2);
+
+#pragma pop_macro("s_addr")
+#endif
+
 /**
  * Ethernet VLAN Header.
  * Contains the 16-bit VLAN Tag Control Identifier and the Ethernet type

Re: [dpdk-dev] [PATCH v9 0/2] support both PIO and MMIO BAR for legacy device in virtio PMD

[Stephen Hemminger]

On Thu, 04 Mar 2021 01:46:50 +0800
"谢华伟(此时此刻）"  wrote:

> virtio PMD assumes legacy device only supports PIO BAR resource. This is 
> wrong.
> As we need to create lots of devices, as PIO resource on x86 is very limited, 
> we expose MMIO(memory IO) BAR.
> 
> Kernel supports both PIO and MMIO BAR for legacy virtio-pci device, and for 
> all
> other pci devices. This patchset handles different type of BAR in the similar 
> way.
> 
> In previous implementation, under igb_uio driver we get PIO address from 
> igb_uio
> sysfs entry; with uio_pci_generic, we get PIO address from /proc/ioports for 
> x86,
> and for other ARCHs, we get PIO address from standard PCI sysfs entry.
> For PIO/MMIO RW, there is different path for different drivers and arch.

Just to add some background. At the time virtio for DPDK was developed,
the kernel only supported legacy mode, and it required I/O ports on x86.

One concern is that, you should make sure these patches still work on
the oldest releases of Linux kernel that DPDK supports. For upstream
kernel that should be 4.4 kernel (oldest currently maintained LTS).
The Linux system requirements doc file needs update!

For distributions, the oldest version would be probably be RHEL 7.

[dpdk-dev] [PATCH] doc: update minimum supported kernel

[Stephen Hemminger]

The DPDK project is only committed to supporting upstream kernel
versions that are still in support.
The 3.16 kernel has reached End Of Life (in June 2020).
The next LTS kernel is 4.19 and is supported until December 2024.

This does not change the existing policy that distribution kernels
that are older are still supported.

Signed-off-by: Stephen Hemminger 
---
 doc/guides/linux_gsg/sys_reqs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst 
b/doc/guides/linux_gsg/sys_reqs.rst
index d7ea8520e558..d08b9126e55f 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -123,7 +123,7 @@ System Software
 
 **Required:**
 
-*   Kernel version >= 3.16
+*   Kernel version >= 4.19
 
 The kernel version required is based on the oldest long term stable kernel 
available
 at kernel.org when the DPDK version is in development.
-- 
2.30.1

[dpdk-dev] [PATCH v2] pflock: implementation of phase-fair reader writer locks

[Stephen Hemminger]

This is a new type of reader-writer lock that provides better fairness
guarantees which makes it better for typical DPDK applications.
They lock internally uses two ticket pools, one for readers and one
for writers.

Phase fair reader writer locks ensure that neither reader or writer will be
starved. Neither reader or writer are preferred, they execute in
alternating phases. All operations of the same time (reader or writer)
that try to acquire the lock are handled in FIFO order.  Write
operations are exclusive, and multiple read operations can be run
together (until a write arrives).

A similar implementation is in Concurrency Kit package in FreeBSD.
For more information see:
   "Reader-Writer Synchronization for Shared-Memory Multiprocessor
Real-Time Systems",
http://www.cs.unc.edu/~anderson/papers/ecrts09b.pdf

Signed-off-by: Stephen Hemminger 
---
v2 - fix truncation of mask (reported by some compilers)
 and docbook formatting

 app/test/meson.build|   6 +
 app/test/test_pflock.c  | 542 
 lib/librte_eal/arm/include/meson.build  |   1 +
 lib/librte_eal/arm/include/rte_pflock.h |  18 +
 lib/librte_eal/include/generic/rte_pflock.h | 273 ++
 lib/librte_eal/ppc/include/meson.build  |   1 +
 lib/librte_eal/ppc/include/rte_pflock.h |  16 +
 lib/librte_eal/x86/include/meson.build  |   1 +
 lib/librte_eal/x86/include/rte_pflock.h |  18 +
 9 files changed, 876 insertions(+)
 create mode 100644 app/test/test_pflock.c
 create mode 100644 lib/librte_eal/arm/include/rte_pflock.h
 create mode 100644 lib/librte_eal/include/generic/rte_pflock.h
 create mode 100644 lib/librte_eal/ppc/include/rte_pflock.h
 create mode 100644 lib/librte_eal/x86/include/rte_pflock.h

diff --git a/app/test/meson.build b/app/test/meson.build
index 561e493a2944..134098de9ac2 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -90,6 +90,7 @@ test_sources = files('commands.c',
'test_mcslock.c',
'test_mp_secondary.c',
'test_per_lcore.c',
+   'test_pflock.c',
'test_pmd_perf.c',
'test_power.c',
'test_power_cpufreq.c',
@@ -228,6 +229,11 @@ fast_tests = [
 ['meter_autotest', true],
 ['multiprocess_autotest', false],
 ['per_lcore_autotest', true],
+['pflock_autotest', true],
+['pflock_test1_autotest', true],
+['pflock_rda_autotest', true],
+['pflock_rds_wrm_autotest', true],
+['pflock_rde_wro_autotest', true],
 ['prefetch_autotest', true],
 ['rcu_qsbr_autotest', true],
 ['red_autotest', true],
diff --git a/app/test/test_pflock.c b/app/test/test_pflock.c
new file mode 100644
index ..cd36c02cc710
--- /dev/null
+++ b/app/test/test_pflock.c
@@ -0,0 +1,542 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2014 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+/*
+ * phase fair lock test
+ * ===
+ * Provides UT for phase fair lock API.
+ * Main concern is on functional testing, but also provides some
+ * performance measurements.
+ * Obviously for proper testing need to be executed with more than one lcore.
+ */
+
+#define ITER_NUM   0x80
+
+#define TEST_SEC   5
+
+static rte_pflock_t sl;
+static rte_pflock_t sl_tab[RTE_MAX_LCORE];
+static uint32_t synchro;
+
+enum {
+   LC_TYPE_RDLOCK,
+   LC_TYPE_WRLOCK,
+};
+
+static struct {
+   rte_pflock_t lock;
+   uint64_t tick;
+   volatile union {
+   uint8_t u8[RTE_CACHE_LINE_SIZE];
+   uint64_t u64[RTE_CACHE_LINE_SIZE / sizeof(uint64_t)];
+   } data;
+} __rte_cache_aligned try_pflock_data;
+
+struct try_pflock_lcore {
+   int32_t rc;
+   int32_t type;
+   struct {
+   uint64_t tick;
+   uint64_t fail;
+   uint64_t success;
+   } stat;
+} __rte_cache_aligned;
+
+static struct try_pflock_lcore try_lcore_data[RTE_MAX_LCORE];
+
+static int
+test_pflock_per_core(__rte_unused void *arg)
+{
+   rte_pflock_write_lock(&sl);
+   printf("Global write lock taken on core %u\n", rte_lcore_id());
+   rte_pflock_write_unlock(&sl);
+
+   rte_pflock_write_lock(&sl_tab[rte_lcore_id()]);
+   printf("Hello from core %u !\n", rte_lcore_id());
+   rte_pflock_write_unlock(&sl_tab[rte_lcore_id()]);
+
+   rte_pflock_read_lock(&sl);
+   printf("Global read lock taken on core %u\n", rte_lcore_id());
+   rte_delay_ms(100);
+   printf("Release global read lock on core %u\n", rte_lcore_id());
+   rte_pflock_read_unlock(&sl);
+
+   return 0;
+}
+
+static rte_pflock_t lk = RTE_PFLOCK_INITIALIZER;
+static volatile uint64_t pflock_data;
+static uint64_t time_count[RTE_MAX_LCORE] = {0};
+
+#define MAX_LOOP 1
+#define TEST_PFLOCK_DEBUG 

[dpdk-dev] [PATCH v10 0/2] support both PIO and MMIO BAR for legacy virito device

[谢华伟(此时此刻）]

virtio PMD assumes legacy device only supports PIO(port-mapped) BAR resource.
This is wrong.  As we need to create lots of devices, as PIO resource on x86 is
very limited, we expose MMIO(memory-mapped I/O) BAR.

Kernel supports both PIO and MMIO BAR for legacy virtio-pci device, and for all
other pci devices. This patchset handles different type of BAR in the similar 
way.

In previous implementation, under igb_uio driver we get PIO address from igb_uio
sysfs entry; with uio_pci_generic, we get PIO address from /proc/ioports for 
x86,
and for other ARCHs, we get PIO address from standard PCI sysfs entry.
For PIO/MMIO RW, there is different path for different drivers and arch.

All of the above is too much twisted.
This patchset unifies the way to get both PIO and MMIO address for different 
driver
and ARCHs, all from standard resource attr under pci sysfs. This is most 
generic.

We distinguish PIO and MMIO by their address range like how kernel does.
It is ugly but works.

v2 changes:
- add more explanation in the commit message

v3 changes:
- fix patch format issues

v4 changes:
- fixes for RTE_KDRV_UIO_GENERIC -> RTE_PCI_KDRV_UIO_GENERIC

v5 changes:
- split into three seperate patches

v6 changes:
- change to DEBUG level for IO bar detection in pci_uio_ioport_map
- rework the code in iobar branch
- fixes commit message format issue
- temporarily remove the 3rd patch for vfio path, leave it for future 
discusssion
- rework against virtio_pmd_rework_v2

v7 changes:
- fix compilation issues of in/out instruction on non X86 archs

v8 changes:
- change the word fix to refactor in patch 1's commit message

v9 changes:
- keep pause version in in/out instructions

v10 changes:
- trival fixes in commit message, like > 75 chars

huawei.xhw (2):
  bus/pci: use PCI standard sysfs entry to get PIO address
  bus/pci: support MMIO in PCI ioport accessors

 drivers/bus/pci/linux/pci.c |  81 
 drivers/bus/pci/linux/pci_uio.c | 202 +---
 2 files changed, 150 insertions(+), 133 deletions(-)

-- 
1.8.3.1

[dpdk-dev] [PATCH v10 1/2] bus/pci: use PCI standard sysfs entry to get PIO address

[谢华伟(此时此刻）]

From: "huawei.xhw" 

Currently virtio PMD asssumes legacy device uses PIO bar.
There are three ways to get PIO(PortIO) address for virtio legacy device.
under igb_uio, get pio address from uio/uio# sysfs attribute
under uio_pci_generic:
for X86, get PIO address from /proc/ioport
for other ARCH, get PIO address from standard PCI sysfs attribute

Actually, igb_uio sysfs attribute exports exactly the same thing as standard
PCI sysfs, i.e, pci_dev->resource[] in kernel source code

This patch refactors these messy things, and uses standard PCI sysfs attribute.

Signed-off-by: huawei xie 
Reviewed-by: Maxime Coquelin 
---
 drivers/bus/pci/linux/pci.c | 77 -
 drivers/bus/pci/linux/pci_uio.c | 64 --
 2 files changed, 46 insertions(+), 95 deletions(-)

diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 2e1808b..0f38abf 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -677,71 +677,6 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
}
 }
 
-#if defined(RTE_ARCH_X86)
-static int
-pci_ioport_map(struct rte_pci_device *dev, int bar __rte_unused,
-   struct rte_pci_ioport *p)
-{
-   uint16_t start, end;
-   FILE *fp;
-   char *line = NULL;
-   char pci_id[16];
-   int found = 0;
-   size_t linesz;
-
-   if (rte_eal_iopl_init() != 0) {
-   RTE_LOG(ERR, EAL, "%s(): insufficient ioport permissions for 
PCI device %s\n",
-   __func__, dev->name);
-   return -1;
-   }
-
-   snprintf(pci_id, sizeof(pci_id), PCI_PRI_FMT,
-dev->addr.domain, dev->addr.bus,
-dev->addr.devid, dev->addr.function);
-
-   fp = fopen("/proc/ioports", "r");
-   if (fp == NULL) {
-   RTE_LOG(ERR, EAL, "%s(): can't open ioports\n", __func__);
-   return -1;
-   }
-
-   while (getdelim(&line, &linesz, '\n', fp) > 0) {
-   char *ptr = line;
-   char *left;
-   int n;
-
-   n = strcspn(ptr, ":");
-   ptr[n] = 0;
-   left = &ptr[n + 1];
-
-   while (*left && isspace(*left))
-   left++;
-
-   if (!strncmp(left, pci_id, strlen(pci_id))) {
-   found = 1;
-
-   while (*ptr && isspace(*ptr))
-   ptr++;
-
-   sscanf(ptr, "%04hx-%04hx", &start, &end);
-
-   break;
-   }
-   }
-
-   free(line);
-   fclose(fp);
-
-   if (!found)
-   return -1;
-
-   p->base = start;
-   RTE_LOG(DEBUG, EAL, "PCI Port IO found start=0x%x\n", start);
-
-   return 0;
-}
-#endif
-
 int
 rte_pci_ioport_map(struct rte_pci_device *dev, int bar,
struct rte_pci_ioport *p)
@@ -756,14 +691,8 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
break;
 #endif
case RTE_PCI_KDRV_IGB_UIO:
-   ret = pci_uio_ioport_map(dev, bar, p);
-   break;
case RTE_PCI_KDRV_UIO_GENERIC:
-#if defined(RTE_ARCH_X86)
-   ret = pci_ioport_map(dev, bar, p);
-#else
ret = pci_uio_ioport_map(dev, bar, p);
-#endif
break;
default:
break;
@@ -830,14 +759,8 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
break;
 #endif
case RTE_PCI_KDRV_IGB_UIO:
-   ret = pci_uio_ioport_unmap(p);
-   break;
case RTE_PCI_KDRV_UIO_GENERIC:
-#if defined(RTE_ARCH_X86)
-   ret = 0;
-#else
ret = pci_uio_ioport_unmap(p);
-#endif
break;
default:
break;
diff --git a/drivers/bus/pci/linux/pci_uio.c b/drivers/bus/pci/linux/pci_uio.c
index f3305a2..01f2a40 100644
--- a/drivers/bus/pci/linux/pci_uio.c
+++ b/drivers/bus/pci/linux/pci_uio.c
@@ -373,10 +373,13 @@
 pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
   struct rte_pci_ioport *p)
 {
+   FILE *f = NULL;
char dirname[PATH_MAX];
char filename[PATH_MAX];
-   int uio_num;
-   unsigned long start;
+   char buf[BUFSIZ];
+   uint64_t phys_addr, end_addr, flags;
+   unsigned long base;
+   int i;
 
if (rte_eal_iopl_init() != 0) {
RTE_LOG(ERR, EAL, "%s(): insufficient ioport permissions for 
PCI device %s\n",
@@ -384,41 +387,66 @@
return -1;
}
 
-   uio_num = pci_get_uio_dev(dev, dirname, sizeof(dirname), 0);
-   if (uio_num < 0)
+   /* open and read addresses of the corresponding resource in sysfs */
+   snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT "/resource",
+   rte_pci_get_sysfs_path(), dev->addr.domain, dev->addr.bus,
+   dev->addr.devid, dev->

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

[谢华伟(此时此刻）]

From: "huawei.xhw" 

With I/O BAR, we get PIO(port-mapped I/O) address.
With MMIO(memory-mapped I/O) BAR, we get mapped virtual address.
We distinguish PIO and MMIO by their address range
like how kernel does, i.e, address below 64K is PIO..
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 
---
 drivers/bus/pci/linux/pci.c |   4 --
 drivers/bus/pci/linux/pci_uio.c | 156 +---
 2 files changed, 113 insertions(+), 47 deletions(-)

diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 0f38abf..0dc99e9 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -715,8 +715,6 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
break;
 #endif
case RTE_PCI_KDRV_IGB_UIO:
-   pci_uio_ioport_read(p, data, len, offset);
-   break;
case RTE_PCI_KDRV_UIO_GENERIC:
pci_uio_ioport_read(p, data, len, offset);
break;
@@ -736,8 +734,6 @@ int rte_pci_write_config(const struct rte_pci_device 
*device,
break;
 #endif
case RTE_PCI_KDRV_IGB_UIO:
-   pci_uio_ioport_write(p, data, len, offset);
-   break;
case RTE_PCI_KDRV_UIO_GENERIC:
pci_uio_ioport_write(p, data, len, offset);
break;
diff --git a/drivers/bus/pci/linux/pci_uio.c b/drivers/bus/pci/linux/pci_uio.c
index 01f2a40..0907051 100644
--- a/drivers/bus/pci/linux/pci_uio.c
+++ b/drivers/bus/pci/linux/pci_uio.c
@@ -368,6 +368,8 @@
return -1;
 }
 
+#define PIO_MAX 0x1
+
 #if defined(RTE_ARCH_X86)
 int
 pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
@@ -381,12 +383,6 @@
unsigned long base;
int i;
 
-   if (rte_eal_iopl_init() != 0) {
-   RTE_LOG(ERR, EAL, "%s(): insufficient ioport permissions for 
PCI device %s\n",
-   __func__, dev->name);
-   return -1;
-   }
-
/* open and read addresses of the corresponding resource in sysfs */
snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT "/resource",
rte_pci_get_sysfs_path(), dev->addr.domain, dev->addr.bus,
@@ -408,15 +404,27 @@
&end_addr, &flags) < 0)
goto error;
 
-   if (!(flags & IORESOURCE_IO)) {
-   RTE_LOG(ERR, EAL, "%s(): bar resource other than IO is not 
supported\n", __func__);
-   goto error;
-   }
-   base = (unsigned long)phys_addr;
-   RTE_LOG(INFO, EAL, "%s(): PIO BAR %08lx detected\n", __func__, base);
+   if (flags & IORESOURCE_IO) {
+   if (rte_eal_iopl_init()) {
+   RTE_LOG(ERR, EAL, "%s(): insufficient ioport 
permissions for PCI device %s\n",
+   __func__, dev->name);
+   goto error;
+   }
 
-   if (base > UINT16_MAX)
+   base = (unsigned long)phys_addr;
+   if (base > PIO_MAX) {
+   RTE_LOG(ERR, EAL, "%s(): %08lx too large PIO 
resource\n", __func__, base);
+   goto error;
+   }
+
+   RTE_LOG(DEBUG, EAL, "%s(): PIO BAR %08lx detected\n", __func__, 
base);
+   } else if (flags & IORESOURCE_MEM) {
+   base = (unsigned long)dev->mem_resource[bar].addr;
+   RTE_LOG(DEBUG, EAL, "%s(): MMIO BAR %08lx detected\n", 
__func__, base);
+   } else {
+   RTE_LOG(ERR, EAL, "%s(): unknown BAR type\n", __func__);
goto error;
+   }
 
/* FIXME only for primary process ? */
if (dev->intr_handle.type == RTE_INTR_HANDLE_UNKNOWN) {
@@ -517,6 +525,92 @@
 }
 #endif
 
+#if defined(RTE_ARCH_X86)
+static inline uint8_t ioread8(void *addr)
+{
+   uint8_t val;
+
+   val = (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint8_t *)addr :
+   inb_p((unsigned long)addr);
+
+   return val;
+}
+
+static inline uint16_t ioread16(void *addr)
+{
+   uint16_t val;
+
+   val = (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint16_t *)addr :
+   inw_p((unsigned long)addr);
+
+   return val;
+}
+
+static inline uint32_t ioread32(void *addr)
+{
+   uint32_t val;
+
+   val = (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint32_t *)addr :
+   inl_p((unsigned long)addr);
+
+   return val;
+}
+
+static inline void iowrite8(uint8_t val, void *addr)
+{
+   (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint8_t *)addr = val :
+   outb_p(val, (unsigned long)addr);
+}
+
+static inline void iowrite16(uint16_t val, void *addr)
+{
+   (uint64_t)(uintptr_t)addr >= PIO_MAX ?
+   *(volatile uint16_t *)addr = val :
+   

[dpdk-dev] [PATCH v3] pflock: implementation of phase-fair reader writer locks

[Stephen Hemminger]

This is a new type of reader-writer lock that provides better fairness
guarantees which makes it better for typical DPDK applications.
They lock internally uses two ticket pools, one for readers and one
for writers.

Phase fair reader writer locks ensure that neither reader or writer will be
starved. Neither reader or writer are preferred, they execute in
alternating phases. All operations of the same time (reader or writer)
that try to acquire the lock are handled in FIFO order.  Write
operations are exclusive, and multiple read operations can be run
together (until a write arrives).

A similar implementation is in Concurrency Kit package in FreeBSD.
For more information see:
   "Reader-Writer Synchronization for Shared-Memory Multiprocessor
Real-Time Systems",
http://www.cs.unc.edu/~anderson/papers/ecrts09b.pdf

Signed-off-by: Stephen Hemminger 
---
v3 - fix some spelling errors inherited in app/test/test_pflock

 app/test/meson.build|   6 +
 app/test/test_pflock.c  | 542 
 lib/librte_eal/arm/include/meson.build  |   1 +
 lib/librte_eal/arm/include/rte_pflock.h |  18 +
 lib/librte_eal/include/generic/rte_pflock.h | 273 ++
 lib/librte_eal/ppc/include/meson.build  |   1 +
 lib/librte_eal/ppc/include/rte_pflock.h |  16 +
 lib/librte_eal/x86/include/meson.build  |   1 +
 lib/librte_eal/x86/include/rte_pflock.h |  18 +
 9 files changed, 876 insertions(+)
 create mode 100644 app/test/test_pflock.c
 create mode 100644 lib/librte_eal/arm/include/rte_pflock.h
 create mode 100644 lib/librte_eal/include/generic/rte_pflock.h
 create mode 100644 lib/librte_eal/ppc/include/rte_pflock.h
 create mode 100644 lib/librte_eal/x86/include/rte_pflock.h

diff --git a/app/test/meson.build b/app/test/meson.build
index 561e493a2944..134098de9ac2 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -90,6 +90,7 @@ test_sources = files('commands.c',
'test_mcslock.c',
'test_mp_secondary.c',
'test_per_lcore.c',
+   'test_pflock.c',
'test_pmd_perf.c',
'test_power.c',
'test_power_cpufreq.c',
@@ -228,6 +229,11 @@ fast_tests = [
 ['meter_autotest', true],
 ['multiprocess_autotest', false],
 ['per_lcore_autotest', true],
+['pflock_autotest', true],
+['pflock_test1_autotest', true],
+['pflock_rda_autotest', true],
+['pflock_rds_wrm_autotest', true],
+['pflock_rde_wro_autotest', true],
 ['prefetch_autotest', true],
 ['rcu_qsbr_autotest', true],
 ['red_autotest', true],
diff --git a/app/test/test_pflock.c b/app/test/test_pflock.c
new file mode 100644
index ..f46610b73914
--- /dev/null
+++ b/app/test/test_pflock.c
@@ -0,0 +1,542 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2014 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+/*
+ * phase fair lock test
+ * ===
+ * Provides UT for phase fair lock API.
+ * Main concern is on functional testing, but also provides some
+ * performance measurements.
+ * Obviously for proper testing need to be executed with more than one lcore.
+ */
+
+#define ITER_NUM   0x80
+
+#define TEST_SEC   5
+
+static rte_pflock_t sl;
+static rte_pflock_t sl_tab[RTE_MAX_LCORE];
+static uint32_t synchro;
+
+enum {
+   LC_TYPE_RDLOCK,
+   LC_TYPE_WRLOCK,
+};
+
+static struct {
+   rte_pflock_t lock;
+   uint64_t tick;
+   volatile union {
+   uint8_t u8[RTE_CACHE_LINE_SIZE];
+   uint64_t u64[RTE_CACHE_LINE_SIZE / sizeof(uint64_t)];
+   } data;
+} __rte_cache_aligned try_pflock_data;
+
+struct try_pflock_lcore {
+   int32_t rc;
+   int32_t type;
+   struct {
+   uint64_t tick;
+   uint64_t fail;
+   uint64_t success;
+   } stat;
+} __rte_cache_aligned;
+
+static struct try_pflock_lcore try_lcore_data[RTE_MAX_LCORE];
+
+static int
+test_pflock_per_core(__rte_unused void *arg)
+{
+   rte_pflock_write_lock(&sl);
+   printf("Global write lock taken on core %u\n", rte_lcore_id());
+   rte_pflock_write_unlock(&sl);
+
+   rte_pflock_write_lock(&sl_tab[rte_lcore_id()]);
+   printf("Hello from core %u !\n", rte_lcore_id());
+   rte_pflock_write_unlock(&sl_tab[rte_lcore_id()]);
+
+   rte_pflock_read_lock(&sl);
+   printf("Global read lock taken on core %u\n", rte_lcore_id());
+   rte_delay_ms(100);
+   printf("Release global read lock on core %u\n", rte_lcore_id());
+   rte_pflock_read_unlock(&sl);
+
+   return 0;
+}
+
+static rte_pflock_t lk = RTE_PFLOCK_INITIALIZER;
+static volatile uint64_t pflock_data;
+static uint64_t time_count[RTE_MAX_LCORE] = {0};
+
+#define MAX_LOOP 1
+#define TEST_PFLOCK_DEBUG 0
+
+static int
+load

Re: [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers

[Ferruh Yigit]

On 3/3/2021 6:19 PM, Dmitry Kozlyuk wrote:

2021-03-03 16:47, Ferruh Yigit:

On 3/3/2021 4:32 PM, Dmitry Kozlyuk wrote:

[...]

If we can't help including / from public headers,
might as well use `struct in_addr`, just replace `#include `
with `#include ` everywhere.

The only remaining issue will be `s_addr` macro on Windows that conflicts with
`struct rte_ether_addr` field `s_addr`. I don't know a better solution than
renaming `s_addr` to `src_addr` in DPDK (OTOH, it will be consistent with
`struct rte_ipvX_hdr` field naming).

Ferruh, what do you think?
   


No problem on the chosen name, that will work fine, but the 'struct
rte_eth_addr' is public struct, we can't rename it without breaking the user
applications.

Still it is possible to rename public struct, but it is a long process, need to
send a deprecation notice and wait for next LTS, 21.11.

Ethernet header already has following, doesn't it help:
#undef s_addr /* Defined in winsock2.h included in windows.h. */


It helps until you do the following:

#include  /* #define s_addr S_un.S_addr */
#include /* #undef s_addr */

struct in_addr a;
a.s_addr = 0; /* ERROR, `s_addr` has been defined to do that */

Or the following:

#include 
#include 

struct rte_ether_hdr eh;
eh.s_addr.addr_bytes[0] = 0;/* ERROR: `addr_s` is a macro */

If you swap include order in each case, it compiles, i.e . code is fragile.
Shims redefine `struct in_addr` and we're trying to get rid of them anyway.



Got it, thanks for clarification.



Here's a solution that always works, however ugly it looks. It defines
`struct rte_ether_hdr` for Windows such that `s_addr` macro works for it if
defined. We can keep it until 21.11, then remove it and rename fields. In
return, we can remove networking shims and workarounds immediately.



Agree it looks ugly :), but I am OK with above plan.
You need to send a deprecation notice for this. We can discuss there if 'd_addr' 
also should be renamed for consistency, or leave with the workaround instead of 
rename ...



`S_un.S_addr` part of `struct in_addr` is documented, and thus is unlikely to
ever change:


https://docs.microsoft.com/en-us/windows/win32/api/winsock2/ns-winsock2-in_addr


diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index 060b63fc9..67d340bb2 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -23,10 +23,6 @@ extern "C" {
  #include 
  #include 
  
-#ifdef RTE_EXEC_ENV_WINDOWS /* Workaround conflict with rte_ether_hdr. */

-#undef s_addr /* Defined in winsock2.h included in windows.h. */
-#endif
-
  #define RTE_ETHER_ADDR_LEN  6 /**< Length of Ethernet address. */
  #define RTE_ETHER_TYPE_LEN  2 /**< Length of Ethernet type field. */
  #define RTE_ETHER_CRC_LEN   4 /**< Length of Ethernet CRC. */
@@ -257,6 +253,8 @@ __rte_experimental
  int
  rte_ether_unformat_addr(const char *str, struct rte_ether_addr *eth_addr);
  
+#if !defined RTE_EXEC_ENV_WINDOWS || defined __DOXYGEN__

+
  /**
   * Ethernet header: Contains the destination address, source address
   * and frame type.
@@ -267,6 +265,28 @@ struct rte_ether_hdr {
uint16_t ether_type;  /**< Frame type. */
  } __rte_aligned(2);
  
+#else

+
+#pragma push_macro("s_addr")
+#ifdef s_addr
+#undef s_addr
+#endif


I guess this needs to be as following, in case this header included before the 
windows header:


#ifdef s_addr
#pragma push_macro("s_addr")
#undef s_addr
#endif


+
+struct rte_ether_hdr {
+   struct rte_ether_addr d_addr; /**< Destination address. */
+   RTE_STD_C11
+   union {
+   struct rte_ether_addr s_addr; /**< Source address. */
+   struct {
+   struct rte_ether_addr S_un;
+   } S_addr;
+   };
+   uint16_t ether_type; /**< Frame type. */
+} __rte_aligned(2);
+
+#pragma pop_macro("s_addr")
+#endif
+
  /**
   * Ethernet VLAN Header.
   * Contains the 16-bit VLAN Tag Control Identifier and the Ethernet type

Re: [dpdk-dev] [PATCH v1] bbdev: adding explicit enum for code block mode

[Tom Rix]

On 2/19/21 4:15 PM, Nicolas Chautru wrote:
> Using explicit enum instead of ambiguous integer value
>
> Signed-off-by: Nicolas Chautru 
> ---
>  app/test-bbdev/test_bbdev_perf.c   | 16 -
>  app/test-bbdev/test_bbdev_vector.c | 16 -
>  drivers/baseband/acc100/rte_acc100_pmd.c   | 42 
> +++---
>  drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 10 +++---
>  drivers/baseband/fpga_lte_fec/fpga_lte_fec.c   | 24 +++--
>  drivers/baseband/turbo_sw/bbdev_turbo_software.c   | 18 +-
>  lib/librte_bbdev/rte_bbdev_op.h| 10 +-
>  7 files changed, 73 insertions(+), 63 deletions(-)
>
> diff --git a/app/test-bbdev/test_bbdev_perf.c 
> b/app/test-bbdev/test_bbdev_perf.c
> index 59b37ed..45b85b9 100644
> --- a/app/test-bbdev/test_bbdev_perf.c
> +++ b/app/test-bbdev/test_bbdev_perf.c
> @@ -1258,7 +1258,7 @@ typedef int (test_case_function)(struct active_device 
> *ad,
>   struct rte_bbdev_op_turbo_dec *turbo_dec = &ref_op->turbo_dec;
>  
>   for (i = 0; i < n; ++i) {
> - if (turbo_dec->code_block_mode == 0) {
> + if (turbo_dec->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
>   ops[i]->turbo_dec.tb_params.ea =
>   turbo_dec->tb_params.ea;
>   ops[i]->turbo_dec.tb_params.eb =
> @@ -1306,7 +1306,7 @@ typedef int (test_case_function)(struct active_device 
> *ad,
>   unsigned int i;
>   struct rte_bbdev_op_turbo_enc *turbo_enc = &ref_op->turbo_enc;
>   for (i = 0; i < n; ++i) {
> - if (turbo_enc->code_block_mode == 0) {
> + if (turbo_enc->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
>   ops[i]->turbo_enc.tb_params.ea =
>   turbo_enc->tb_params.ea;
>   ops[i]->turbo_enc.tb_params.eb =
> @@ -1661,7 +1661,7 @@ typedef int (test_case_function)(struct active_device 
> *ad,
>   struct rte_bbdev_op_ldpc_dec *ldpc_dec = &ref_op->ldpc_dec;
>  
>   for (i = 0; i < n; ++i) {
> - if (ldpc_dec->code_block_mode == 0) {
> + if (ldpc_dec->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
>   ops[i]->ldpc_dec.tb_params.ea =
>   ldpc_dec->tb_params.ea;
>   ops[i]->ldpc_dec.tb_params.eb =
> @@ -1715,7 +1715,7 @@ typedef int (test_case_function)(struct active_device 
> *ad,
>   unsigned int i;
>   struct rte_bbdev_op_ldpc_enc *ldpc_enc = &ref_op->ldpc_enc;
>   for (i = 0; i < n; ++i) {
> - if (ldpc_enc->code_block_mode == 0) {
> + if (ldpc_enc->code_block_mode == RTE_BBDEV_TRANSPORT_BLOCK) {
>   ops[i]->ldpc_enc.tb_params.ea = ldpc_enc->tb_params.ea;
>   ops[i]->ldpc_enc.tb_params.eb = ldpc_enc->tb_params.eb;
>   ops[i]->ldpc_enc.tb_params.cab =
> @@ -2239,7 +2239,7 @@ typedef int (test_case_function)(struct active_device 
> *ad,
>   uint8_t i;
>   uint32_t c, r, tb_size = 0;
>  
> - if (op->turbo_dec.code_block_mode) {
> + if (op->turbo_dec.code_block_mode == RTE_BBDEV_CODE_BLOCK) {
>   tb_size = op->turbo_dec.tb_params.k_neg;
>   } else {
>   c = op->turbo_dec.tb_params.c;
> @@ -2259,7 +2259,7 @@ typedef int (test_case_function)(struct active_device 
> *ad,
>   uint32_t c, r, tb_size = 0;
>   uint16_t sys_cols = (op->ldpc_dec.basegraph == 1) ? 22 : 10;
>  
> - if (op->ldpc_dec.code_block_mode) {
> + if (op->ldpc_dec.code_block_mode == RTE_BBDEV_CODE_BLOCK) {
>   tb_size = sys_cols * op->ldpc_dec.z_c - op->ldpc_dec.n_filler;
>   } else {
>   c = op->ldpc_dec.tb_params.c;
> @@ -2277,7 +2277,7 @@ typedef int (test_case_function)(struct active_device 
> *ad,
>   uint8_t i;
>   uint32_t c, r, tb_size = 0;
>  
> - if (op->turbo_enc.code_block_mode) {
> + if (op->turbo_enc.code_block_mode == RTE_BBDEV_CODE_BLOCK) {
>   tb_size = op->turbo_enc.tb_params.k_neg;
>   } else {
>   c = op->turbo_enc.tb_params.c;
> @@ -2297,7 +2297,7 @@ typedef int (test_case_function)(struct active_device 
> *ad,
>   uint32_t c, r, tb_size = 0;
>   uint16_t sys_cols = (op->ldpc_enc.basegraph == 1) ? 22 : 10;
>  
> - if (op->turbo_enc.code_block_mode) {
> + if (op->ldpc_enc.code_block_mode == RTE_BBDEV_CODE_BLOCK) {
>   tb_size = sys_cols * op->ldpc_enc.z_c - op->ldpc_enc.n_filler;
>   } else {
>   c = op->turbo_enc.tb_params.c;
> diff --git a/app/test-bbdev/test_bbdev_vector.c 
> b/app/test-bbdev/test_bbdev_vector.c
> index 50d1da0..614dbd1 100644
> --- a/app/test-bbdev/test_bbdev_vector.c
> +++ b/app/test-bbdev/test_bbdev_vector.c
> @@ -1052,9 +1052,9 @@
>   if (!(mask & TEST_BBDEV_VF_CODE_BLOCK_MODE)) {
>   printf(
>   "WARNING:

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Dumitrescu, Cristian]

Hi Matan,

> -Original Message-
> From: Matan Azrad 
> Sent: Tuesday, March 2, 2021 6:10 PM
> To: Dumitrescu, Cristian ; Li Zhang
> ; Dekel Peled ; Ori Kam
> ; Slava Ovsiienko 
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> ; Raslan Darawsheh ;
> m...@smartsharesystems.com; ajit.khapa...@broadcom.com; Yigit, Ferruh
> ; Singh, Jasvinder 
> Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> 
> Hi Cristian
> 
> Good discussion, thank you for that!
> 
> From: Dumitrescu, Cristian
> > Hi Matan,
> >
> > > -Original Message-
> > > From: Matan Azrad 
> > > Sent: Tuesday, March 2, 2021 12:37 PM
> > > To: Dumitrescu, Cristian ; Li Zhang
> > > ; Dekel Peled ; Ori Kam
> > > ; Slava Ovsiienko 
> > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> ;
> > > Raslan Darawsheh ; m...@smartsharesystems.com;
> > > ajit.khapa...@broadcom.com; Yigit, Ferruh ;
> > > Singh, Jasvinder 
> > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > >
> > > HI Cristian
> > >
> > > From: Dumitrescu, Cristian
> > > > Hi Matan,
> > > >
> > > > > -Original Message-
> > > > > From: Matan Azrad 
> > > > > Sent: Tuesday, March 2, 2021 7:02 AM
> > > > > To: Dumitrescu, Cristian ; Li Zhang
> > > > > ; Dekel Peled ; Ori Kam
> > > > > ; Slava Ovsiienko 
> > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > > ;
> > > > > Raslan Darawsheh ;
> m...@smartsharesystems.com;
> > > > > ajit.khapa...@broadcom.com; Yigit, Ferruh
> > > > > ; Singh, Jasvinder
> > > > > 
> > > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > > > >
> > > > >
> > > > >
> > > > > Hi Cristian
> > > > >
> > > > > Thank you for review, please see inline.
> > > > >
> > > > > From: Dumitrescu, Cristian
> > > > > > > From: dev  On Behalf Of Li Zhang
> > > > > 
> > > > > > We had this same problem earlier for the rte_tm.h API, where
> > > > > > people
> > > > > asked to
> > > > > > add support for WRED and shaper rates specified in packets to
> > > > > > the existing
> > > > > byte
> > > > > > rate support. I am more than happy to support adding the same
> > > > > > here, but please let's adopt the same solution here rather than
> > > > > > invent a different approach.
> > > > > >
> > > > > > Please refer to struct rte_tm_wred_params and struct
> > > > > rte_tm_shaper_params
> > > > > > from rte_tm.h: the packets vs. bytes mode is explicitly
> > > > > > specified through
> > > > > the use
> > > > > > of a flag called packet_mode that is added to the WRED and
> > > > > > shaper
> > > profile.
> > > > > > When packet_mode is 0, the profile rates and bucket sizes are
> > > > > > specified in bytes per second and bytes, respectively; when
> > > > > > packet_mode is not 0, the profile rates and bucket sizes are
> > > > > > specified in packets and packets per
> > > > > second,
> > > > > > respectively. The same profile parameters are used, no need to
> > > > > > invent additional algorithms (such as srTCM - packet mode) or
> > > > > > profile data
> > > > > structures.
> > > > > > Can we do the same here, please?
> > > > >
> > > > > This flag approach is very intuitive suggestion and it has advantages.
> > > > >
> > > > > The main problem with the flag approach is that it breaks ABI and API.
> > > > > The profile structure size is changed due to a new field - ABI
> breakage.
> > > > > The user must initialize the flag with zero to get old behavior -
> > > > > API
> > > breakage.
> > > > >
> > > >
> > > > The rte_mtr API is experimental, all the API functions are correctly
> > > > marked with __rte_experimental in rte_mtr.h file, so we can safely
> > > > change the API
> > > and
> > > > the ABI breakage is not applicable here. Therefore, this problem
> > > > does not
> > > exist,
> > > > correct?
> > >
> > > Yes, but still meter is not new API and I know that a lot of user uses
> > > it for a long time.
> > > Forcing them to change while we have good solution that don't force
> > > it, looks me problematic.
> > >
> >
> > Not really, only 3 drivers are currently implementing this API.
> 
> The user is not the PMD, the PMDs are the providers.
> I'm talking about all our customers, all the current DPDK based applications
> like OVS and others (I familiar with at least 4 ConnectX customer 
> applications)
> which use the meter API and I'm sure there are more around the world.
> 
> > Even to these drivers, the required changes are none or extremely small:
> as Ajit
> > was also noting, as the default value of 0 continues to represent the
> existing
> > byte mode, all you have to do is make sure the new flag is set to zero in 
> > the
> > profile params structure, which is already done implicitly in most places as
> this
> > structure is initialized to all-zeros.
> 
> Are you sure all the world initialize the struct to 0? and also in this case,
> without new compilation, not all the struct will be zeroes(the old size is
> smaller).
> 
> > A simple search exercise for struct rte_mtr_meter_profile is all tha

[dpdk-dev] [PATCH 0/4] Support ice PMD on Windows

[Pallavi Kadam]

This patch-set enables building the Intel ice PMD on Windows.

Depends-on: series-15230 ("bus/pci: fix probing for non-netuio bound devices")

Pallavi Kadam (4):
  build: enable iavf driver on Windows
  net/ice: build on Windows
  net/ice: disable ice DDP package on Windows
  doc: update ice PMD and 21.05 release notes

 doc/guides/nics/features/ice.ini   |  1 +
 doc/guides/nics/ice.rst| 16 ++--
 doc/guides/rel_notes/release_21_05.rst |  4 
 drivers/common/cpt/meson.build |  6 ++
 drivers/common/iavf/iavf_osdep.h   |  9 +
 drivers/common/meson.build |  3 ---
 drivers/common/mvep/meson.build|  6 ++
 drivers/common/octeontx/meson.build|  6 ++
 drivers/common/octeontx2/meson.build   |  6 ++
 drivers/common/qat/meson.build |  6 ++
 drivers/common/sfc_efx/meson.build |  6 ++
 drivers/net/ice/base/ice_flow.c|  2 +-
 drivers/net/ice/base/ice_flow.h|  2 +-
 drivers/net/ice/base/ice_osdep.h   | 15 +++
 drivers/net/ice/base/ice_switch.c  |  2 +-
 drivers/net/ice/base/ice_vlan_mode.h   |  1 +
 drivers/net/ice/ice_dcf_ethdev.c   |  1 -
 drivers/net/ice/ice_dcf_parent.c   | 10 +-
 drivers/net/ice/ice_ethdev.c   | 12 +---
 drivers/net/ice/ice_rxtx_vec_avx2.c|  2 +-
 drivers/net/ice/ice_rxtx_vec_avx512.c  |  2 +-
 drivers/net/ice/meson.build| 10 --
 22 files changed, 103 insertions(+), 25 deletions(-)

-- 
2.18.0.windows.1

[dpdk-dev] [PATCH 1/4] build: enable iavf driver on Windows

[Pallavi Kadam]

Enable IAVF driver to build on Windows as it is required
to build ice PMD.
Disable all other drivers from common directory.
This patch also includes fix for a macro redefinition warning
in the IAVF driver.

Signed-off-by: Pallavi Kadam 
Reviewed-by: Ranjit Menon 
---
 drivers/common/cpt/meson.build   | 6 ++
 drivers/common/iavf/iavf_osdep.h | 9 +
 drivers/common/meson.build   | 3 ---
 drivers/common/mvep/meson.build  | 6 ++
 drivers/common/octeontx/meson.build  | 6 ++
 drivers/common/octeontx2/meson.build | 6 ++
 drivers/common/qat/meson.build   | 6 ++
 drivers/common/sfc_efx/meson.build   | 6 ++
 8 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/drivers/common/cpt/meson.build b/drivers/common/cpt/meson.build
index beecf0da3..1127267ba 100644
--- a/drivers/common/cpt/meson.build
+++ b/drivers/common/cpt/meson.build
@@ -1,6 +1,12 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2018 Cavium, Inc
 
+if is_windows
+   build = false
+   reason = 'not supported on Windows'
+   subdir_done()
+endif
+
 sources = files('cpt_fpm_tables.c',
'cpt_pmd_ops_helper.c')
 
diff --git a/drivers/common/iavf/iavf_osdep.h b/drivers/common/iavf/iavf_osdep.h
index eaefde88e..76c186a5b 100644
--- a/drivers/common/iavf/iavf_osdep.h
+++ b/drivers/common/iavf/iavf_osdep.h
@@ -55,6 +55,15 @@ typedef uint64_ts64;
 #define __be64  uint64_t
 #endif
 
+/* Avoid macro redefinition warning on Windows */
+#ifdef RTE_EXEC_ENV_WINDOWS
+#ifdef min
+#undef min
+#endif
+#ifdef max
+#undef max
+#endif
+#endif
 #define min(a, b) RTE_MIN(a, b)
 #define max(a, b) RTE_MAX(a, b)
 
diff --git a/drivers/common/meson.build b/drivers/common/meson.build
index ba6325adf..2a0c43054 100644
--- a/drivers/common/meson.build
+++ b/drivers/common/meson.build
@@ -1,9 +1,6 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2018 Cavium, Inc
 
-if is_windows
-   subdir_done()
-endif
 
 std_deps = ['eal']
 drivers = ['cpt', 'dpaax', 'iavf', 'mvep', 'octeontx', 'octeontx2', 'sfc_efx']
diff --git a/drivers/common/mvep/meson.build b/drivers/common/mvep/meson.build
index 7cd968b38..a929e2311 100644
--- a/drivers/common/mvep/meson.build
+++ b/drivers/common/mvep/meson.build
@@ -4,6 +4,12 @@
 # All rights reserved.
 #
 
+if is_windows
+   build = false
+   reason = 'not supported on Windows'
+   subdir_done()
+endif
+
 dep = dependency('libmusdk', required: false, method: 'pkg-config')
 if not dep.found()
build = false
diff --git a/drivers/common/octeontx/meson.build 
b/drivers/common/octeontx/meson.build
index 203d1ef49..02b57b95c 100644
--- a/drivers/common/octeontx/meson.build
+++ b/drivers/common/octeontx/meson.build
@@ -2,4 +2,10 @@
 # Copyright(c) 2018 Cavium, Inc
 #
 
+if is_windows
+   build = false
+   reason = 'not supported on Windows'
+   subdir_done()
+endif
+
 sources = files('octeontx_mbox.c')
diff --git a/drivers/common/octeontx2/meson.build 
b/drivers/common/octeontx2/meson.build
index 84fb11524..97293d1a7 100644
--- a/drivers/common/octeontx2/meson.build
+++ b/drivers/common/octeontx2/meson.build
@@ -2,6 +2,12 @@
 # Copyright(C) 2019 Marvell International Ltd.
 #
 
+if is_windows
+   build = false
+   reason = 'not supported on Windows'
+   subdir_done()
+endif
+
 if not dpdk_conf.get('RTE_ARCH_64')
build = false
reason = 'only supported on 64-bit'
diff --git a/drivers/common/qat/meson.build b/drivers/common/qat/meson.build
index 67f7aca97..3ad7dd501 100644
--- a/drivers/common/qat/meson.build
+++ b/drivers/common/qat/meson.build
@@ -1,6 +1,12 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2017-2018 Intel Corporation
 
+if is_windows
+   build = false
+   reason = 'not supported on Windows'
+   subdir_done()
+endif
+
 qat_crypto = true
 qat_crypto_path = 'crypto/qat'
 qat_crypto_relpath = '../../' + qat_crypto_path
diff --git a/drivers/common/sfc_efx/meson.build 
b/drivers/common/sfc_efx/meson.build
index 6cb9f0737..a2dfed0ec 100644
--- a/drivers/common/sfc_efx/meson.build
+++ b/drivers/common/sfc_efx/meson.build
@@ -5,6 +5,12 @@
 # This software was jointly developed between OKTET Labs (under contract
 # for Solarflare) and Solarflare Communications, Inc.
 
+if is_windows
+   build = false
+   reason = 'not supported on Windows'
+   subdir_done()
+endif
+
 if (arch_subdir != 'x86' or not dpdk_conf.get('RTE_ARCH_64')) and (arch_subdir 
!= 'arm' or not host_machine.cpu_family().startswith('aarch64'))
build = false
reason = 'only supported on x86_64 and aarch64'
-- 
2.18.0.windows.1

[dpdk-dev] [PATCH 2/4] net/ice: build on Windows

[Pallavi Kadam]

Add Intel ice PMD support on Windows.
Remove #include sys/ioctl header file as it is not needed.
Replace x86intrin.h with rte_vect.h to avoid __m_prefetchw conflicting
types.
Replace POSIX usleep() API with rte API.
Add a new macro for the access() API as the original function
has been deprecated on Windows.
Add extra cflags '-fno-asynchronous-unwind-tables'
to avoid MinGW build error:
Error: invalid register for .seh_savexmm

Signed-off-by: Pallavi Kadam 
Reviewed-by: Ranjit Menon 
---
 drivers/net/ice/base/ice_flow.c   |  2 +-
 drivers/net/ice/base/ice_flow.h   |  2 +-
 drivers/net/ice/base/ice_osdep.h  | 15 +++
 drivers/net/ice/base/ice_switch.c |  2 +-
 drivers/net/ice/base/ice_vlan_mode.h  |  1 +
 drivers/net/ice/ice_dcf_ethdev.c  |  1 -
 drivers/net/ice/ice_dcf_parent.c  | 10 +-
 drivers/net/ice/ice_ethdev.c  |  6 +++---
 drivers/net/ice/ice_rxtx_vec_avx2.c   |  2 +-
 drivers/net/ice/ice_rxtx_vec_avx512.c |  2 +-
 drivers/net/ice/meson.build   | 10 --
 11 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ice/base/ice_flow.c b/drivers/net/ice/base/ice_flow.c
index a081fbe5a..a4c233d4c 100644
--- a/drivers/net/ice/base/ice_flow.c
+++ b/drivers/net/ice/base/ice_flow.c
@@ -3139,7 +3139,7 @@ enum ice_status ice_flow_rem_entry(struct ice_hw *hw, 
enum ice_block blk,
if (entry_h == ICE_FLOW_ENTRY_HANDLE_INVAL)
return ICE_ERR_PARAM;
 
-   entry = ICE_FLOW_ENTRY_PTR((unsigned long)entry_h);
+   entry = ICE_FLOW_ENTRY_PTR((intptr_t)entry_h);
 
/* Retain the pointer to the flow profile as the entry will be freed */
prof = entry->prof;
diff --git a/drivers/net/ice/base/ice_flow.h b/drivers/net/ice/base/ice_flow.h
index c3bce1319..af15ecb0f 100644
--- a/drivers/net/ice/base/ice_flow.h
+++ b/drivers/net/ice/base/ice_flow.h
@@ -446,7 +446,7 @@ struct ice_flow_entry {
u8 acts_cnt;
 };
 
-#define ICE_FLOW_ENTRY_HNDL(e) ((unsigned long)e)
+#define ICE_FLOW_ENTRY_HNDL(e) ((intptr_t)e)
 #define ICE_FLOW_ENTRY_PTR(h)  ((struct ice_flow_entry *)(h))
 
 struct ice_flow_prof {
diff --git a/drivers/net/ice/base/ice_osdep.h b/drivers/net/ice/base/ice_osdep.h
index 46ac86834..f4cc762e9 100644
--- a/drivers/net/ice/base/ice_osdep.h
+++ b/drivers/net/ice/base/ice_osdep.h
@@ -62,9 +62,24 @@ typedef uint64_ts64;
 #define __be64  uint64_t
 #endif
 
+/* Avoid macro redefinition warning on Windows */
+#ifdef RTE_EXEC_ENV_WINDOWS
+#ifdef min
+#undef min
+#endif
+#ifdef max
+#undef max
+#endif
+#endif
 #define min(a, b) RTE_MIN(a, b)
 #define max(a, b) RTE_MAX(a, b)
 
+#ifdef RTE_EXEC_ENV_WINDOWS
+#define ice_access _access
+#else
+#define ice_access access
+#endif
+
 #define FIELD_SIZEOF(t, f) RTE_SIZEOF_FIELD(t, f)
 #define ARRAY_SIZE(arr) RTE_DIM(arr)
 
diff --git a/drivers/net/ice/base/ice_switch.c 
b/drivers/net/ice/base/ice_switch.c
index 4568242c1..b546e3d4e 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -6684,7 +6684,7 @@ ice_fill_valid_words(struct ice_adv_lkup_elem *rule,
 
for (j = 0; j < sizeof(rule->m_u) / sizeof(u16); j++)
if (((u16 *)&rule->m_u)[j] &&
-   rule->type < ARRAY_SIZE(ice_prot_ext)) {
+   (unsigned long long)rule->type < ARRAY_SIZE(ice_prot_ext)) {
/* No more space to accommodate */
if (word >= ICE_MAX_CHAIN_WORDS)
return 0;
diff --git a/drivers/net/ice/base/ice_vlan_mode.h 
b/drivers/net/ice/base/ice_vlan_mode.h
index e9f13e781..bcb6ff713 100644
--- a/drivers/net/ice/base/ice_vlan_mode.h
+++ b/drivers/net/ice/base/ice_vlan_mode.h
@@ -6,6 +6,7 @@
 #define _ICE_VLAN_MODE_H_
 
 #include "ice_osdep.h"
+#include "ice_status.h"
 
 struct ice_hw;
 
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index e0772295e..af4731f55 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -5,7 +5,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/net/ice/ice_dcf_parent.c b/drivers/net/ice/ice_dcf_parent.c
index 476fd4906..a8571b35e 100644
--- a/drivers/net/ice/ice_dcf_parent.c
+++ b/drivers/net/ice/ice_dcf_parent.c
@@ -121,7 +121,7 @@ ice_dcf_vsi_update_service_handler(void *param)
struct ice_dcf_hw *hw = reset_param->dcf_hw;
struct ice_dcf_adapter *adapter;
 
-   usleep(ICE_DCF_VSI_UPDATE_SERVICE_INTERVAL);
+   rte_delay_us(ICE_DCF_VSI_UPDATE_SERVICE_INTERVAL);
 
rte_spinlock_lock(&vsi_update_lock);
 
@@ -315,24 +315,24 @@ ice_dcf_request_pkg_name(struct ice_hw *hw, char 
*pkg_name)
snprintf(pkg_name, ICE_MAX_PKG_FILENAME_SIZE,
 ICE_PKG_FILE_SEARCH_PATH_UPDATES "ice-%016llx.pkg",
 (unsigned long long)dsn);
-   if (!access(pkg_name, 0))
+   if (!ice_access(pkg_name, 0))
return 0;
 

[dpdk-dev] [PATCH 3/4] net/ice: disable ice DDP package on Windows

[Pallavi Kadam]

Disable loading of private DDP packages in ice PMD on Windows.

Signed-off-by: Pallavi Kadam 
Reviewed-by: Ranjit Menon 
---
 drivers/net/ice/ice_ethdev.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index d22bc92ff..1f5f16d42 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -1652,6 +1652,7 @@ ice_pf_setup(struct ice_pf *pf)
  * Extract device serial number from PCIe Configuration Space and
  * determine the pkg file path according to the DSN.
  */
+#ifndef RTE_EXEC_ENV_WINDOWS
 static int
 ice_pkg_file_search_path(struct rte_pci_device *pci_dev, char *pkg_file)
 {
@@ -1689,6 +1690,7 @@ ice_pkg_file_search_path(struct rte_pci_device *pci_dev, 
char *pkg_file)
strncpy(pkg_file, ICE_PKG_FILE_DEFAULT, ICE_MAX_PKG_FILENAME_SIZE);
return 0;
 }
+#endif
 
 enum ice_pkg_type
 ice_load_pkg_type(struct ice_hw *hw)
@@ -1714,6 +1716,7 @@ ice_load_pkg_type(struct ice_hw *hw)
return package_type;
 }
 
+#ifndef RTE_EXEC_ENV_WINDOWS
 static int ice_load_pkg(struct rte_eth_dev *dev)
 {
struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
@@ -1785,6 +1788,7 @@ static int ice_load_pkg(struct rte_eth_dev *dev)
rte_free(buf);
return err;
 }
+#endif
 
 static void
 ice_base_queue_get(struct ice_pf *pf)
@@ -2065,6 +2069,7 @@ ice_dev_init(struct rte_eth_dev *dev)
return -EINVAL;
}
 
+#ifndef RTE_EXEC_ENV_WINDOWS
ret = ice_load_pkg(dev);
if (ret) {
if (ad->devargs.safe_mode_support == 0) {
@@ -2077,6 +2082,7 @@ ice_dev_init(struct rte_eth_dev *dev)
"Entering Safe Mode");
ad->is_safe_mode = 1;
}
+#endif
 
PMD_INIT_LOG(INFO, "FW %d.%d.%05d API %d.%d",
 hw->fw_maj_ver, hw->fw_min_ver, hw->fw_build,
-- 
2.18.0.windows.1

[dpdk-dev] [PATCH 4/4] doc: update ice PMD and 21.05 release notes

[Pallavi Kadam]

Add documentation to support ice PMD on Windows.
Update the release notes and features list for the same.

Signed-off-by: Pallavi Kadam 
Reviewed-by: Ranjit Menon 
---
 doc/guides/nics/features/ice.ini   |  1 +
 doc/guides/nics/ice.rst| 16 ++--
 doc/guides/rel_notes/release_21_05.rst |  4 
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/doc/guides/nics/features/ice.ini b/doc/guides/nics/features/ice.ini
index e30a7d2e5..2b93872b1 100644
--- a/doc/guides/nics/features/ice.ini
+++ b/doc/guides/nics/features/ice.ini
@@ -40,5 +40,6 @@ Module EEPROM dump   = Y
 Multiprocess aware   = Y
 FreeBSD  = Y
 Linux= Y
+Windows  = Y
 x86-32   = Y
 x86-64   = Y
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index ccda26f82..d9d4da505 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -8,8 +8,8 @@ The ice PMD (**librte_net_ice**) provides poll mode driver 
support for
 10/25/50/100 Gbps Intel?? Ethernet 800 Series Network Adapters based on
 the Intel Ethernet Controller E810 and Intel Ethernet Connection E822/E823.
 
-Prerequisites
--
+Linux Prerequisites
+---
 
 - Follow the DPDK :ref:`Getting Started Guide for Linux ` to setup 
the basic DPDK environment.
 
@@ -25,6 +25,18 @@ Prerequisites
 - To understand DDP for COMMs usage with DPDK, please review `Intel?? Ethernet 
800 Series Telecommunication (Comms)
   Dynamic Device Personalization (DDP) Package 
`_.
 
+Windows Prerequisites
+-
+
+- Follow the DPDK `Getting Started Guide for Windows 
`_ to setup the basic DPDK 
environment.
+
+- Identify the Intel?? Ethernet adapter and get the latest NVM/FW version.
+
+- To access any Intel?? Ethernet hardware, load the NetUIO driver in place of 
existing built-in (inbox) driver.
+
+- To load NetUIO driver, follow the steps mentioned in `dpdk-kmods repository
+  `_.
+
 
 Recommended Matching List
 -
diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst
index 5aa9ed7db..e28d9a6c8 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -55,6 +55,10 @@ New Features
  Also, make sure to start the actual text at the margin.
  ===
 
+* **Updated Intel ice driver.**
+
+  * Added Intel ice support on Windows.
+
 
 Removed Items
 -
-- 
2.18.0.windows.1

[dpdk-dev] [PATCH] ethdev: add Field ID doxygen description

[Alexander Kozyrev]

Field IDs for the MODIFY_FIELD action lack doxygen comments
and not visible in online DPDK documentation because of that.
Provide a meaningful description for every Field ID for the
rte_flow_field_id enumeration.

Fixes: 73b68f4c54 ("ethdev: introduce generic modify flow action")
Cc: sta...@dpdk.org

Signed-off-by: Alexander Kozyrev 
---
 lib/librte_ethdev/rte_flow.h | 58 ++--
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index 68c68cdd6c..669e677e91 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -2832,35 +2832,35 @@ struct rte_flow_shared_action;
  * Field IDs for MODIFY_FIELD action.
  */
 enum rte_flow_field_id {
-   RTE_FLOW_FIELD_START = 0, /**< Start of a packet. */
-   RTE_FLOW_FIELD_MAC_DST,
-   RTE_FLOW_FIELD_MAC_SRC,
-   RTE_FLOW_FIELD_VLAN_TYPE,
-   RTE_FLOW_FIELD_VLAN_ID,
-   RTE_FLOW_FIELD_MAC_TYPE,
-   RTE_FLOW_FIELD_IPV4_DSCP,
-   RTE_FLOW_FIELD_IPV4_TTL,
-   RTE_FLOW_FIELD_IPV4_SRC,
-   RTE_FLOW_FIELD_IPV4_DST,
-   RTE_FLOW_FIELD_IPV6_DSCP,
-   RTE_FLOW_FIELD_IPV6_HOPLIMIT,
-   RTE_FLOW_FIELD_IPV6_SRC,
-   RTE_FLOW_FIELD_IPV6_DST,
-   RTE_FLOW_FIELD_TCP_PORT_SRC,
-   RTE_FLOW_FIELD_TCP_PORT_DST,
-   RTE_FLOW_FIELD_TCP_SEQ_NUM,
-   RTE_FLOW_FIELD_TCP_ACK_NUM,
-   RTE_FLOW_FIELD_TCP_FLAGS,
-   RTE_FLOW_FIELD_UDP_PORT_SRC,
-   RTE_FLOW_FIELD_UDP_PORT_DST,
-   RTE_FLOW_FIELD_VXLAN_VNI,
-   RTE_FLOW_FIELD_GENEVE_VNI,
-   RTE_FLOW_FIELD_GTP_TEID,
-   RTE_FLOW_FIELD_TAG,
-   RTE_FLOW_FIELD_MARK,
-   RTE_FLOW_FIELD_META,
-   RTE_FLOW_FIELD_POINTER, /**< Memory pointer. */
-   RTE_FLOW_FIELD_VALUE,   /**< Immediate value. */
+   RTE_FLOW_FIELD_START = 0,   /**< Start of a packet. */
+   RTE_FLOW_FIELD_MAC_DST, /**< Destination MAC Address. */
+   RTE_FLOW_FIELD_MAC_SRC, /**< Source MAC Address. */
+   RTE_FLOW_FIELD_VLAN_TYPE,   /**< 802.1Q Tag Identifier. */
+   RTE_FLOW_FIELD_VLAN_ID, /**< 802.1Q VLAN Identifier. */
+   RTE_FLOW_FIELD_MAC_TYPE,/**< EtherType. */
+   RTE_FLOW_FIELD_IPV4_DSCP,   /**< IPv4 DSCP. */
+   RTE_FLOW_FIELD_IPV4_TTL,/**< IPv4 Time To Live. */
+   RTE_FLOW_FIELD_IPV4_SRC,/**< IPv4 Source Address. */
+   RTE_FLOW_FIELD_IPV4_DST,/**< IPv4 Destination Address. */
+   RTE_FLOW_FIELD_IPV6_DSCP,   /**< IPv6 DSCP. */
+   RTE_FLOW_FIELD_IPV6_HOPLIMIT,   /**< IPv6 Hop Limit. */
+   RTE_FLOW_FIELD_IPV6_SRC,/**< IPv6 Source Address. */
+   RTE_FLOW_FIELD_IPV6_DST,/**< IPv6 Destination Address. */
+   RTE_FLOW_FIELD_TCP_PORT_SRC,/**< TCP Source Port Number. */
+   RTE_FLOW_FIELD_TCP_PORT_DST,/**< TCP Destination Port Number. */
+   RTE_FLOW_FIELD_TCP_SEQ_NUM, /**< TCP Sequence Number. */
+   RTE_FLOW_FIELD_TCP_ACK_NUM, /**< TCP Acknowledgment Number. */
+   RTE_FLOW_FIELD_TCP_FLAGS,   /**< TCP Flags. */
+   RTE_FLOW_FIELD_UDP_PORT_SRC,/**< UDP Source Port Number. */
+   RTE_FLOW_FIELD_UDP_PORT_DST,/**< UDP Destination Port Number. */
+   RTE_FLOW_FIELD_VXLAN_VNI,   /**< VXLAN Network Identifier. */
+   RTE_FLOW_FIELD_GENEVE_VNI,  /**< GENEVE Network Identifier. */
+   RTE_FLOW_FIELD_GTP_TEID,/**< GTP Tunnel Endpoint Identifier. */
+   RTE_FLOW_FIELD_TAG, /**< Tag value. */
+   RTE_FLOW_FIELD_MARK,/**< Mark value. */
+   RTE_FLOW_FIELD_META,/**< Metadata value. */
+   RTE_FLOW_FIELD_POINTER, /**< Memory pointer. */
+   RTE_FLOW_FIELD_VALUE,   /**< Immediate value. */
 };
 
 /**
-- 
2.24.1

[dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields

[Dmitry Kozlyuk]

It is proposed to rename fields of `struct rte_ether_hdr`,
`s_addr` tp `src_addr` and `d_addr` to `dst_addr`,
due to the clash with system macro on Windows.
Until remaining is done in 21.11, a workaround can be used.

Windows Sockets headers contain `#define s_addr S_un.S_addr`, which
conflicts with `s_addr` field of `struct rte_ether_hdr`. Undefining
this macro in  is breaking some usages of DPDK
and Windows headers in one file.

Example 1:

#include 
#include 
struct in_addr addr;
/* addr.s_addr = 0; ERROR: s_addr undefined by DPDK */

Example 2:

#include 
#include 
struct rte_ether_hdr eh;
/* eh.s_addr.addr_bytes[0] = 0; ERROR: `addr_s` is a macro */

It is not mandatory to rename `d_addr`, this is for consistency only.
Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.

Workaround is to define `struct rte_ether_hdr` in such a away that
it can be used with or without `s_addr` macro (as defined on Windows)
This can be done for Windows only or for all platforms to save space.

#pragma push_macro("s_addr")
#ifdef s_addr
#undef s_addr
#endif

struct rte_ether_hdr {
struct rte_ether_addr d_addr; /**< Destination address. */
RTE_STD_C11
union {
struct rte_ether_addr s_addr; /**< Source address. */
struct {
struct rte_ether_addr S_un;
/**< MUST NOT be used directly, only via s_addr */
} S_addr;
/*< MUST NOT be used directly, only via s_addr */
};
uint16_t ether_type; /**< Frame type. */
} __rte_aligned(2);

#pragma pop_macro("s_addr")

Signed-off-by: Dmitry Kozlyuk 
---
 doc/guides/rel_notes/deprecation.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 82c1a90a3..f7be10543 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -125,3 +125,7 @@ Deprecation Notices
 * cmdline: ``cmdline`` structure will be made opaque to hide platform-specific
   content. On Linux and FreeBSD, supported prior to DPDK 20.11,
   original structure will be kept until DPDK 21.11.
+
+* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
+  will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK 20.11
+  in order to avoid conflict with Windows Sockets headers.
-- 
2.29.2

Re: [dpdk-dev] [PATCH v2 4/6] net/pcap: add libpcap wrappers

[Dmitry Kozlyuk]

2021-03-03 19:30, Ferruh Yigit:
> On 3/3/2021 6:19 PM, Dmitry Kozlyuk wrote:
> > 2021-03-03 16:47, Ferruh Yigit:  
> >> On 3/3/2021 4:32 PM, Dmitry Kozlyuk wrote:  
[...]
> > +#pragma push_macro("s_addr")
> > +#ifdef s_addr
> > +#undef s_addr
> > +#endif  
> 
> I guess this needs to be as following, in case this header included before 
> the 
> windows header:
> 
> #ifdef s_addr
> #pragma push_macro("s_addr")
> #undef s_addr
> #endif

It actually works both ways.
I used #ifdef inside so that #pragma pop_macro doesn't need its own guard.

Re: [dpdk-dev] [PATCH 3/4] net/ice: disable ice DDP package on Windows

[Dmitry Kozlyuk]

2021-03-03 13:59, Pallavi Kadam:
> Disable loading of private DDP packages in ice PMD on Windows.
> 
> Signed-off-by: Pallavi Kadam 
> Reviewed-by: Ranjit Menon 
> ---
>  drivers/net/ice/ice_ethdev.c | 6 ++
>  1 file changed, 6 insertions(+)

Are DDP packages unavailable on Windows or is their loading disabled because
reading from PCI config space is not implemented by netuio? In the former
case, please document the reason in commit (and probably in used guide?).
In the latter case, could you instead fix rte_pci_config_read() to return (-1)
on Windows, so that DDP loading automatically fails at reading capabilities?
This would ensure ICE PMD remains portable by compiling all of its code in
every platform.

Re: [dpdk-dev] [PATCH 4/4] doc: update ice PMD and 21.05 release notes

[Dmitry Kozlyuk]

2021-03-03 13:59, Pallavi Kadam:
> Add documentation to support ice PMD on Windows.
> Update the release notes and features list for the same.
> 
> Signed-off-by: Pallavi Kadam 
> Reviewed-by: Ranjit Menon 
> ---
>  doc/guides/nics/features/ice.ini   |  1 +
>  doc/guides/nics/ice.rst| 16 ++--
>  doc/guides/rel_notes/release_21_05.rst |  4 
>  3 files changed, 19 insertions(+), 2 deletions(-)

It is preferred to update docs in single commit with code.

Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields

[Stephen Hemminger]

> +
> +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
> +  will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK 20.11
> +  in order to avoid conflict with Windows Sockets headers.

If those fields were a problem now, there might be others in future.
Don't use src_addr and dst_addr because those are already used in rte_ipv4_hdr.

Linux and FreeBSD use:

struct ether_header
{
  uint8_t  ether_dhost[ETH_ALEN];   /* destination eth addr */
  uint8_t  ether_shost[ETH_ALEN];   /* source ether addr*/
  uint16_t ether_type;  /* packet type ID field */
} __attribute__ ((__packed__));

So why not ether_dhost/ether_shost?

Re: [dpdk-dev] [PATCH v4] bus/pci/windows: support for PCI scan allowed and blocked lists

[Ranjit Menon]

On 2/28/2021 10:52 PM, Khoa To wrote:

EAL -a and -b options are used to specify which PCI devices are
explicitly allowed or blocked during PCI bus scan.  This evaluation
is missing in the Windows implementation of rte_pci_scan.

This patch provides this missing functionality, so that apps can specify
which NetUIO devices to ignore during PCI bus scan.

Signed-off-by: Khoa To 
---
v4:
* Fix coding style warning with unaligned comments
v3:
* Move the check inside pci_scan_one
* Small change to pci_scan_one to malloc only after checks succeeded
v2:
* Truncate commit description lines to 75 charaters or less

  drivers/bus/pci/windows/pci.c | 23 ---
  1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/bus/pci/windows/pci.c b/drivers/bus/pci/windows/pci.c
index f66258452..0d184f24d 100644
--- a/drivers/bus/pci/windows/pci.c
+++ b/drivers/bus/pci/windows/pci.c
@@ -308,17 +308,24 @@ set_kernel_driver_type(PSP_DEVINFO_DATA device_info_data,
  static int
  pci_scan_one(HDEVINFO dev_info, PSP_DEVINFO_DATA device_info_data)
  {
-   struct rte_pci_device *dev;
+   struct rte_pci_device *dev = NULL;
int ret = -1;
char  pci_device_info[REGSTR_VAL_MAX_HCID_LEN];
struct rte_pci_addr addr;
struct rte_pci_id pci_id;
  
-	dev = malloc(sizeof(*dev));

-   if (dev == NULL)
+   ret = get_device_pci_address(dev_info, device_info_data, &addr);
+   if (ret != 0)
goto end;
  
-	memset(dev, 0, sizeof(*dev));

+   if (rte_pci_ignore_device(&addr)) {
+   /*
+* We won't add this device, but we want to continue
+* looking for supported devices
+*/
+   ret = ERROR_CONTINUE;
+   goto end;
+   }
  
  	ret = get_pci_hardware_id(dev_info, device_info_data,

pci_device_info, sizeof(pci_device_info));
@@ -335,10 +342,12 @@ pci_scan_one(HDEVINFO dev_info, PSP_DEVINFO_DATA 
device_info_data)
goto end;
}
  
-	ret = get_device_pci_address(dev_info, device_info_data, &addr);

-   if (ret != 0)
+   dev = malloc(sizeof(*dev));
+   if (dev == NULL)
goto end;
  
+	memset(dev, 0, sizeof(*dev));

+
dev->addr = addr;
dev->id = pci_id;
dev->max_vfs = 0; /* TODO: get max_vfs */
@@ -417,7 +426,7 @@ rte_pci_scan(void)
device_index++;
/* we only want to enumerate net & netuio class devices */
if (IsEqualGUID(&(device_info_data.ClassGuid),
-   &GUID_DEVCLASS_NET) ||
+   &GUID_DEVCLASS_NET) ||
IsEqualGUID(&(device_info_data.ClassGuid),
&GUID_DEVCLASS_NETUIO)) {
ret = pci_scan_one(dev_info, &device_info_data);


This last change appears to be a formatting change. Was it required by 
checkpatch?


Other than that...

Acked-by: Ranjit Menon 

Re: [dpdk-dev] [PATCH v4] bus/pci/windows: support for PCI scan allowed and blocked lists

[Khoa To]

On Wed, 3 Mar 2021, Ranjit Menon wrote:


On 2/28/2021 10:52 PM, Khoa To wrote:

 EAL -a and -b options are used to specify which PCI devices are
 explicitly allowed or blocked during PCI bus scan.  This evaluation
 is missing in the Windows implementation of rte_pci_scan.

 This patch provides this missing functionality, so that apps can specify
 which NetUIO devices to ignore during PCI bus scan.

 Signed-off-by: Khoa To 
 ---
 v4:
 * Fix coding style warning with unaligned comments
 v3:
 * Move the check inside pci_scan_one
 * Small change to pci_scan_one to malloc only after checks succeeded
 v2:
 * Truncate commit description lines to 75 charaters or less

   drivers/bus/pci/windows/pci.c | 23 ---
   1 file changed, 16 insertions(+), 7 deletions(-)



This last change appears to be a formatting change. Was it required by 
checkpatch?


Other than that...

Acked-by: Ranjit Menon 



Thanks, Ranjit. Yes, v4 was just some white-space fixes for a CI warning.

Re: [dpdk-dev] [PATCH 00/11] bnxt fixes

[Ajit Khaparde]

On Wed, Feb 24, 2021 at 7:33 AM Kalesh A P  wrote:

> From: Kalesh AP 
>
> This patchset contain bnxt bug fixes and enhancements.
>
> Please apply.
>
> Ajit Khaparde (1):
>   net/bnxt: update to new version of backing store
>
> Kalesh AP (9):
>   net/bnxt: remove unused macro
>   net/bnxt: fix vnic configuration
>   net/bnxt: remove extra blank line
>   net/bnxt: update HWRM structures
>   net/bnxt: log port id in async events
>   net/bnxt: handle echo request async message
>   net/bnxt: fix firmware fatal error handling
>   net/bnxt: fix fw readiness check during recovery
>   net/bnxt: fix PTP support for thor
>
> Venkat Duvvuru (1):
>   net/bnxt: update number of queues per vnic in single queue mode
>
>  drivers/net/bnxt/bnxt.h|   24 +-
>  drivers/net/bnxt/bnxt_cpr.c|   25 +-
>  drivers/net/bnxt/bnxt_ethdev.c |  175 +-
>  drivers/net/bnxt/bnxt_hwrm.c   |   93 +-
>  drivers/net/bnxt/bnxt_hwrm.h   |6 +-
>  drivers/net/bnxt/bnxt_rxq.c|3 +-
>  drivers/net/bnxt/bnxt_rxr.c|   17 +-
>  drivers/net/bnxt/bnxt_util.h   |2 +
>  drivers/net/bnxt/bnxt_vnic.h   |2 -
>  drivers/net/bnxt/hsi_struct_def_dpdk.h | 3720
> +---
>  10 files changed, 3267 insertions(+), 800 deletions(-)
>
Patchset applied to dpdk-next-net-brcm. Thanks


>
> --
> 2.10.1
>
>

Re: [dpdk-dev] [Linuxarm] Re: [PATCH V2 04/14] net/hns3: add Rx and Tx bytes stats

[oulijun]

在 2021/3/3 22:24, Ferruh Yigit 写道:

On 3/3/2021 2:08 PM, oulijun wrote:



在 2021/3/3 21:28, Ferruh Yigit 写道:

On 3/2/2021 1:58 PM, Lijun Ou wrote:

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


copy/paste from previous version:

Why statistics enabled only with macro?
It is not common to use macro to enable the stats, what do you think 
to remove it, to be consistent with rest of the PMDs?

I'm sorry. I thought it was a success.
  Firstly, the macro is used to control the statistics to ensure 
performance and facilitate flexible usage. For example, the macro 
needs to be disabled when high performance is required.
secondly the byte statistics of other vendors are implemented by 
reading and writing registers. Therefore, macros are not used.By the 
way, the MLX driver has a precedent (code snippets can be intercepted 
here).


It is not convenient for a user re-compile the DPDK to be able to get 
the ethdev byte statistics, stats are not developer/debug information, 
end user may need them. And this recompilation may not be an option for 
the distributed software.


How much performance affect it has if you enable it always?

We theoretically analyzed that being on a critical path might have a 
performance impact. Maybe the actual mountain is negligible.
And just to double check, isn't there a way to get this information from 
HW without calculating it in the driver?



OK
The compile time flags, specially after meson switch, hard to enable and 
a little hidden, it is very easy to have broken code there, that is why 
it better to prevent compile time flags as much as possible.

.

After internal analysis, you can accept your comments and remove macros.
I will fix it.

Re: [dpdk-dev] [PATCH v2] net/ice: fix wrong RSS hash update

[Yang, Qiming]

Acked-by: Qiming Yang 

> -Original Message-
> From: Wu, Wenjun1 
> Sent: 2021年3月3日 15:57
> To: dev@dpdk.org; Yang, Qiming ; Zhang, Qi Z
> 
> Cc: Wu, Wenjun1 ; sta...@dpdk.org
> Subject: [PATCH v2] net/ice: fix wrong RSS hash update
> 
> This patch change redundant judgment statements to disable RSS when users
> need to disable RSS or RSS hash function configured is not supported.
> 
> Fixes: 4717a12cfaf1 ("net/ice: initialize and update RSS based on user 
> config")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Wenjun Wu 
> 
> ---
> v2: do pf->rss_hf = 0 when rss_conf->rss_hf == 0 instead of direct removal to
> avoid unnecessary judgment.
> ---
>  drivers/net/ice/ice_ethdev.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c index
> f43b2e0b2..299162286 100644
> --- a/drivers/net/ice/ice_ethdev.c
> +++ b/drivers/net/ice/ice_ethdev.c
> @@ -4461,8 +4461,10 @@ ice_rss_hash_update(struct rte_eth_dev *dev,
>   if (status)
>   return status;
> 
> - if (rss_conf->rss_hf == 0)
> + if (rss_conf->rss_hf == 0) {
> + pf->rss_hf = 0;
>   return 0;
> + }
> 
>   /* RSS hash configuration */
>   ice_rss_hash_set(pf, rss_conf->rss_hf);
> --
> 2.25.1

Re: [dpdk-dev] [PATCH 00/14] ice: base code update

[Yang, Qiming]

Hi,

> -Original Message-
> From: Zhang, Qi Z 
> Sent: 2021年3月2日 15:24
> To: Yang, Qiming 
> Cc: dev@dpdk.org; Wang, Haiyue ; Guo, Junfeng
> ; Zhang, Qi Z 
> Subject: [PATCH 00/14] ice: base code update
> 
> Main change:
> 1. Support GTPU inner l3/l4 for FDIR
> 2. Support GTPU extention header for FDIR 3. Support switch filter (GTPU
> tunnel + IP flow) 4. couple bug fixes.
> 
> Qi Zhang (14):
>   net/ice/base: add firmware log support
>   net/ice/base: signed external device package programming
>   net/ice/base: post update double reset solution restriction
>   net/ice/base: enable GTPU inner L3/L4 for FDIR
>   net/ice/base: expose link configuration error
>   net/ice/base: enable more GTPU inner L3 fields for FDIR
>   net/ice/base: support for switch filter (GTP tunnel+IP flow)
>   net/ice/base: support GTPU IP inner IPv6 for FDIR
>   net/ice/base: fix incorrect payload indicator on PTYPE
>   net/ice/base: mark PTYPE 2 as reserved
>   net/ice/base: add code to update boost TCAM for DVM
>   net/ice/base: update GTPU EH dummy pkts for FDIR
>   net/ice/base: fix uninitialized struct
>   net/ice/base: cleanup fltr list in case of allocation issues
> 
>  drivers/net/ice/base/ice_adminq_cmd.h|  83 -
>  drivers/net/ice/base/ice_common.c|   1 +
>  drivers/net/ice/base/ice_fdir.c  | 412 ---
>  drivers/net/ice/base/ice_fdir.h  |  22 ++
>  drivers/net/ice/base/ice_flex_pipe.c | 223 ++--
>  drivers/net/ice/base/ice_flex_pipe.h |   1 +
>  drivers/net/ice/base/ice_flex_type.h |  13 +
>  drivers/net/ice/base/ice_flow.c  |   9 +-
>  drivers/net/ice/base/ice_lan_tx_rx.h |   4 +-
>  drivers/net/ice/base/ice_protocol_type.h |   8 +-
>  drivers/net/ice/base/ice_switch.c| 117 ---
>  drivers/net/ice/base/ice_type.h  |   6 +
>  drivers/net/ice/base/ice_vlan_mode.c |   7 +
>  13 files changed, 679 insertions(+), 227 deletions(-)
> 
> --
> 2.26.2

Acked-by: Qiming Yang 

Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile

[Matan Azrad]

Hi Cristian

From: Dumitrescu, Cristian
> Hi Matan,
> 
> > -Original Message-
> > From: Matan Azrad 
> > Sent: Tuesday, March 2, 2021 6:10 PM
> > To: Dumitrescu, Cristian ; Li Zhang
> > ; Dekel Peled ; Ori Kam
> > ; Slava Ovsiienko 
> > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon ;
> > Raslan Darawsheh ; m...@smartsharesystems.com;
> > ajit.khapa...@broadcom.com; Yigit, Ferruh ;
> > Singh, Jasvinder 
> > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> >
> > Hi Cristian
> >
> > Good discussion, thank you for that!
> >
> > From: Dumitrescu, Cristian
> > > Hi Matan,
> > >
> > > > -Original Message-
> > > > From: Matan Azrad 
> > > > Sent: Tuesday, March 2, 2021 12:37 PM
> > > > To: Dumitrescu, Cristian ; Li Zhang
> > > > ; Dekel Peled ; Ori Kam
> > > > ; Slava Ovsiienko 
> > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > ;
> > > > Raslan Darawsheh ; m...@smartsharesystems.com;
> > > > ajit.khapa...@broadcom.com; Yigit, Ferruh
> > > > ; Singh, Jasvinder
> > > > 
> > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile
> > > >
> > > > HI Cristian
> > > >
> > > > From: Dumitrescu, Cristian
> > > > > Hi Matan,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Matan Azrad 
> > > > > > Sent: Tuesday, March 2, 2021 7:02 AM
> > > > > > To: Dumitrescu, Cristian ; Li
> > > > > > Zhang ; Dekel Peled ; Ori
> > > > > > Kam ; Slava Ovsiienko
> > > > > > 
> > > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> > > > ;
> > > > > > Raslan Darawsheh ;
> > m...@smartsharesystems.com;
> > > > > > ajit.khapa...@broadcom.com; Yigit, Ferruh
> > > > > > ; Singh, Jasvinder
> > > > > > 
> > > > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS
> > > > > > profile
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Cristian
> > > > > >
> > > > > > Thank you for review, please see inline.
> > > > > >
> > > > > > From: Dumitrescu, Cristian
> > > > > > > > From: dev  On Behalf Of Li Zhang
> > > > > > 
> > > > > > > We had this same problem earlier for the rte_tm.h API, where
> > > > > > > people
> > > > > > asked to
> > > > > > > add support for WRED and shaper rates specified in packets
> > > > > > > to the existing
> > > > > > byte
> > > > > > > rate support. I am more than happy to support adding the
> > > > > > > same here, but please let's adopt the same solution here
> > > > > > > rather than invent a different approach.
> > > > > > >
> > > > > > > Please refer to struct rte_tm_wred_params and struct
> > > > > > rte_tm_shaper_params
> > > > > > > from rte_tm.h: the packets vs. bytes mode is explicitly
> > > > > > > specified through
> > > > > > the use
> > > > > > > of a flag called packet_mode that is added to the WRED and
> > > > > > > shaper
> > > > profile.
> > > > > > > When packet_mode is 0, the profile rates and bucket sizes
> > > > > > > are specified in bytes per second and bytes, respectively;
> > > > > > > when packet_mode is not 0, the profile rates and bucket
> > > > > > > sizes are specified in packets and packets per
> > > > > > second,
> > > > > > > respectively. The same profile parameters are used, no need
> > > > > > > to invent additional algorithms (such as srTCM - packet
> > > > > > > mode) or profile data
> > > > > > structures.
> > > > > > > Can we do the same here, please?
> > > > > >
> > > > > > This flag approach is very intuitive suggestion and it has 
> > > > > > advantages.
> > > > > >
> > > > > > The main problem with the flag approach is that it breaks ABI and 
> > > > > > API.
> > > > > > The profile structure size is changed due to a new field - ABI
> > breakage.
> > > > > > The user must initialize the flag with zero to get old
> > > > > > behavior - API
> > > > breakage.
> > > > > >
> > > > >
> > > > > The rte_mtr API is experimental, all the API functions are
> > > > > correctly marked with __rte_experimental in rte_mtr.h file, so
> > > > > we can safely change the API
> > > > and
> > > > > the ABI breakage is not applicable here. Therefore, this problem
> > > > > does not
> > > > exist,
> > > > > correct?
> > > >
> > > > Yes, but still meter is not new API and I know that a lot of user
> > > > uses it for a long time.
> > > > Forcing them to change while we have good solution that don't
> > > > force it, looks me problematic.
> > > >
> > >
> > > Not really, only 3 drivers are currently implementing this API.
> >
> > The user is not the PMD, the PMDs are the providers.
> > I'm talking about all our customers, all the current DPDK based
> > applications like OVS and others (I familiar with at least 4 ConnectX
> > customer applications) which use the meter API and I'm sure there are more
> around the world.
> >
> > > Even to these drivers, the required changes are none or extremely small:
> > as Ajit
> > > was also noting, as the default value of 0 continues to represent
> > > the
> > existing
> > > byte mode, all you have to do is make sure the new flag is set to
> > > zero in the profile params struct

Re: [dpdk-dev] [PATCH v8 2/3] ethdev: tunnel offload model

[Eli Britstein]

On 3/3/2021 4:03 PM, Ivan Malov wrote:

Hi,

Could someone please also clarify the meaning (from PMD standpoint and 
from application's standpoint) of the 64-bit field "tun_id" in 
"rte_flow_tunnel"? The current comment reads: "Tunnel identification", 
which is quite ambiguous, not to mention the fact that it simply 
expands the field's name. Does this ID have anything to do with 
VXLAN's VNI (which is 24-bit field)?


rte_flow_tunnel struct is the tunnel details communicated between the 
application and PMD when applying flows, and from the PMD to the 
application upon miss.


The fields in it are porting of the kernel's 'struct ip_tunnel_key'. See 
https://elixir.bootlin.com/linux/latest/source/include/net/ip_tunnels.h#L40


Regarding 'tun_id' - yes. In case of VXLAN tunnel it stores the VNI.



As far as I can learn from the testpmd patch series, this field gets 
printed only if it's non-zero. Hmm. A special value of sorts? Maybe 
clarify this, too?


Thank you.

On 02/03/2021 12:42, Thomas Monjalon wrote:

02/03/2021 10:22, Ivan Malov:

Hi Gregory, Eli,

On 16/10/2020 15:51, Gregory Etelson wrote:
  > Applications wishing to offload tunneled traffic are required to 
use
  > the rte_flow primitives, such as group, meta, mark, tag, and 
others to

  > model their high-level objects.  The hardware model design for

As far as I understand, the model is an abstraction of sorts, and the
quoted lines provide examples of primitives which applications would
have to use if the model did not exist.

Looking at the implementation, I don't quite discern any means to let
the application query PMD-specific values of "rte_flow_attr". In
example, the PMD may need to enforce "transfer=1" both for the "tunnel
set" rule and for "tunnel match" one. What if "group" and "priority"
values also need to be implicitly controlled by the PMD for the tunnel
offload rules?

Have you considered adding an abstraction for "rte_flow_attr" in terms
of this model?

  > The first VXLAN packet that arrives matches the rule in group 0 and
  > jumps to group 3.  In group 3 the packet will miss since there 
is no


This example considers jumping from group 0 to group 3. First of all,
it's unclear whether this model intentionally lets the application
choose group values freely (see my question above) or simply lacks an
interface to let the application use values enforced by the PMD (if
any). Secondly, given the fact that existing description of
"rte_flow_attr" does not shed any light on how groups are ordered by
default, when no JUMPs are configured (it only explains how priority
levels are ordered within the given group but not how groups are
ordered), it's unclear whether the model intentionally permits the
application to jump between arbitrary groups (in example, from 0 to 3)
and not necessarily between, say, 0 to 1. More to that, it's unclear
whether the model lets the application jump from, say, group 0 to the
very same group, 0 ("recirculation") or not. Or is the "recirculation"
is in fact the main scenario in the model? Could you please 
elaborate on

the model's expectations of groups?

Thank you.


Given the questions, I think the discussion should be concluded
(when done) with a patch updating the API description.
Thanks for the questions and clarifications to come :)

Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields

[Dmitry Kozlyuk]

2021-03-03 15:54, Stephen Hemminger:
> > +
> > +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
> > +  will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK 
> > 20.11
> > +  in order to avoid conflict with Windows Sockets headers.  
> 
> If those fields were a problem now, there might be others in future.

One I can think of is `min` and `max` macros from `windows.h`: they are used
as field names in `rte_compressdev.h` and `rte_cryptodev.h` (and more than
once have they been worked around in PMD code, see i40e and ice patches).
Do you prefer a single notice for all such conflicts we can identify now?

> Don't use src_addr and dst_addr because those are already used in 
> rte_ipv4_hdr.

Not sure what DPDK policy is: `rte_ipv4/6_hdr` use completely custom names,
while `rte_arp_hdr` uses traditional names with `arp_` prefix.
Coming from C++, I chose the former approach, but it's not a strong opinion.

> Linux and FreeBSD use:
> 
> struct ether_header
> {
>   uint8_t  ether_dhost[ETH_ALEN]; /* destination eth addr */
>   uint8_t  ether_shost[ETH_ALEN]; /* source ether addr*/
>   uint16_t ether_type;/* packet type ID field */
> } __attribute__ ((__packed__));
> 
> So why not ether_dhost/ether_shost?

Works for me, let's see what others think.

Re: [dpdk-dev] [PATCH v4] bus/pci/windows: support for PCI scan allowed and blocked lists

[Dmitry Kozlyuk]

2021-02-28 22:52, Khoa To:
> EAL -a and -b options are used to specify which PCI devices are
> explicitly allowed or blocked during PCI bus scan.  This evaluation
> is missing in the Windows implementation of rte_pci_scan.
> 
> This patch provides this missing functionality, so that apps can specify
> which NetUIO devices to ignore during PCI bus scan.
> 
> Signed-off-by: Khoa To 
> ---
> v4:
> * Fix coding style warning with unaligned comments
> v3:
> * Move the check inside pci_scan_one
> * Small change to pci_scan_one to malloc only after checks succeeded
> v2:
> * Truncate commit description lines to 75 charaters or less
> 
>  drivers/bus/pci/windows/pci.c | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)

Acked-by: Dmitry Kozlyuk 

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

[Lijun Ou]

This series add three features according to the
21.05 roadmap as well as fix some bugs.

v2->v3:
- fix some patchs title.
- delete the macro with patch[4/14].

v1->v2:
- fix the commit log for patch[8/14].
- add more commit log information for patch[13/14].
- add a fix patch[7/14] because the version will not support
  for copper phy before merge patch[8/14]. 

Chengchang Tang (4):
  net/hns3: support module EEPROM dump
  net/hns3: add more registers to dump
  net/hns3: fix HW buffer size on MTU update
  net/hns3: fix imprecise statistics

Chengwen Feng (2):
  net/hns3: implement Tx mbuf free on demand
  net/hns3: support RXD advanced layout

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

Huisong Li (5):
  net/hns3: encapsulate a port shaping interface
  net/hns3: fix device capabilities for copper media type
  net/hns3: support PF device with copper phys
  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  |   2 +
 doc/guides/nics/features/hns3_vf.ini   |   1 +
 doc/guides/rel_notes/release_21_05.rst |   6 +
 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   | 275 +
 drivers/net/hns3/hns3_rxtx.h   |  12 +
 drivers/net/hns3/hns3_rxtx_vec_neon.h  |   9 +
 drivers/net/hns3/hns3_rxtx_vec_sve.c   |   8 +
 drivers/net/hns3/hns3_stats.c  | 287 --
 drivers/net/hns3/hns3_stats.h  |  12 +-
 20 files changed, 1211 insertions(+), 198 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH V3 10/14] net/hns3: fix HW buffer size on MTU update

[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 
---
V2->V3:
- rewrite the patch title
---
 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 V3 11/14] net/hns3: remove unused parameter from func declaration

[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 V3 13/14] net/hns3: add process for MAC interrupt

[Lijun Ou]

From: Hongbo Zheng 

TNL is the abbreviation of tunnel, which means port
here. MAC TNL interrupt indicates the MAC status
report of the network port, which will be generated
when the MAC status changes.

This patch enables MAC TNL interrupt reporting, and
queries and prints the corresponding MAC status when
the interrupt is received, then clear the MAC interrupt
status. Because this interrupt uses the same interrupt
as RAS, the interrupt log is adjusted.

Signed-off-by: Hongbo Zheng 
Signed-off-by: Lijun Ou 
---
V1->V2:
- add more information for commit log
---
 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 "
+   

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

[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 | 221 ++
 1 file changed, 72 insertions(+), 149 deletions(-)

diff --git a/drivers/net/hns3/hns3_stats.c b/drivers/net/hns3/hns3_stats.c
index 87035e3..941c75f 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,24 +562,34 @@ 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;
 
-

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

[Lijun Ou]

From: Chengchang Tang 

This patch add support for dumping module EEPROM.

Signed-off-by: Chengchang Tang 
Signed-off-by: Lijun Ou 
---
V2->V3:
- add "Module EEPROM dump" feature to hns3.ini and hns3_vf.ini
- fix the release notes location with Hisilicon hns3
---
 doc/guides/nics/features/hns3.ini  |   1 +
 doc/guides/rel_notes/release_21_05.rst |   4 +
 drivers/net/hns3/hns3_cmd.h|  16 
 drivers/net/hns3/hns3_ethdev.c | 159 +
 4 files changed, 180 insertions(+)

diff --git a/doc/guides/nics/features/hns3.ini 
b/doc/guides/nics/features/hns3.ini
index ef432af..a1f5f9e 100644
--- a/doc/guides/nics/features/hns3.ini
+++ b/doc/guides/nics/features/hns3.ini
@@ -39,6 +39,7 @@ Extended stats   = Y
 Stats per queue  = Y
 FW version   = Y
 Registers dump   = Y
+Module EEPROM dump   = Y
 Multiprocess aware   = Y
 Linux= Y
 ARMv8= Y
diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst
index ca28d05..b82ea82 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -55,6 +55,10 @@ New Features
  Also, make sure to start the actual text at the margin.
  ===
 
+* **Updated Hisilicon hns3 driver.**
+
+  * Added support for module EEPROM dumping.
+
 * **Updated Wangxun txgbe driver.**
 
   * Added support for txgbevf PMD.
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_MI

[dpdk-dev] [PATCH V3 07/14] net/hns3: fix device capabilities for copper media type

[Lijun Ou]

From: Huisong Li 

The configuration operation for PHY is implemented by firmware. And
a capability flag will be report to driver, which means the firmware
supports the PHY driver.  However, the current implementation only
supports obtaining the capability bit, but some basic functions of
copper ports in driver, such as, the query of link status and link
info, are not supported.

Therefore, it is necessary for driver to set the copper capability
bit to zero when the firmware supports the configuration of the PHY.

Fixes: 438752358158 ("net/hns3: get device capability from firmware")
Fixes: 95e50325864c ("net/hns3: support copper media type")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 drivers/net/hns3/hns3_cmd.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 32cd56b..ec34615 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -423,8 +423,14 @@ static void hns3_parse_capability(struct hns3_hw *hw,
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_PTP_B, 1);
if (hns3_get_bit(caps, HNS3_CAPS_TX_PUSH_B))
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_TX_PUSH_B, 1);
+   /*
+* Currently, the query of link status and link info on copper ports
+* are not supported. So it is necessary for driver to set the copper
+* capability bit to zero when the firmware supports the configuration
+* of the PHY.
+*/
if (hns3_get_bit(caps, HNS3_CAPS_PHY_IMP_B))
-   hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 1);
+   hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 0);
if (hns3_get_bit(caps, HNS3_CAPS_TQP_TXRX_INDEP_B))
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_INDEP_TXRX_B, 1);
if (hns3_get_bit(caps, HNS3_CAPS_STASH_B))
-- 
2.7.4

[dpdk-dev] [PATCH V3 03/14] net/hns3: implement Tx mbuf free on demand

[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 
---
V2->V3:
- rewrite the patch title according to Ferruh Yigit's advice
---
 doc/guides/nics/features/hns3.ini  |  1 +
 doc/guides/nics/features/hns3_vf.ini   |  1 +
 doc/guides/rel_notes/release_21_05.rst |  1 +
 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(+)

diff --git a/doc/guides/nics/features/hns3.ini 
b/doc/guides/nics/features/hns3.ini
index a1f5f9e..3aeea8e 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 b82ea82..15e016e 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -58,6 +58,7 @@ New Features
 * **Updated Hisilicon hns3 driver.**
 
   * Added support for module EEPROM dumping.
+  * Added support for freeing Tx mbuf on demand.
 
 * **Updated Wangxun txgbe driver.**
 
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 == hn

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

[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 V3 06/14] net/hns3: encapsulate a port shaping interface

[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 V3 05/14] net/hns3: add imissed packet stats

[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 777d36a..87035e3 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 V3 08/14] net/hns3: support PF device with copper phys

[Lijun Ou]

From: Huisong Li 

The normal operation of devices with copper phys 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 PF device with copper phys based on the capability bit.
If supported, the driver set a flag indicating that the firmware
takes over the PHY, and then the firmware initializes the PHY.

This patch supports the query of link status and link info, and
existing basic features for PF device with copper phys.

Signed-off-by: Huisong Li 
Signed-off-by: Lijun Ou 
---
V1->V2:
- rewrite commit log
---
 doc/guides/rel_notes/release_21_05.rst |   1 +
 drivers/net/hns3/hns3_cmd.c|   8 +--
 drivers/net/hns3/hns3_cmd.h|  37 +++
 drivers/net/hns3/hns3_ethdev.c | 115 +++--
 drivers/net/hns3/hns3_ethdev.h |   5 ++
 5 files changed, 153 insertions(+), 13 deletions(-)

diff --git a/doc/guides/rel_notes/release_21_05.rst 
b/doc/guides/rel_notes/release_21_05.rst
index 15e016e..23f7f0b 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -59,6 +59,7 @@ New Features
 
   * Added support for module EEPROM dumping.
   * Added support for freeing Tx mbuf on demand.
+  * Added support for copper port in Kunpeng930.
 
 * **Updated Wangxun txgbe driver.**
 
diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index ec34615..32cd56b 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -423,14 +423,8 @@ static void hns3_parse_capability(struct hns3_hw *hw,
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_PTP_B, 1);
if (hns3_get_bit(caps, HNS3_CAPS_TX_PUSH_B))
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_TX_PUSH_B, 1);
-   /*
-* Currently, the query of link status and link info on copper ports
-* are not supported. So it is necessary for driver to set the copper
-* capability bit to zero when the firmware supports the configuration
-* of the PHY.
-*/
if (hns3_get_bit(caps, HNS3_CAPS_PHY_IMP_B))
-   hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 0);
+   hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_COPPER_B, 1);
if (hns3_get_bit(caps, HNS3_CAPS_TQP_TXRX_INDEP_B))
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_INDEP_TXRX_B, 1);
if (hns3_get_bit(caps, HNS3_CAPS_STASH_B))
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) {
+   

[dpdk-dev] [PATCH V3 09/14] net/hns3: support RXD advanced layout

[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 fields.
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 V3 12/14] net/hns3: fix memory leakage for mbuf

[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 V3 04/14] net/hns3: add Rx and Tx bytes stats

[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.

Signed-off-by: Min Hu (Connor) 
Signed-off-by: Lijun Ou 
---
V2->V3:
- remote the macro RTE_LIBRTE_HNS3_PMD_SOFT_COUNTER
- update the commit log
---
 drivers/net/hns3/hns3_rxtx.c  | 16 
 drivers/net/hns3/hns3_rxtx_vec_neon.h |  9 +
 drivers/net/hns3/hns3_rxtx_vec_sve.c  |  8 
 drivers/net/hns3/hns3_stats.c | 18 ++
 4 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 5e79177..2099006 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2181,6 +2181,9 @@ 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);
 
+   /* Increment bytes counter  */
+   rxq->basic_stats.bytes += rxm->pkt_len;
+
rx_pkts[nb_rx++] = rxm;
continue;
 pkt_err:
@@ -2401,6 +2404,9 @@ hns3_recv_scattered_pkts(void *rx_queue,
   cksum_err);
hns3_rxd_to_vlan_tci(rxq, first_seg, l234_info, &rxd);
 
+   /* Increment bytes counter */
+   rxq->basic_stats.bytes += first_seg->pkt_len;
+
rx_pkts[nb_rx++] = first_seg;
first_seg = NULL;
continue;
@@ -3516,6 +3522,11 @@ 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);
+
+   /* Increment bytes counter */
+   uint32_t j;
+   for (j = 0; j < PER_LOOP_NUM; j++)
+   txq->basic_stats.bytes += pkts[i + j]->pkt_len;
}
if (unlikely(leftover > 0)) {
for (i = 0; i < leftover; i++) {
@@ -3523,6 +3534,9 @@ hns3_tx_fill_hw_ring(struct hns3_tx_queue *txq,
 pkts + mainpart + i);
hns3_tx_setup_1bd(txdp + mainpart + i,
  pkts + mainpart + i);
+
+   /* Increment bytes counter */
+   txq->basic_stats.bytes += pkts[mainpart + i]->pkt_len;
}
}
 }
@@ -3661,6 +3675,8 @@ 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));
 
+   /* Increment bytes counter */
+   txq->basic_stats.bytes += tx_pkt->pkt_len;
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..68f098f 100644
--- a/drivers/net/hns3/hns3_rxtx_vec_neon.h
+++ b/drivers/net/hns3/hns3_rxtx_vec_neon.h
@@ -61,6 +61,9 @@ 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;
+
+   /* Increment bytes counter */
+   txq->basic_stats.bytes += (*tx_pkts)->pkt_len;
}
 
nb_commit -= n;
@@ -72,6 +75,9 @@ 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;
+
+   /* Increment bytes counter */
+   txq->basic_stats.bytes += (*tx_pkts)->pkt_len;
}
 
next_to_use += nb_commit;
@@ -116,6 +122,9 @@ 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);
+
+   /* Increment bytes counter */
+   rxq->basic_stats.bytes += pkt->pkt_len;
}
 
return retcode;
diff --git a/drivers/net/hns3/hns3_rxtx_vec_sve.c 
b/drivers/net/hns3/hns3_rxtx_vec_sve.c
index b02bae7..2a22a1a 100644
--- a/drivers/net/hns3/hns3_rxtx_vec_sve.c
+++ b/drivers/net/hns3/hns3_rxtx_vec_sve.c
@@ -58,6 +58,9 @@ hns3_desc_parse_field_sve(struct hns3_rx_queue *rxq,
if (likely(key->bd_base_info[i] & BIT(HNS3_RXD_L3L4P_B)))
hns3_rx_set_cksum_flag(rx_pkts[i],
rx_pkts[i]->packet_type, cksum_err);
+
+   /* Increment bytes counter */
+   rxq->basic_stats.bytes += rx_pkts[i]->