RE: [PATCH v3] raw/ifpga: fix pthread cannot join

2022-01-21 Thread Zhang, Tianfei



> -Original Message-
> From: Stephen Hemminger 
> Sent: Thursday, January 20, 2022 11:47 PM
> To: Huang, Wei 
> Cc: dev@dpdk.org; Xu, Rosen ; Zhang, Qi Z
> ; sta...@dpdk.org; Zhang, Tianfei
> ; Yigit, Ferruh 
> Subject: Re: [PATCH v3] raw/ifpga: fix pthread cannot join
> 
> On Thu, 20 Jan 2022 00:58:14 -0500
> Wei Huang  wrote:
> 
> > diff --git a/drivers/raw/ifpga/ifpga_rawdev.c
> > b/drivers/raw/ifpga/ifpga_rawdev.c
> > index 8d9db58..2bc569b 100644
> > --- a/drivers/raw/ifpga/ifpga_rawdev.c
> > +++ b/drivers/raw/ifpga/ifpga_rawdev.c
> > @@ -497,7 +497,7 @@ static int set_surprise_link_check_aer(
> > int gsd_enable, ret;
> >  #define MS 1000
> >
> > -   while (1) {
> > +   while (ifpga_monitor_start) {
> 
> This will work on x86 CPU but not on CPU's with weak memory ordering like
> ARM.
> 
> You need to use atomic_builtin when accessing a flag shared between threads
> that is not being protected by a lock.

We submitted a v5 patch for your suggestion, but got a " coding style issues" 
which said that: 
Warning in drivers/raw/ifpga/ifpga_rawdev.c:
Using rte_atomicNN_xxx

We look at the devtools/checkpatches.sh script, it mentioned that rte_atomic 
APIs are forbidden.

ifpga_monitor_start just a flags to enable and disable the threads not share 
with threads. When the driver init it will start the thread, 
when the driver remove it want to stop the thread. I don't think it will has a 
concurrency issue on this scenario.





[RFC] mempool: cache preparation

2022-01-21 Thread Morten Brørup
Some drivers bypass the mbuf/mempool library functions, to manipulate the 
mempool cache directly for improved performance.

Specifically, the AVX512 implementation of some of the Intel PMDs copy an array 
of objects from the cache to a field in an array of some structure, i.e. it is 
not a 1:1 memcpy. This method avoids having to copy the array of pointers into 
a temporary array before copying them into the fields of the target array, and 
thus improves performance and reduces CPU cache pollution.

For such purposes, the mempool API could provide functions to prepare the 
mempool cache for a direct access operation, and commit the transaction:
1. Prepare the cache for getting N objects directly from the objs array. This 
function returns the address of the position in the cache array, from where the 
objects can be read, or NULL if failed.
2. Commit after getting the N objects.
3. Prepare the cache for putting N objects directly into the objs array. This 
function returns the address of the position in the cache array, to where the 
objects can be written, or NULL if failed.
4. Commit after putting the N objects.

The functions only need to support getting/putting exactly N objects; i.e. the 
"prepare" functions do not need return a value indicating some number less than 
N is available. Likewise, the "commit" functions do not need to support any N 
other than the N in the preceding "prepare" function.

This API extension would provide a clean interface to directly access the 
mempool cache with high performance, so copy-pasting the mempool's cache 
handling logic can be avoided, and bugs like [1] would not survive.

Would this be useful?

[1]: https://bugs.dpdk.org/show_bug.cgi?id=923


Med venlig hilsen / Kind regards,
-Morten Brørup



Re: [PATCH v2 1/1] mempool: implement index-based per core cache

2022-01-21 Thread Bruce Richardson
On Fri, Jan 21, 2022 at 06:01:23AM +, Honnappa Nagarahalli wrote:
> 
> > 
> > +CC Beilei as i40e maintainer
> > 
> > > From: Dharmik Thakkar [mailto:dharmik.thak...@arm.com] Sent:
> > > Thursday, 13 January 2022 06.37
> > >
> > > Current mempool per core cache implementation stores pointers to
> > > mbufs On 64b architectures, each pointer consumes 8B This patch
> > > replaces it with index-based implementation, where in each buffer is
> > > addressed by (pool base address + index) It reduces the amount of
> > > memory/cache required for per core cache
> > >
> > > L3Fwd performance testing reveals minor improvements in the cache
> > > performance (L1 and L2 misses reduced by 0.60%) with no change in
> > > throughput
> > >
> > > Suggested-by: Honnappa Nagarahalli 
> > > Signed-off-by: Dharmik Thakkar  Reviewed-by:
> > > Ruifeng Wang  --- lib/mempool/rte_mempool.h
> > > | 150 +-
> > > lib/mempool/rte_mempool_ops_default.c |   7 ++ 2 files changed, 156
> > > insertions(+), 1 deletion(-)
> > >
> > > diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
> > > index 1e7a3c15273c..f2403fbc97a7 100644 ---
> > > a/lib/mempool/rte_mempool.h +++ b/lib/mempool/rte_mempool.h @@ -50,6
> > > +50,10 @@ #include  #include 
> > >
> > > +#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE +#include 
> > > +#endif + #include "rte_mempool_trace_fp.h"
> > >
> > >  #ifdef __cplusplus @@ -239,6 +243,9 @@ struct rte_mempool { int32_t
> > >  ops_index;
> > >
> > >   struct rte_mempool_cache *local_cache; /**< Per-lcore local cache
> > >   */ +#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE +void
> > >   *pool_base_value; /**< Base value to calculate indices */ +#endif
> > >
> > >   uint32_t populated_size; /**< Number of populated objects.
> > >   */ struct rte_mempool_objhdr_list elt_list; /**< List of objects in
> > >   pool */ @@ -1314,7 +1321,22 @@ rte_mempool_cache_flush(struct
> > >   rte_mempool_cache *cache, if (cache == NULL || cache->len == 0)
> > >   return; rte_mempool_trace_cache_flush(cache, mp); + +#ifdef
> > >   RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE +   unsigned int i; +
> > >   unsigned int cache_len = cache->len; +  void
> > >   *obj_table[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; +   void *base_value =
> > >   mp->pool_base_value; +  uint32_t *cache_objs = (uint32_t *)
> > >   cache->objs;
> > 
> > Hi Dharmik and Honnappa,
> > 
> > The essence of this patch is based on recasting the type of the objs
> > field in the rte_mempool_cache structure from an array of pointers to
> > an array of uint32_t.
> > 
> > However, this effectively breaks the ABI, because the rte_mempool_cache
> > structure is public and part of the API.
> The patch does not change the public structure, the new member is under
> compile time flag, not sure how it breaks the ABI.
> 
> > 
> > Some drivers [1] even bypass the mempool API and access the
> > rte_mempool_cache structure directly, assuming that the objs array in
> > the cache is an array of pointers. So you cannot recast the fields in
> > the rte_mempool_cache structure the way this patch requires.
> IMO, those drivers are at fault. The mempool cache structure is public
> only because the APIs are inline. We should still maintain modularity and
> not use the members of structures belonging to another library directly.
> A similar effort involving rte_ring was not accepted sometime back [1]
> 
> [1]
> http://inbox.dpdk.org/dev/dbapr08mb5814907968595ee56f5e20a798...@dbapr08mb5814.eurprd08.prod.outlook.com/
> 
> > 
> > Although I do consider bypassing an API's accessor functions "spaghetti
> > code", this driver's behavior is formally acceptable as long as the
> > rte_mempool_cache structure is not marked as internal.
> > 
> > I really liked your idea of using indexes instead of pointers, so I'm
> > very sorry to shoot it down. :-(
> > 
> > [1]: E.g. the Intel i40e PMD,
> > http://code.dpdk.org/dpdk/latest/source/drivers/net/i40e/i40e_rxtx_vec_avx
> > 512.c#L25
> It is possible to throw an error when this feature is enabled in this
> file. Alternatively, this PMD could implement the code for index based
> mempool.
>
Yes, it can implement it, and if this model get put in mempool it probably
will [even if it's just a fallback to the mempool code in that case].

However, I would object to adding in this model in the library right now if it
cannot be proved to show some benefit in a realworld case. As I understand
it, the only benefit seen has been in unit test cases? I want to ensure
that for any perf improvements we put in that they have some real-world
applicabilty - the amoung of applicability will depend on the scope and
impact - and by the same token that we don't reject simplifications or
improvements on the basis that they *might* cause issues, if all perf data
fails to show any problem.

So for this patch, can we get some perf numbers for an app where it does
show the value of it? L3fwd is a very trivial app, and as such is usually
fairly reliable in sh

RE: [EXT] Re: [PATCH v3 21/29] crypto/cnxk: add more info on command timeout

2022-01-21 Thread Akhil Goyal


> 17/12/2021 10:20, Anoob Joseph:
> > Print more info when command timeout happens. Print software and
> > hardware queue information.
> >
> > Signed-off-by: Anoob Joseph 
> > Signed-off-by: Tejasree Kondoj 
> > ---
> > +void
> > +cnxk_cpt_dump_on_err(struct cnxk_cpt_qp *qp)
> > +{
> > +   struct pending_queue *pend_q = &qp->pend_q;
> > +   uint64_t inflight, enq_ptr, deq_ptr, insts;
> > +   union cpt_lf_q_inst_ptr inst_ptr;
> > +   union cpt_lf_inprog lf_inprog;
> > +
> > +   plt_print("Lcore ID: %d, LF/QP ID: %d", rte_lcore_id(), qp->lf.lf_id);
> > +   plt_print("");
> > +   plt_print("S/w pending queue:");
> > +   plt_print("\tHead: %ld", pend_q->head);
> > +   plt_print("\tTail: %ld", pend_q->tail);
> > +   plt_print("\tMask: 0x%lx", pend_q->pq_mask);
> > +   plt_print("\tInflight count: %ld",
> > + pending_queue_infl_cnt(pend_q->head, pend_q->tail,
> > +pend_q->pq_mask));
> > +
> > +   plt_print("");
> > +   plt_print("H/w pending queue:");
> > +
> > +   lf_inprog.u = plt_read64(qp->lf.rbase + CPT_LF_INPROG);
> > +   inflight = lf_inprog.s.inflight;
> > +   plt_print("\tInflight in engines: %ld", inflight);
> > +
> > +   inst_ptr.u = plt_read64(qp->lf.rbase + CPT_LF_Q_INST_PTR);
> > +
> > +   enq_ptr = inst_ptr.s.nq_ptr;
> > +   deq_ptr = inst_ptr.s.dq_ptr;
> > +
> > +   if (enq_ptr >= deq_ptr)
> > +   insts = enq_ptr - deq_ptr;
> > +   else
> > +   insts = (enq_ptr + pend_q->pq_mask + 1 + 320 + 40) - deq_ptr;
> > +
> > +   plt_print("\tNQ ptr: 0x%lx", enq_ptr);
> > +   plt_print("\tDQ ptr: 0x%lx", deq_ptr);
> > +   plt_print("Insts waiting in CPT: %ld", insts);
> > +
> > +   plt_print("");
> > +   roc_cpt_afs_print(qp->lf.roc_cpt);
> > +}
> 
> This functions is wrong. You cannot print 64-bit values with %l.
> In 32-bit mode, compilation will fail.
> Please use PRIx64.
> 
> Note: this mistake is warned by the script devtools/checkpatches.sh
>   Warning in drivers/crypto/cnxk/cnxk_cryptodev_ops.c:
>   Using %l format, prefer %PRI*64 if type is [u]int64_t
I believe there is something wrong in the reporting;
it said 1 warning which is for spell check of head
and in the end a line is added for another warning.
I skipped this issue as it was a false positive for spelling. Did not see the 
last line.

WARNING:TYPO_SPELLING: 'tHead' may be misspelled - perhaps 'thread'?
#157: FILE: drivers/crypto/cnxk/cnxk_cryptodev_ops.c:718:
+   plt_print(" Head: %ld", pend_q->head);

total: 0 errors, 1 warnings, 84 lines checked
^^  
Warning in drivers/crypto/cnxk/cnxk_cryptodev_ops.c:
Using %l format, prefer %PRI*64 if type is [u]int64_t

> 
> I will wait for the next-crypto tree to be fixed.
> 
Following changes are mage in this patch on crypto tree.
diff --git a/drivers/crypto/cnxk/cnxk_cryptodev_ops.c 
b/drivers/crypto/cnxk/cnxk_cryptodev_ops.c
index 0ce54d7bf0..67a2d9b08e 100644
--- a/drivers/crypto/cnxk/cnxk_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cnxk_cryptodev_ops.c
@@ -715,10 +715,10 @@ cnxk_cpt_dump_on_err(struct cnxk_cpt_qp *qp)
plt_print("Lcore ID: %d, LF/QP ID: %d", rte_lcore_id(), qp->lf.lf_id);
plt_print("");
plt_print("S/w pending queue:");
-   plt_print("\tHead: %ld", pend_q->head);
-   plt_print("\tTail: %ld", pend_q->tail);
-   plt_print("\tMask: 0x%lx", pend_q->pq_mask);
-   plt_print("\tInflight count: %ld",
+   plt_print("\tHead: %"PRIu64"", pend_q->head);
+   plt_print("\tTail: %"PRIu64"", pend_q->tail);
+   plt_print("\tMask: 0x%"PRIx64"", pend_q->pq_mask);
+   plt_print("\tInflight count: %"PRIu64"",
  pending_queue_infl_cnt(pend_q->head, pend_q->tail,
 pend_q->pq_mask));

@@ -727,7 +727,7 @@ cnxk_cpt_dump_on_err(struct cnxk_cpt_qp *qp)

lf_inprog.u = plt_read64(qp->lf.rbase + CPT_LF_INPROG);
inflight = lf_inprog.s.inflight;
-   plt_print("\tInflight in engines: %ld", inflight);
+   plt_print("\tInflight in engines: %"PRIu64"", inflight);

inst_ptr.u = plt_read64(qp->lf.rbase + CPT_LF_Q_INST_PTR);

@@ -739,9 +739,9 @@ cnxk_cpt_dump_on_err(struct cnxk_cpt_qp *qp)
else
insts = (enq_ptr + pend_q->pq_mask + 1 + 320 + 40) - deq_ptr;

-   plt_print("\tNQ ptr: 0x%lx", enq_ptr);
-   plt_print("\tDQ ptr: 0x%lx", deq_ptr);
-   plt_print("Insts waiting in CPT: %ld", insts);
+   plt_print("\tNQ ptr: 0x%"PRIx64"", enq_ptr);
+   plt_print("\tDQ ptr: 0x%"PRIx64"", deq_ptr);
+   plt_print("Insts waiting in CPT: %"PRIu64"", insts);

plt_print("");
roc_cpt_afs_print(qp->lf.roc_cpt);


Re: [PATCH v6 00/26] Net/SPNIC: support SPNIC into DPDK 22.03

2022-01-21 Thread Yanling Song
On Wed, 19 Jan 2022 16:56:52 +
Ferruh Yigit  wrote:

> On 12/30/2021 6:08 AM, Yanling Song wrote:
> > The patchsets introduce SPNIC driver for Ramaxel's SPNxx serial NIC
> > cards into DPDK 22.03. Ramaxel Memory Technology is a company which
> > supply a lot of electric products: storage, communication, PCB...
> > SPNxxx is a serial PCIE interface NIC cards:
> > SPN110: 2 PORTs *25G
> > SPN120: 4 PORTs *25G
> > SPN130: 2 PORTs *100G
> >   
> 
> Hi Yanling,
> 
> As far as I can see hnic (from Huawei) and this spnic drivers are
> alike, what is the relation between these two?
> 
It is hard to create a brand new driver from scratch, so we referenced
to hinic driver when developing spnic.

> > The following is main features of our SPNIC:
> > - TSO
> > - LRO
> > - Flow control
> > - SR-IOV(Partially supported)
> > - VLAN offload
> > - VLAN filter
> > - CRC offload
> > - Promiscuous mode
> > - RSS
> > 
> > v6->v5, No real changes:
> > 1. Move the fix of RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS from patch 26
> > to patch 2; 2. Change the description of patch 26.
> > 
> > v5->v4:
> > 1. Add prefix "spinc_" for external functions;
> > 2. Remove temporary MACRO: RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS
> > 3. Do not use void* for keeping the type information
> > 
> > v3->v4:
> > 1. Fix ABI test failure;
> > 2. Remove some descriptions in spnic.rst.
> > 
> > v2->v3:
> > 1. Fix clang compiling failure.
> > 
> > v1->v2:
> > 1. Fix coding style issues and compiling failures;
> > 2. Only support linux in meson.build;
> > 3. Use CLOCK_MONOTONIC_COARSE instead of
> > CLOCK_MONOTONIC/CLOCK_MONOTONIC_RAW; 4. Fix time_before();
> > 5. Remove redundant checks in spnic_dev_configure();
> > 
> > Yanling Song (26):
> >drivers/net: introduce a new PMD driver
> >net/spnic: initialize the HW interface
> >net/spnic: add mbox message channel
> >net/spnic: introduce event queue
> >net/spnic: add mgmt module
> >net/spnic: add cmdq and work queue
> >net/spnic: add interface handling cmdq message
> >net/spnic: add hardware info initialization
> >net/spnic: support MAC and link event handling
> >net/spnic: add function info initialization
> >net/spnic: add queue pairs context initialization
> >net/spnic: support mbuf handling of Tx/Rx
> >net/spnic: support Rx congfiguration
> >net/spnic: add port/vport enable
> >net/spnic: support IO packets handling
> >net/spnic: add device configure/version/info
> >net/spnic: support RSS configuration update and get
> >net/spnic: support VLAN filtering and offloading
> >net/spnic: support promiscuous and allmulticast Rx modes
> >net/spnic: support flow control
> >net/spnic: support getting Tx/Rx queues info
> >net/spnic: net/spnic: support xstats statistics
> >net/spnic: support VFIO interrupt
> >net/spnic: support Tx/Rx queue start/stop
> >net/spnic: add doc infrastructure
> >net/spnic: fixes unsafe C style code  
> 
> <...>



Re: [PATCH v6 02/26] net/spnic: initialize the HW interface

2022-01-21 Thread Yanling Song
On Wed, 19 Jan 2022 17:05:14 +
Ferruh Yigit  wrote:

> On 12/30/2021 6:08 AM, Yanling Song wrote:
> > Add HW interface registers and initialize the HW
> > interface.
> > 
> > Signed-off-by: Yanling Song   
> 
> <...>
> 
> > diff --git a/drivers/net/spnic/base/spnic_hwdev.h
> > b/drivers/net/spnic/base/spnic_hwdev.h new file mode 100644
> > index 00..c89a4fa840
> > --- /dev/null
> > +++ b/drivers/net/spnic/base/spnic_hwdev.h
> > @@ -0,0 +1,29 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2021 Ramaxel Memory Technology, Ltd
> > + */
> > +
> > +#ifndef _SPNIC_HWDEV_H_
> > +#define _SPNIC_HWDEV_H_
> > +
> > +#include 
> > +  
> 
> Why is this header required in this file?
> 
It is a mistake. Will be removed in the next version.
> 
> <...>
> 
> > +#ifdef SPNIC_RELEASE
> > +static int wait_until_doorbell_flush_states(struct spnic_hwif
> > *hwif,
> > +   enum
> > spnic_doorbell_ctrl states) +{
> > +   enum spnic_doorbell_ctrl db_ctrl;
> > +   u32 cnt = 0;
> > +
> > +   if (!hwif)
> > +   return -EINVAL;
> > +
> > +   while (cnt < SPNIC_WAIT_DOORBELL_AND_OUTBOUND_TIMEOUT) {
> > +   db_ctrl = spnic_get_doorbell_ctrl_status(hwif);
> > +   if (db_ctrl == states)
> > +   return 0;
> > +
> > +   rte_delay_ms(1);
> > +   cnt++;
> > +   }
> > +
> > +   return -EFAULT;
> > +}
> > +#endif  
> 
> What is this 'SPNIC_RELEASE' macro and why it exists?
> 
> Please get rid of all all compile time macros, if the code is not
> required you can delete it while upstreaming.

OK. 'SPNIC_RELEASE' will be removed. 

> 
> <...>
> 
> >   struct spnic_nic_dev {
> > +   struct spnic_hwdev *hwdev; /* Hardware device */
> > +
> > +   struct spnic_txq **txqs;
> > +   struct spnic_rxq **rxqs;
> > +   struct rte_mempool *cpy_mpool;
> > +
> > +   u16 num_sqs;
> > +   u16 num_rqs;
> > +   u16 max_sqs;
> > +   u16 max_rqs;
> > +
> > +   u16 rx_buff_len;
> > +   u16 mtu_size;
> > +
> > +   u16 rss_state;
> > +   u8 num_rss;
> > +   u8 rsvd0;
> > +
> > +   u32 rx_mode;
> > +   u8 rx_queue_list[SPNIC_MAX_QUEUE_NUM];
> > +   rte_spinlock_t queue_list_lock;
> > +   pthread_mutex_t rx_mode_mutex;
> > +
> > +   u32 default_cos;
> > +   u32 rx_csum_en;
> > +
> > u32 dev_status;
> > +
> > +   bool pause_set;
> > +   pthread_mutex_t pause_mutuex;
> > +
> > +   struct rte_ether_addr default_addr;
> > +   struct rte_ether_addr *mc_list;
> > +
> > char dev_name[SPNIC_DEV_NAME_LEN];
> > +   u32 vfta[SPNIC_VFTA_SIZE]; /* VLAN bitmap */
> >   };  
> 
> 
> Most of these additions to the struct is not used at all, can you
> please add them when they are used?

Ok. Will be changed in the next version.



Re: [PATCH v6 05/26] net/spnic: add mgmt module

2022-01-21 Thread Yanling Song
On Wed, 19 Jan 2022 17:22:51 +
Ferruh Yigit  wrote:

> On 12/30/2021 6:08 AM, Yanling Song wrote:
> > Mgmt module manage the message gerenated from the hardware.
> > This patch implements mgmt module initialization, related event
> > processing and message command definition.
> > 
> > Signed-off-by: Yanling Song   
> 
> <...>
> 
> > +static void spnic_get_port_link_info(u8 link_state, struct
> > rte_eth_link *link) +{
> > +   if (!link_state) {
> > +   link->link_status = ETH_LINK_DOWN;
> > +   link->link_speed = ETH_SPEED_NUM_NONE;
> > +   link->link_duplex = ETH_LINK_HALF_DUPLEX;
> > +   link->link_autoneg = ETH_LINK_FIXED;
> > +   }  
> 
> The driver is using deprecated macros. If you can rebase on top of
> latest next-net, you will get the warnings.
> 
> Since it is hard to continue with bunch of build errors, I will wait
> for next version and can continue the reviews with it.

Thanks for pointing it out. Will use new macros to replace the old ones
in the next version.


Re: [PATCH v6 09/26] net/spnic: support MAC and link event handling

2022-01-21 Thread Yanling Song
On Wed, 19 Jan 2022 17:26:47 +
Ferruh Yigit  wrote:

> On 12/30/2021 6:08 AM, Yanling Song wrote:
> > This commit adds interfaces to add/remove MAC addresses
> > and registers related ops to struct eth_dev_ops. Furthermore,
> > this commit adds callback to handle link events.
> >   
> 
> The patch also adds the VF dev_ops.
> 
> It would be more clear to support PF first and add mbox support and
> VF later. But VF support is crept into the code from early patches, I
> assume that is because the driver is already complete and spliting it
> is hard at this stage..
> 
Yes. it is.

> Similarly the primary/secondary support seems spread through the
> patches, hard to separate the feature.
> 
> 
> Above are sign of the patches are not split logically which makes
> harder to review them and detect any issues, and future fixes
> references won't be clear.
> 
> If you can clarify the split more, that would be great but I can see
> it is hard with an existing driver.
> 
Sorry for the inconvenient. Will split the patches clearly in the next
version. 

> > Signed-off-by: Yanling Song   
> 



Re: [PATCH] config/cn10k: align mempool elements to 128 bytes

2022-01-21 Thread Jerin Jacob
On Thu, Jan 20, 2022 at 3:21 PM Jerin Jacob  wrote:
>
> On Tue, Dec 14, 2021 at 2:53 PM Ruifeng Wang  wrote:
> >
> > > -Original Message-
> > > From: pbhagavat...@marvell.com 
> > > Sent: Monday, December 13, 2021 7:06 PM
> > > To: jer...@marvell.com; Jan Viktorin ; Ruifeng
> > > Wang ; Bruce Richardson
> > > 
> > > Cc: dev@dpdk.org; Pavan Nikhilesh 
> > > Subject: [PATCH] config/cn10k: align mempool elements to 128 bytes
> > >
> > > From: Pavan Nikhilesh 
> > >
> > > Mempool elements are by default aligned to CACHELINE_SIZE.
> > > In CN10K cacheline size is 64B but the RoC requires buffers to be aligned 
> > > to
> > > 128B.
> > > Set RTE_MEMPOOL_ALIGN to 128 to force mempool buffers to be aligned
> > > 128 bytes.
> > >
> > > Signed-off-by: Pavan Nikhilesh 
> > > ---
> > >  config/arm/meson.build | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > > 213324d262..33afe1a9ad 100644
> > > --- a/config/arm/meson.build
> > > +++ b/config/arm/meson.build
> > > @@ -276,7 +276,8 @@ soc_cn10k = {
> > >  'implementer' : '0x41',
> > >  'flags': [
> > >  ['RTE_MAX_LCORE', 24],
> > > -['RTE_MAX_NUMA_NODES', 1]
> > > +['RTE_MAX_NUMA_NODES', 1],
> > > +['RTE_MEMPOOL_ALIGN', 128]
> > >  ],
> > >  'part_number': '0xd49',
> > >  'extra_march_features': ['crypto'],
> > > --
> > > 2.17.1
> >
> > Reviewed-by: Ruifeng Wang 
>
> Applied to dpdk-next-net-mrvl/for-next-net. Thanks

As per @Ferruh Yigit  suggestion, This patch will be taken through the
main tree.
I changed state as New and Delegate as @Thomas Monjalon for this patch in pw.

>
>
> Added
> Fixes: 1b4c86a721c9 ("config/arm: add Marvell CN10K")
> Cc: sta...@dpdk.org
> >


Re: [PATCH v6 25/26] net/spnic: add doc infrastructure

2022-01-21 Thread Yanling Song
On Wed, 19 Jan 2022 17:27:56 +
Ferruh Yigit  wrote:

> On 12/30/2021 6:09 AM, Yanling Song wrote:
> > This patch adds doc infrastructure for spnic PMD driver.
> > 
> > Signed-off-by: Yanling Song   
> 
> <...>
> 
> > diff --git a/doc/guides/nics/spnic.rst b/doc/guides/nics/spnic.rst
> > new file mode 100644
> > index 00..fd04178f8a
> > --- /dev/null
> > +++ b/doc/guides/nics/spnic.rst
> > @@ -0,0 +1,55 @@
> > +..  SPDX-License-Identifier: BSD-3-Clause
> > +Copyright(c) 2021 Ramaxel Memory Technology, Ltd
> > +
> > +
> > +SPNIC Poll Mode Driver
> > +==
> > +
> > +The spnic PMD (**librte_net_spnic**) provides poll mode driver
> > support +for 25Gbps/100Gbps SPNxxx Network Adapters.
> > +  
> 
> Can you please provide more information to the device, and add a link
> to the product page?
> 
More information will be supplied in the next version. But the web page
is still under construction.

> > +
> > +Features
> > +
> > +
> > +- Multiple queues for TX and RX
> > +- Receiver Side Scaling??RSS??
> > +- RSS supports IPv4, IPv6, TCPv4, TCPv6, UDPv4 and UDPv6, use
> > inner type for VXLAN as default +- MAC/VLAN filtering
> > +- Checksum offload
> > +- TSO offload
> > +- LRO offload
> > +- Promiscuous mode
> > +- Port hardware statistics
> > +- Link state information
> > +- Link flow control(pause frame)
> > +- Scattered and gather for TX and RX
> > +- SR-IOV - Partially supported VFIO only
> > +- VLAN filter and VLAN offload
> > +- Allmulticast mode
> > +- MTU update
> > +- Unicast MAC filter
> > +- Multicast MAC filter
> > +- Set Link down or up
> > +- FW version
> > +- Multi arch support: x86_64, ARMv8.  
> 
> 
> Please build this list in each patch as these features are added.
> So have the base documentation in first patch, later as above
> features added update this file in that patch.
> 
> Same for above .ini file.
> 
Ok. Will do it this way in the next version.

> > +
> > +Prerequisites
> > +-
> > +
> > +- Follow the DPDK :ref:`Getting Started Guide for Linux
> > ` to setup the basic DPDK environment. +
> > +
> > +Driver compilation and testing
> > +--
> > +
> > +Refer to the document :ref:`compiling and testing a PMD for a NIC
> > ` +for details.
> > +
> > +It is highly recommended to upgrade the spnic driver and firmware
> > to avoid the compatibility issues, +and check the work mode with
> > the latest product documents. +
> > +Limitations or Known issues
> > +---
> > +Build with ICC is not supported yet.
> > +X86-32, Power8, ARMv7 and BSD are not supported yet.  
> 



Re: [PATCH v6 26/26] net/spnic: fixes unsafe C style code

2022-01-21 Thread Yanling Song
On Wed, 19 Jan 2022 17:28:11 +
Ferruh Yigit  wrote:

> On 12/30/2021 6:09 AM, Yanling Song wrote:
> > Use the hardware structure instead of void* as parameter of
> > function to keep the type information  
> 
> Hi Yanling,
> 
> This is a new driver and first patchset for it. Instead of fixing it
> in the set, why not update old patches to introduce them correct at
> first place?
> 
Thanks for the guide. Will do it this way in the next version.

> > 
> > Signed-off-by: Yanling Song 
> > ---
> >   drivers/net/spnic/base/spnic_cmdq.c  |  14 +--
> >   drivers/net/spnic/base/spnic_cmdq.h  |   6 +-
> >   drivers/net/spnic/base/spnic_hw_cfg.c|  49 --
> >   drivers/net/spnic/base/spnic_hw_cfg.h|  16 ++--
> >   drivers/net/spnic/base/spnic_hw_comm.c   |  32 ---
> >   drivers/net/spnic/base/spnic_hw_comm.h   |  22 ++---
> >   drivers/net/spnic/base/spnic_hwdev.c |   8 +-
> >   drivers/net/spnic/base/spnic_hwif.c  |  52 +--
> >   drivers/net/spnic/base/spnic_hwif.h  |  22 ++---
> >   drivers/net/spnic/base/spnic_mgmt.c  |   9 +-
> >   drivers/net/spnic/base/spnic_mgmt.h  |   4 +-
> >   drivers/net/spnic/base/spnic_nic_cfg.c   | 110
> > +++ drivers/net/spnic/base/spnic_nic_cfg.h   |
> > 84 - drivers/net/spnic/base/spnic_nic_event.c |  30
> > +++ drivers/net/spnic/base/spnic_nic_event.h |  10 +--
> >   drivers/net/spnic/base/spnic_wq.c|   3 +-
> >   drivers/net/spnic/base/spnic_wq.h|   2 +-
> >   drivers/net/spnic/spnic_ethdev.c |  10 +--
> >   drivers/net/spnic/spnic_io.c |  34 +++
> >   drivers/net/spnic/spnic_io.h |  10 +--
> >   drivers/net/spnic/spnic_rx.c |   4 +-
> >   drivers/net/spnic/spnic_tx.c |   4 +-
> >   22 files changed, 252 insertions(+), 283 deletions(-)  
> 
> 
> <...>
> 



RE: [RFC] mempool: cache preparation

2022-01-21 Thread Ananyev, Konstantin



> 
> Some drivers bypass the mbuf/mempool library functions, to manipulate the 
> mempool cache directly for improved performance.
> 
> Specifically, the AVX512 implementation of some of the Intel PMDs copy an 
> array of objects from the cache to a field in an array of some
> structure, i.e. it is not a 1:1 memcpy. This method avoids having to copy the 
> array of pointers into a temporary array before copying them
> into the fields of the target array, and thus improves performance and 
> reduces CPU cache pollution.
> 
> For such purposes, the mempool API could provide functions to prepare the 
> mempool cache for a direct access operation, and commit the
> transaction:
> 1. Prepare the cache for getting N objects directly from the objs array. This 
> function returns the address of the position in the cache array,
> from where the objects can be read, or NULL if failed.
> 2. Commit after getting the N objects.
> 3. Prepare the cache for putting N objects directly into the objs array. This 
> function returns the address of the position in the cache array, to
> where the objects can be written, or NULL if failed.
> 4. Commit after putting the N objects.
> 
> The functions only need to support getting/putting exactly N objects; i.e. 
> the "prepare" functions do not need return a value indicating
> some number less than N is available. Likewise, the "commit" functions do not 
> need to support any N other than the N in the preceding
> "prepare" function.
> 
> This API extension would provide a clean interface to directly access the 
> mempool cache with high performance, so copy-pasting the
> mempool's cache handling logic can be avoided, and bugs like [1] would not 
> survive.
> 
> Would this be useful?
> 
> [1]: https://bugs.dpdk.org/show_bug.cgi?id=923
> 

I think it is a very good idea, definitely worth to try.
I am also a bit worried that we have some PMD code that bypasses existing 
mempool cache functions,
so if we can close the gap here while keeping the perf we have - would be great.
Thanks
Konstantin


Re: [PATCH 3/8] common/cnxk: change order of frag sizes and infos

2022-01-21 Thread Ferruh Yigit

On 12/9/2021 9:13 AM, Nithin Dabilpuram wrote:

Change the order of frag sizes and infos to match HW
implementation.

Signed-off-by: Nithin Dabilpuram 
Signed-off-by: Vidya Sagar Velumuri 
---
  drivers/common/cnxk/hw/cpt.h | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/common/cnxk/hw/cpt.h b/drivers/common/cnxk/hw/cpt.h
index 919f842..99a900c 100644
--- a/drivers/common/cnxk/hw/cpt.h
+++ b/drivers/common/cnxk/hw/cpt.h
@@ -286,10 +286,10 @@ struct cpt_frag_info_s {
union {
uint64_t u64;
struct {
-   union cpt_frag_info f3;
-   union cpt_frag_info f2;
-   union cpt_frag_info f1;
union cpt_frag_info f0;
+   union cpt_frag_info f1;
+   union cpt_frag_info f2;
+   union cpt_frag_info f3;
};
} w0;
  
@@ -297,10 +297,10 @@ struct cpt_frag_info_s {

union {
uint64_t u64;
struct {
-   uint16_t frag_size3;
-   uint16_t frag_size2;
-   uint16_t frag_size1;
uint16_t frag_size0;
+   uint16_t frag_size1;
+   uint16_t frag_size2;
+   uint16_t frag_size3;



If this is related to the endianness requirement of the HW, it can be good to 
comment
this in the code.


};
} w1;
  };




Re: [PATCH 6/8] common/cnxk: handle issues from static analysis

2022-01-21 Thread Ferruh Yigit

On 12/9/2021 9:13 AM, Nithin Dabilpuram wrote:

From: Gowrishankar Muthukrishnan

Handle issues reported by static analysis tool such as
null pointer dereferences, variable initialization, etc.

Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Nithin Dabilpuram


Hi Gowrishankar, Nithin,

On its own static analysis issues fixed is not very descriptive,
can you please split the patch to the fix types, like:
- fix null pointer derefences
- fix variable initialization
...


Re: [PATCH 7/8] net/cnxk: improve inbound inline error handling for cn9k

2022-01-21 Thread Ferruh Yigit

On 12/9/2021 9:13 AM, Nithin Dabilpuram wrote:

Improve inbound inline error handling for CN9K in terms of
packet delivered to application for different kinds of errors.

Also update udp ports to be used for UDP encapsulation support.



This second change seems very unrelated with first change (unless I am missing 
something),
can you please split it to another patch?


Signed-off-by: Nithin Dabilpuram




Re: [PATCH 1/8] common/cnxk: fix shift offset for tl3 length disable

2022-01-21 Thread Ferruh Yigit

On 1/19/2022 4:15 PM, Jerin Jacob wrote:

On Thu, Dec 9, 2021 at 2:43 PM Nithin Dabilpuram
 wrote:


Fix shift offset for length disable flag in NIXX_AF_TL3X_SHAPE
register to be 24 instead of zero similar to other level SHAPE
registers. Also mask unused bits in adjust value.

Fixes: 0885429c3028 ("common/cnxk: add NIX TM hierarchy enable/disable")

Signed-off-by: Nithin Dabilpuram 
Signed-off-by: Satha Rao 



1) FIxed following warning
Is it candidate for Cc: sta...@dpdk.org backport?
 common/cnxk: fix shift offset for tl3 length disable

2) Change tl3 to TL3.

Applied to dpdk-next-net-mrvl/for-next-net. Thanks




I commented on a few changes mainly related to the patch splitting,
can it be possible to have a new version of the set?

Thanks,
ferruh


Re: [PATCH v5 1/2] event/cnxk: update min interval calculation

2022-01-21 Thread Jerin Jacob
On Mon, Dec 13, 2021 at 4:44 PM  wrote:
>
> From: Pavan Nikhilesh 
>
> Minimum supported interval should now be retrieved from
> mailbox based on the clock source and clock frequency.
>
> Signed-off-by: Pavan Nikhilesh 
> ---
> v5:
> - Rebase on master.


Applied to dpdk-next-net-eventdev/for-main. Thanks


> v4:
> - Rebase on master, fix NULL checks.
> v3:
> - Add new mbox interface.
> v2:
> - Fixed devargs parsing and rebased.
>
>  drivers/common/cnxk/roc_tim.c   | 32 +++-
>  drivers/common/cnxk/roc_tim.h   |  9 +++-
>  drivers/common/cnxk/version.map |  1 +
>  drivers/event/cnxk/cnxk_tim_evdev.c | 69 +---
>  drivers/event/cnxk/cnxk_tim_evdev.h | 81 +
>  5 files changed, 138 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/common/cnxk/roc_tim.c b/drivers/common/cnxk/roc_tim.c
> index 534b697bee..cefd9bc89d 100644
> --- a/drivers/common/cnxk/roc_tim.c
> +++ b/drivers/common/cnxk/roc_tim.c
> @@ -145,7 +145,7 @@ int
>  roc_tim_lf_config(struct roc_tim *roc_tim, uint8_t ring_id,
>   enum roc_tim_clk_src clk_src, uint8_t ena_periodic,
>   uint8_t ena_dfb, uint32_t bucket_sz, uint32_t chunk_sz,
> - uint32_t interval)
> + uint32_t interval, uint64_t intervalns, uint64_t clockfreq)
>  {
> struct dev *dev = &roc_sso_to_sso_priv(roc_tim->roc_sso)->dev;
> struct tim_config_req *req;
> @@ -162,6 +162,8 @@ roc_tim_lf_config(struct roc_tim *roc_tim, uint8_t 
> ring_id,
> req->enableperiodic = ena_periodic;
> req->enabledontfreebuffer = ena_dfb;
> req->interval = interval;
> +   req->intervalns = intervalns;
> +   req->clockfreq = clockfreq;
> req->gpioedge = TIM_GPIO_LTOH_TRANS;
>
> rc = mbox_process(dev->mbox);
> @@ -173,6 +175,34 @@ roc_tim_lf_config(struct roc_tim *roc_tim, uint8_t 
> ring_id,
> return 0;
>  }
>
> +int
> +roc_tim_lf_interval(struct roc_tim *roc_tim, enum roc_tim_clk_src clk_src,
> +   uint64_t clockfreq, uint64_t *intervalns,
> +   uint64_t *interval)
> +{
> +   struct dev *dev = &roc_sso_to_sso_priv(roc_tim->roc_sso)->dev;
> +   struct tim_intvl_req *req;
> +   struct tim_intvl_rsp *rsp;
> +   int rc = -ENOSPC;
> +
> +   req = mbox_alloc_msg_tim_get_min_intvl(dev->mbox);
> +   if (req == NULL)
> +   return rc;
> +
> +   req->clockfreq = clockfreq;
> +   req->clocksource = clk_src;
> +   rc = mbox_process_msg(dev->mbox, (void **)&rsp);
> +   if (rc < 0) {
> +   tim_err_desc(rc);
> +   return rc;
> +   }
> +
> +   *intervalns = rsp->intvl_ns;
> +   *interval = rsp->intvl_cyc;
> +
> +   return 0;
> +}
> +
>  int
>  roc_tim_lf_alloc(struct roc_tim *roc_tim, uint8_t ring_id, uint64_t *clk)
>  {
> diff --git a/drivers/common/cnxk/roc_tim.h b/drivers/common/cnxk/roc_tim.h
> index 159b021a31..392732eae2 100644
> --- a/drivers/common/cnxk/roc_tim.h
> +++ b/drivers/common/cnxk/roc_tim.h
> @@ -10,6 +10,8 @@ enum roc_tim_clk_src {
> ROC_TIM_CLK_SRC_GPIO,
> ROC_TIM_CLK_SRC_GTI,
> ROC_TIM_CLK_SRC_PTP,
> +   ROC_TIM_CLK_SRC_SYNCE,
> +   ROC_TIM_CLK_SRC_BTS,
> ROC_TIM_CLK_SRC_INVALID,
>  };
>
> @@ -33,7 +35,12 @@ int __roc_api roc_tim_lf_config(struct roc_tim *roc_tim, 
> uint8_t ring_id,
> enum roc_tim_clk_src clk_src,
> uint8_t ena_periodic, uint8_t ena_dfb,
> uint32_t bucket_sz, uint32_t chunk_sz,
> -   uint32_t interval);
> +   uint32_t interval, uint64_t intervalns,
> +   uint64_t clockfreq);
> +int __roc_api roc_tim_lf_interval(struct roc_tim *roc_tim,
> + enum roc_tim_clk_src clk_src,
> + uint64_t clockfreq, uint64_t *intervalns,
> + uint64_t *interval);
>  int __roc_api roc_tim_lf_alloc(struct roc_tim *roc_tim, uint8_t ring_id,
>uint64_t *clk);
>  int __roc_api roc_tim_lf_free(struct roc_tim *roc_tim, uint8_t ring_id);
> diff --git a/drivers/common/cnxk/version.map b/drivers/common/cnxk/version.map
> index 07c6720f0c..5379ed2d39 100644
> --- a/drivers/common/cnxk/version.map
> +++ b/drivers/common/cnxk/version.map
> @@ -346,6 +346,7 @@ INTERNAL {
> roc_tim_lf_disable;
> roc_tim_lf_enable;
> roc_tim_lf_free;
> +   roc_tim_lf_interval;
> roc_se_ctx_swap;
>
> local: *;
> diff --git a/drivers/event/cnxk/cnxk_tim_evdev.c 
> b/drivers/event/cnxk/cnxk_tim_evdev.c
> index 99b3acee7c..becab1d1b1 100644
> --- a/drivers/event/cnxk/cnxk_tim_evdev.c
> +++ b/drivers/event/cnxk/cnxk_tim_evdev.c
> @@ -2,6 +2,8 @@
>   * Copyright(C) 2021 Marvell.
>   */
>
> +#include 
> +
>  #include "cnxk_eventdev.h"
>  #inc

Re: [PATCH v6 00/26] Net/SPNIC: support SPNIC into DPDK 22.03

2022-01-21 Thread Ferruh Yigit

On 1/21/2022 9:27 AM, Yanling Song wrote:

On Wed, 19 Jan 2022 16:56:52 +
Ferruh Yigit  wrote:


On 12/30/2021 6:08 AM, Yanling Song wrote:

The patchsets introduce SPNIC driver for Ramaxel's SPNxx serial NIC
cards into DPDK 22.03. Ramaxel Memory Technology is a company which
supply a lot of electric products: storage, communication, PCB...
SPNxxx is a serial PCIE interface NIC cards:
SPN110: 2 PORTs *25G
SPN120: 4 PORTs *25G
SPN130: 2 PORTs *100G
   


Hi Yanling,

As far as I can see hnic (from Huawei) and this spnic drivers are
alike, what is the relation between these two?


It is hard to create a brand new driver from scratch, so we referenced
to hinic driver when developing spnic.



That is OK, but based on the familiarity of the code you may consider
keeping the original code Copyright, I didn't investigate in
that level but cc'ed hinic maintainers for info.
Also cc'ed Hemant for guidance.


But my question was more related to the HW, is there any relation between
the hinic HW and spnic HW? Like one is derived from other etc...


The following is main features of our SPNIC:
- TSO
- LRO
- Flow control
- SR-IOV(Partially supported)
- VLAN offload
- VLAN filter
- CRC offload
- Promiscuous mode
- RSS

v6->v5, No real changes:
1. Move the fix of RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS from patch 26
to patch 2; 2. Change the description of patch 26.

v5->v4:
1. Add prefix "spinc_" for external functions;
2. Remove temporary MACRO: RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS
3. Do not use void* for keeping the type information

v3->v4:
1. Fix ABI test failure;
2. Remove some descriptions in spnic.rst.

v2->v3:
1. Fix clang compiling failure.

v1->v2:
1. Fix coding style issues and compiling failures;
2. Only support linux in meson.build;
3. Use CLOCK_MONOTONIC_COARSE instead of
CLOCK_MONOTONIC/CLOCK_MONOTONIC_RAW; 4. Fix time_before();
5. Remove redundant checks in spnic_dev_configure();

Yanling Song (26):
drivers/net: introduce a new PMD driver
net/spnic: initialize the HW interface
net/spnic: add mbox message channel
net/spnic: introduce event queue
net/spnic: add mgmt module
net/spnic: add cmdq and work queue
net/spnic: add interface handling cmdq message
net/spnic: add hardware info initialization
net/spnic: support MAC and link event handling
net/spnic: add function info initialization
net/spnic: add queue pairs context initialization
net/spnic: support mbuf handling of Tx/Rx
net/spnic: support Rx congfiguration
net/spnic: add port/vport enable
net/spnic: support IO packets handling
net/spnic: add device configure/version/info
net/spnic: support RSS configuration update and get
net/spnic: support VLAN filtering and offloading
net/spnic: support promiscuous and allmulticast Rx modes
net/spnic: support flow control
net/spnic: support getting Tx/Rx queues info
net/spnic: net/spnic: support xstats statistics
net/spnic: support VFIO interrupt
net/spnic: support Tx/Rx queue start/stop
net/spnic: add doc infrastructure
net/spnic: fixes unsafe C style code


<...>






Re: [PATCH 1/8] common/cnxk: fix shift offset for tl3 length disable

2022-01-21 Thread Nithin Kumar Dabilpuram




On 1/21/22 3:38 PM, Ferruh Yigit wrote:

On 1/19/2022 4:15 PM, Jerin Jacob wrote:

On Thu, Dec 9, 2021 at 2:43 PM Nithin Dabilpuram
 wrote:


Fix shift offset for length disable flag in NIXX_AF_TL3X_SHAPE
register to be 24 instead of zero similar to other level SHAPE
registers. Also mask unused bits in adjust value.

Fixes: 0885429c3028 ("common/cnxk: add NIX TM hierarchy enable/disable")

Signed-off-by: Nithin Dabilpuram 
Signed-off-by: Satha Rao 



1) FIxed following warning
Is it candidate for Cc: sta...@dpdk.org backport?
 common/cnxk: fix shift offset for tl3 length disable

2) Change tl3 to TL3.

Applied to dpdk-next-net-mrvl/for-next-net. Thanks




I commented on a few changes mainly related to the patch splitting,
can it be possible to have a new version of the set?


Ack, will send next version with comments addressed.

Thanks
Nithin


Thanks,
ferruh


Re: [PATCH] eventdev/rx_adapter: add event port get api

2022-01-21 Thread Jerin Jacob
On Wed, Dec 22, 2021 at 11:43 AM Naga Harish K S V
 wrote:
>
> This patch introduces new api for retrieving event port id
> of eth rx adapter.
>
> Signed-off-by: Naga Harish K S V 
> ---
>  lib/eventdev/rte_event_eth_rx_adapter.c | 20 
>  lib/eventdev/rte_event_eth_rx_adapter.h | 20 
>  lib/eventdev/version.map|  1 +
>  3 files changed, 41 insertions(+)
>
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c 
> b/lib/eventdev/rte_event_eth_rx_adapter.c
> index 809416d9b7..fca2e38690 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> @@ -3119,6 +3119,26 @@ rte_event_eth_rx_adapter_service_id_get(uint8_t id, 
> uint32_t *service_id)
> return rx_adapter->service_inited ? 0 : -ESRCH;
>  }
>
> +int
> +rte_event_eth_rx_adapter_event_port_get(uint8_t id, uint8_t *event_port_id)
> +{
> +   struct event_eth_rx_adapter *rx_adapter;
> +
> +   if (rxa_memzone_lookup())
> +   return -ENOMEM;
> +
> +   RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
> +
> +   rx_adapter = rxa_id_to_adapter(id);
> +   if (rx_adapter == NULL || event_port_id == NULL)
> +   return -EINVAL;
> +
> +   if (rx_adapter->service_inited)
> +   *event_port_id = rx_adapter->event_port_id;
> +
> +   return rx_adapter->service_inited ? 0 : -ESRCH;
> +}
> +
>  int
>  rte_event_eth_rx_adapter_cb_register(uint8_t id,
> uint16_t eth_dev_id,
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h 
> b/lib/eventdev/rte_event_eth_rx_adapter.h
> index 9546d792e9..1364eafe38 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> @@ -37,6 +37,7 @@
>   *  - rte_event_eth_rx_adapter_queue_conf_get()
>   *  - rte_event_eth_rx_adapter_queue_stats_get()
>   *  - rte_event_eth_rx_adapter_queue_stats_reset()
> + *  - rte_event_eth_rx_adapter_event_port_get()
>   *
>   * The application creates an ethernet to event adapter using
>   * rte_event_eth_rx_adapter_create_ext() or rte_event_eth_rx_adapter_create()
> @@ -684,6 +685,25 @@ rte_event_eth_rx_adapter_queue_stats_reset(uint8_t id,
> uint16_t eth_dev_id,
> uint16_t rx_queue_id);
>
> +/**
> + * Retrieve the event port ID of an adapter. If the adapter doesn't use
> + * a rte_service function, this function returns -ESRCH.
> + *
> + * @param id
> + *  Adapter identifier.
> + *
> + * @param [out] event_port_id
> + *  A pointer to a uint32_t, to be filled in with the port id.

Pointer to uint8t_t. Right?


> + *
> + * @return
> + *  - 0: Success
> + *  - <0: Error code on failure, if the adapter doesn't use a rte_service
> + * function, this function returns -ESRCH.
> + */
> +__rte_experimental
> +int
> +rte_event_eth_rx_adapter_event_port_get(uint8_t id, uint8_t *event_port_id);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
> index ade1f1182e..91d2b5723b 100644
> --- a/lib/eventdev/version.map
> +++ b/lib/eventdev/version.map
> @@ -102,6 +102,7 @@ EXPERIMENTAL {
>
> # added in 21.11

See below

> rte_event_eth_rx_adapter_create_with_params;

Added in 22.03.
Also please update the release note for the new API addition.

> +   rte_event_eth_rx_adapter_event_port_get;
> rte_event_eth_rx_adapter_queue_conf_get;
> rte_event_eth_rx_adapter_queue_stats_get;
> rte_event_eth_rx_adapter_queue_stats_reset;
> --
> 2.25.1
>


[PATCH v2 00/15] add packet generator library and example app

2022-01-21 Thread Ronan Randles
V2
  - Add UDP protocol support
  - Add VXLAN protocol support
  - Removed gen/packet telemetry function as it was unimplemented
  - Fixed IPv4 endianness issue

As I am coming to the end of my internship I will now longer be working on this
project. As discussed on the thread [1] this patchset will be marked
non-applicable on patchwork. We are posting the V2 here to make the rework
publicly available.
  - Ronan

[1] DPDK Mailing list discussion around Gen library upstreaming;
http://mails.dpdk.org/archives/dev/2022-January/232845.html


This patchset introduces a Gen library for DPDK. This library provides an easy
way to generate traffic in order to test software based network components.

This library enables the basic functionality required in the traffic generator.
This includes: raw data setting, packet Tx and Rx, creation and destruction of a
 Gen instance and various types of data parsing.
This functionality is implemented in "lib/gen/rte_gen.c". IPv4 parsing
functionality is also added in "lib/net/rte_ip.c", this is then used in the gen
library.

A sample app is included in "examples/generator" which shows the use of the gen
library in making a traffic generator. This can be used to generate traffic by
running the dpdk-generator generator executable. This sample app supports
runtime stats reporting (/gen/stats) and line rate limiting
(/gen/mpps,) through telemetry.py.

As more features are added to the gen library, the sample application will
become more powerful through the "/gen/packet" string parameter
(currently supports IP and Ether address setting). This will allow every
application to generate more complex traffic types in the future without
changing API.

Harry van Haaren (6):
  gen: add files for initial traffic generation library
  gen: add basic Rx and Tx routines and tests
  gen: add raw packet data API and tests
  gen: add parsing infrastructure and Ether protocol
  gen: add gen IP parsing
  examples/generator: import code from basicfwd.c

Ronan Randles (9):
  net: add string to IPv4 parse function
  net: add function to pretty print IPv4
  examples/generator: enable gen library for traffic gen
  examples/generator: telemetry support
  examples/generator: link status check added
  examples/generator: line rate limiting
  gen: add UDP support
  net/vxlan: instance flag endianness refactored
  gen: add VXLAN support

 app/test/meson.build   |   4 +
 app/test/test_gen.c| 186 +
 app/test/test_net.c|  87 +
 doc/api/doxy-api-index.md  |   3 +-
 doc/api/doxy-api.conf.in   |   1 +
 examples/generator/main.c  | 470 ++
 examples/generator/meson.build |  13 +
 examples/meson.build   |   1 +
 lib/gen/meson.build|   6 +
 lib/gen/rte_gen.c  | 694 +
 lib/gen/rte_gen.h  | 114 ++
 lib/gen/version.map|  10 +
 lib/meson.build|   1 +
 lib/net/meson.build|   1 +
 lib/net/rte_ip.c   |  58 +++
 lib/net/rte_ip.h   |  38 ++
 lib/net/rte_vxlan.h|  10 +-
 lib/net/version.map|   7 +
 18 files changed, 1702 insertions(+), 2 deletions(-)
 create mode 100644 app/test/test_gen.c
 create mode 100644 app/test/test_net.c
 create mode 100644 examples/generator/main.c
 create mode 100644 examples/generator/meson.build
 create mode 100644 lib/gen/meson.build
 create mode 100644 lib/gen/rte_gen.c
 create mode 100644 lib/gen/rte_gen.h
 create mode 100644 lib/gen/version.map
 create mode 100644 lib/net/rte_ip.c

-- 
2.25.1



[PATCH v2 01/15] net: add string to IPv4 parse function

2022-01-21 Thread Ronan Randles
Added function that accepts ip string as a parameter and returns an ip
address represented by a uint32_t. Relevant unit test for this function
is also included.

Signed-off-by: Harry van Haaren 
Signed-off-by: Ronan Randles 
---
 app/test/meson.build |  2 ++
 app/test/test_net.c  | 61 
 lib/net/meson.build  |  1 +
 lib/net/rte_ip.c | 43 +++
 lib/net/rte_ip.h | 18 +
 lib/net/version.map  |  6 +
 6 files changed, 131 insertions(+)
 create mode 100644 app/test/test_net.c
 create mode 100644 lib/net/rte_ip.c

diff --git a/app/test/meson.build b/app/test/meson.build
index 344a609a4d..8cdfb783a9 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -100,6 +100,7 @@ test_sources = files(
 'test_meter.c',
 'test_mcslock.c',
 'test_mp_secondary.c',
+'test_net.c',
 'test_per_lcore.c',
 'test_pflock.c',
 'test_pmd_perf.c',
@@ -177,6 +178,7 @@ test_deps = [
 'ipsec',
 'lpm',
 'member',
+'net',
 'node',
 'pipeline',
 'port',
diff --git a/app/test/test_net.c b/app/test/test_net.c
new file mode 100644
index 00..2cb7d3e1c9
--- /dev/null
+++ b/app/test/test_net.c
@@ -0,0 +1,61 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include "test.h"
+
+static int
+test_rte_ip_parse_addr(void)
+{
+   printf("Running IP parsing tests...\n");
+
+   struct str_ip_t {
+   const char *str;
+   uint32_t exp_output;
+   uint32_t expected_to_fail;
+   } str_ip_tests[] = {
+   { .str = "1.2.3.4", .exp_output = RTE_IPV4(1, 2, 3, 4)},
+   { .str = "192.168.255.255", .exp_output =
+   RTE_IPV4(192, 168, 255, 255)},
+   { .str = "172.16.0.9", .exp_output =
+   RTE_IPV4(172, 16, 0, 9)},
+   { .str = "1.2.3", .expected_to_fail = 1},
+   { .str = "1.2.3.4.5", .expected_to_fail = 1},
+   { .str = "fail.1.2.3", .expected_to_fail = 1},
+   { .str = "", .expected_to_fail = 1},
+   { .str = "1.2.3.fail", .expected_to_fail = 1}
+   };
+
+   uint32_t i;
+   for (i = 0; i < RTE_DIM(str_ip_tests); i++) {
+   uint32_t test_addr;
+   int32_t err = rte_ip_parse_addr(str_ip_tests[i].str,
+   &test_addr);
+   if (!test_addr) {
+   if (str_ip_tests[i].expected_to_fail != 1)
+   return -1;
+   }
+
+   if (err || test_addr != str_ip_tests[i].exp_output) {
+   if (str_ip_tests[i].expected_to_fail != 1)
+   return -1;
+   }
+   }
+
+
+   return 0;
+}
+
+static int
+test_net_tests(void)
+{
+   int ret = test_rte_ip_parse_addr();
+   return ret;
+}
+
+REGISTER_TEST_COMMAND(net_autotest, test_net_tests);
diff --git a/lib/net/meson.build b/lib/net/meson.build
index e899846578..b2577a7592 100644
--- a/lib/net/meson.build
+++ b/lib/net/meson.build
@@ -26,6 +26,7 @@ headers = files(
 sources = files(
 'rte_arp.c',
 'rte_ether.c',
+'rte_ip.c',
 'rte_net.c',
 'rte_net_crc.c',
 )
diff --git a/lib/net/rte_ip.c b/lib/net/rte_ip.c
new file mode 100644
index 00..b859dfb640
--- /dev/null
+++ b/lib/net/rte_ip.c
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include 
+#include 
+
+int32_t
+rte_ip_parse_addr(const char *src_ip, uint32_t *output_addr)
+{
+   int32_t ret = 0;
+   char *current_position;
+
+   if (src_ip == NULL)
+   return -1;
+
+   char *tok = strdup(src_ip);
+   if (tok == NULL)
+   return -1;
+
+   char *current_digit = strtok_r(tok, ".", ¤t_position);
+
+   *output_addr = 0;
+   uint32_t i = 0;
+   while (current_digit) {
+   uint32_t shift = ((3 - i) * 8);
+   unsigned long parsed_value = strtoul(current_digit, NULL, 0)
+   << shift;
+
+   if (parsed_value == 0 && strcmp(current_digit, "0"))
+   break;
+
+   *output_addr |= parsed_value;
+   current_digit = strtok_r(NULL, ".", ¤t_position);
+   i++;
+
+   }
+   if (i != 4)
+   return -1;
+
+   free(tok);
+   return ret;
+}
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index c575250852..188054fda4 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -426,6 +426,24 @@ rte_ipv4_udptcp_cksum_verify(const struct rte_ipv4_hdr 
*ipv4_hdr,
return 0;
 }
 
+/**
+ * IP address parser.
+ *
+ * @param src_ip
+ *   The IP

[PATCH v2 02/15] net: add function to pretty print IPv4

2022-01-21 Thread Ronan Randles
This function accepts an uint32_t representation of an IP address and
produces a string representation stored in a char * buffer. Realavent
unit tests also included.

Signed-off-by: Ronan Randles 
---
 app/test/test_net.c | 26 ++
 lib/net/rte_ip.c| 15 +++
 lib/net/rte_ip.h| 20 
 lib/net/version.map |  1 +
 4 files changed, 62 insertions(+)

diff --git a/app/test/test_net.c b/app/test/test_net.c
index 2cb7d3e1c9..75beeea671 100644
--- a/app/test/test_net.c
+++ b/app/test/test_net.c
@@ -46,7 +46,32 @@ test_rte_ip_parse_addr(void)
return -1;
}
}
+   return 0;
+}
+
+static int
+test_rte_ip_print_addr(void)
+{
+   printf("Running IP printing tests...\n");
+   char buffer[128];
 
+   struct ip_str_t {
+   uint32_t ip_addr;
+   const char *exp_output;
+   } ip_str_tests[] = {
+   { .ip_addr = 16909060, .exp_output = "1.2.3.4"},
+   { .ip_addr = 3232301055, . exp_output = "192.168.255.255"},
+   { .ip_addr = 2886729737, .exp_output = "172.16.0.9"}
+   };
+
+   uint32_t i;
+   for (i = 0; i < RTE_DIM(ip_str_tests); i++) {
+   int32_t err = rte_ip_print_addr(ip_str_tests[i].ip_addr,
+   buffer, 128);
+
+   if (err || strcmp(buffer, ip_str_tests[i].exp_output))
+   return -1;
+   }
 
return 0;
 }
@@ -55,6 +80,7 @@ static int
 test_net_tests(void)
 {
int ret = test_rte_ip_parse_addr();
+   ret += test_rte_ip_print_addr();
return ret;
 }
 
diff --git a/lib/net/rte_ip.c b/lib/net/rte_ip.c
index b859dfb640..fbd9161317 100644
--- a/lib/net/rte_ip.c
+++ b/lib/net/rte_ip.c
@@ -41,3 +41,18 @@ rte_ip_parse_addr(const char *src_ip, uint32_t *output_addr)
free(tok);
return ret;
 }
+
+int32_t
+rte_ip_print_addr(uint32_t ip_addr, char *buffer, uint32_t buffer_size)
+{
+   if (buffer == NULL)
+   return -1;
+
+   snprintf(buffer, buffer_size, "%u.%u.%u.%u",
+   (ip_addr >> 24),
+   (ip_addr >> 16) & UINT8_MAX,
+   (ip_addr >> 8) & UINT8_MAX,
+ip_addr & UINT8_MAX);
+
+   return 0;
+}
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 188054fda4..e46f0b41ba 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -444,6 +444,26 @@ __rte_experimental
 int32_t
 rte_ip_parse_addr(const char *src_ip, uint32_t *output_addr);
 
+
+/**
+ * Print IP address from 32 bit int into char * buffer.
+ *
+ * @param ip_addr
+ *   ip address to be printed.
+ * @param buffer
+ *   The buffer the string will be saved into.
+ * @param buffer_size
+ *   size of buffer to be used.
+ *
+ * @retval 0
+ *   Success.
+ * @retval -1
+ *   Failure due to invalid input arguments.
+ */
+__rte_experimental
+int32_t
+rte_ip_print_addr(uint32_t ip_addr, char *buffer, uint32_t buffer_size);
+
 /**
  * IPv6 Header
  */
diff --git a/lib/net/version.map b/lib/net/version.map
index c530d1a4e4..7fe9892d03 100644
--- a/lib/net/version.map
+++ b/lib/net/version.map
@@ -17,4 +17,5 @@ EXPERIMENTAL {
global:
 
rte_ip_parse_addr;
+   rte_ip_print_addr;
 };
-- 
2.25.1



[PATCH v2 03/15] gen: add files for initial traffic generation library

2022-01-21 Thread Ronan Randles
From: Harry van Haaren 

This commit adds empty files to the DPDK build for a traffic
generation library, including the bare create and destroy functions.
Unit testing infrastructure is added for the create function.

Signed-off-by: Harry van Haaren 
Signed-off-by: Ronan Randles 
---
 app/test/meson.build  |  2 ++
 app/test/test_gen.c   | 55 +++
 doc/api/doxy-api-index.md |  3 ++-
 doc/api/doxy-api.conf.in  |  1 +
 lib/gen/meson.build   |  5 
 lib/gen/rte_gen.c | 33 +++
 lib/gen/rte_gen.h | 44 +++
 lib/gen/version.map   |  6 +
 lib/meson.build   |  1 +
 9 files changed, 149 insertions(+), 1 deletion(-)
 create mode 100644 app/test/test_gen.c
 create mode 100644 lib/gen/meson.build
 create mode 100644 lib/gen/rte_gen.c
 create mode 100644 lib/gen/rte_gen.h
 create mode 100644 lib/gen/version.map

diff --git a/app/test/meson.build b/app/test/meson.build
index 8cdfb783a9..c282493d10 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -66,6 +66,7 @@ test_sources = files(
 'test_fib6_perf.c',
 'test_func_reentrancy.c',
 'test_flow_classify.c',
+'test_gen.c',
 'test_graph.c',
 'test_graph_perf.c',
 'test_hash.c',
@@ -173,6 +174,7 @@ test_deps = [
 'eventdev',
 'fib',
 'flow_classify',
+'gen',
 'graph',
 'hash',
 'ipsec',
diff --git a/app/test/test_gen.c b/app/test/test_gen.c
new file mode 100644
index 00..f53f4a6608
--- /dev/null
+++ b/app/test/test_gen.c
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+static struct rte_mempool *mp;
+
+static int
+testsuite_setup(void)
+{
+   if (!mp) {
+   mp = rte_pktmbuf_pool_create("test_gen_mp", 8192, 256, 0, 2048,
+   SOCKET_ID_ANY);
+   }
+   return mp ? TEST_SUCCESS : TEST_FAILED;
+}
+
+static void
+testsuite_teardown(void)
+{
+   rte_mempool_free(mp);
+}
+
+static int
+test_gen_create(void)
+{
+   struct rte_gen *gen = rte_gen_create(mp);
+   TEST_ASSERT_FAIL(gen, "Expected valid pointer after create()");
+
+   rte_gen_destroy(gen);
+   return 0;
+}
+
+static struct unit_test_suite gen_suite  = {
+   .suite_name = "gen: packet generator unit test suite",
+   .setup = testsuite_setup,
+   .teardown = testsuite_teardown,
+   .unit_test_cases = {
+   TEST_CASE_ST(NULL, NULL, test_gen_create),
+   TEST_CASES_END() /**< NULL terminate unit test array */
+   }
+};
+
+static int
+test_gen_suite(void)
+{
+   return unit_test_suite_runner(&gen_suite);
+}
+
+REGISTER_TEST_COMMAND(gen_autotest, test_gen_suite);
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 4245b9635c..f7ddadd21a 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -220,7 +220,8 @@ The public API headers are grouped by topics:
   [log](@ref rte_log.h),
   [errno]  (@ref rte_errno.h),
   [trace]  (@ref rte_trace.h),
-  [trace_point](@ref rte_trace_point.h)
+  [trace_point](@ref rte_trace_point.h),
+  [gen](@ref rte_gen.h)
 
 - **misc**:
   [EAL config] (@ref rte_eal.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index db2ca9b6ed..6344e949d9 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -41,6 +41,7 @@ INPUT   = @TOPDIR@/doc/api/doxy-api-index.md \
   @TOPDIR@/lib/eventdev \
   @TOPDIR@/lib/fib \
   @TOPDIR@/lib/flow_classify \
+  @TOPDIR@/lib/gen \
   @TOPDIR@/lib/gpudev \
   @TOPDIR@/lib/graph \
   @TOPDIR@/lib/gro \
diff --git a/lib/gen/meson.build b/lib/gen/meson.build
new file mode 100644
index 00..3c5d854645
--- /dev/null
+++ b/lib/gen/meson.build
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2021 Intel Corporation
+
+sources = files('rte_gen.c')
+headers = files('rte_gen.h')
diff --git a/lib/gen/rte_gen.c b/lib/gen/rte_gen.c
new file mode 100644
index 00..d993772422
--- /dev/null
+++ b/lib/gen/rte_gen.c
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 Intel Corporation
+ */
+
+#include "rte_gen.h"
+
+#include 
+
+/** Structure that represents a traffic generator. */
+struct rte_gen {
+   /* Mempool that buffers are retrieved from. */
+   struct rte_mempool *mp;
+};
+
+/* Allocate and initialize a traffic generator instance. */
+struct rte_gen *
+rte_gen_create(struct rte_mempool *mempool)
+{
+   struct rte_gen *gen = rte_zmalloc(NULL, sizeof(*gen), 0);
+   if (gen

[PATCH v2 04/15] gen: add basic Rx and Tx routines and tests

2022-01-21 Thread Ronan Randles
From: Harry van Haaren 

This commit introduces functions for basic mbuf rx and tx.
This commit also contains a unit test that calls rte_gen_rx_burst
and rte_gen_tx_burst to send bursts of 32 packets repeatedly in
order to verify their functionality

Signed-off-by: Harry van Haaren 
Signed-off-by: Ronan Randles 
---
 app/test/test_gen.c | 46 ++
 lib/gen/meson.build |  1 +
 lib/gen/rte_gen.c   | 43 +++
 lib/gen/rte_gen.h   | 49 +
 lib/gen/version.map |  2 ++
 5 files changed, 141 insertions(+)

diff --git a/app/test/test_gen.c b/app/test/test_gen.c
index f53f4a6608..ceacd8c7c4 100644
--- a/app/test/test_gen.c
+++ b/app/test/test_gen.c
@@ -8,6 +8,8 @@
 
 #include "test.h"
 
+#define BURST_MAX 32
+
 static struct rte_mempool *mp;
 
 static int
@@ -36,12 +38,56 @@ test_gen_create(void)
return 0;
 }
 
+static int
+test_gen_basic_rxtx(void)
+{
+   struct rte_gen *gen = rte_gen_create(mp);
+   TEST_ASSERT_FAIL(gen, "Expected valid pointer after create()");
+
+   struct rte_mbuf *bufs[BURST_MAX];
+   uint16_t nb_rx = rte_gen_rx_burst(gen, bufs, BURST_MAX);
+   TEST_ASSERT_EQUAL(nb_rx, BURST_MAX, "Expected rx packet burst.");
+
+   uint64_t latency[BURST_MAX];
+   uint16_t nb_tx = rte_gen_tx_burst(gen, bufs, latency, BURST_MAX);
+   TEST_ASSERT_EQUAL(nb_tx, BURST_MAX, "Expected tx packet burst.");
+
+   rte_gen_destroy(gen);
+   return 0;
+}
+
+static int
+test_gen_loop_rxtx(void)
+{
+   struct rte_gen *gen = rte_gen_create(mp);
+   TEST_ASSERT_FAIL(gen, "Expected valid pointer after create()");
+
+   uint32_t total_sent = 0;
+
+   while (total_sent < 100) {
+   struct rte_mbuf *bufs[BURST_MAX];
+   uint16_t nb_rx = rte_gen_rx_burst(gen, bufs, BURST_MAX);
+   TEST_ASSERT_EQUAL(nb_rx, BURST_MAX, "Expected rx packet 
burst.");
+
+   uint64_t latency[BURST_MAX];
+   uint16_t nb_tx = rte_gen_tx_burst(gen, bufs, latency, nb_rx);
+   TEST_ASSERT_EQUAL(nb_tx, BURST_MAX, "Expected tx packet 
burst.");
+
+   total_sent += nb_tx;
+   }
+
+   rte_gen_destroy(gen);
+   return 0;
+}
+
 static struct unit_test_suite gen_suite  = {
.suite_name = "gen: packet generator unit test suite",
.setup = testsuite_setup,
.teardown = testsuite_teardown,
.unit_test_cases = {
TEST_CASE_ST(NULL, NULL, test_gen_create),
+   TEST_CASE_ST(NULL, NULL, test_gen_basic_rxtx),
+   TEST_CASE_ST(NULL, NULL, test_gen_loop_rxtx),
TEST_CASES_END() /**< NULL terminate unit test array */
}
 };
diff --git a/lib/gen/meson.build b/lib/gen/meson.build
index 3c5d854645..753984cbba 100644
--- a/lib/gen/meson.build
+++ b/lib/gen/meson.build
@@ -3,3 +3,4 @@
 
 sources = files('rte_gen.c')
 headers = files('rte_gen.h')
+deps += ['mempool', 'mbuf']
diff --git a/lib/gen/rte_gen.c b/lib/gen/rte_gen.c
index d993772422..f0ad57fa81 100644
--- a/lib/gen/rte_gen.c
+++ b/lib/gen/rte_gen.c
@@ -4,8 +4,11 @@
 
 #include "rte_gen.h"
 
+#include 
 #include 
 
+#define GEN_MAX_BURST 32
+
 /** Structure that represents a traffic generator. */
 struct rte_gen {
/* Mempool that buffers are retrieved from. */
@@ -31,3 +34,43 @@ rte_gen_destroy(struct rte_gen *gen)
 {
rte_free(gen);
 }
+
+uint16_t
+rte_gen_rx_burst(struct rte_gen *gen,
+struct rte_mbuf **rx_pkts,
+const uint16_t nb_pkts)
+{
+   /* Get a bulk of nb_pkts from the mempool. */
+   int err = rte_mempool_get_bulk(gen->mp, (void **)rx_pkts, nb_pkts);
+   if (err)
+   return 0;
+
+   const uint32_t pkt_len = 64;
+
+   uint32_t i;
+   for (i = 0; i < nb_pkts; i++) {
+   struct rte_mbuf *m = rx_pkts[i];
+   uint8_t *pkt_data = rte_pktmbuf_mtod(m, uint8_t *);
+
+   memset(pkt_data, 0, pkt_len);
+
+   m->pkt_len  = pkt_len;
+   m->data_len = pkt_len;
+   }
+
+   return nb_pkts;
+}
+
+uint16_t
+rte_gen_tx_burst(struct rte_gen *gen,
+struct rte_mbuf **tx_pkts,
+uint64_t *pkt_latencies,
+const uint16_t nb_pkts)
+{
+   RTE_SET_USED(gen);
+   RTE_SET_USED(pkt_latencies);
+
+   rte_pktmbuf_free_bulk(tx_pkts, nb_pkts);
+
+   return nb_pkts;
+}
diff --git a/lib/gen/rte_gen.h b/lib/gen/rte_gen.h
index 5b30430f9e..09ee1e8872 100644
--- a/lib/gen/rte_gen.h
+++ b/lib/gen/rte_gen.h
@@ -25,6 +25,7 @@ extern "C" {
 struct rte_gen;
 
 /* Forward declarations for DPDK componeents. */
+struct rte_mbuf;
 struct rte_mempool;
 
 /* Allocate and initialize a traffic generator instance. */
@@ -37,6 +38,54 @@ __rte_experimental
 void
 rte_gen_destroy(struct rte_gen *gen);
 
+/**
+ * Call to receive a burst of generated packets
+ *
+ * @param gen
+ *   Gen instance to be 

[PATCH v2 05/15] gen: add raw packet data API and tests

2022-01-21 Thread Ronan Randles
From: Harry van Haaren 

This commit adds a new API to gen, allowing the caller to set
raw packet data with a size. Tests are added to test the new
API with randomized packet data.

Signed-off-by: Harry van Haaren 
---
 app/test/test_gen.c | 33 
 lib/gen/rte_gen.c   | 62 +
 lib/gen/rte_gen.h   |  9 +++
 lib/gen/version.map |  1 +
 4 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/app/test/test_gen.c b/app/test/test_gen.c
index ceacd8c7c4..b60ceaef8a 100644
--- a/app/test/test_gen.c
+++ b/app/test/test_gen.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "test.h"
 
@@ -75,6 +76,37 @@ test_gen_loop_rxtx(void)
 
total_sent += nb_tx;
}
+   rte_gen_destroy(gen);
+   return 0;
+}
+
+static int
+test_gen_packet_set_raw(void)
+{
+   struct rte_gen *gen = rte_gen_create(mp);
+   TEST_ASSERT_FAIL(gen, "Expected valid pointer after create()");
+
+   /* Set a raw packet payload, and ensure the next received packet has
+* that packet data as contents and size.
+*/
+   uint64_t pkt_data[8];
+   uint32_t i;
+   for (i = 0; i < 8; i++)
+   pkt_data[i] = rte_rand();
+
+   int32_t err = rte_gen_packet_set_raw(gen, (void *)pkt_data, 64);
+   TEST_ASSERT_EQUAL(err, 0, "Expected set raw() to return success.");
+
+   struct rte_mbuf *bufs[BURST_MAX];
+   uint16_t nb_rx = rte_gen_rx_burst(gen, bufs, 1);
+   TEST_ASSERT_EQUAL(nb_rx, 1, "Expected rx packet burst.");
+
+   void *mbuf_data = rte_pktmbuf_mtod(bufs[0], void *);
+   int32_t data_equal = memcmp(pkt_data, mbuf_data, 64) == 0;
+   TEST_ASSERT_EQUAL(data_equal, 1,
+   "Expected packet data equal to input data.");
+
+   rte_pktmbuf_free(bufs[0]);
 
rte_gen_destroy(gen);
return 0;
@@ -88,6 +120,7 @@ static struct unit_test_suite gen_suite  = {
TEST_CASE_ST(NULL, NULL, test_gen_create),
TEST_CASE_ST(NULL, NULL, test_gen_basic_rxtx),
TEST_CASE_ST(NULL, NULL, test_gen_loop_rxtx),
+   TEST_CASE_ST(NULL, NULL, test_gen_packet_set_raw),
TEST_CASES_END() /**< NULL terminate unit test array */
}
 };
diff --git a/lib/gen/rte_gen.c b/lib/gen/rte_gen.c
index f0ad57fa81..8a54c4bcdb 100644
--- a/lib/gen/rte_gen.c
+++ b/lib/gen/rte_gen.c
@@ -6,13 +6,25 @@
 
 #include 
 #include 
+#include 
+#include 
+
+RTE_LOG_REGISTER(gen_logtype, lib.gen, NOTICE);
+
+#define GEN_LOG(level, fmt, args...)   \
+   rte_log(RTE_LOG_ ## level, gen_logtype, "%s(): " fmt,   \
+   __func__, ## args)
 
 #define GEN_MAX_BURST 32
+#define GEN_INIT_PKT_SIZE 64
 
 /** Structure that represents a traffic generator. */
 struct rte_gen {
/* Mempool that buffers are retrieved from. */
struct rte_mempool *mp;
+
+   /* Packet template to send. */
+   struct rte_mbuf *base_pkt;
 };
 
 /* Allocate and initialize a traffic generator instance. */
@@ -25,6 +37,15 @@ rte_gen_create(struct rte_mempool *mempool)
 
gen->mp = mempool;
 
+   uint8_t data[GEN_INIT_PKT_SIZE];
+   memset(data, 0, GEN_INIT_PKT_SIZE);
+   int32_t err = rte_gen_packet_set_raw(gen, data, GEN_INIT_PKT_SIZE);
+   if (err) {
+   GEN_LOG(ERR, "Failed to set initial packet\n");
+   rte_free(gen);
+   return NULL;
+   }
+
return gen;
 }
 
@@ -32,9 +53,37 @@ rte_gen_create(struct rte_mempool *mempool)
 void
 rte_gen_destroy(struct rte_gen *gen)
 {
+   rte_pktmbuf_free(gen->base_pkt);
rte_free(gen);
 }
 
+int32_t
+rte_gen_packet_set_raw(struct rte_gen *gen,
+  const uint8_t *raw_data,
+  uint32_t raw_data_size)
+{
+
+   struct rte_mbuf *new_pkt = rte_pktmbuf_alloc(gen->mp);
+   if (!new_pkt) {
+   GEN_LOG(ERR, "Failed to retireve mbuf for parser\n");
+   return -ENOMEM;
+   }
+
+   uint8_t *base_data = rte_pktmbuf_mtod(new_pkt, uint8_t *);
+   new_pkt->pkt_len = raw_data_size;
+   new_pkt->data_len = raw_data_size;
+   rte_memcpy(base_data, raw_data, raw_data_size);
+
+   /* If old packet exists, free it. */
+   struct rte_mbuf *old_pkt = gen->base_pkt;
+   gen->base_pkt = new_pkt;
+
+   if (old_pkt)
+   rte_pktmbuf_free(old_pkt);
+
+   return 0;
+}
+
 uint16_t
 rte_gen_rx_burst(struct rte_gen *gen,
 struct rte_mbuf **rx_pkts,
@@ -45,17 +94,20 @@ rte_gen_rx_burst(struct rte_gen *gen,
if (err)
return 0;
 
-   const uint32_t pkt_len = 64;
+   if (!gen->base_pkt)
+   return 0;
+
+   const uint32_t base_size = gen->base_pkt->pkt_len;
+   const uint8_t *base_data = rte_pktmbuf_mtod(gen->base_pkt, uint8_t *);
 
uint32_t i;
for (i = 0; i < nb_pkts; i++) {
struct rte_mb

[PATCH v2 06/15] gen: add parsing infrastructure and Ether protocol

2022-01-21 Thread Ronan Randles
From: Harry van Haaren 

This commit adds parsing infrastructure and support
for Ether parsing. Appropriate unit tests are also added

Signed-off-by: Harry van Haaren 
---
 app/test/test_gen.c |  29 +
 lib/gen/meson.build |   2 +-
 lib/gen/rte_gen.c   | 299 
 lib/gen/rte_gen.h   |  12 ++
 lib/gen/version.map |   1 +
 5 files changed, 342 insertions(+), 1 deletion(-)

diff --git a/app/test/test_gen.c b/app/test/test_gen.c
index b60ceaef8a..324582d0a5 100644
--- a/app/test/test_gen.c
+++ b/app/test/test_gen.c
@@ -112,6 +112,34 @@ test_gen_packet_set_raw(void)
return 0;
 }
 
+static int
+test_gen_packet_parse_string(void)
+{
+   struct rte_gen *gen = rte_gen_create(mp);
+   TEST_ASSERT_FAIL(gen, "Expected valid pointer after create()");
+
+   struct str_parse_t {
+   const char *str;
+   } pkt_strings[] = {
+   { .str = "Ether()"},
+   { .str = "Ether()/"},
+   { .str = "/Ether()"},
+   { .str = "/Ether()/"}
+   };
+
+   uint32_t i;
+   for (i = 0; i < RTE_DIM(pkt_strings); i++) {
+   const char *pkt_str = pkt_strings[i].str;
+   int32_t err = rte_gen_packet_parse_string(gen, pkt_str, NULL);
+   TEST_ASSERT_EQUAL(err, 0, "Expected string %s to parse.",
+   pkt_str);
+   }
+
+   rte_gen_destroy(gen);
+   return 0;
+}
+
+
 static struct unit_test_suite gen_suite  = {
.suite_name = "gen: packet generator unit test suite",
.setup = testsuite_setup,
@@ -121,6 +149,7 @@ static struct unit_test_suite gen_suite  = {
TEST_CASE_ST(NULL, NULL, test_gen_basic_rxtx),
TEST_CASE_ST(NULL, NULL, test_gen_loop_rxtx),
TEST_CASE_ST(NULL, NULL, test_gen_packet_set_raw),
+   TEST_CASE_ST(NULL, NULL, test_gen_packet_parse_string),
TEST_CASES_END() /**< NULL terminate unit test array */
}
 };
diff --git a/lib/gen/meson.build b/lib/gen/meson.build
index 753984cbba..b3a55564f4 100644
--- a/lib/gen/meson.build
+++ b/lib/gen/meson.build
@@ -3,4 +3,4 @@
 
 sources = files('rte_gen.c')
 headers = files('rte_gen.h')
-deps += ['mempool', 'mbuf']
+deps += ['mempool', 'mbuf', 'net']
diff --git a/lib/gen/rte_gen.c b/lib/gen/rte_gen.c
index 8a54c4bcdb..4d3fe4017f 100644
--- a/lib/gen/rte_gen.c
+++ b/lib/gen/rte_gen.c
@@ -9,12 +9,18 @@
 #include 
 #include 
 
+#include 
+
 RTE_LOG_REGISTER(gen_logtype, lib.gen, NOTICE);
 
 #define GEN_LOG(level, fmt, args...)   \
rte_log(RTE_LOG_ ## level, gen_logtype, "%s(): " fmt,   \
__func__, ## args)
 
+/* Don't prefix with function name, breaks the Scapy style formatting. */
+#define GEN_LOG_PROTOCOL(level, fmt, args...)  \
+   rte_log(RTE_LOG_ ## level, gen_logtype, fmt, ## args)
+
 #define GEN_MAX_BURST 32
 #define GEN_INIT_PKT_SIZE 64
 
@@ -126,3 +132,296 @@ rte_gen_tx_burst(struct rte_gen *gen,
 
return nb_pkts;
 }
+
+enum GEN_PROTO {
+   GEN_PROTO_INVALID,
+   GEN_PROTO_ETHER,
+
+   /* Must be last. */
+   GEN_PROTO_COUNT,
+};
+
+typedef void (*gen_log_func)(void *data, const char *indent);
+
+/* Structure for holding offset and function pointers for protocol. */
+struct protocol_meta {
+   /* Byte offset into packet where this protocol starts. */
+   uint32_t offset;
+   /* Function to call to log the packet's information. */
+   gen_log_func log_func;
+};
+
+/* Allow up to 32 nexted '/' characters in the protocol string. */
+#define GEN_PROTO_PARSE_MAX 16
+
+/* Structure to hold state required while parsing. */
+struct gen_parser {
+   /* Mbuf the parsed data is being put into. */
+   struct rte_mbuf *mbuf;
+   uint8_t *mbuf_data;
+
+   /* Offset into the packet data to parse to next. */
+   uint32_t buf_write_offset;
+
+   /* Parsing state. */
+   uint8_t parse_iter;
+   char indent_str[(GEN_PROTO_PARSE_MAX * 2) + 1];
+
+   /* String being parsed. */
+   char *parse_string;
+   char *parse_strtok_save_ptr;
+
+   /* Store metadata for parse/display of protocols.  */
+   struct protocol_meta proto_meta[GEN_PROTO_PARSE_MAX];
+
+   /* Per protocol hit counters. */
+   uint32_t proto_hit_counters[GEN_PROTO_COUNT];
+};
+
+/* Forward declaration of recursive parsing function.
+ * @param inner reports back the inner protocol that was handled. This is often
+ * required for the outer protocol to indicate what the inner protocol is.
+ */
+static int32_t
+gen_parser_parse_next(struct gen_parser *parser, enum GEN_PROTO *inner);
+
+/* Return void pointer to the position in the data buffer to parse into. */
+static inline void *
+gen_parser_get_data_ptr(struct gen_parser *parser)
+{
+   return &parser->mbuf_data[parser->buf_write_offset];
+}
+
+/* Initialize a parser structure. */
+static int32_t
+gen_parser_init(struct gen_parse

[PATCH v2 07/15] gen: add gen IP parsing

2022-01-21 Thread Ronan Randles
From: Harry van Haaren 

This commit adds support for the parsing of "IP(src=...,dst=...)"
strings. Parse string API improvement for app RCU.
Appropriate unit tests also added.

Signed-off-by: Harry van Haaren 
Signed-off-by: Ronan Randles 
---
 app/test/test_gen.c |  29 +++--
 lib/gen/rte_gen.c   | 153 +++-
 2 files changed, 177 insertions(+), 5 deletions(-)

diff --git a/app/test/test_gen.c b/app/test/test_gen.c
index 324582d0a5..7b67835c80 100644
--- a/app/test/test_gen.c
+++ b/app/test/test_gen.c
@@ -117,26 +117,47 @@ test_gen_packet_parse_string(void)
 {
struct rte_gen *gen = rte_gen_create(mp);
TEST_ASSERT_FAIL(gen, "Expected valid pointer after create()");
-
struct str_parse_t {
const char *str;
+   uint32_t expected_to_fail;
} pkt_strings[] = {
{ .str = "Ether()"},
{ .str = "Ether()/"},
{ .str = "/Ether()"},
-   { .str = "/Ether()/"}
+   { .str = "/Ether()/"},
+   { .str = "Ether()/IP()"},
+   { .str = "Ether()/IP(src=1.2.3.4,dst=5.6.7.8)"},
+   { .str = "Ether()/IP(src=1.2.3.4,dst=192.168.255.255)"},
+   { .str = "Ether()/IP(dst=172.16.0.9,src=1.2.3.4)"},
+   { .str = "Ether()/IP(src=1.2.3.4)"},
+   { .str = "Ether()/IP(srdst=5.6.7.8)", .expected_to_fail = 1},
+   { .str = "Ether()/IP(src=1.2.3.4,ds=)", .expected_to_fail = 1},
+   { .str = "Ether()/IP(src=1.2.3.4,dst=)", .expected_to_fail = 1},
+   { .str = "Ether()/IP(src=,dst=5.6.7.8)", .expected_to_fail = 1},
+   { .str = "Ether()/IP(sr=,dst=5.6.7.8)", .expected_to_fail = 1},
+   { .str = "Ether()/IP(src=1.2.3.fail,dst=5.6.7.8)",
+   .expected_to_fail = 1},
};
 
uint32_t i;
for (i = 0; i < RTE_DIM(pkt_strings); i++) {
const char *pkt_str = pkt_strings[i].str;
int32_t err = rte_gen_packet_parse_string(gen, pkt_str, NULL);
-   TEST_ASSERT_EQUAL(err, 0, "Expected string %s to parse.",
-   pkt_str);
+
+   if (err && pkt_strings[i].expected_to_fail != 1) {
+   printf("Expected string %s to parse.", pkt_str);
+   return -1;
+   }
+   /* False pass if reached with no err when e_t_f = 1 */
+   if (!err && pkt_strings[i].expected_to_fail) {
+   printf("False Pass on string: %s\n", pkt_str);
+   return -1;
+   }
}
 
rte_gen_destroy(gen);
return 0;
+
 }
 
 
diff --git a/lib/gen/rte_gen.c b/lib/gen/rte_gen.c
index 4d3fe4017f..4020150712 100644
--- a/lib/gen/rte_gen.c
+++ b/lib/gen/rte_gen.c
@@ -10,6 +10,7 @@
 #include 
 
 #include 
+#include 
 
 RTE_LOG_REGISTER(gen_logtype, lib.gen, NOTICE);
 
@@ -136,6 +137,7 @@ rte_gen_tx_burst(struct rte_gen *gen,
 enum GEN_PROTO {
GEN_PROTO_INVALID,
GEN_PROTO_ETHER,
+   GEN_PROTO_IPV4,
 
/* Must be last. */
GEN_PROTO_COUNT,
@@ -219,6 +221,145 @@ gen_parser_init(struct gen_parser *parser, struct rte_gen 
*gen,
return -ENOMEM;
 }
 
+static void
+gen_log_ipv4(void *data, const char *indent)
+{
+   struct rte_ipv4_hdr *ip = data;
+
+   const char *proto_str;
+   switch (ip->next_proto_id) {
+   case 0:
+   proto_str = "hopopt";
+   break;
+   default:
+   proto_str = "unknown next proto";
+   break;
+   }
+
+   GEN_LOG_PROTOCOL(DEBUG,
+   "###[ IP ]###\n%sversion = %d\n%sihl = %d\n%stos = %d\n"
+   "%slen = %d\n%sid = %d\n%sflags = 0x%x\n%sfrag = %d\n"
+   "%sttl = %d\n%sproto = %s (%d)\n%schksum 0x%x\n%ssrc = 0x%x\n"
+   "%sdst = 0x%x\n%soptions = %s\n",
+   indent, ip->version_ihl >> 4,
+   indent, ip->version_ihl & RTE_IPV4_HDR_IHL_MASK,
+   indent, ip->type_of_service,
+   indent, rte_be_to_cpu_16(ip->total_length),
+   indent, rte_be_to_cpu_16(ip->packet_id), /* TODO: Scapy ID? */
+   indent, rte_be_to_cpu_16(ip->packet_id), /*TODO: Scapy Flags?*/
+   indent, rte_be_to_cpu_16(ip->fragment_offset),
+   indent, ip->time_to_live,
+   indent, proto_str, ip->next_proto_id,
+   indent, rte_be_to_cpu_16(ip->hdr_checksum),
+   indent, rte_be_to_cpu_32(ip->src_addr),
+   indent, rte_be_to_cpu_32(ip->dst_addr),
+   indent, "notImplemented");
+}
+
+static int32_t
+gen_parse_ipv4_params(char *protocol_str, struct rte_ipv4_hdr *ip)
+{
+   /* Strings to look for. */
+   static const char * const items[] = {
+   "src=",
+   "dst=",
+   };
+   const uint32_t num_items = RTE_DIM(items

[PATCH v2 08/15] examples/generator: import code from basicfwd.c

2022-01-21 Thread Ronan Randles
From: Harry van Haaren 

Import files from basicfwd.c to act as starting point for
gen library sample app

Signed-off-by: Harry van Haaren 
Signed-off-by: Ronan Randles 
---
 examples/generator/main.c  | 226 +
 examples/generator/meson.build |  12 ++
 2 files changed, 238 insertions(+)
 create mode 100644 examples/generator/main.c
 create mode 100644 examples/generator/meson.build

diff --git a/examples/generator/main.c b/examples/generator/main.c
new file mode 100644
index 00..0082f588b4
--- /dev/null
+++ b/examples/generator/main.c
@@ -0,0 +1,226 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2015 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RX_RING_SIZE 1024
+#define TX_RING_SIZE 1024
+
+#define NUM_MBUFS 8191
+#define MBUF_CACHE_SIZE 256
+#define BURST_SIZE 32
+
+/* Configuration of ethernet ports. 8<  */
+static const struct rte_eth_conf port_conf_default = {
+   .rxmode = {
+   .max_lro_pkt_size = RTE_ETHER_MAX_LEN,
+   },
+};
+/* >8 End of configuration of ethernet ports. */
+
+/* basicfwd.c: Basic DPDK skeleton forwarding example. */
+
+/*
+ * Initializes a given port using global settings and with the RX buffers
+ * coming from the mbuf_pool passed as a parameter.
+ */
+
+/* Main functional part of port initialization. 8< */
+static inline int
+port_init(uint16_t port, struct rte_mempool *mbuf_pool)
+{
+   struct rte_eth_conf port_conf = port_conf_default;
+   const uint16_t rx_rings = 1, tx_rings = 1;
+   uint16_t nb_rxd = RX_RING_SIZE;
+   uint16_t nb_txd = TX_RING_SIZE;
+   int retval;
+   uint16_t q;
+   struct rte_eth_dev_info dev_info;
+   struct rte_eth_txconf txconf;
+
+   if (!rte_eth_dev_is_valid_port(port))
+   return -1;
+
+   retval = rte_eth_dev_info_get(port, &dev_info);
+   if (retval != 0) {
+   printf("Error during getting device (port %u) info: %s\n",
+   port, strerror(-retval));
+   return retval;
+   }
+
+   if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MBUF_FAST_FREE)
+   port_conf.txmode.offloads |=
+   DEV_TX_OFFLOAD_MBUF_FAST_FREE;
+
+   /* Configure the Ethernet device. */
+   retval = rte_eth_dev_configure(port, rx_rings, tx_rings, &port_conf);
+   if (retval != 0)
+   return retval;
+
+   retval = rte_eth_dev_adjust_nb_rx_tx_desc(port, &nb_rxd, &nb_txd);
+   if (retval != 0)
+   return retval;
+
+   /* Allocate and set up 1 RX queue per Ethernet port. */
+   for (q = 0; q < rx_rings; q++) {
+   retval = rte_eth_rx_queue_setup(port, q, nb_rxd,
+   rte_eth_dev_socket_id(port), NULL, mbuf_pool);
+   if (retval < 0)
+   return retval;
+   }
+
+   txconf = dev_info.default_txconf;
+   txconf.offloads = port_conf.txmode.offloads;
+   /* Allocate and set up 1 TX queue per Ethernet port. */
+   for (q = 0; q < tx_rings; q++) {
+   retval = rte_eth_tx_queue_setup(port, q, nb_txd,
+   rte_eth_dev_socket_id(port), &txconf);
+   if (retval < 0)
+   return retval;
+   }
+
+   /* Starting Ethernet port. 8< */
+   retval = rte_eth_dev_start(port);
+   /* >8 End of starting of ethernet port. */
+   if (retval < 0)
+   return retval;
+
+   /* Display the port MAC address. */
+   struct rte_ether_addr addr;
+   retval = rte_eth_macaddr_get(port, &addr);
+   if (retval != 0)
+   return retval;
+
+   printf("Port %u MAC: %02" PRIx8 " %02" PRIx8 " %02" PRIx8
+  " %02" PRIx8 " %02" PRIx8 " %02" PRIx8 "\n",
+   port, RTE_ETHER_ADDR_BYTES(&addr));
+
+   /* Enable RX in promiscuous mode for the Ethernet device. */
+   retval = rte_eth_promiscuous_enable(port);
+   /* End of setting RX port in promiscuous mode. */
+   if (retval != 0)
+   return retval;
+
+   return 0;
+}
+/* >8 End of main functional part of port initialization. */
+
+/*
+ * The lcore main. This is the main thread that does the work, reading from
+ * an input port and writing to an output port.
+ */
+
+ /* Basic forwarding application lcore. 8< */
+static __rte_noreturn void
+lcore_main(void)
+{
+   uint16_t port;
+
+   /*
+* Check that the port is on the same NUMA node as the polling thread
+* for best performance.
+*/
+   RTE_ETH_FOREACH_DEV(port)
+   if (rte_eth_dev_socket_id(port) >= 0 &&
+   rte_eth_dev_socket_id(port) !=
+   (int)rte_socket_id())
+   printf("WARNING, port %u is on remote NUMA node to "
+ 

[PATCH v2 09/15] examples/generator: enable gen library for traffic gen

2022-01-21 Thread Ronan Randles
This commit shows the steps necessary to enable traffic generation
using the gen library

Signed-off-by: Ronan Randles 
---
 examples/generator/main.c  | 175 ++---
 examples/generator/meson.build |   1 +
 examples/meson.build   |   1 +
 3 files changed, 120 insertions(+), 57 deletions(-)

diff --git a/examples/generator/main.c b/examples/generator/main.c
index 0082f588b4..1ddf4c1603 100644
--- a/examples/generator/main.c
+++ b/examples/generator/main.c
@@ -1,14 +1,18 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2010-2015 Intel Corporation
+ * Copyright(c) 2021 Intel Corporation
  */
 
 #include 
 #include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #define RX_RING_SIZE 1024
 #define TX_RING_SIZE 1024
@@ -16,23 +20,23 @@
 #define NUM_MBUFS 8191
 #define MBUF_CACHE_SIZE 256
 #define BURST_SIZE 32
+#define MIN_THREADS 3
 
-/* Configuration of ethernet ports. 8<  */
 static const struct rte_eth_conf port_conf_default = {
.rxmode = {
.max_lro_pkt_size = RTE_ETHER_MAX_LEN,
},
 };
-/* >8 End of configuration of ethernet ports. */
 
-/* basicfwd.c: Basic DPDK skeleton forwarding example. */
+static volatile int done;
+static struct rte_mempool *mbuf_pool;
+struct rte_gen *gen;
+
+static void handle_sigint(int sig);
 
-/*
- * Initializes a given port using global settings and with the RX buffers
+/* Initializes a given port using global settings and with the RX buffers
  * coming from the mbuf_pool passed as a parameter.
  */
-
-/* Main functional part of port initialization. 8< */
 static inline int
 port_init(uint16_t port, struct rte_mempool *mbuf_pool)
 {
@@ -68,6 +72,12 @@ port_init(uint16_t port, struct rte_mempool *mbuf_pool)
if (retval != 0)
return retval;
 
+   int lcore_available_count = rte_lcore_count();
+   if (lcore_available_count < MIN_THREADS) {
+   printf("Not enough threads available\n");
+   return -1;
+   }
+
/* Allocate and set up 1 RX queue per Ethernet port. */
for (q = 0; q < rx_rings; q++) {
retval = rte_eth_rx_queue_setup(port, q, nb_rxd,
@@ -86,9 +96,8 @@ port_init(uint16_t port, struct rte_mempool *mbuf_pool)
return retval;
}
 
-   /* Starting Ethernet port. 8< */
+   /* Start the Ethernet port. */
retval = rte_eth_dev_start(port);
-   /* >8 End of starting of ethernet port. */
if (retval < 0)
return retval;
 
@@ -104,27 +113,67 @@ port_init(uint16_t port, struct rte_mempool *mbuf_pool)
 
/* Enable RX in promiscuous mode for the Ethernet device. */
retval = rte_eth_promiscuous_enable(port);
-   /* End of setting RX port in promiscuous mode. */
if (retval != 0)
return retval;
 
return 0;
 }
-/* >8 End of main functional part of port initialization. */
 
-/*
- * The lcore main. This is the main thread that does the work, reading from
+/* The lcore main. This is the main thread that does the work, reading from
  * an input port and writing to an output port.
  */
+static int
+lcore_producer(__rte_unused void *arg)
+{
+   uint16_t port;
+
+   /* Check that the port is on the same NUMA node as the polling thread
+* for best performance.
+*/
+   RTE_ETH_FOREACH_DEV(port)
+   if (rte_eth_dev_socket_id(port) >= 0 &&
+   rte_eth_dev_socket_id(port) !=
+   (int)rte_socket_id())
+   printf("WARNING, port %u is on remote NUMA node to "
+   "polling thread.\n\tPerformance will "
+   "not be optimal.\n", port);
 
- /* Basic forwarding application lcore. 8< */
-static __rte_noreturn void
-lcore_main(void)
+   /* Run until the application is quit or killed. */
+   while (!done) {
+   struct rte_mbuf *bufs[BURST_SIZE];
+   int i;
+   /* Receive packets from gen and then tx them over port */
+   RTE_ETH_FOREACH_DEV(port) {
+   int nb_recieved = rte_gen_rx_burst(gen, bufs,
+   BURST_SIZE);
+   for (i = 0; i < nb_recieved; i++) {
+   bufs[i]->pkt_len = 64;
+   bufs[i]->data_len = 64;
+   }
+
+   uint16_t nb_tx = rte_eth_tx_burst(port, 0, bufs,
+   nb_recieved);
+   if (nb_tx != nb_recieved)
+   rte_pktmbuf_free_bulk(&bufs[nb_tx],
+   (nb_recieved - nb_tx));
+
+   if (unlikely(nb_tx == 0))
+   continue;
+
+ 

[PATCH v2 10/15] examples/generator: telemetry support

2022-01-21 Thread Ronan Randles
This commit adds telemetry introducing the callback functions
and returning measured values

Signed-off-by: Ronan Randles 
---
 examples/generator/main.c | 142 +++---
 1 file changed, 118 insertions(+), 24 deletions(-)

diff --git a/examples/generator/main.c b/examples/generator/main.c
index 1ddf4c1603..1ac3caafcc 100644
--- a/examples/generator/main.c
+++ b/examples/generator/main.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define RX_RING_SIZE 1024
 #define TX_RING_SIZE 1024
@@ -32,6 +33,27 @@ static volatile int done;
 static struct rte_mempool *mbuf_pool;
 struct rte_gen *gen;
 
+struct gen_args {
+   /* Inputs */
+   struct rte_gen *gen;
+
+   /* Outputs */
+   uint64_t tx_total_packets;
+   uint64_t rx_total_packets;
+   uint64_t rx_missed_total;
+   uint64_t tx_failed;
+   uint64_t last_tx_total;
+   uint64_t measured_tx_pps;
+} __rte_cache_aligned;
+/* Expose a struct as a global so the telemetry callbacks can access the
+ * data required to provide stats etc.
+ */
+struct telemetry_userdata {
+   struct gen_args *prod;
+   struct gen_args *cons;
+};
+static struct telemetry_userdata telemetry_userdata;
+
 static void handle_sigint(int sig);
 
 /* Initializes a given port using global settings and with the RX buffers
@@ -123,10 +145,11 @@ port_init(uint16_t port, struct rte_mempool *mbuf_pool)
  * an input port and writing to an output port.
  */
 static int
-lcore_producer(__rte_unused void *arg)
+lcore_producer(void *arg)
 {
+   struct gen_args *args = arg;
+   struct rte_gen *gen = args->gen;
uint16_t port;
-
/* Check that the port is on the same NUMA node as the polling thread
 * for best performance.
 */
@@ -138,25 +161,34 @@ lcore_producer(__rte_unused void *arg)
"polling thread.\n\tPerformance will "
"not be optimal.\n", port);
 
+   uint64_t tsc_hz = rte_get_tsc_hz();
+   uint64_t last_tsc_reading = 0;
+   uint64_t last_tx_total = 0;
+
/* Run until the application is quit or killed. */
while (!done) {
struct rte_mbuf *bufs[BURST_SIZE];
-   int i;
+   uint16_t nb_tx = 0;
/* Receive packets from gen and then tx them over port */
RTE_ETH_FOREACH_DEV(port) {
-   int nb_recieved = rte_gen_rx_burst(gen, bufs,
+   int nb_generated = rte_gen_rx_burst(gen, bufs,
BURST_SIZE);
-   for (i = 0; i < nb_recieved; i++) {
-   bufs[i]->pkt_len = 64;
-   bufs[i]->data_len = 64;
-   }
 
-   uint16_t nb_tx = rte_eth_tx_burst(port, 0, bufs,
-   nb_recieved);
-   if (nb_tx != nb_recieved)
-   rte_pktmbuf_free_bulk(&bufs[nb_tx],
-   (nb_recieved - nb_tx));
+   uint64_t start_tsc = rte_rdtsc();
+   if (start_tsc > last_tsc_reading + tsc_hz) {
+   args->measured_tx_pps = args->tx_total_packets -
+   last_tx_total;
+   last_tx_total = args->tx_total_packets;
+   last_tsc_reading = start_tsc;
+   }
+   nb_tx = rte_eth_tx_burst(port, 0, bufs, nb_generated);
+   args->tx_total_packets += nb_tx;
 
+   uint64_t tx_failed = nb_generated - nb_tx;
+   if (nb_tx != nb_generated) {
+   rte_pktmbuf_free_bulk(&bufs[nb_tx], tx_failed);
+   args->tx_failed += tx_failed;
+   }
if (unlikely(nb_tx == 0))
continue;
 
@@ -169,10 +201,11 @@ lcore_producer(__rte_unused void *arg)
  * an input port and writing to an output port.
  */
 static int
-lcore_consumer(__rte_unused void *arg)
+lcore_consumer(void *arg)
 {
+   struct gen_args *args = arg;
+   struct rte_gen *gen = args->gen;
uint16_t port;
-
/* Check that the port is on the same NUMA node as the polling thread
 * for best performance.
 */
@@ -195,16 +228,16 @@ lcore_consumer(__rte_unused void *arg)
uint64_t latency[BURST_SIZE];
uint16_t nb_rx = rte_eth_rx_burst(port, 0, bufs,
BURST_SIZE);
-   rte_gen_tx_burst(gen, bufs, latency, nb_rx);
+   if (unlikely(nb_rx == 0))
+   continue;
+
+

[PATCH v2 11/15] examples/generator: link status check added

2022-01-21 Thread Ronan Randles
This commit brings in a link status check so that the generator will
only start sending packets once there is something on the other end of
the link.

Signed-off-by: Ronan Randles 
---
 examples/generator/main.c | 68 ++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/examples/generator/main.c b/examples/generator/main.c
index 1ac3caafcc..0834a094a4 100644
--- a/examples/generator/main.c
+++ b/examples/generator/main.c
@@ -27,9 +27,13 @@ static const struct rte_eth_conf port_conf_default = {
.rxmode = {
.max_lro_pkt_size = RTE_ETHER_MAX_LEN,
},
+   .intr_conf = {
+   .lsc = 1, /**< lsc interrupt */
+   },
 };
 
 static volatile int done;
+static volatile int link_status[RTE_MAX_ETHPORTS];
 static struct rte_mempool *mbuf_pool;
 struct rte_gen *gen;
 
@@ -56,6 +60,30 @@ static struct telemetry_userdata telemetry_userdata;
 
 static void handle_sigint(int sig);
 
+static int
+link_status_change_cb(uint16_t port_id, enum rte_eth_event_type type,
+ void *param, void *ret_param)
+{
+   if (unlikely(port_id >= RTE_DIM(link_status)))
+   rte_panic("got LSC interrupt for unknown port id\n");
+
+   RTE_SET_USED(type);
+   RTE_SET_USED(param);
+   RTE_SET_USED(ret_param);
+
+   struct rte_eth_link link;
+   int ret = rte_eth_link_get_nowait(port_id, &link);
+   if (ret < 0) {
+   printf("Failed link get on port %d: %s\n",
+  port_id, rte_strerror(-ret));
+   return ret;
+   }
+
+   printf("Link status change port %i\n", port_id);
+   link_status[port_id] = link.link_status;
+   return 0;
+}
+
 /* Initializes a given port using global settings and with the RX buffers
  * coming from the mbuf_pool passed as a parameter.
  */
@@ -99,6 +127,9 @@ port_init(uint16_t port, struct rte_mempool *mbuf_pool)
printf("Not enough threads available\n");
return -1;
}
+   /* Register the LinkStatusChange callback */
+   rte_eth_dev_callback_register(port, RTE_ETH_EVENT_INTR_LSC,
+ link_status_change_cb, NULL);
 
/* Allocate and set up 1 RX queue per Ethernet port. */
for (q = 0; q < rx_rings; q++) {
@@ -138,9 +169,33 @@ port_init(uint16_t port, struct rte_mempool *mbuf_pool)
if (retval != 0)
return retval;
 
+   struct rte_eth_link link;
+   int ret = rte_eth_link_get_nowait(port, &link);
+   if (ret < 0) {
+   printf("Failed link get on port %d: %s\n", port,
+   rte_strerror(-ret));
+   return ret;
+   }
+
+   link_status[port] = link.link_status;
+
return 0;
 }
 
+static void
+gen_wait_for_links_up(void)
+{
+   /* Ensure all available ports are up before generating packets */
+   uint16_t nb_eth_ports = rte_eth_dev_count_avail();
+   uint16_t nb_links_up = 0;
+   while (!done && nb_links_up < nb_eth_ports) {
+   if (link_status[nb_links_up])
+   nb_links_up++;
+
+   rte_delay_us_block(100);
+   }
+}
+
 /* The lcore main. This is the main thread that does the work, reading from
  * an input port and writing to an output port.
  */
@@ -164,12 +219,19 @@ lcore_producer(void *arg)
uint64_t tsc_hz = rte_get_tsc_hz();
uint64_t last_tsc_reading = 0;
uint64_t last_tx_total = 0;
+   uint16_t nb_tx = 0;
+
+   /* Wait for links to come up before generating packets */
+   gen_wait_for_links_up();
+   if (!done)
+   printf("Generating packets...\n");
 
/* Run until the application is quit or killed. */
while (!done) {
+
struct rte_mbuf *bufs[BURST_SIZE];
-   uint16_t nb_tx = 0;
/* Receive packets from gen and then tx them over port */
+
RTE_ETH_FOREACH_DEV(port) {
int nb_generated = rte_gen_rx_burst(gen, bufs,
BURST_SIZE);
@@ -217,8 +279,12 @@ lcore_consumer(void *arg)
"polling thread.\n\tPerformance will "
"not be optimal.\n", port);
 
+   /* Wait for links to come up before generating packets */
+   gen_wait_for_links_up();
+
/* Run until the application is quit or killed. */
while (!done) {
+
struct rte_mbuf *bufs[BURST_SIZE];
 
/* Receive packets over port and then tx them to gen library
-- 
2.25.1



[PATCH v2 12/15] examples/generator: line rate limiting

2022-01-21 Thread Ronan Randles
This commit introduces line rate limiting using a token passing method.
The target traffic rate default is currently hard coded, this can be set
using telemetry.

Signed-off-by: Ronan Randles 
---
 examples/generator/main.c | 79 +--
 1 file changed, 51 insertions(+), 28 deletions(-)

diff --git a/examples/generator/main.c b/examples/generator/main.c
index 0834a094a4..16292f06db 100644
--- a/examples/generator/main.c
+++ b/examples/generator/main.c
@@ -40,6 +40,7 @@ struct rte_gen *gen;
 struct gen_args {
/* Inputs */
struct rte_gen *gen;
+   uint64_t target_tx_pps;
 
/* Outputs */
uint64_t tx_total_packets;
@@ -195,7 +196,6 @@ gen_wait_for_links_up(void)
rte_delay_us_block(100);
}
 }
-
 /* The lcore main. This is the main thread that does the work, reading from
  * an input port and writing to an output port.
  */
@@ -217,43 +217,63 @@ lcore_producer(void *arg)
"not be optimal.\n", port);
 
uint64_t tsc_hz = rte_get_tsc_hz();
+   float tsc_hz_f = (float)tsc_hz;
uint64_t last_tsc_reading = 0;
uint64_t last_tx_total = 0;
uint16_t nb_tx = 0;
+   float tokens = 0;
 
/* Wait for links to come up before generating packets */
gen_wait_for_links_up();
if (!done)
printf("Generating packets...\n");
 
+   uint64_t token_last_add_tsc = rte_rdtsc();
+
/* Run until the application is quit or killed. */
while (!done) {
-
struct rte_mbuf *bufs[BURST_SIZE];
-   /* Receive packets from gen and then tx them over port */
-
-   RTE_ETH_FOREACH_DEV(port) {
-   int nb_generated = rte_gen_rx_burst(gen, bufs,
-   BURST_SIZE);
-
-   uint64_t start_tsc = rte_rdtsc();
-   if (start_tsc > last_tsc_reading + tsc_hz) {
-   args->measured_tx_pps = args->tx_total_packets -
-   last_tx_total;
-   last_tx_total = args->tx_total_packets;
-   last_tsc_reading = start_tsc;
+   /* Track time since last token add and calculate number
+* of tokens to give per second to implement line rate limiting
+*/
+   uint64_t now = rte_rdtsc();
+   uint64_t tsc_delta = now - token_last_add_tsc;
+   float token_scalar = (float)tsc_delta / tsc_hz_f;
+   float add_tokens = args->target_tx_pps * token_scalar;
+   /* If there are tokens to be added and we haven't exceeded
+* the target rate then we add tokens
+*/
+   if (add_tokens > 1.f) {
+   if (tokens < args->target_tx_pps) {
+   tokens += add_tokens;
+   token_last_add_tsc = now;
}
-   nb_tx = rte_eth_tx_burst(port, 0, bufs, nb_generated);
-   args->tx_total_packets += nb_tx;
-
-   uint64_t tx_failed = nb_generated - nb_tx;
-   if (nb_tx != nb_generated) {
-   rte_pktmbuf_free_bulk(&bufs[nb_tx], tx_failed);
-   args->tx_failed += tx_failed;
+   }
+   /* Receive packets from gen and then tx them over port */
+   if (tokens >= BURST_SIZE) {
+   RTE_ETH_FOREACH_DEV(port) {
+   int nb_generated = rte_gen_rx_burst(gen, bufs,
+   BURST_SIZE);
+
+   uint64_t start_tsc = rte_rdtsc();
+   if (start_tsc > last_tsc_reading + tsc_hz) {
+   args->measured_tx_pps =
+   args->tx_total_packets - last_tx_total;
+   last_tx_total = args->tx_total_packets;
+   last_tsc_reading = start_tsc;
+   }
+   nb_tx = rte_eth_tx_burst(port, 0, bufs,
+   nb_generated);
+   args->tx_total_packets += nb_tx;
+   tokens -= nb_tx;
+
+   uint64_t tx_failed = nb_generated - nb_tx;
+   if (nb_tx != nb_generated) {
+   rte_pktmbuf_free_bulk(&bufs[nb_tx],
+   tx_failed);
+   args->tx_failed += tx_failed;
+   }
  

[PATCH v2 13/15] gen: add UDP support

2022-01-21 Thread Ronan Randles
This commit adds UDP parsing and logging. Unit tested by the adition of
"UDP()" string to 'test_gen_packet_parse_string()'

Signed-off-by: Ronan Randles 
---
 app/test/test_gen.c |  1 +
 lib/gen/rte_gen.c   | 66 +
 2 files changed, 67 insertions(+)

diff --git a/app/test/test_gen.c b/app/test/test_gen.c
index 7b67835c80..a0b00d6a6e 100644
--- a/app/test/test_gen.c
+++ b/app/test/test_gen.c
@@ -137,6 +137,7 @@ test_gen_packet_parse_string(void)
{ .str = "Ether()/IP(sr=,dst=5.6.7.8)", .expected_to_fail = 1},
{ .str = "Ether()/IP(src=1.2.3.fail,dst=5.6.7.8)",
.expected_to_fail = 1},
+   { .str = "Ether()/IP()/UDP()"},
};
 
uint32_t i;
diff --git a/lib/gen/rte_gen.c b/lib/gen/rte_gen.c
index 4020150712..3a67ce8b6c 100644
--- a/lib/gen/rte_gen.c
+++ b/lib/gen/rte_gen.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 
 RTE_LOG_REGISTER(gen_logtype, lib.gen, NOTICE);
 
@@ -138,6 +139,7 @@ enum GEN_PROTO {
GEN_PROTO_INVALID,
GEN_PROTO_ETHER,
GEN_PROTO_IPV4,
+   GEN_PROTO_UDP,
 
/* Must be last. */
GEN_PROTO_COUNT,
@@ -231,6 +233,9 @@ gen_log_ipv4(void *data, const char *indent)
case 0:
proto_str = "hopopt";
break;
+   case IPPROTO_UDP:
+   proto_str = "UDP";
+   break;
default:
proto_str = "unknown next proto";
break;
@@ -351,6 +356,12 @@ gen_parse_ipv4(struct gen_parser *parser, char 
*protocol_str)
}
 
switch (inner) {
+   case GEN_PROTO_UDP:
+   ip->next_proto_id = IPPROTO_UDP;
+   struct rte_udp_hdr *udp = gen_parser_get_data_ptr(parser);
+   udp->dgram_cksum = 0;
+   break;
+
default:
/* Default protocol is hopopt (0). */
break;
@@ -430,6 +441,55 @@ gen_parse_ether(struct gen_parser *parser, char 
*protocol_str)
return 0;
 }
 
+static void
+gen_log_udp(void *data, const char *indent)
+{
+   struct rte_udp_hdr *udp = data;
+
+   GEN_LOG_PROTOCOL(DEBUG,
+   "###[ UDP ]###\n%ssport= %u\n%sdport= %u\n%s"
+   "len= %u\n%schksum= %u\n",
+   indent, rte_be_to_cpu_16(udp->src_port),
+   indent, rte_be_to_cpu_16(udp->dst_port),
+   indent, rte_be_to_cpu_16(udp->dgram_len),
+   indent, rte_be_to_cpu_16(udp->dgram_cksum));
+
+}
+
+static int32_t
+gen_parse_udp(struct gen_parser *parser, char *protocol_str)
+{
+   RTE_SET_USED(protocol_str);
+   struct rte_udp_hdr *udp = gen_parser_get_data_ptr(parser);
+   uint32_t pre_udp_len = parser->buf_write_offset;
+   memset(udp, 0, sizeof(*udp));
+
+   /* Move up write pointer in packet. */
+   parser->buf_write_offset += sizeof(*udp);
+
+   /* Recurse and handle inner protocol. */
+   enum GEN_PROTO inner;
+   int err = gen_parser_parse_next(parser, &inner);
+
+   switch (inner) {
+   default:
+   /* default to DNS like other packet generation tools */
+   udp->src_port = rte_cpu_to_be_16(53);
+   udp->dst_port = rte_cpu_to_be_16(53);
+   break;
+   };
+
+   /* Minimum len is the UDP header itself (8 bytes) or more */
+   int32_t total_len = parser->mbuf->data_len;
+   int32_t dgram_len = total_len - pre_udp_len;
+   if (dgram_len < 8)
+   printf("error parsing dgram len, %d\n", dgram_len);
+
+   udp->dgram_len = rte_cpu_to_be_16(dgram_len);
+
+   return err;
+}
+
 /* (Name, Function-pointer) pairs for supported parse types */
 typedef int32_t (*gen_parse_func)(struct gen_parser *parser,
char *protocol_str);
@@ -455,6 +515,12 @@ static struct gen_parse_func_t gen_protocols[] = {
.parse_func = gen_parse_ipv4,
.log_func = gen_log_ipv4,
},
+   {
+   .name = "UDP(",
+   .proto = GEN_PROTO_UDP,
+   .parse_func = gen_parse_udp,
+   .log_func = gen_log_udp,
+   }
 
 };
 
-- 
2.25.1



[PATCH v2 14/15] net/vxlan: instance flag endianness refactored

2022-01-21 Thread Ronan Randles
This patch improves the setting of the instance flag in the
rte_vxlan_hdr struct, by using a byte to represent vx_flag_bits.
Previously it was exposed to the user via a rte_be32_t value, which
required handling endianness at the application level. The code uses a
union to ensure that existing code continues to work as before, while
allowing the improved more usable method to co-exist.

A new #define is introduced to represent the instance bit, which must be
set if a vxlan header contains a valid VNI field, see
https://datatracker.ietf.org/doc/html/rfc7348 for details

Signed-off-by: Ronan Randles 
---
 lib/net/rte_vxlan.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/lib/net/rte_vxlan.h b/lib/net/rte_vxlan.h
index 929fa7a1dd..86b6d8a3ae 100644
--- a/lib/net/rte_vxlan.h
+++ b/lib/net/rte_vxlan.h
@@ -24,6 +24,7 @@ extern "C" {
 /** VXLAN default port. */
 #define RTE_VXLAN_DEFAULT_PORT 4789
 #define RTE_VXLAN_GPE_DEFAULT_PORT 4790
+#define RTE_VXLAN_FLAGS_I (1 << 3)
 
 /**
  * VXLAN protocol header.
@@ -31,7 +32,14 @@ extern "C" {
  * Reserved fields (24 bits and 8 bits)
  */
 struct rte_vxlan_hdr {
-   rte_be32_t vx_flags; /**< flag (8) + Reserved (24). */
+   RTE_STD_C11
+   union {
+   struct {
+   uint8_t vx_flag_bits;
+   uint8_t reserved[3];
+   };
+   rte_be32_t vx_flags; /**< flag (8) + Reserved (24). */
+   };
rte_be32_t vx_vni;   /**< VNI (24) + Reserved (8). */
 } __rte_packed;
 
-- 
2.25.1



[PATCH v2 15/15] gen: add VXLAN support

2022-01-21 Thread Ronan Randles
This commit adds VXLAN parsing and logging functionality. Unit test with
additional test case to test_gen_packet_parse_string.

Signed-off-by: Ronan Randles 
---
 app/test/test_gen.c |  1 +
 lib/gen/rte_gen.c   | 50 +
 2 files changed, 51 insertions(+)

diff --git a/app/test/test_gen.c b/app/test/test_gen.c
index a0b00d6a6e..f05851831a 100644
--- a/app/test/test_gen.c
+++ b/app/test/test_gen.c
@@ -138,6 +138,7 @@ test_gen_packet_parse_string(void)
{ .str = "Ether()/IP(src=1.2.3.fail,dst=5.6.7.8)",
.expected_to_fail = 1},
{ .str = "Ether()/IP()/UDP()"},
+   { .str = "Ether()/IP()/UDP()/VXLAN()"},
};
 
uint32_t i;
diff --git a/lib/gen/rte_gen.c b/lib/gen/rte_gen.c
index 3a67ce8b6c..431ffc5b2a 100644
--- a/lib/gen/rte_gen.c
+++ b/lib/gen/rte_gen.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 RTE_LOG_REGISTER(gen_logtype, lib.gen, NOTICE);
 
@@ -140,6 +141,7 @@ enum GEN_PROTO {
GEN_PROTO_ETHER,
GEN_PROTO_IPV4,
GEN_PROTO_UDP,
+   GEN_PROTO_VXLAN,
 
/* Must be last. */
GEN_PROTO_COUNT,
@@ -472,6 +474,10 @@ gen_parse_udp(struct gen_parser *parser, char 
*protocol_str)
int err = gen_parser_parse_next(parser, &inner);
 
switch (inner) {
+   case GEN_PROTO_VXLAN:
+   udp->src_port = rte_cpu_to_be_16(RTE_VXLAN_DEFAULT_PORT);
+   udp->dst_port = rte_cpu_to_be_16(RTE_VXLAN_DEFAULT_PORT);
+   break;
default:
/* default to DNS like other packet generation tools */
udp->src_port = rte_cpu_to_be_16(53);
@@ -490,6 +496,44 @@ gen_parse_udp(struct gen_parser *parser, char 
*protocol_str)
return err;
 }
 
+static int32_t
+gen_parse_vxlan(struct gen_parser *parser, char *protocol_str)
+{
+   RTE_SET_USED(protocol_str);
+   struct rte_vxlan_hdr *vxlan = gen_parser_get_data_ptr(parser);
+   memset(vxlan, 0, sizeof(*vxlan));
+
+   uint32_t input_vni = 1000;
+   vxlan->vx_vni = rte_cpu_to_be_32(input_vni << 8);
+
+   /* Move up write pointer in packet. */
+   parser->buf_write_offset += sizeof(*vxlan);
+
+   enum GEN_PROTO inner;
+   int err = gen_parser_parse_next(parser, &inner);
+
+   vxlan->vx_flag_bits = RTE_VXLAN_FLAGS_I;
+
+   switch (inner) {
+   default:
+   /* Not supporting VXLAN-GPE and next proto today. */
+   break;
+   }
+
+   return err;
+}
+
+static void
+gen_log_vxlan(void *data, const char *indent)
+{
+   struct rte_vxlan_hdr *vxlan = data;
+
+   GEN_LOG_PROTOCOL(DEBUG,
+   "###[ VXLAN ]###\n%svx_flags= %u\n%svx_vni= %u\n",
+   indent, rte_be_to_cpu_32(vxlan->vx_flags),
+   indent, rte_be_to_cpu_32(vxlan->vx_vni));
+}
+
 /* (Name, Function-pointer) pairs for supported parse types */
 typedef int32_t (*gen_parse_func)(struct gen_parser *parser,
char *protocol_str);
@@ -520,6 +564,12 @@ static struct gen_parse_func_t gen_protocols[] = {
.proto = GEN_PROTO_UDP,
.parse_func = gen_parse_udp,
.log_func = gen_log_udp,
+   },
+   {
+   .name = "VXLAN(",
+   .proto = GEN_PROTO_VXLAN,
+   .parse_func = gen_parse_vxlan,
+   .log_func = gen_log_vxlan,
}
 
 };
-- 
2.25.1



Re: [PATCH v2 1/3] gpudev: mem alloc aligned memory

2022-01-21 Thread Thomas Monjalon
08/01/2022 01:20, eagost...@nvidia.com:
> From: Elena Agostini 
> 
> Similarly to rte_malloc, rte_gpu_mem_alloc accept as
> input the memory alignment size.
> 
> GPU driver should return GPU memory address aligned
> with the input value.
> 
> Changelog:
> - rte_gpu_mem_alloc parameters order
> 
> Signed-off-by: Elena Agostini 

Squashed and applied, thanks.





[dpdk-dev v1] crypto/qat: fix QAT GEN4 AEAD job in raw data path

2022-01-21 Thread Kai Ji
This patch fix the cipher params configuration in AEAD job if
QAT GEN4 unified cipher slice(UCS) enabled.

Fixes: 328d690d2f60 ("crypto/qat: update raw data path")
Cc: roy.fan.zh...@intel.com

Signed-off-by: Kai Ji 
---
 drivers/crypto/qat/qat_sym_hw_dp.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/qat/qat_sym_hw_dp.c 
b/drivers/crypto/qat/qat_sym_hw_dp.c
index 12825e448b..792ad2b213 100644
--- a/drivers/crypto/qat/qat_sym_hw_dp.c
+++ b/drivers/crypto/qat/qat_sym_hw_dp.c
@@ -533,8 +533,20 @@ enqueue_one_aead_job(struct qat_sym_session *ctx,
/* CPM 1.7 uses single pass to treat AEAD as cipher operation */
if (ctx->is_single_pass) {
enqueue_one_cipher_job(ctx, req, iv, ofs, data_len);
-   cipher_param->spc_aad_addr = aad->iova;
-   cipher_param->spc_auth_res_addr = digest->iova;
+
+   if (ctx->is_ucs) {
+   /* QAT GEN4 uses single pass to treat AEAD as cipher
+* operation
+*/
+   struct icp_qat_fw_la_cipher_20_req_params 
*cipher_param_20 =
+   (void *)&req->serv_specif_rqpars;
+   cipher_param_20->spc_aad_addr = aad->iova;
+   cipher_param_20->spc_auth_res_addr = digest->iova;
+   } else {
+   cipher_param->spc_aad_addr = aad->iova;
+   cipher_param->spc_auth_res_addr = digest->iova;
+   }
+
return;
}
 
-- 
2.30.2



RE: [dpdk-dev v1] crypto/qat: fix QAT GEN4 AEAD job in raw data path

2022-01-21 Thread Zhang, Roy Fan
> -Original Message-
> From: Ji, Kai 
> Sent: Friday, January 21, 2022 10:39 AM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Ji, Kai ; Zhang, Roy Fan
> 
> Subject: [dpdk-dev v1] crypto/qat: fix QAT GEN4 AEAD job in raw data path
> 
> This patch fix the cipher params configuration in AEAD job if
> QAT GEN4 unified cipher slice(UCS) enabled.
> 
> Fixes: 328d690d2f60 ("crypto/qat: update raw data path")
> Cc: roy.fan.zh...@intel.com
> 
> Signed-off-by: Kai Ji 
> ---
Nice catch, thanks!
Acked-by: Fan Zhang 


Re: [EXT] Re: [PATCH v3 21/29] crypto/cnxk: add more info on command timeout

2022-01-21 Thread Thomas Monjalon
21/01/2022 10:16, Akhil Goyal:
> > Note: this mistake is warned by the script devtools/checkpatches.sh
> >   Warning in drivers/crypto/cnxk/cnxk_cryptodev_ops.c:
> >   Using %l format, prefer %PRI*64 if type is [u]int64_t
> I believe there is something wrong in the reporting;
> it said 1 warning which is for spell check of head
> and in the end a line is added for another warning.
> I skipped this issue as it was a false positive for spelling. Did not see the 
> last line.
> 
> WARNING:TYPO_SPELLING: 'tHead' may be misspelled - perhaps 'thread'?
> #157: FILE: drivers/crypto/cnxk/cnxk_cryptodev_ops.c:718:
> + plt_print(" Head: %ld", pend_q->head);
> 
> total: 0 errors, 1 warnings, 84 lines checked
>   ^^  
> Warning in drivers/crypto/cnxk/cnxk_cryptodev_ops.c:
> Using %l format, prefer %PRI*64 if type is [u]int64_t

That's because they are 2 different checks.
The first total is from checkpatch.pl.




RE: [PATCH 05/12] gen: add raw packet data API and tests

2022-01-21 Thread Van Haaren, Harry
> -Original Message-
> From: Van Haaren, Harry
> Sent: Thursday, January 20, 2022 10:21 AM
> To: 'Thomas Monjalon' ; Randles, Ronan
> 
> Cc: dev@dpdk.org; Jerin Jacob ; dev@dpdk.org;
> Richardson, Bruce 
> Subject: RE: [PATCH 05/12] gen: add raw packet data API and tests



> But to summarize, it seems there are multiple questions/concerns around
> merging the gen library into DPDK. That's OK, this is not a critical feature 
> to
> upstream, I thought it might be useful to the wider community.
> 
> As some rework was done from the V1 to a V2, adding some protocols and
> generally
> advancing the library, Ronan and I will post the V2 to list to make it 
> publicly
> available.
> We can mark the V2 as "not applicable" in patchwork once sent.

As promised, the reworked V2 patches are available here;
http://patches.dpdk.org/project/dpdk/cover/20220121103122.2926856-1-ronan.rand...@intel.com/

They are marked as "not applicable" in patchwork, so will not be candidates
for merge, but are available for interested folks to work with.

I'd like to thank Ronan for his work on the Gen library during his internship,
it is useful tool for my testing usages, and I expect to continue using it in 
future!

Thanks community for reviews and suggestions on improving post-v1.

Regards, -Harry




RE: [PATCH v2 00/13] Add new cases to lookaside IPsec tests

2022-01-21 Thread Akhil Goyal
> Add new tests to lookaside IPsec tests.
> 
> * Support for chained operations.
> * AES-CBC 128 NULL auth known vector tests.
> * AES-CBC 128 HMAC-SHA256 known vector tests.
> * AES-CBC 128 HMAC-SHA384 known vector tests.
> * AES-CBC 128 HMAC-SHA512 known vector tests.
> * NULL cipher AES-XCBC known vector tests.
> * Tunnel mode tests
>   * IPv6 in IPv6
>   * IPv4 in IPv4
>   * IPv4 in IPv6
>   * IPv6 in IPv4
> * IPv4 transport mode tests.
> * Tunnel mode fragment packet tests.
> * Security stats tests.
> * AES-CTR tests.
> * set/copy DF tests.
> 
> Changes in v2:
> - Moved release notes update to originating patch
> - Fixed build failure with last patch
> 
> Ankur Dwivedi (1):
>   test/crypto: add security stats cases
> 
> Anoob Joseph (5):
>   test/crypto: add IPsec aes-cbc known vectors
>   test/crypto: add chained operations in combined cases
>   test/crypto: add transport mode cases
>   test/crypto: add aes xcbc known vectors
>   test/crypto: add copy and set DF cases
> 
> Tejasree Kondoj (7):
>   test/crypto: add IPsec AES-CBC-HMAC-SHA256 known vectors
>   test/crypto: add IPv6 tunnel mode cases
>   test/crypto: add IPsec HMAC-SHA384/512 known vectors
>   test/crypto: add IPsec fragmented packet known vectors
>   test/crypto: add lookaside IPsec AES-CTR known vectors
>   test/crypto: add fragmented packet case
>   test/crypto: skip null auth in ICV corrupt case
> 
>  app/test/test_cryptodev.c  | 395 +-
>  app/test/test_cryptodev_security_ipsec.c   | 352 -
>  app/test/test_cryptodev_security_ipsec.h   | 113 +++
>  .../test_cryptodev_security_ipsec_test_vectors.h   | 828
> +
>  doc/guides/rel_notes/release_22_03.rst |  19 +
>  5 files changed, 1665 insertions(+), 42 deletions(-)
> 
Series Acked-by: Akhil Goyal 

Applied to dpdk-next-crypto


RE: [EXT] [PATCH v2 8/8] crypto/dpaa_sec: add debug framework

2022-01-21 Thread Akhil Goyal
> Adding useful debug prints in DPAA driver for
> easy debugging.
> 
> Signed-off-by: Gagandeep Singh 
> ---
>  doc/guides/cryptodevs/dpaa_sec.rst |  10 ++
>  drivers/bus/dpaa/dpaa_bus.c|  16 ++-
>  drivers/crypto/dpaa_sec/dpaa_sec.c | 192 -
>  3 files changed, 213 insertions(+), 5 deletions(-)
> 
Fix checkpatch issues

Warning in drivers/crypto/dpaa_sec/dpaa_sec.c:
Using %l format, prefer %PRI*64 if type is [u]int64_t


RE: [EXT] [PATCH v2 5/8] crypto/dpaa2_sec: change digest size for AES_CMAC

2022-01-21 Thread Akhil Goyal
> From: Hemant Agrawal 
> 
> Change the digest size to supported value by the HW engine.
> 
> Signed-off-by: Hemant Agrawal 
> ---
>  drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
> b/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
> index 6aa1c01e95..ab652936bc 100644
> --- a/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
> +++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h
> @@ -579,11 +579,11 @@ static const struct rte_cryptodev_capabilities
> dpaa2_sec_capabilities[] = {
>   .increment = 1
>   },
>   .digest_size = {
> - .min = 4,
> + .min = 12,
>   .max = 16,
>   .increment = 4
>   },
> - .aad_size = { 0 }
> + .iv_size = { 0 }
Digest size is changed but why is aad_size removed in this patch.



RE: [PATCH 1/1] mempool: implement index-based per core cache

2022-01-21 Thread Ananyev, Konstantin


Hi Dharmik,
> >
> >>>
>  Current mempool per core cache implementation stores pointers to mbufs
>  On 64b architectures, each pointer consumes 8B
>  This patch replaces it with index-based implementation,
>  where in each buffer is addressed by (pool base address + index)
>  It reduces the amount of memory/cache required for per core cache
> 
>  L3Fwd performance testing reveals minor improvements in the cache
>  performance (L1 and L2 misses reduced by 0.60%)
>  with no change in throughput
> >>>
> >>> I feel really sceptical about that patch and the whole idea in general:
> >>> - From what I read above there is no real performance improvement 
> >>> observed.
> >>> (In fact on my IA boxes mempool_perf_autotest reports ~20% slowdown,
> >>> see below for more details).
> >>
> >> Currently, the optimizations (loop unroll and vectorization) are only 
> >> implemented for ARM64.
> >> Similar optimizations can be implemented for x86 platforms which should 
> >> close the performance gap
> >> and in my understanding should give better performance for a bulk size of 
> >> 32.
> >
> > Might be, but I still don't see the reason for such effort.
> > As you mentioned there is no performance improvement in 'real' apps: l3fwd, 
> > etc.
> > on ARM64 even with vectorized version of the code.
> >
> 
> IMO, even without performance improvement, it is advantageous because the 
> same performance is being achieved
> with less memory and cache utilization using the patch.
> 
> >>> - Space utilization difference looks neglectable too.
> >>
> >> Sorry, I did not understand this point.
> >
> > As I understand one of the expectations from that patch was:
> > reduce memory/cache required, which should improve cache utilization
> > (less misses, etc.).
> > Though I think such improvements would be neglectable and wouldn't
> > cause any real performance gain.
> 
> The cache utilization performance numbers are for the l3fwd app, which might 
> not be bottlenecked at the mempool per core cache.
> Theoretically, this patch enables storing twice the number of objects in the 
> cache as compared to the original implementation.

It saves you 4 just bytes per mbuf.
Even for simple l2fwd-like workload we access ~100 bytes per mbuf.
Let's do a simplistic estimation of  number of affected cache-lines l for 
l2fwd. 
For bulk of 32 packets, assuming 64B per cache-line and 16B per HW desc:

   number 
of cache-lines accessed 
   cache with 
pointers / cache with indexes 
mempool_get:(32*8)/64=4  /  
(32*4)/64=2
RX (read HW desc):(32*16)/64=8   /   
(32*16)/64=8
RX (write mbuf fields, 1st cache line):(32*64)/64=3   /   (32*64)/64=32
update mac addrs: (32*64)/64=32 /   
(32*64)/64=32   
TX (write HW desc):   (32*16)/64=8   /   
(32*16)/64=8
free mbufs (read 2nd mbuf cache line): (32*64)/64=32/   (32*64)/64=32   
mempool_put:(32*8)/64=4/
(32*4)/64=2
total: 120  
   116

So, if my calculations are correct, max estimated gain for cache utilization 
would be:
(120-116)*100/120=3.33% 
Note that numbers are for over-simplistic usage scenario.
In more realistic ones, when we have to touch more cache-lines per packet,
that difference would be even less noticeable.
So I really doubt we will see some noticeable improvements in terms of cache 
utilization
with that patch.

> >
> >>> - The change introduces a new build time config option with a major 
> >>> limitation:
> >>>  All memzones in a pool have to be within the same 4GB boundary.
> >>>  To address it properly, extra changes will be required in 
> >>> init(/populate) part of the code.
> >>
> >> I agree to the above mentioned challenges and I am currently working on 
> >> resolving these issues.
> >
> > I still think that to justify such changes some really noticeable 
> > performance
> > improvement needs to be demonstrated: double-digit speedup for 
> > l3fwd/ipsec-secgw/...
> > Otherwise it just not worth the hassle.
> >
> 
> Like I mentioned earlier, the app might not be bottlenecked at the mempool 
> per core cache.
> That could be the reason the numbers with l3fwd don’t fully show the 
> advantage of the patch.

As I said above, I don’t think we'll see any real advantage here.
But feel free to pick-up different app and prove me wrong.
After all we have plenty of sample apps that do provide enough
pressure on the cache: l3fwd-acl, ipsec-secgw.
Or you can even apply these patches from Sean:
https://patches.dpdk.org/project/dpdk/list/?series=20999
to run l3fwd with configurable routes.
That should help you to make it

RE: [EXT] [PATCH v2 4/8] crypto/dpaa2_sec: support AES-GMAC

2022-01-21 Thread Akhil Goyal
> From: Akhil Goyal 
> 
> This patch supports AES_GMAC algorithm for DPAA2
> driver.
> 
> Signed-off-by: Akhil Goyal 
> Signed-off-by: Gagandeep Singh 
> ---
>  doc/guides/cryptodevs/features/dpaa2_sec.ini |  1 +
>  drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c  | 14 -
>  drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h| 30 
>  lib/cryptodev/rte_crypto_sym.h   |  4 ++-
>  4 files changed, 47 insertions(+), 2 deletions(-)

This patch should be split in two - cryptodev change should be separate patch.

> diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
> index daa090b978..4644fa3e25 100644
> --- a/lib/cryptodev/rte_crypto_sym.h
> +++ b/lib/cryptodev/rte_crypto_sym.h
> @@ -467,8 +467,10 @@ enum rte_crypto_aead_algorithm {
>   /**< AES algorithm in CCM mode. */
>   RTE_CRYPTO_AEAD_AES_GCM,
>   /**< AES algorithm in GCM mode. */
> - RTE_CRYPTO_AEAD_CHACHA20_POLY1305
> + RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
>   /**< Chacha20 cipher with poly1305 authenticator */
> + RTE_CRYPTO_AEAD_AES_GMAC
> + /**< AES algorithm in GMAC mode. */
>  };
AES-GMAC is also defined as AUTH algo. It may be removed but that would be
ABI break.
Is it not possible to use AES-GMAC as auth algo?


RE: [EXT] [PATCH v2 3/8] crypto/dpaa2_sec: ordered queue support

2022-01-21 Thread Akhil Goyal
> From: Nipun Gupta 
> 
> This patch supports ordered queue for DPAA2 platform.
> 
> Signed-off-by: Nipun Gupta 
> ---
>  drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 255 +++-
>  drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h   |   8 +-
>  drivers/crypto/dpaa2_sec/mc/fsl_dpseci.h|  14 +-
>  3 files changed, 263 insertions(+), 14 deletions(-)
> 

> +static uint16_t
> +dpaa2_sec_enqueue_burst_ordered(void *qp, struct rte_crypto_op **ops,
> + uint16_t nb_ops)
> +{
> + /* Function to transmit the frames to given device and VQ*/
> + uint32_t loop;
> + int32_t ret;
> + struct qbman_fd fd_arr[MAX_TX_RING_SLOTS];
> + uint32_t frames_to_send, num_free_eq_desc, retry_count;
> + struct qbman_eq_desc eqdesc[MAX_TX_RING_SLOTS];
> + struct dpaa2_sec_qp *dpaa2_qp = (struct dpaa2_sec_qp *)qp;
> + struct qbman_swp *swp;
> + uint16_t num_tx = 0;
> + /*todo - need to support multiple buffer pools */

Remove/fix TODO

> 
> @@ -3780,6 +3983,40 @@ dpaa2_sec_eventq_attach(const struct
> rte_cryptodev *dev,
>   cfg.options |= DPSECI_QUEUE_OPT_ORDER_PRESERVATION;
>   cfg.order_preservation_en = 1;
>   }
> +
> + if (event->sched_type == RTE_SCHED_TYPE_ORDERED) {
> + struct opr_cfg ocfg;
> +
> + /* Restoration window size = 256 frames */
> + ocfg.oprrws = 3;
> + /* Restoration window size = 512 frames for LX2 */
> + if (dpaa2_svr_family == SVR_LX2160A)
> + ocfg.oprrws = 4;
> + /* Auto advance NESN window enabled */
> + ocfg.oa = 1;
> + /* Late arrival window size disabled */
> + ocfg.olws = 0;
> + /* ORL resource exhaustaion advance NESN disabled */
> + ocfg.oeane = 0;
> + /* Loose ordering enabled */
> + ocfg.oloe = 1;
> + priv->en_loose_ordered = 1;
> + /* Strict ordering enabled if explicitly set */
> + if (getenv("DPAA2_STRICT_ORDERING_ENABLE")) {
> + ocfg.oloe = 0;
> + priv->en_loose_ordered = 0;
> + }

Can we use devarg to enable strict ordering instead of env variable?
Also need to document this.




RE: [PATCH 1/1] mempool: implement index-based per core cache

2022-01-21 Thread Ananyev, Konstantin


> 
> 
> Hi Dharmik,
> > >
> > >>>
> >  Current mempool per core cache implementation stores pointers to mbufs
> >  On 64b architectures, each pointer consumes 8B
> >  This patch replaces it with index-based implementation,
> >  where in each buffer is addressed by (pool base address + index)
> >  It reduces the amount of memory/cache required for per core cache
> > 
> >  L3Fwd performance testing reveals minor improvements in the cache
> >  performance (L1 and L2 misses reduced by 0.60%)
> >  with no change in throughput
> > >>>
> > >>> I feel really sceptical about that patch and the whole idea in general:
> > >>> - From what I read above there is no real performance improvement 
> > >>> observed.
> > >>> (In fact on my IA boxes mempool_perf_autotest reports ~20% slowdown,
> > >>> see below for more details).
> > >>
> > >> Currently, the optimizations (loop unroll and vectorization) are only 
> > >> implemented for ARM64.
> > >> Similar optimizations can be implemented for x86 platforms which should 
> > >> close the performance gap
> > >> and in my understanding should give better performance for a bulk size 
> > >> of 32.
> > >
> > > Might be, but I still don't see the reason for such effort.
> > > As you mentioned there is no performance improvement in 'real' apps: 
> > > l3fwd, etc.
> > > on ARM64 even with vectorized version of the code.
> > >
> >
> > IMO, even without performance improvement, it is advantageous because the 
> > same performance is being achieved
> > with less memory and cache utilization using the patch.
> >
> > >>> - Space utilization difference looks neglectable too.
> > >>
> > >> Sorry, I did not understand this point.
> > >
> > > As I understand one of the expectations from that patch was:
> > > reduce memory/cache required, which should improve cache utilization
> > > (less misses, etc.).
> > > Though I think such improvements would be neglectable and wouldn't
> > > cause any real performance gain.
> >
> > The cache utilization performance numbers are for the l3fwd app, which 
> > might not be bottlenecked at the mempool per core cache.
> > Theoretically, this patch enables storing twice the number of objects in 
> > the cache as compared to the original implementation.
> 
> It saves you 4 just bytes per mbuf.
> Even for simple l2fwd-like workload we access ~100 bytes per mbuf.
> Let's do a simplistic estimation of  number of affected cache-lines l for 
> l2fwd.
> For bulk of 32 packets, assuming 64B per cache-line and 16B per HW desc:
> 
>number 
> of cache-lines accessed
>cache with 
> pointers / cache with indexes
> mempool_get:(32*8)/64=4  
> /  (32*4)/64=2
> RX (read HW desc):(32*16)/64=8   /   
> (32*16)/64=8
> RX (write mbuf fields, 1st cache line):(32*64)/64=3   /   
> (32*64)/64=32

Should be:
RX (write mbuf fields, 1st cache line):(32*64)/64=32   /   (32*64)/64=32
off course

> update mac addrs: (32*64)/64=32 /   
> (32*64)/64=32
> TX (write HW desc):   (32*16)/64=8   /   
> (32*16)/64=8
> free mbufs (read 2nd mbuf cache line): (32*64)/64=32/   (32*64)/64=32
> mempool_put:(32*8)/64=4/  
>   (32*4)/64=2
> total: 120
>  116
> 
> So, if my calculations are correct, max estimated gain for cache utilization 
> would be:
> (120-116)*100/120=3.33%
> Note that numbers are for over-simplistic usage scenario.
> In more realistic ones, when we have to touch more cache-lines per packet,
> that difference would be even less noticeable.
> So I really doubt we will see some noticeable improvements in terms of cache 
> utilization
> with that patch.
> 
> > >
> > >>> - The change introduces a new build time config option with a major 
> > >>> limitation:
> > >>>  All memzones in a pool have to be within the same 4GB boundary.
> > >>>  To address it properly, extra changes will be required in 
> > >>> init(/populate) part of the code.
> > >>
> > >> I agree to the above mentioned challenges and I am currently working on 
> > >> resolving these issues.
> > >
> > > I still think that to justify such changes some really noticeable 
> > > performance
> > > improvement needs to be demonstrated: double-digit speedup for 
> > > l3fwd/ipsec-secgw/...
> > > Otherwise it just not worth the hassle.
> > >
> >
> > Like I mentioned earlier, the app might not be bottlenecked at the mempool 
> > per core cache.
> > That could be the reason the numbers with l3fwd don’t fully show the 
> > advantage of the patch.
> 
> As I said above, I don’t think we'll see any real advantage here.
> But feel free to pick-u

Re: [EXT] [PATCH] examples/l3fwd: fix Rx burst size for event mode

2022-01-21 Thread Jerin Jacob
On Tue, Jan 18, 2022 at 4:08 PM Sunil Kumar Kori  wrote:
>
>
>
> Regards
> Sunil Kumar Kori
>
> >-Original Message-
> >From: nipun.gu...@nxp.com 
> >Sent: Tuesday, January 11, 2022 10:36 AM
> >To: dev@dpdk.org
> >Cc: Jerin Jacob Kollanukkaran ; Sunil Kumar Kori
> >; tho...@monjalon.net; hemant.agra...@nxp.com;
> >sta...@dpdk.org; Nipun Gupta 
> >Subject: [EXT] [PATCH] examples/l3fwd: fix Rx burst size for event mode
> >
> >External Email
> >
> >--
> >From: Nipun Gupta 
> >
> >While dequeing the packets from the event device, burst size is provided in

dequeuing

> >the API. This was not getting properly conigured in the application. This 
> >patch

configured

> >correctly configures the burst size.
> >
> >Fixes: aaf58cb85b62 ("examples/l3fwd: add event port and queue setup")
> >Cc: sta...@dpdk.org
> >
> >Signed-off-by: Nipun Gupta 
> >---

>
> Acked-by: Sunil Kumar Kori 
>

Fixed above typo
Applied to dpdk-next-net-eventdev/for-main. Thanks


[PATCH v2 01/10] common/cnxk: fix shift offset for TL3 length disable

2022-01-21 Thread Nithin Dabilpuram
Fix shift offset for length disable flag in NIXX_AF_TL3X_SHAPE
register to be 24 instead of zero similar to other level SHAPE
registers. Also mask unused bits in adjust value.

Fixes: 0885429c3028 ("common/cnxk: add NIX TM hierarchy enable/disable")
Cc: sta...@dpdk.org

Signed-off-by: Nithin Dabilpuram 
Signed-off-by: Satha Rao 
---

v2:
- Updated series from Jerin
- Handle comments from Ferruh in patch 3/8.
- Split patch 6/8 to two patches 
- Split patch 7/8 to two patches

 drivers/common/cnxk/roc_nix_tm_utils.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_nix_tm_utils.c 
b/drivers/common/cnxk/roc_nix_tm_utils.c
index 543adf9..9e80c2a 100644
--- a/drivers/common/cnxk/roc_nix_tm_utils.c
+++ b/drivers/common/cnxk/roc_nix_tm_utils.c
@@ -642,6 +642,7 @@ nix_tm_shaper_reg_prep(struct nix_tm_node *node,
else if (profile)
adjust = profile->pkt_len_adj;
 
+   adjust &= 0x1FF;
plt_tm_dbg("Shaper config node %s(%u) lvl %u id %u, "
   "pir %" PRIu64 "(%" PRIu64 "B),"
   " cir %" PRIu64 "(%" PRIu64 "B)"
@@ -708,7 +709,7 @@ nix_tm_shaper_reg_prep(struct nix_tm_node *node,
/* Configure RED algo */
reg[k] = NIX_AF_TL3X_SHAPE(schq);
regval[k] = (adjust | (uint64_t)node->red_algo << 9 |
-(uint64_t)node->pkt_mode);
+(uint64_t)node->pkt_mode << 24);
k++;
 
break;
-- 
2.8.4



[PATCH v2 02/10] common/cnxk: use for loop in shaper profiles cleanup

2022-01-21 Thread Nithin Dabilpuram
From: Gowrishankar Muthukrishnan 

In shaper profiles cleanup, Klockwork static analyzer tool reports
infinite loop although existing loop condition is alright.
False positive may be due to tqh_first not checked in loop,
hence switching to FOREACH_SAFE to make Klockwork happy.

Signed-off-by: Gowrishankar Muthukrishnan 
Signed-off-by: Shijith Thotton 
Acked-by: Jerin Jacob 
---
 drivers/common/cnxk/roc_nix_tm.c   | 8 
 drivers/common/cnxk/roc_platform.h | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/common/cnxk/roc_nix_tm.c b/drivers/common/cnxk/roc_nix_tm.c
index b3d8ebd..fe9e83f 100644
--- a/drivers/common/cnxk/roc_nix_tm.c
+++ b/drivers/common/cnxk/roc_nix_tm.c
@@ -17,16 +17,16 @@ bitmap_ctzll(uint64_t slab)
 void
 nix_tm_clear_shaper_profiles(struct nix *nix)
 {
-   struct nix_tm_shaper_profile *shaper_profile;
+   struct nix_tm_shaper_profile *shaper_profile, *tmp;
+   struct nix_tm_shaper_profile_list *list;
 
-   shaper_profile = TAILQ_FIRST(&nix->shaper_profile_list);
-   while (shaper_profile != NULL) {
+   list = &nix->shaper_profile_list;
+   PLT_TAILQ_FOREACH_SAFE(shaper_profile, list, shaper, tmp) {
if (shaper_profile->ref_cnt)
plt_warn("Shaper profile %u has non zero references",
 shaper_profile->id);
TAILQ_REMOVE(&nix->shaper_profile_list, shaper_profile, shaper);
nix_tm_shaper_profile_free(shaper_profile);
-   shaper_profile = TAILQ_FIRST(&nix->shaper_profile_list);
}
 }
 
diff --git a/drivers/common/cnxk/roc_platform.h 
b/drivers/common/cnxk/roc_platform.h
index 85aa6dc..adcd2fa 100644
--- a/drivers/common/cnxk/roc_platform.h
+++ b/drivers/common/cnxk/roc_platform.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "roc_bits.h"
@@ -53,6 +54,7 @@
 #define BITMASK_ULL GENMASK_ULL
 #define PLT_ALIGN_CEIL  RTE_ALIGN_CEIL
 #define PLT_INITRTE_INIT
+#define PLT_TAILQ_FOREACH_SAFE  RTE_TAILQ_FOREACH_SAFE
 
 /** Divide ceil */
 #define PLT_DIV_CEIL(x, y) \
-- 
2.8.4



[PATCH v2 03/10] common/cnxk: fix byte order of frag sizes and infos

2022-01-21 Thread Nithin Dabilpuram
Change the byte order of frag sizes and infos to match HW
implementation.

Fixes: 64a73ebd87bd ("common/cnxk: add CPT hardware definitions")
Cc: sta...@dpdk.org

Signed-off-by: Nithin Dabilpuram 
Signed-off-by: Vidya Sagar Velumuri 
---
 drivers/common/cnxk/hw/cpt.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/common/cnxk/hw/cpt.h b/drivers/common/cnxk/hw/cpt.h
index 919f842..3ade4dc 100644
--- a/drivers/common/cnxk/hw/cpt.h
+++ b/drivers/common/cnxk/hw/cpt.h
@@ -286,10 +286,11 @@ struct cpt_frag_info_s {
union {
uint64_t u64;
struct {
-   union cpt_frag_info f3;
-   union cpt_frag_info f2;
-   union cpt_frag_info f1;
+   /* CPT HW swaps each 8B word implicitly */
union cpt_frag_info f0;
+   union cpt_frag_info f1;
+   union cpt_frag_info f2;
+   union cpt_frag_info f3;
};
} w0;
 
@@ -297,10 +298,11 @@ struct cpt_frag_info_s {
union {
uint64_t u64;
struct {
-   uint16_t frag_size3;
-   uint16_t frag_size2;
-   uint16_t frag_size1;
+   /* CPT HW swaps each 8B word implicitly */
uint16_t frag_size0;
+   uint16_t frag_size1;
+   uint16_t frag_size2;
+   uint16_t frag_size3;
};
} w1;
 };
-- 
2.8.4



[PATCH v2 04/10] common/cnxk: reset stale values on error debug registers

2022-01-21 Thread Nithin Dabilpuram
From: Harman Kalra 

LF's error debug registers like NIX_LF_SQ_OP_ERR_DBG,
NIX_LF_MNQ_ERR_DBG, NIX_LF_SEND_ERR_DBG captures debug
info for an error detected during LMT operation or meta
enqueue or after meta enqueue granted respectively. HW
sets a valid bit when info is captured and SW is expected
to clear this valid bit by writing 1, else these registers
will show stale values of first interrupt when occurred and
will never update with subsequent interrupts.

Signed-off-by: Harman Kalra 
Acked-by: Jerin Jacob 
---
 drivers/common/cnxk/roc_nix_irq.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_nix_irq.c 
b/drivers/common/cnxk/roc_nix_irq.c
index a5cd9d4..7dcd533 100644
--- a/drivers/common/cnxk/roc_nix_irq.c
+++ b/drivers/common/cnxk/roc_nix_irq.c
@@ -202,9 +202,12 @@ nix_lf_sq_debug_reg(struct nix *nix, uint32_t off)
uint64_t reg;
 
reg = plt_read64(nix->base + off);
-   if (reg & BIT_ULL(44))
+   if (reg & BIT_ULL(44)) {
plt_err("SQ=%d err_code=0x%x", (int)((reg >> 8) & 0xf),
(uint8_t)(reg & 0xff));
+   /* Clear valid bit */
+   plt_write64(BIT_ULL(44), nix->base + off);
+   }
 }
 
 static void
-- 
2.8.4



[PATCH v2 05/10] common/cnxk: always use single interrupt ID with NIX

2022-01-21 Thread Nithin Dabilpuram
From: Harman Kalra 

An errata exists whereby, in certain cases NIX may use an
incorrect QINT_IDX for SQ interrupts. As a result, the
interrupt may not be delivered to software, or may not be
associated with the correct SQ.
When NIX uses an incorrect QINT_IDX :
1. NIX_LF_QINT(0..63)_CNT[COUNT] will be incremented for
incorrect QINT.
2. NIX_LF_QINT(0..63)_INT[INTR] will be set for incorrect
QINT.

Signed-off-by: Harman Kalra 
Acked-by: Jerin Jacob 
---
 drivers/common/cnxk/roc_nix_queue.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/common/cnxk/roc_nix_queue.c 
b/drivers/common/cnxk/roc_nix_queue.c
index c638cd4..80e1c9f 100644
--- a/drivers/common/cnxk/roc_nix_queue.c
+++ b/drivers/common/cnxk/roc_nix_queue.c
@@ -690,7 +690,11 @@ sq_cn9k_init(struct nix *nix, struct roc_nix_sq *sq, 
uint32_t rr_quantum,
aq->sq.sq_int_ena |= BIT(NIX_SQINT_MNQ_ERR);
 
/* Many to one reduction */
-   aq->sq.qint_idx = sq->qid % nix->qints;
+   /* Assigning QINT 0 to all the SQs, an errata exists where NIXTX can
+* send incorrect QINT_IDX when reporting queue interrupt (QINT). This
+* might result in software missing the interrupt.
+*/
+   aq->sq.qint_idx = 0;
 }
 
 static int
@@ -789,8 +793,11 @@ sq_init(struct nix *nix, struct roc_nix_sq *sq, uint32_t 
rr_quantum,
aq->sq.sq_int_ena |= BIT(NIX_SQINT_SEND_ERR);
aq->sq.sq_int_ena |= BIT(NIX_SQINT_MNQ_ERR);
 
-   /* Many to one reduction */
-   aq->sq.qint_idx = sq->qid % nix->qints;
+   /* Assigning QINT 0 to all the SQs, an errata exists where NIXTX can
+* send incorrect QINT_IDX when reporting queue interrupt (QINT). This
+* might result in software missing the interrupt.
+*/
+   aq->sq.qint_idx = 0;
 }
 
 static int
-- 
2.8.4



[PATCH v2 06/10] common/cnxk: fix null pointer dereferences

2022-01-21 Thread Nithin Dabilpuram
Fix null pointer dereference issues reported by
klockwork(static analysis tool).

Fixes: c045d2e5cbbc ("common/cnxk: add CPT configuration")
Fixes: 585bb3e538f9 ("common/cnxk: add VF support to base device class")
Fixes: 665ff1ccc2c4 ("common/cnxk: add base device class")
Fixes: da57d4589a6f ("common/cnxk: support NIX flow control")
Fixes: 218d022e1f3f ("common/cnxk: support NIX stats")
Fixes: 4efa6e82fe43 ("common/cnxk: support NIX extended stats")
Fixes: 0885429c3028 ("common/cnxk: add NIX TM hierarchy enable/disable")
Cc: sta...@dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan 
Signed-off-by: Nithin Dabilpuram 
Acked-by: Jerin Jacob 
---
 drivers/common/cnxk/roc_cpt.c   |  3 ++
 drivers/common/cnxk/roc_dev.c   | 19 
 drivers/common/cnxk/roc_nix_debug.c |  6 
 drivers/common/cnxk/roc_nix_fc.c| 12 
 drivers/common/cnxk/roc_nix_queue.c | 61 ++---
 drivers/common/cnxk/roc_nix_stats.c | 18 +++
 drivers/common/cnxk/roc_nix_tm.c|  6 
 7 files changed, 121 insertions(+), 4 deletions(-)

diff --git a/drivers/common/cnxk/roc_cpt.c b/drivers/common/cnxk/roc_cpt.c
index 8f8e6d3..84cc5f0 100644
--- a/drivers/common/cnxk/roc_cpt.c
+++ b/drivers/common/cnxk/roc_cpt.c
@@ -385,6 +385,9 @@ cpt_lfs_alloc(struct dev *dev, uint8_t eng_grpmsk, uint8_t 
blkaddr,
return -EINVAL;
 
req = mbox_alloc_msg_cpt_lf_alloc(mbox);
+   if (!req)
+   return -ENOSPC;
+
req->nix_pf_func = 0;
if (inl_dev_sso && nix_inl_dev_pffunc_get())
req->sso_pf_func = nix_inl_dev_pffunc_get();
diff --git a/drivers/common/cnxk/roc_dev.c b/drivers/common/cnxk/roc_dev.c
index 926a916..0ac50ca 100644
--- a/drivers/common/cnxk/roc_dev.c
+++ b/drivers/common/cnxk/roc_dev.c
@@ -152,6 +152,11 @@ af_pf_wait_msg(struct dev *dev, uint16_t vf, int num_msg)
/* Reserve PF/VF mbox message */
size = PLT_ALIGN(size, MBOX_MSG_ALIGN);
rsp = mbox_alloc_msg(&dev->mbox_vfpf, vf, size);
+   if (!rsp) {
+   plt_err("Failed to reserve VF%d message", vf);
+   continue;
+   }
+
mbox_rsp_init(msg->id, rsp);
 
/* Copy message from AF<->PF mbox to PF<->VF mbox */
@@ -236,6 +241,12 @@ vf_pf_process_msgs(struct dev *dev, uint16_t vf)
BIT_ULL(vf % max_bits);
rsp = (struct ready_msg_rsp *)mbox_alloc_msg(
mbox, vf, sizeof(*rsp));
+   if (!rsp) {
+   plt_err("Failed to alloc VF%d READY message",
+   vf);
+   continue;
+   }
+
mbox_rsp_init(msg->id, rsp);
 
/* PF/VF function ID */
@@ -988,6 +999,9 @@ dev_setup_shared_lmt_region(struct mbox *mbox, bool 
valid_iova, uint64_t iova)
struct lmtst_tbl_setup_req *req;
 
req = mbox_alloc_msg_lmtst_tbl_setup(mbox);
+   if (!req)
+   return -ENOSPC;
+
/* This pcifunc is defined with primary pcifunc whose LMT address
 * will be shared. If call contains valid IOVA, following pcifunc
 * field is of no use.
@@ -1061,6 +1075,11 @@ dev_lmt_setup(struct dev *dev)
 */
if (!dev->disable_shared_lmt) {
idev = idev_get_cfg();
+   if (!idev) {
+   errno = EFAULT;
+   goto free;
+   }
+
if (!__atomic_load_n(&idev->lmt_pf_func, __ATOMIC_ACQUIRE)) {
idev->lmt_base_addr = dev->lmt_base;
idev->lmt_pf_func = dev->pf_func;
diff --git a/drivers/common/cnxk/roc_nix_debug.c 
b/drivers/common/cnxk/roc_nix_debug.c
index 266935a..7dc54f3 100644
--- a/drivers/common/cnxk/roc_nix_debug.c
+++ b/drivers/common/cnxk/roc_nix_debug.c
@@ -323,6 +323,9 @@ nix_q_ctx_get(struct dev *dev, uint8_t ctype, uint16_t qid, 
__io void **ctx_p)
int rc;
 
aq = mbox_alloc_msg_nix_aq_enq(mbox);
+   if (!aq)
+   return -ENOSPC;
+
aq->qidx = qid;
aq->ctype = ctype;
aq->op = NIX_AQ_INSTOP_READ;
@@ -341,6 +344,9 @@ nix_q_ctx_get(struct dev *dev, uint8_t ctype, uint16_t qid, 
__io void **ctx_p)
struct nix_cn10k_aq_enq_req *aq;
 
aq = mbox_alloc_msg_nix_cn10k_aq_enq(mbox);
+   if (!aq)
+   return -ENOSPC;
+
aq->qidx = qid;
aq->ctype = ctype;
aq->op = NIX_AQ_INSTOP_READ;
diff --git a/drivers/common/cnxk/roc_nix_fc.c b/drivers/common/cnxk/roc_nix_fc.c
index ca29cd2..d311371 100644
--- a/drivers/common/cnxk/roc_nix_fc.c
+++ b/drivers/common/cnxk/roc_nix_fc.c
@@ -113,6 +113,9 @@ nix_fc_cq_config_get(struct roc_nix *r

[PATCH v2 07/10] common/cnxk: fix uninitialized variable issues

2022-01-21 Thread Nithin Dabilpuram
Fix uninitialized variable issues reported by
klockwork(static analysis tool).

Fixes: ed135040f0ab ("common/cnxk: add CPT LF configuration")
Fixes: 585bb3e538f9 ("common/cnxk: add VF support to base device class")
Fixes: 58debb813a8d ("common/cnxk: enable TM to listen on Rx pause frames")

Cc: sta...@dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan 
Signed-off-by: Nithin Dabilpuram 
Acked-by: Jerin Jacob 
---
 drivers/common/cnxk/roc_cpt.c| 4 ++--
 drivers/common/cnxk/roc_dev.c| 2 +-
 drivers/common/cnxk/roc_nix_tm.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/common/cnxk/roc_cpt.c b/drivers/common/cnxk/roc_cpt.c
index 84cc5f0..0e2dc45 100644
--- a/drivers/common/cnxk/roc_cpt.c
+++ b/drivers/common/cnxk/roc_cpt.c
@@ -815,9 +815,9 @@ roc_cpt_eng_grp_add(struct roc_cpt *roc_cpt, enum 
cpt_eng_type eng_type)
 void
 roc_cpt_iq_disable(struct roc_cpt_lf *lf)
 {
+   volatile union cpt_lf_q_grp_ptr grp_ptr = {.u = 0x0};
+   volatile union cpt_lf_inprog lf_inprog = {.u = 0x0};
union cpt_lf_ctl lf_ctl = {.u = 0x0};
-   union cpt_lf_q_grp_ptr grp_ptr;
-   union cpt_lf_inprog lf_inprog;
int timeout = 20;
int cnt;
 
diff --git a/drivers/common/cnxk/roc_dev.c b/drivers/common/cnxk/roc_dev.c
index 0ac50ca..9a86969 100644
--- a/drivers/common/cnxk/roc_dev.c
+++ b/drivers/common/cnxk/roc_dev.c
@@ -57,7 +57,7 @@ pf_af_sync_msg(struct dev *dev, struct mbox_msghdr **rsp)
struct mbox *mbox = dev->mbox;
struct mbox_dev *mdev = &mbox->dev[0];
 
-   volatile uint64_t int_status;
+   volatile uint64_t int_status = 0;
struct mbox_msghdr *msghdr;
uint64_t off;
int rc = 0;
diff --git a/drivers/common/cnxk/roc_nix_tm.c b/drivers/common/cnxk/roc_nix_tm.c
index 3b38cc0..a0448be 100644
--- a/drivers/common/cnxk/roc_nix_tm.c
+++ b/drivers/common/cnxk/roc_nix_tm.c
@@ -424,7 +424,7 @@ nix_tm_bp_config_get(struct roc_nix *roc_nix, bool 
*is_enabled)
 
if (req) {
req->num_regs = k;
-   rc = mbox_process(mbox);
+   rc = mbox_process_msg(mbox, (void **)&rsp);
if (rc)
goto err;
/* Report it as enabled only if enabled or all */
-- 
2.8.4



[PATCH v2 08/10] net/cnxk: improve inbound inline error handling for cn9k

2022-01-21 Thread Nithin Dabilpuram
Improve inbound inline error handling for CN9K in terms of
packet delivered to application for different kinds of errors.

Signed-off-by: Nithin Dabilpuram 
---
 drivers/common/cnxk/roc_ie_on.h | 16 -
 drivers/net/cnxk/cn9k_rx.h  | 50 +++--
 2 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/drivers/common/cnxk/roc_ie_on.h b/drivers/common/cnxk/roc_ie_on.h
index 53591c6..376e698 100644
--- a/drivers/common/cnxk/roc_ie_on.h
+++ b/drivers/common/cnxk/roc_ie_on.h
@@ -188,7 +188,21 @@ struct roc_ie_on_inb_sa {
 #define ROC_IE_ONF_MAJOR_OP_PROCESS_INBOUND_IPSEC  0x26UL
 
 /* Ucode completion codes */
-#define ROC_IE_ONF_UCC_SUCCESS 0
+#define ROC_IE_ON_UCC_SUCCESS0
+#define ROC_IE_ON_UCC_ENC_TYPE_ERR   0xB1
+#define ROC_IE_ON_UCC_IP_VER_ERR 0xB2
+#define ROC_IE_ON_UCC_PROTO_ERR  0xB3
+#define ROC_IE_ON_UCC_CTX_INVALID0xB4
+#define ROC_IE_ON_UCC_CTX_DIR_MISMATCH   0xB5
+#define ROC_IE_ON_UCC_IP_PAYLOAD_TYPE_ERR 0xB6
+#define ROC_IE_ON_UCC_CTX_FLAG_MISMATCH  0xB7
+#define ROC_IE_ON_UCC_SPI_MISMATCH   0xBE
+#define ROC_IE_ON_UCC_IP_CHKSUM_ERR  0xBF
+#define ROC_IE_ON_UCC_AUTH_ERR   0xC3
+#define ROC_IE_ON_UCC_PADDING_INVALID0xC4
+#define ROC_IE_ON_UCC_SA_MISMATCH0xCC
+#define ROC_IE_ON_UCC_L2_HDR_INFO_ERR0xCF
+#define ROC_IE_ON_UCC_L2_HDR_LEN_ERR 0xE0
 
 struct roc_ie_onf_sa_ctl {
uint32_t spi;
diff --git a/drivers/net/cnxk/cn9k_rx.h b/drivers/net/cnxk/cn9k_rx.h
index 225bb41..cbb6299 100644
--- a/drivers/net/cnxk/cn9k_rx.h
+++ b/drivers/net/cnxk/cn9k_rx.h
@@ -211,6 +211,52 @@ ipsec_antireplay_check(struct roc_onf_ipsec_inb_sa *sa,
return rc;
 }
 
+static inline uint64_t
+nix_rx_sec_mbuf_err_update(const union nix_rx_parse_u *rx, uint16_t res,
+  uint64_t *rearm_val, uint16_t *len)
+{
+   uint8_t uc_cc = res >> 8;
+   uint8_t cc = res & 0xFF;
+   uint64_t data_off;
+   uint64_t ol_flags;
+   uint16_t m_len;
+
+   if (unlikely(cc != CPT_COMP_GOOD))
+   return RTE_MBUF_F_RX_SEC_OFFLOAD |
+  RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED;
+
+   data_off = *rearm_val & (BIT_ULL(16) - 1);
+   m_len = rx->cn9k.pkt_lenm1 + 1;
+
+   switch (uc_cc) {
+   case ROC_IE_ON_UCC_IP_PAYLOAD_TYPE_ERR:
+   case ROC_IE_ON_UCC_AUTH_ERR:
+   case ROC_IE_ON_UCC_PADDING_INVALID:
+   /* Adjust data offset to start at copied L2 */
+   data_off += ROC_ONF_IPSEC_INB_SPI_SEQ_SZ +
+   ROC_ONF_IPSEC_INB_MAX_L2_SZ;
+   ol_flags = RTE_MBUF_F_RX_SEC_OFFLOAD |
+  RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED;
+   break;
+   case ROC_IE_ON_UCC_CTX_INVALID:
+   case ROC_IE_ON_UCC_SPI_MISMATCH:
+   case ROC_IE_ON_UCC_SA_MISMATCH:
+   /* Return as normal packet */
+   ol_flags = 0;
+   break;
+   default:
+   /* Return as error packet after updating packet lengths */
+   ol_flags = RTE_MBUF_F_RX_SEC_OFFLOAD |
+  RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED;
+   break;
+   }
+
+   *len = m_len;
+   *rearm_val = *rearm_val & ~(BIT_ULL(16) - 1);
+   *rearm_val |= data_off;
+   return ol_flags;
+}
+
 static __rte_always_inline uint64_t
 nix_rx_sec_mbuf_update(const struct nix_cqe_hdr_s *cq, struct rte_mbuf *m,
   uintptr_t sa_base, uint64_t *rearm_val, uint16_t *len)
@@ -236,8 +282,8 @@ nix_rx_sec_mbuf_update(const struct nix_cqe_hdr_s *cq, 
struct rte_mbuf *m,
 
rte_prefetch0((void *)data);
 
-   if (unlikely(res != (CPT_COMP_GOOD | ROC_IE_ONF_UCC_SUCCESS << 8)))
-   return RTE_MBUF_F_RX_SEC_OFFLOAD | 
RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED;
+   if (unlikely(res != (CPT_COMP_GOOD | ROC_IE_ON_UCC_SUCCESS << 8)))
+   return nix_rx_sec_mbuf_err_update(rx, res, rearm_val, len);
 
data += lcptr;
/* 20 bits of tag would have the SPI */
-- 
2.8.4



[PATCH v2 09/10] common/cnxk: set UDP ports for IPsec UDP encapsulation

2022-01-21 Thread Nithin Dabilpuram
Set UDP ports for IPsec UDP encapsulation feature in
outbound inline.

Signed-off-by: Nithin Dabilpuram 
---
 drivers/common/cnxk/cnxk_security.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/common/cnxk/cnxk_security.c 
b/drivers/common/cnxk/cnxk_security.c
index 30562b4..8b4dd1c 100644
--- a/drivers/common/cnxk/cnxk_security.c
+++ b/drivers/common/cnxk/cnxk_security.c
@@ -710,6 +710,12 @@ cnxk_onf_ipsec_outb_sa_fill(struct roc_onf_ipsec_outb_sa 
*sa,
return -EINVAL;
}
 
+   /* Update udp encap ports */
+   if (ipsec_xfrm->options.udp_encap == 1) {
+   sa->udp_src = 4500;
+   sa->udp_dst = 4500;
+   }
+
 skip_tunnel_info:
rte_wmb();
 
-- 
2.8.4



[PATCH v2 10/10] net/cnxk: synchronize inline session create and destroy

2022-01-21 Thread Nithin Dabilpuram
Synchronize inline session create and destroy using spinlock.
Also move security related error prints outside the spinlock.

Signed-off-by: Nithin Dabilpuram 
---
 drivers/net/cnxk/cn10k_ethdev_sec.c | 35 ---
 drivers/net/cnxk/cn9k_ethdev_sec.c  | 32 ++--
 drivers/net/cnxk/cnxk_ethdev.c  |  7 +--
 drivers/net/cnxk/cnxk_ethdev.h  |  6 ++
 4 files changed, 65 insertions(+), 15 deletions(-)

diff --git a/drivers/net/cnxk/cn10k_ethdev_sec.c 
b/drivers/net/cnxk/cn10k_ethdev_sec.c
index 235c168..12cec0a 100644
--- a/drivers/net/cnxk/cn10k_ethdev_sec.c
+++ b/drivers/net/cnxk/cn10k_ethdev_sec.c
@@ -238,6 +238,8 @@ cn10k_eth_sec_session_create(void *device,
struct rte_crypto_sym_xform *crypto;
struct cnxk_eth_sec_sess *eth_sec;
bool inbound, inl_dev;
+   rte_spinlock_t *lock;
+   char tbuf[128] = {0};
int rc = 0;
 
if (conf->action_type != RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL)
@@ -272,6 +274,9 @@ cn10k_eth_sec_session_create(void *device,
memset(eth_sec, 0, sizeof(struct cnxk_eth_sec_sess));
sess_priv.u64 = 0;
 
+   lock = inbound ? &dev->inb.lock : &dev->outb.lock;
+   rte_spinlock_lock(lock);
+
/* Acquire lock on inline dev for inbound */
if (inbound && inl_dev)
roc_nix_inl_dev_lock();
@@ -287,12 +292,14 @@ cn10k_eth_sec_session_create(void *device,
/* Get Inbound SA from NIX_RX_IPSEC_SA_BASE */
sa = roc_nix_inl_inb_sa_get(&dev->nix, inl_dev, ipsec->spi);
if (!sa && dev->inb.inl_dev) {
-   plt_err("Failed to create ingress sa, inline dev "
-   "not found or spi not in range");
+   snprintf(tbuf, sizeof(tbuf),
+"Failed to create ingress sa, inline dev "
+"not found or spi not in range");
rc = -ENOTSUP;
goto mempool_put;
} else if (!sa) {
-   plt_err("Failed to create ingress sa");
+   snprintf(tbuf, sizeof(tbuf),
+"Failed to create ingress sa");
rc = -EFAULT;
goto mempool_put;
}
@@ -301,8 +308,9 @@ cn10k_eth_sec_session_create(void *device,
 
/* Check if SA is already in use */
if (inb_sa->w2.s.valid) {
-   plt_err("Inbound SA with SPI %u already in use",
-   ipsec->spi);
+   snprintf(tbuf, sizeof(tbuf),
+"Inbound SA with SPI %u already in use",
+ipsec->spi);
rc = -EBUSY;
goto mempool_put;
}
@@ -313,7 +321,8 @@ cn10k_eth_sec_session_create(void *device,
/* Fill inbound sa params */
rc = cnxk_ot_ipsec_inb_sa_fill(inb_sa_dptr, ipsec, crypto);
if (rc) {
-   plt_err("Failed to init inbound sa, rc=%d", rc);
+   snprintf(tbuf, sizeof(tbuf),
+"Failed to init inbound sa, rc=%d", rc);
goto mempool_put;
}
 
@@ -371,7 +380,8 @@ cn10k_eth_sec_session_create(void *device,
/* Fill outbound sa params */
rc = cnxk_ot_ipsec_outb_sa_fill(outb_sa_dptr, ipsec, crypto);
if (rc) {
-   plt_err("Failed to init outbound sa, rc=%d", rc);
+   snprintf(tbuf, sizeof(tbuf),
+"Failed to init outbound sa, rc=%d", rc);
rc |= cnxk_eth_outb_sa_idx_put(dev, sa_idx);
goto mempool_put;
}
@@ -409,6 +419,7 @@ cn10k_eth_sec_session_create(void *device,
}
if (inbound && inl_dev)
roc_nix_inl_dev_unlock();
+   rte_spinlock_unlock(lock);
 
plt_nix_dbg("Created %s session with spi=%u, sa_idx=%u inl_dev=%u",
inbound ? "inbound" : "outbound", eth_sec->spi,
@@ -422,7 +433,11 @@ cn10k_eth_sec_session_create(void *device,
 mempool_put:
if (inbound && inl_dev)
roc_nix_inl_dev_unlock();
+   rte_spinlock_unlock(lock);
+
rte_mempool_put(mempool, eth_sec);
+   if (rc)
+   plt_err("%s", tbuf);
return rc;
 }
 
@@ -433,12 +448,16 @@ cn10k_eth_sec_session_destroy(void *device, struct 
rte_security_session *sess)
struct cnxk_eth_dev *dev = cnxk_eth_pmd_priv(eth_dev);
struct cnxk_eth_sec_sess *eth_sec;
struct rte_mempool *mp;
+   rte_spinlock_t *lock;
void *sa_dptr;
 
eth_sec = cnxk_eth_sec_sess_get_by_sess(dev, sess);
if (!eth_sec)
return -ENOENT;
 
+   lock = eth_sec

Re: [PATCH v3] app/eventdev: add crypto producer mode

2022-01-21 Thread Jerin Jacob
On Tue, Jan 4, 2022 at 4:04 PM Shijith Thotton  wrote:
>
> In crypto producer mode, producer core enqueues cryptodev with software
> generated crypto ops and worker core dequeues crypto completion events
> from the eventdev. Event crypto metadata used for above processing is
> pre-populated in each crypto session.
>
> Parameter --prod_type_cryptodev can be used to enable crypto producer
> mode. Parameter --crypto_adptr_mode can be set to select the crypto
> adapter mode, 0 for OP_NEW and 1 for OP_FORWARD.
>
> This mode can be used to measure the performance of crypto adapter.
>
> Example:
>   ./dpdk-test-eventdev -l 0-2 -w  -w  -- \
>   --prod_type_cryptodev --crypto_adptr_mode 1 --test=perf_atq \
>   --stlist=a --wlcores 1 --plcores 2
>
> Signed-off-by: Shijith Thotton 
> ---
> v3:
> * Reduce dereference inside loop.

Hi @Gujjar, Abhinandan S

Do you have any comments or objections to merging this change?


>
> v2:
> * Fix RHEL compilation warning.
>
>  app/test-eventdev/evt_common.h   |   3 +
>  app/test-eventdev/evt_main.c |  13 +-
>  app/test-eventdev/evt_options.c  |  27 ++
>  app/test-eventdev/evt_options.h  |  12 +
>  app/test-eventdev/evt_test.h |   6 +
>  app/test-eventdev/test_perf_atq.c|  51 
>  app/test-eventdev/test_perf_common.c | 410 ++-
>  app/test-eventdev/test_perf_common.h |  16 ++
>  app/test-eventdev/test_perf_queue.c  |  52 
>  doc/guides/tools/testeventdev.rst|  13 +
>  10 files changed, 596 insertions(+), 7 deletions(-)
>
> diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
> index f466434459..2f301a7e79 100644
> --- a/app/test-eventdev/evt_common.h
> +++ b/app/test-eventdev/evt_common.h
> @@ -7,6 +7,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -39,6 +40,7 @@ enum evt_prod_type {
> EVT_PROD_TYPE_SYNT,  /* Producer type Synthetic i.e. CPU. */
> EVT_PROD_TYPE_ETH_RX_ADPTR,  /* Producer type Eth Rx Adapter. */
> EVT_PROD_TYPE_EVENT_TIMER_ADPTR,  /* Producer type Timer Adapter. */
> +   EVT_PROD_TYPE_EVENT_CRYPTO_ADPTR,  /* Producer type Crypto Adapter. */
> EVT_PROD_TYPE_MAX,
>  };
>
> @@ -77,6 +79,7 @@ struct evt_options {
> uint64_t timer_tick_nsec;
> uint64_t optm_timer_tick_nsec;
> enum evt_prod_type prod_type;
> +   enum rte_event_crypto_adapter_mode crypto_adptr_mode;
>  };
>
>  static inline bool
> diff --git a/app/test-eventdev/evt_main.c b/app/test-eventdev/evt_main.c
> index 194c980c7a..cef0fb1382 100644
> --- a/app/test-eventdev/evt_main.c
> +++ b/app/test-eventdev/evt_main.c
> @@ -161,12 +161,19 @@ main(int argc, char **argv)
> goto mempool_destroy;
> }
> }
> +   /* Test specific cryptodev setup */
> +   if (test->ops.cryptodev_setup) {
> +   if (test->ops.cryptodev_setup(test, &opt)) {
> +   evt_err("%s: cryptodev setup failed", opt.test_name);
> +   goto ethdev_destroy;
> +   }
> +   }
>
> /* Test specific eventdev setup */
> if (test->ops.eventdev_setup) {
> if (test->ops.eventdev_setup(test, &opt)) {
> evt_err("%s: eventdev setup failed", opt.test_name);
> -   goto ethdev_destroy;
> +   goto cryptodev_destroy;
> }
> }
>
> @@ -197,6 +204,10 @@ main(int argc, char **argv)
> if (test->ops.eventdev_destroy)
> test->ops.eventdev_destroy(test, &opt);
>
> +cryptodev_destroy:
> +   if (test->ops.cryptodev_destroy)
> +   test->ops.cryptodev_destroy(test, &opt);
> +
>  ethdev_destroy:
> if (test->ops.ethdev_destroy)
> test->ops.ethdev_destroy(test, &opt);
> diff --git a/app/test-eventdev/evt_options.c b/app/test-eventdev/evt_options.c
> index 753a7dbd7d..5ad1491020 100644
> --- a/app/test-eventdev/evt_options.c
> +++ b/app/test-eventdev/evt_options.c
> @@ -122,6 +122,26 @@ evt_parse_timer_prod_type_burst(struct evt_options *opt,
> return 0;
>  }
>
> +static int
> +evt_parse_crypto_prod_type(struct evt_options *opt,
> +  const char *arg __rte_unused)
> +{
> +   opt->prod_type = EVT_PROD_TYPE_EVENT_CRYPTO_ADPTR;
> +   return 0;
> +}
> +
> +static int
> +evt_parse_crypto_adptr_mode(struct evt_options *opt, const char *arg)
> +{
> +   uint8_t mode;
> +   int ret;
> +
> +   ret = parser_read_uint8(&mode, arg);
> +   opt->crypto_adptr_mode = mode ? RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD :
> +   RTE_EVENT_CRYPTO_ADAPTER_OP_NEW;
> +   return ret;
> +}
> +
>  static int
>  evt_parse_test_name(struct evt_options *opt, const char *arg)
>  {
> @@ -335,6 +355,7 @@ usage(char *program)
> "\t--queue_priority   : enable queue priority\n"
> "\t--deq_tmo_nsec : global dequ

Re: [PATCH v2 0/6] allow more DPDK libs to be disabled on build

2022-01-21 Thread David Marchand
On Wed, Jan 19, 2022 at 7:31 PM Bruce Richardson
 wrote:
>
> *A common request on-list has been to allow more of the DPDK build to be 
> disabled by those who are
> doing their own builds and only use a subset of the libraries. To this end, 
> this patchset makes some
> infrastructure changes [first two patches] to make it easier to have 
> libraries disabled, and then
> adds a six libraries to the "optional" list.
>
> V2: fix missing PCI and vdev bus driver dependencies in patch 2.
>
> Bruce Richardson (6):
>   lib: allow recursive disabling of libs in build
>   app/test: link unit test binary against all available libs
>   build: add node library to optional list
>   build: add flow classification library to optional list
>   build: add "packet framework" libs to optional list
>   build: add cfgfile library to optional list
>
>  app/test/meson.build | 76 
>  lib/meson.build  | 30 +++--
>  2 files changed, 42 insertions(+), 64 deletions(-)
>

Series applied, thanks Bruce.


-- 
David Marchand



Re: [dpdk-ci] [RFC] Proposal for allowing rerun of tests

2022-01-21 Thread Kevin Traynor

On 13/04/2021 14:50, Aaron Conole wrote:

Greetings,

During the various CI pipelines, sometimes a test setup or lab will
have an internal failure unrelated to the specific patch.  Perhaps
'master' branch (or the associated -next branch) is broken and we cannot
get a successful run anyway.  Perhaps a network outage occurs during
infrastructure setup.  Perhaps some other transient error clobbers the
setup.  In all of these cases the report to the mailing flags the patch
as 'FAIL'.

It would be very helpful if maintainers had the ability to tell various
CI infrastructures to restart / rerun patch tests.  For now, this has to
be done by the individual managers of those labs.  Some labs, it isn't
possible.  Others, it's possible but is a very time-consuming process to
restart a test case.  In all cases, a maintainer needs to spend time
communicating with a lab manager.  This could be made a bit nicer.



Just to tie two relevant threads together. I made a request in 
http://mails.dpdk.org/archives/ci/2022-January/001593.html for a 
"retest" button (or really any manual but self-sufficient way) to 
kick-off immediately what is run in periodic branch testing. Something 
might be there already, that i'm just not aware of.


This could be used by LTS maintainers, and possibly main, *-next branch 
maintainers coming up to releases.


thanks,
Kevin.


One proposal we (Michael and I) have toyed with for our lab is having
the infrastructure monitor patchwork comments for a restart flag, and
kick off based on that information.  Patchwork tracks all of the
comments for each patch / series so we could look at the series that
are still in a state for 'merging' (new, assigned, etc) and check the
patch .comments API for new comments.  Getting the data from PW should
be pretty simple - but I think that knowing whether to kick off the
test might be more difficult.  We have concerns about which messages we
should accept (for example, can anyone ask for a series to be rerun, and
we'll need to track which rerun messages we've accepted).  The
convention needs to be something we all can work with (ie: /Re-check:
[checkname] or something as a single line in the email).

This is just a start to identify and explain the concern.  Maybe there
are other issues we've not considered, or maybe folks think this is a
terrible idea not worth spending any time developing.  I think there's
enough use for it that I am raising it here, and we can discuss it.

Thanks,
-Aaron





Re: [PATCH 05/12] gen: add raw packet data API and tests

2022-01-21 Thread Xueming(Steven) Li
On Mon, 2021-12-20 at 18:51 +0530, Jerin Jacob wrote:
> On Fri, Dec 17, 2021 at 5:10 PM Van Haaren, Harry
>  wrote:
> > 
> > +CC Thomas;
> > 
> > > -Original Message-
> > > From: Jerin Jacob 
> > > Sent: Wednesday, December 15, 2021 12:41 PM
> > > To: Randles, Ronan 
> > > Cc: dpdk-dev ; Van Haaren, Harry
> > > 
> > > Subject: Re: [PATCH 05/12] gen: add raw packet data API and tests
> > > 
> > > On Tue, Dec 14, 2021 at 7:43 PM Ronan Randles 
> > > wrote:
> > > > 
> > > > From: Harry van Haaren 
> > 
> > 
> > 
> > > > +   const uint32_t base_size = gen->base_pkt->pkt_len;
> > > > +   const uint8_t *base_data = rte_pktmbuf_mtod(gen->base_pkt, 
> > > > uint8_t
> > > *);
> > > 
> > > I think, the very next feature will be generating packets for
> > > incrementing IP addresses or so.
> > 
> > Hah, yes! It’s a logical next step, and indeed we have POC code internally 
> > that Ronan
> > and I have worked on that does this :) I've been using this internal POC of
> > testing of OVS for ~ a year now, and it provides a pretty nice workflow for 
> > me.
> > 
> > > In this case, one packet-based template will not work.
> > 
> > Why not? I agree that "pre-calculating" all packets will not work, but the 
> > approach
> > we have taken for this library is different. See below;
> > 
> > > May we worth consider that use case into API framework first and add 
> > > support
> > > later for implementation as it may change the complete land space of API 
> > > to have
> > > better performance. Options like struct rte_gen logical object can have
> > > N templates instead of one is an option on the table. :-)
> > 
> > Agree - more complex usages have been designed for too. Let me explain;
> > 
> > 1) A single gen instance uses a single template, and has "modifiers" that 
> > allow
> > manipulation of the packet before sending. The gen->base_pkt is copied to 
> > the
> > destination mbuf, and then updated by the modifiers. This approach is much 
> > better
> > to allow for huge flow-counts (> 1 million?) as pre-calculating and storing 
> > 1 million
> > packets is a waste of memory, and causes a lot of mem-IO for the datapath 
> > core.
> > 
> > 2) The "modifiers" approach allows any number of things to be changed, with 
> > little
> > mem-IO, and variable CPU cycle cost based on the modifiers themselves.
> > If the CPU cycle cost of generating packets is too high, just add more 
> > cores :)
> > 
> > 3) There are also some smarts we can apply for pre-calculating only a small 
> > amount of
> > data per packet (e.g. uniformly-random distributed src ip). The memory 
> > footprint is
> > lower than pre-calc of whole packets, and the runtime overhead of 
> > uniform-random
> > is moved to configure time instead of on the datapath.
> > 
> > 4) Dynamically generating packets by modification of templates allows for 
> > cool things
> > to be added, e.g. adding timestamps to packets, and calculating latency can
> > be done using the modifier concept and a protocol string 
> > "Ether()/IP()/UDP()/TSC()".
> > If the packet is being decapped by the target application, the string 
> > params can provide
> > context for where to "retrieve" the TSC from on RX in the generator: 
> > "TSC(rx_offset=30)".
> > I've found this approach to be very flexible and nice, so am a big fan :)
> > 
> > 5) In order to have multiple streams of totally-different traffic types 
> > (read "from multiple templates")
> > the user can initialize multiple rte_gen instances. This allows 
> > applications that require multi-stream traffic
> > to achieve that too, with the same abstraction as a single template stream. 
> > Initially the generator app is just
> > providing a single stream, but this application can be expanded to many 
> > usages over the next year before 22.11 :)
> 
> OK. I thought "modifiers" will need some sort of critical section in
> multiple producer use cases. If so,
> one option could be N streams in one gen instance vs N gen instance.
> Just my 2c. Anyway, you folks can decide
> on one option vs another. Only my concern was including such features
> affect the prototype of existing APIs or not?
> In either case, No strong opinion.

Sometimes we need RSS with limited streams, modifies need to copy
template data, then modify accordingly, involves more cycles and data
cache, not a good choice for performance test.

By cloning a list of templates, just copy the mbuf headers, seems more
efficient for such case.

Agree modifiers a flexible way to do things more powerful, hopefully we
have them all :)

> 
> 
> > 
> > I could ramble on a bit more, but mostly diminishing returns I think... 
> > I'll just use this email as a reply to Thomas' tweet;
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Ftmonjalo%2Fstatus%2F1337313985662771201&data=04%7C01%7Cxuemingl%40nvidia.com%7Cedc55ae350504eaebe0b08d9c3bbb464%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637756033240578829%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w

Re: [PATCH] eal: log hugepage create errors with filename

2022-01-21 Thread Thomas Monjalon
07/01/2022 12:53, Bruce Richardson:
> On Thu, Dec 23, 2021 at 11:21:58AM -0800, Stephen Hemminger wrote:
> > While debugging running DPDK service in a container, it is
> > useful to see which file creation failed.  Don't hide this
> > failure with DEBUG.
> > 
> > Signed-off-by: Stephen Hemminger 
> > ---
> >  lib/eal/linux/eal_memalloc.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> Acked-by: Bruce Richardson 
> 
> Should we consider this a bugfix for backporting? Not printing the failing
> path seems an omission that should be fixed generally.

Yes adding Cc stable

Applied, thanks.





Re: [PATCH] build: remove custom dependency checks in drivers

2022-01-21 Thread Thomas Monjalon
> > > Some drivers currently have their own checks and give some non
> > > consistent reasons when an internal dependency is unavailable.
> > >
> > > drivers/meson.build also checks for internal dependencies via 'deps'.
> > > Let's rely on it for consistency, and smaller code.
> > >
> > > Signed-off-by: David Marchand 
> > > ---
> > Thanks for the cleanup.
> > 
> > Acked-by: Bruce Richardson 
> 
> Thank you.
> 
> Acked-by: Long Li 

Applied, thanks




Re: [PATCH 2/2] net/nfp: remove useless range checks

2022-01-21 Thread Ferruh Yigit

On 1/11/2022 2:54 PM, Kevin Traynor wrote:

On 05/01/2022 10:32, Maxime Gouin wrote:

reported by code analysis tool C++test (version 10.4):



Hi Maxime,

Can you please give some information on this tool?

Thanks,
ferruh


/build/dpdk-20.11/drivers/net/nfp/nfpcore/nfp_target.h
375   Condition "island < 1" is always evaluated to false
415   Condition "island < 1" is always evaluated to false
547   Condition "target < 0" is always evaluated to false


All of these conditions have the same error. They call
NFP_CPP_ID_ISLAND_of or NFP_CPP_ID_TARGET_of which return a uint8_t and
put the result in "island" or "target" which are integers. These variables
can only contain values between 0 and 255.

Fixes: c7e9729da6b5 ("net/nfp: support CPP")



Cc: sta...@dpdk.org


Signed-off-by: Maxime Gouin 
Reviewed-by: Olivier Matz 
---


Acked-by: Kevin Traynor 



For series,
Reviewed-by: Ferruh Yigit 

Series applied to dpdk-next-net/main, thanks.


Re: [PATCH 00/12] add packet generator library and example app

2022-01-21 Thread Xueming(Steven) Li
On Tue, 2021-12-14 at 14:12 +, Ronan Randles wrote:
> This patchset introduces a Gen library for DPDK. This library provides an easy
> way to generate traffic in order to test software based network components.
> 
> This library enables the basic functionality required in the traffic 
> generator.
> This includes: raw data setting, packet Tx and Rx, creation and destruction 
> of a
>  Gen instance and various types of data parsing.
> This functionality is implemented in "lib/gen/rte_gen.c". IPv4 parsing
> functionality is also added in "lib/net/rte_ip.c", this is then used in the 
> gen
> library.
> 
> A sample app is included in "examples/generator" which shows the use of the 
> gen
> library in making a traffic generator. This can be used to generate traffic by
> running the dpdk-generator generator executable. This sample app supports
> runtime stats reporting (/gen/stats) and line rate limiting
> (/gen/mpps,) through telemetry.py.
> 
> As more features are added to the gen library, the sample application will
> become more powerful through the "/gen/packet" string parameter
> (currently supports IP and Ether address setting). This will allow every
> application to generate more complex traffic types in the future without
> changing API.

A good start, thanks.

Testpmd can do txonly, rxonly, forwarding, but no rx+tx only :) I guess
that's the key of a GEN. testpmd also has "--stats-period" to show
statistics in non-interactive mode, very close to a GEN, but not
enough. Testpmd can toggle a lot of settings like offloading, that's an
advantage. Do you see an chance to make the lib part of testpmd?

I tried to leverage Scapy syntax into testpmd [1][2]: to set fancy
template - useful to test flows, or dump packet using different scapy
detail level. unfotunately I don't have time to finish it. Parsing
packet from string is boring, any consideration on this?

[1]: https://github.com/steevenlee/dpdk/commits/upstream_scapy
[2]: doc
https://github.com/steevenlee/dpdk/blob/875b8407f769465837513d29a495af3cc1a29765/doc/guides/howto/scapy.rst

> 
> Harry van Haaren (6):
>   gen: add files for initial traffic generation library
>   gen: add basic Rx and Tx routines and tests
>   gen: add raw packet data API and tests
>   gen: add parsing infrastructure and Ether protocol
>   gen: add gen IP parsing
>   examples/generator: import code from basicfwd.c
> 
> Ronan Randles (6):
>   net: add string to IPv4 parse function
>   net: add function to pretty print IPv4
>   examples/generator: enable gen library for traffic gen
>   examples/generator: telemetry support
>   examples/generator: link status check added
>   examples/generator: line rate limiting
> 
>  app/test/meson.build   |   4 +
>  app/test/test_gen.c| 184 +++
>  app/test/test_net.c|  87 ++
>  doc/api/doxy-api-index.md  |   3 +-
>  doc/api/doxy-api.conf.in   |   1 +
>  examples/generator/main.c  | 483 
>  examples/generator/meson.build |  13 +
>  examples/meson.build   |   1 +
>  lib/gen/meson.build|   6 +
>  lib/gen/rte_gen.c  | 553 +
>  lib/gen/rte_gen.h  | 114 +++
>  lib/gen/version.map|  10 +
>  lib/meson.build|   1 +
>  lib/net/meson.build|   1 +
>  lib/net/rte_ip.c   |  58 
>  lib/net/rte_ip.h   |  38 +++
>  lib/net/version.map|   9 +
>  17 files changed, 1565 insertions(+), 1 deletion(-)
>  create mode 100644 app/test/test_gen.c
>  create mode 100644 app/test/test_net.c
>  create mode 100644 examples/generator/main.c
>  create mode 100644 examples/generator/meson.build
>  create mode 100644 lib/gen/meson.build
>  create mode 100644 lib/gen/rte_gen.c
>  create mode 100644 lib/gen/rte_gen.h
>  create mode 100644 lib/gen/version.map
>  create mode 100644 lib/net/rte_ip.c
> 



Re: [PATCH v5 2/2] testpmd: fix l4 sw csum over multi segments

2022-01-21 Thread Ferruh Yigit

On 1/6/2022 4:03 PM, Xiaoyun Li wrote:

In csum forwarding mode, software UDP/TCP csum calculation only takes
the first segment into account while using the whole packet length so
the calculation will read invalid memory region with multi-segments
packets and will get wrong value.
This patch fixes this issue.

Signed-off-by: Xiaoyun Li 
Tested-by: Sunil Pai G 


Can you please check following check-git-log.sh warnings:

./devtools/check-git-log.sh -2
Wrong headline label:
testpmd: fix l4 sw csum over multi segments
Wrong headline case:
"testpmd: fix l4 sw csum over multi segments": l4 --> L4
Wrong headline case:
"testpmd: fix l4 sw csum over multi segments": sw --> SW
Missing 'Fixes' tag:
testpmd: fix l4 sw csum over multi segments




---
  app/test-pmd/csumonly.c | 41 ++---
  1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 2aeea243b6..0fbe1f1be7 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -96,12 +96,13 @@ struct simple_gre_hdr {
  } __rte_packed;
  
  static uint16_t

-get_udptcp_checksum(void *l3_hdr, void *l4_hdr, uint16_t ethertype)
+get_udptcp_checksum(struct rte_mbuf *m, void *l3_hdr, uint16_t l4_off,
+   uint16_t ethertype)
  {
if (ethertype == _htons(RTE_ETHER_TYPE_IPV4))
-   return rte_ipv4_udptcp_cksum(l3_hdr, l4_hdr);
+   return rte_ipv4_udptcp_cksum_mbuf(m, l3_hdr, l4_off);
else /* assume ethertype == RTE_ETHER_TYPE_IPV6 */
-   return rte_ipv6_udptcp_cksum(l3_hdr, l4_hdr);
+   return rte_ipv6_udptcp_cksum_mbuf(m, l3_hdr, l4_off);
  }
  
  /* Parse an IPv4 header to fill l3_len, l4_len, and l4_proto */

@@ -460,7 +461,7 @@ parse_encap_ip(void *encap_ip, struct testpmd_offload_info 
*info)
   * depending on the testpmd command line configuration */
  static uint64_t
  process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
-   uint64_t tx_offloads)
+   uint64_t tx_offloads, struct rte_mbuf *m)
  {
struct rte_ipv4_hdr *ipv4_hdr = l3_hdr;
struct rte_udp_hdr *udp_hdr;
@@ -468,6 +469,7 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
struct rte_sctp_hdr *sctp_hdr;
uint64_t ol_flags = 0;
uint32_t max_pkt_len, tso_segsz = 0;
+   uint16_t l4_off;
  
  	/* ensure packet is large enough to require tso */

if (!info->is_tunnel) {
@@ -510,9 +512,15 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
if (tx_offloads & RTE_ETH_TX_OFFLOAD_UDP_CKSUM) {
ol_flags |= RTE_MBUF_F_TX_UDP_CKSUM;
} else {
+   if (info->is_tunnel)
+   l4_off = info->l2_len +
+info->outer_l3_len +
+info->l2_len + info->l3_len;
+   else
+   l4_off = info->l2_len +  
info->l3_len;
udp_hdr->dgram_cksum = 0;
udp_hdr->dgram_cksum =
-   get_udptcp_checksum(l3_hdr, udp_hdr,
+   get_udptcp_checksum(m, l3_hdr, l4_off,
info->ethertype);
}
}
@@ -527,9 +535,14 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
else if (tx_offloads & RTE_ETH_TX_OFFLOAD_TCP_CKSUM) {
ol_flags |= RTE_MBUF_F_TX_TCP_CKSUM;
} else {
+   if (info->is_tunnel)
+   l4_off = info->l2_len + info->outer_l3_len +
+info->l2_len + info->l3_len;
+   else
+   l4_off = info->l2_len + info->l3_len;
tcp_hdr->cksum = 0;
tcp_hdr->cksum =
-   get_udptcp_checksum(l3_hdr, tcp_hdr,
+   get_udptcp_checksum(m, l3_hdr, l4_off,
info->ethertype);
}
  #ifdef RTE_LIB_GSO
@@ -557,7 +570,7 @@ process_inner_cksums(void *l3_hdr, const struct 
testpmd_offload_info *info,
  /* Calculate the checksum of outer header */
  static uint64_t
  process_outer_cksums(void *outer_l3_hdr, struct testpmd_offload_info *info,
-   uint64_t tx_offloads, int tso_enabled)
+   uint64_t tx_offloads, int tso_enabled, struct rte_mbuf *m)
  {
struct rte_ipv4_hdr *ipv4_hdr = outer_l3_hdr;
struct rte_ipv6_hdr *ipv6_hdr = outer_l3_hdr;
@@ -611,12 +624,9 @@ process_outer_cksums(void *outer_l3_hdr, struc

Re: [PATCH v5 1/2] net: add functions to calculate UDP/TCP cksum in mbuf

2022-01-21 Thread Ferruh Yigit

On 1/6/2022 4:03 PM, Xiaoyun Li wrote:

Add functions to call rte_raw_cksum_mbuf() to calculate IPv4/6
UDP/TCP checksum in mbuf which can be over multi-segments.

Signed-off-by: Xiaoyun Li 
Acked-by: Aman Singh 
Tested-by: Sunil Pai G 



Thanks Xiaoyun, patch looks good to me:
Acked-by: Ferruh Yigit 


Olivier,
Just reminder of this patch if you want to to review.


RE: [PATCH 00/12] add packet generator library and example app

2022-01-21 Thread Van Haaren, Harry
> -Original Message-
> From: Xueming(Steven) Li 
> Sent: Friday, January 21, 2022 2:45 PM
> To: dev@dpdk.org; Randles, Ronan 
> Cc: Van Haaren, Harry 
> Subject: Re: [PATCH 00/12] add packet generator library and example app
> 
> On Tue, 2021-12-14 at 14:12 +, Ronan Randles wrote:
> > This patchset introduces a Gen library for DPDK. This library provides an 
> > easy
> > way to generate traffic in order to test software based network components.
> >
> > This library enables the basic functionality required in the traffic 
> > generator.
> > This includes: raw data setting, packet Tx and Rx, creation and destruction 
> > of a
> >  Gen instance and various types of data parsing.
> > This functionality is implemented in "lib/gen/rte_gen.c". IPv4 parsing
> > functionality is also added in "lib/net/rte_ip.c", this is then used in the 
> > gen
> > library.
> >
> > A sample app is included in "examples/generator" which shows the use of the
> gen
> > library in making a traffic generator. This can be used to generate traffic 
> > by
> > running the dpdk-generator generator executable. This sample app supports
> > runtime stats reporting (/gen/stats) and line rate limiting
> > (/gen/mpps,) through telemetry.py.
> >
> > As more features are added to the gen library, the sample application will
> > become more powerful through the "/gen/packet" string parameter
> > (currently supports IP and Ether address setting). This will allow every
> > application to generate more complex traffic types in the future without
> > changing API.
> 
> A good start, thanks.
> 
> Testpmd can do txonly, rxonly, forwarding, but no rx+tx only :) I guess
> that's the key of a GEN. testpmd also has "--stats-period" to show
> statistics in non-interactive mode, very close to a GEN, but not
> enough. Testpmd can toggle a lot of settings like offloading, that's an
> advantage. Do you see an chance to make the lib part of testpmd?
> 
> I tried to leverage Scapy syntax into testpmd [1][2]: to set fancy
> template - useful to test flows, or dump packet using different scapy
> detail level. unfotunately I don't have time to finish it. Parsing
> packet from string is boring, any consideration on this?

Hi Steven,

Yes I recall the patchset to extend DPDK with python/scapy itself, and indeed 
this was my first approach too!
I build a proof-of-concept for enabling a 
"run-python-script-inside-eth-null-PMD-rx-function" approach.
Although this worked (in a clunky way, using packet.__bytes__() in python 
script..), the performance was
extremely low. An optimization was to pre-calculate e.g. 1 million packets, and 
leave them all in memory,
which causes memory waste, and lack of performance due to memory-boundedness in 
the CPU.

There is a fundamental blocking issue here - the generation/creation of packets 
is slow. Even updating a
single flow, or single parameter of the packet, could/would require 
recalculation of checksums... so leads
to the C code needing to know the L2/L3/L4 offsets. Even then, the 
re-calculation over 1-million packets
puts a lot of memory pressure - the packets cannot be re-used (from mempool 
lcore cache) if they need
to be "unique" through pre-computation, resulting in cache-trashing.

As a solution, moving to a native/C language based creation of a "base packet" 
(template) with "modifiers"
seemed a good fit. It allows best-case performance (mempool cache) and lowest 
compute per-packet.
The "modifiers" are "pay for what you need" approach to flows/updates/etc, 
allowing user to choose
the right balance of traffic-complexity vs CPU-cost to generate it.

All in all; handling string-parsing in C is not fun - but by paying that price 
we can gain many other things...

I think that a "gen" engine for TestPMD could be interesting for certain 
use-cases yes. As your links below,
the "expect" behaviour is a particularly nice way of working for testing! There 
is an implementation for
net/null PMD to create packets with Gen library, but is not ready for upstream 
so was not included in V2.

For multi-flow latency testing, I'm not sure if TestPMD is the ideal tool, as 
it does not prioritize RX/latency
at all costs: e.g lcores perform both RX and TX functionality. The dedicated 
"example/generator" is a sample
application that provides the basis for a more latency/jitter focused 
application, however there is much work
to do there to make it a production-ready tool.

Note that at the moment, the status of the Gen work is as follows;
- Upstream discussion: 
http://mails.dpdk.org/archives/dev/2022-January/232965.html
- V2 patch: 
http://patches.dpdk.org/project/dpdk/cover/20220121103122.2926856-1-ronan.rand...@intel.com/

Regards, -Harry

PS: Side note around Python/Scapy: its an *awesome* tool. I like it a lot, but 
for DPDK levels of performance,
and in a latency/performance critical use-case, I'm not convinced it is the 
right tool to use.


> [1]: https://github.com/steevenlee/dpdk/commits/upstream_scapy
> [2]: doc
> htt

[PATCH] build: fix meson warning about using compiler warning flags

2022-01-21 Thread Bruce Richardson
Each build, meson would issue a warning reporting that the
"warning_level" setting should be used in place of adding -Wextra
directly to our build commands. Testing with meson 0.61 shows that the
only difference for gcc and clang builds between warning levels 1 and
2 is the addition of -Wextra, so we can remove the warning by deleting
our explicit set of Wextra and changing the build defaults to
warning_level 2.

Fixes: 524a0d5d66b9 ("build: enable extra warnings with meson")

Signed-off-by: Bruce Richardson 
---

NOTE1: Not putting CC stable for this patch, I don't believe it's worth
the risk of backporting.

NOTE2: For reference, when building a test "hello world" project with
different warning levels, the following flags are used by meson:

warning_level=0: 
warning_level=1: -Wall -Winvalid-pch
warning_level=2: -Wall -Winvalid-pch -Wextra
warning_level=3: -Wall -Winvalid-pch -Wextra -Wpedantic
---
 config/meson.build | 5 ++---
 meson.build| 2 +-
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/config/meson.build b/config/meson.build
index ee12318d4f..7134e80e8d 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -247,10 +247,9 @@ endif
 add_project_arguments('-include', 'rte_config.h', language: 'c')
 
 # enable extra warnings and disable any unwanted warnings
+# -Wall is added by default at warning level 1, and -Wextra
+# at warning level 2 (DPDK default)
 warning_flags = [
-# -Wall is added by meson by default, so add -Wextra only
-'-Wextra',
-
 # additional warnings in alphabetical order
 '-Wcast-qual',
 '-Wdeprecated',
diff --git a/meson.build b/meson.build
index 1223b79d74..070243a33d 100644
--- a/meson.build
+++ b/meson.build
@@ -7,7 +7,7 @@ project('DPDK', 'C',
 version: run_command(find_program('cat', 'more'),
 files('VERSION'), check: true).stdout().strip(),
 license: 'BSD',
-default_options: ['buildtype=release', 'default_library=static'],
+default_options: ['buildtype=release', 'default_library=static', 
'warning_level=2'],
 meson_version: '>= 0.49.2'
 )
 
-- 
2.32.0



[PATCH v2] build: fix meson warning about using compiler warning flags

2022-01-21 Thread Bruce Richardson
Each build, meson would issue a warning reporting that the
"warning_level" setting should be used in place of adding -Wextra
directly to our build commands. Testing with meson 0.61 shows that the
only difference for gcc and clang builds between warning levels 1 and
2 is the addition of -Wextra, so we can remove the warning by deleting
our explicit set of Wextra and changing the build defaults to
warning_level 2.

Fixes: 524a0d5d66b9 ("build: enable extra warnings with meson")

Signed-off-by: Bruce Richardson 
---
V2: fixed CI apply issues due to V1 being based on top of patch
'build: fix warnings when running external commands'

NOTE1: Not putting CC stable for this patch, I don't believe it's worth
the risk of backporting.

NOTE2: For reference, when building a test "hello world" project with
different warning levels, the following flags are used by meson:

warning_level=0: 
warning_level=1: -Wall -Winvalid-pch
warning_level=2: -Wall -Winvalid-pch -Wextra
warning_level=3: -Wall -Winvalid-pch -Wextra -Wpedantic
---
 config/meson.build | 5 ++---
 meson.build| 2 +-
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/config/meson.build b/config/meson.build
index 805d5d51d0..cb236d9187 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -246,10 +246,9 @@ endif
 add_project_arguments('-include', 'rte_config.h', language: 'c')
 
 # enable extra warnings and disable any unwanted warnings
+# -Wall is added by default at warning level 1, and -Wextra
+# at warning level 2 (DPDK default)
 warning_flags = [
-# -Wall is added by meson by default, so add -Wextra only
-'-Wextra',
-
 # additional warnings in alphabetical order
 '-Wcast-qual',
 '-Wdeprecated',
diff --git a/meson.build b/meson.build
index 12cb6e0e83..0a844bce9e 100644
--- a/meson.build
+++ b/meson.build
@@ -7,7 +7,7 @@ project('DPDK', 'C',
 version: run_command(find_program('cat', 'more'),
 files('VERSION')).stdout().strip(),
 license: 'BSD',
-default_options: ['buildtype=release', 'default_library=static'],
+default_options: ['buildtype=release', 'default_library=static', 
'warning_level=2'],
 meson_version: '>= 0.49.2'
 )
 
-- 
2.32.0



Re: [PATCH v5] raw/ifpga: fix pthread cannot join

2022-01-21 Thread Stephen Hemminger
On Thu, 20 Jan 2022 22:32:46 -0500
Wei Huang  wrote:

> @@ -497,7 +497,7 @@ static int set_surprise_link_check_aer(
>   int gsd_enable, ret;
>  #define MS 1000
>  
> - while (1) {
> + while (rte_atomic32_read(&ifpga_monitor_start)) {

Better, but rte_atomic is deprecated in favor of using __atomic builtin
instead. This is because there are more options possible with 
__atomic_load_n than rte_atomic32_read.  rte_atomic32_read has to assume
worst case memory ordering, and your example relaxed memory ordering is
what you need.


Re: [PATCH v2 02/15] net: add function to pretty print IPv4

2022-01-21 Thread Stephen Hemminger
On Fri, 21 Jan 2022 10:31:09 +
Ronan Randles  wrote:

> +int32_t
> +rte_ip_print_addr(uint32_t ip_addr, char *buffer, uint32_t buffer_size)
> +{
> + if (buffer == NULL)
> + return -1;
> +
> + snprintf(buffer, buffer_size, "%u.%u.%u.%u",
> + (ip_addr >> 24),
> + (ip_addr >> 16) & UINT8_MAX,
> + (ip_addr >> 8) & UINT8_MAX,
> +  ip_addr & UINT8_MAX);
> +
> + return 0;

NAK
Broken on big endian machines.
Once again, why does DPDK need to reinvent everything?


Re: [PATCH] build: fix meson warning about using compiler warning flags

2022-01-21 Thread Luca Boccassi
On Fri, 2022-01-21 at 15:53 +, Bruce Richardson wrote:
> Each build, meson would issue a warning reporting that the
> "warning_level" setting should be used in place of adding -Wextra
> directly to our build commands. Testing with meson 0.61 shows that the
> only difference for gcc and clang builds between warning levels 1 and
> 2 is the addition of -Wextra, so we can remove the warning by deleting
> our explicit set of Wextra and changing the build defaults to
> warning_level 2.
> 
> Fixes: 524a0d5d66b9 ("build: enable extra warnings with meson")
> 
> Signed-off-by: Bruce Richardson 
> ---
> 
> NOTE1: Not putting CC stable for this patch, I don't believe it's worth
> the risk of backporting.
> 
> NOTE2: For reference, when building a test "hello world" project with
> different warning levels, the following flags are used by meson:
> 
> warning_level=0: 
> warning_level=1: -Wall -Winvalid-pch
> warning_level=2: -Wall -Winvalid-pch -Wextra
> warning_level=3: -Wall -Winvalid-pch -Wextra -Wpedantic
> ---
>  config/meson.build | 5 ++---
>  meson.build| 2 +-
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/config/meson.build b/config/meson.build
> index ee12318d4f..7134e80e8d 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -247,10 +247,9 @@ endif
>  add_project_arguments('-include', 'rte_config.h', language: 'c')
>  
> 
>  # enable extra warnings and disable any unwanted warnings
> +# -Wall is added by default at warning level 1, and -Wextra
> +# at warning level 2 (DPDK default)
>  warning_flags = [
> -# -Wall is added by meson by default, so add -Wextra only
> -'-Wextra',
> -
>  # additional warnings in alphabetical order
>  '-Wcast-qual',
>  '-Wdeprecated',
> diff --git a/meson.build b/meson.build
> index 1223b79d74..070243a33d 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -7,7 +7,7 @@ project('DPDK', 'C',
>  version: run_command(find_program('cat', 'more'),
>  files('VERSION'), check: true).stdout().strip(),
>  license: 'BSD',
> -default_options: ['buildtype=release', 'default_library=static'],
> +default_options: ['buildtype=release', 'default_library=static', 
> 'warning_level=2'],
>  meson_version: '>= 0.49.2'
>  )
>  
> 

Acked-by: Luca Boccassi 

-- 
Kind regards,
Luca Boccassi


Re: [PATCH v5 2/2] testpmd: fix l4 sw csum over multi segments

2022-01-21 Thread Kevin Traynor

On 06/01/2022 16:03, Xiaoyun Li wrote:

In csum forwarding mode, software UDP/TCP csum calculation only takes
the first segment into account while using the whole packet length so
the calculation will read invalid memory region with multi-segments
packets and will get wrong value.
This patch fixes this issue.


There should be a 'Fixes:' tag and assuming you want this patch 
backported to LTS, 'Cc: sta...@dpdk.org' too.




Re: [PATCH v2 05/10] common/cnxk: always use single interrupt ID with NIX

2022-01-21 Thread Kevin Traynor

On 21/01/2022 12:04, Nithin Dabilpuram wrote:

From: Harman Kalra

An errata exists whereby, in certain cases NIX may use an
incorrect QINT_IDX for SQ interrupts. As a result, the
interrupt may not be delivered to software, or may not be
associated with the correct SQ.
When NIX uses an incorrect QINT_IDX :
1. NIX_LF_QINT(0..63)_CNT[COUNT] will be incremented for
incorrect QINT.
2. NIX_LF_QINT(0..63)_INT[INTR] will be set for incorrect
QINT.

Signed-off-by: Harman Kalra
Acked-by: Jerin Jacob
---


Patches 4/10 and 5/10 look like fixes, that should have Fixes: tags. 
Also, please mark them for stable if you would like them backported to LTS.




Re: [PATCH 00/15] fix and feature for hns3 PMD

2022-01-21 Thread Ferruh Yigit

On 1/7/2022 10:15 AM, Min Hu (Connor) wrote:

This patch contains 15 patches, which include fixing codecheck warning
,code refactor and indirect counter action support.


Chengwen Feng (4):
   net/hns3: remove invalid encapsulation function
   net/hns3: delete strerror invoke
   net/hns3: rename function
   net/hns3: support indirect counter action

Huisong Li (10):
   net/hns3: remove unnecessary assignment
   net/hns3: fix a misjudgment expression
   net/hns3: extract a common API to initialize MAC addrs
   net/hns3: remove unnecessary black lines
   net/hns3: extract a function to handle reset fail
   net/hns3: extract functions to create RSS and FDIR flow rule
   net/hns3: remove unused variables
   net/hns3: remove the number of queue descriptors
   net/hns3: remove the printing of memory addresses
   net/hns3: extract a common interface to obtain revision ID

Jie Hai (1):
   net/hns3: remove unnecessary 'inline'



Hi Connor,

Patch by patch build fails, first failing patch is 7/15.
Can you please fix it with a new version?


Re: [dpdklab] Re: [dpdk-ci] [RFC] Proposal for allowing rerun of tests

2022-01-21 Thread Lincoln Lavoie
Hi Kevin,

I'll add some notes around this to the 2022 planning doc.  The retests
requests for the periodic tests are tricky from the discussed patchworks /
mailing list approach, because there isn't an associated patch or patch
ID.  So, we just need to document or agree on how to "flag" what the
request is, so the system could uniquely ID what branch / test to rerun.

I'll also add this to the list for the dashboard technical debt as well, as
there may be a graphical interface stuff (i.e. a button) we could add to
the UNH-IOL hosted testing.

Cheers,
Lincoln

On Fri, Jan 21, 2022 at 9:00 AM Kevin Traynor  wrote:

> On 13/04/2021 14:50, Aaron Conole wrote:
> > Greetings,
> >
> > During the various CI pipelines, sometimes a test setup or lab will
> > have an internal failure unrelated to the specific patch.  Perhaps
> > 'master' branch (or the associated -next branch) is broken and we cannot
> > get a successful run anyway.  Perhaps a network outage occurs during
> > infrastructure setup.  Perhaps some other transient error clobbers the
> > setup.  In all of these cases the report to the mailing flags the patch
> > as 'FAIL'.
> >
> > It would be very helpful if maintainers had the ability to tell various
> > CI infrastructures to restart / rerun patch tests.  For now, this has to
> > be done by the individual managers of those labs.  Some labs, it isn't
> > possible.  Others, it's possible but is a very time-consuming process to
> > restart a test case.  In all cases, a maintainer needs to spend time
> > communicating with a lab manager.  This could be made a bit nicer.
> >
>
> Just to tie two relevant threads together. I made a request in
> http://mails.dpdk.org/archives/ci/2022-January/001593.html for a
> "retest" button (or really any manual but self-sufficient way) to
> kick-off immediately what is run in periodic branch testing. Something
> might be there already, that i'm just not aware of.
>
> This could be used by LTS maintainers, and possibly main, *-next branch
> maintainers coming up to releases.
>
> thanks,
> Kevin.
>
> > One proposal we (Michael and I) have toyed with for our lab is having
> > the infrastructure monitor patchwork comments for a restart flag, and
> > kick off based on that information.  Patchwork tracks all of the
> > comments for each patch / series so we could look at the series that
> > are still in a state for 'merging' (new, assigned, etc) and check the
> > patch .comments API for new comments.  Getting the data from PW should
> > be pretty simple - but I think that knowing whether to kick off the
> > test might be more difficult.  We have concerns about which messages we
> > should accept (for example, can anyone ask for a series to be rerun, and
> > we'll need to track which rerun messages we've accepted).  The
> > convention needs to be something we all can work with (ie: /Re-check:
> > [checkname] or something as a single line in the email).
> >
> > This is just a start to identify and explain the concern.  Maybe there
> > are other issues we've not considered, or maybe folks think this is a
> > terrible idea not worth spending any time developing.  I think there's
> > enough use for it that I am raising it here, and we can discuss it.
> >
> > Thanks,
> > -Aaron
> >
>
>

-- 
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)



[PATCH] sched: Cleanup qos scheduler defines from rte_config

2022-01-21 Thread Megha Ajmera
Cleanup of sched config options those are by-default not defined.

Signed-off-by: Megha Ajmera 
Acked-by: Cristian Dumitrescu 
---
 config/rte_config.h   | 7 ---
 lib/sched/rte_sched.c | 4 
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/config/rte_config.h b/config/rte_config.h
index cab4390a97..917097630e 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -88,13 +88,6 @@
 /* rte_power defines */
 #define RTE_MAX_LCORE_FREQS 64
 
-/* rte_sched defines */
-#undef RTE_SCHED_CMAN
-#undef RTE_SCHED_COLLECT_STATS
-#undef RTE_SCHED_SUBPORT_TC_OV
-#define RTE_SCHED_PORT_N_GRINDERS 8
-#undef RTE_SCHED_VECTOR
-
 /* KNI defines */
 #define RTE_KNI_PREEMPT_DEFAULT 1
 
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 62b3d2e315..6c3e3bb0bf 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -35,6 +35,10 @@
 
 #endif
 
+#ifndef RTE_SCHED_PORT_N_GRINDERS
+#define RTE_SCHED_PORT_N_GRINDERS 8
+#endif
+
 #define RTE_SCHED_TB_RATE_CONFIG_ERR  (1e-7)
 #define RTE_SCHED_WRR_SHIFT   3
 #define RTE_SCHED_MAX_QUEUES_PER_TC   RTE_SCHED_BE_QUEUES_PER_PIPE
-- 
2.25.1



Re: [PATCH] common/cnxk: fix incorrect error checking

2022-01-21 Thread Tomasz Duszynski
On Tue, Dec 21, 2021 at 04:02:20PM +0800, Weiguo Li wrote:
> Fixes: 804c108b039a ("common/cnxk: set BPHY IRQ handler")
>
> Signed-off-by: Weiguo Li 
> ---
>  drivers/common/cnxk/roc_bphy_irq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/common/cnxk/roc_bphy_irq.c 
> b/drivers/common/cnxk/roc_bphy_irq.c
> index f4e9b341af..5ba73c98dc 100644
> --- a/drivers/common/cnxk/roc_bphy_irq.c
> +++ b/drivers/common/cnxk/roc_bphy_irq.c
> @@ -261,9 +261,9 @@ roc_bphy_irq_handler_set(struct roc_bphy_irq_chip *chip, 
> int irq_num,
>   CPU_SET(curr_cpu, &intr_cpuset);
>   retval = pthread_setaffinity_np(pthread_self(), sizeof(intr_cpuset),
>   &intr_cpuset);

Use rc instead. This will generate less changes and will match
local conventions.

> - if (rc < 0) {
> + if (retval < 0) {
>   plt_err("Failed to set affinity mask");
> - return rc;
> + return retval;
>   }
>
>   irq_usr.isr_base = (uint64_t)roc_bphy_intr_handler;
> --
> 2.25.1
>


[PATCH v6] raw/ifpga: fix pthread cannot join

2022-01-21 Thread Wei Huang
From: Tianfei Zhang 

When we want to close a thread, we should set a flag to notify
thread handler function.

Fixes: 9c006c45 ("raw/ifpga: scan PCIe BDF device tree")
Cc: sta...@dpdk.org

Signed-off-by: Tianfei Zhang 
---
v2: update commit log
---
v3: set thread id to 0 after pthread_join
---
v4: do not evaluate and set pthread_t variable
---
v5: use builtin atomic function to access ifpga_monitor_start flag
---
v6: use __atomic_xxx_n to replace rte_atomicNN_xxx
---
 drivers/raw/ifpga/ifpga_rawdev.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/raw/ifpga/ifpga_rawdev.c b/drivers/raw/ifpga/ifpga_rawdev.c
index 8d9db58..19c2357 100644
--- a/drivers/raw/ifpga/ifpga_rawdev.c
+++ b/drivers/raw/ifpga/ifpga_rawdev.c
@@ -497,7 +497,7 @@ static int set_surprise_link_check_aer(
int gsd_enable, ret;
 #define MS 1000
 
-   while (1) {
+   while (__atomic_load_n(&ifpga_monitor_start, __ATOMIC_RELAXED)) {
gsd_enable = 0;
for (i = 0; i < IFPGA_RAWDEV_NUM; i++) {
ifpga_rdev = &ifpga_rawdevices[i];
@@ -525,7 +525,7 @@ static int set_surprise_link_check_aer(
 {
int ret;
 
-   if (ifpga_monitor_start == 0) {
+   if (!__atomic_load_n(&ifpga_monitor_start, __ATOMIC_RELAXED)) {
ret = rte_ctrl_thread_create(&ifpga_monitor_start_thread,
 "ifpga-monitor", NULL,
 ifpga_rawdev_gsd_handle, NULL);
@@ -534,7 +534,7 @@ static int set_surprise_link_check_aer(
"Fail to create ifpga nonitor thread");
return -1;
}
-   ifpga_monitor_start = 1;
+   __atomic_store_n(&ifpga_monitor_start, 1, __ATOMIC_RELAXED);
}
 
return 0;
@@ -544,7 +544,9 @@ static int set_surprise_link_check_aer(
 {
int ret;
 
-   if (ifpga_monitor_start == 1) {
+   if (__atomic_load_n(&ifpga_monitor_start, __ATOMIC_RELAXED)) {
+   __atomic_store_n(&ifpga_monitor_start, 0, __ATOMIC_RELAXED);
+
ret = pthread_cancel(ifpga_monitor_start_thread);
if (ret)
IFPGA_RAWDEV_PMD_ERR("Can't cancel the thread");
@@ -553,8 +555,6 @@ static int set_surprise_link_check_aer(
if (ret)
IFPGA_RAWDEV_PMD_ERR("Can't join the thread");
 
-   ifpga_monitor_start = 0;
-
return ret;
}
 
-- 
1.8.3.1



[PATCH v2] common/cnxk: fix incorrect error checking

2022-01-21 Thread Weiguo Li
Fixes: 804c108b039a ("common/cnxk: set BPHY IRQ handler")

Signed-off-by: Weiguo Li 
---
 drivers/common/cnxk/roc_bphy_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/common/cnxk/roc_bphy_irq.c 
b/drivers/common/cnxk/roc_bphy_irq.c
index f4e9b341af..f4954d2a28 100644
--- a/drivers/common/cnxk/roc_bphy_irq.c
+++ b/drivers/common/cnxk/roc_bphy_irq.c
@@ -259,7 +259,7 @@ roc_bphy_irq_handler_set(struct roc_bphy_irq_chip *chip, 
int irq_num,
 
CPU_ZERO(&intr_cpuset);
CPU_SET(curr_cpu, &intr_cpuset);
-   retval = pthread_setaffinity_np(pthread_self(), sizeof(intr_cpuset),
+   rc = pthread_setaffinity_np(pthread_self(), sizeof(intr_cpuset),
&intr_cpuset);
if (rc < 0) {
plt_err("Failed to set affinity mask");
-- 
2.25.1



Re: [PATCH 1/8] ethdev: introduce IP reassembly offload

2022-01-21 Thread Andrew Rybchenko

On 1/3/22 18:08, Akhil Goyal wrote:

IP Reassembly is a costly operation if it is done in software.
The operation becomes even more costlier if IP fragmants are encrypted.
However, if it is offloaded to HW, it can considerably save application cycles.

Hence, a new offload RTE_ETH_RX_OFFLOAD_IP_REASSEMBLY is introduced in
ethdev for devices which can attempt reassembly of packets in hardware.
rte_eth_dev_info is updated with the reassembly capabilities which a device
can support.


Yes, reassembly is really complicated process taking possibility to have
overlapping fragments, out-of-order etc.
There are network attacks based on IP reassembly.
Will it simply result in IP reassembly failure if no buffers are left
for IP fragments? What will be reported in mbuf if some packets overlap?
Just raw packets as is or reassembly result with holes?
I think behavour should be specified/


The resulting reassembled packet would be a typical segmented mbuf in
case of success.

And if reassembly of fragments is failed or is incomplete (if fragments do
not come before the reass_timeout), the mbuf ol_flags can be updated.
This is updated in a subsequent patch.

Signed-off-by: Akhil Goyal 
---
  doc/guides/nics/features.rst | 12 
  lib/ethdev/rte_ethdev.c  |  1 +
  lib/ethdev/rte_ethdev.h  | 32 +++-
  3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 27be2d2576..1dfdee9602 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -602,6 +602,18 @@ Supports inner packet L4 checksum.

``tx_offload_capa,tx_queue_offload_capa:RTE_ETH_TX_OFFLOAD_OUTER_UDP_CKSUM``.
  
  
+.. _nic_features_ip_reassembly:

+
+IP reassembly
+-
+
+Supports IP reassembly in hardware.
+
+* **[uses] rte_eth_rxconf,rte_eth_rxmode**: 
``offloads:RTE_ETH_RX_OFFLOAD_IP_REASSEMBLY``.


Looking at the patch I see no changes and usage of rte_eth_rxconf and
rte_eth_rxmode. It should be added here later if corresponding changes
come in subsequent patches.


+* **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_IP_REASSEMBLY_INCOMPLETE``


Same here. The flag is not defined yet. So, it must not be mentioned in
the patch.
.

+* **[provides] rte_eth_dev_info**: ``reass_capa``.
+
+
  .. _nic_features_shared_rx_queue:
  
  Shared Rx queue




diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index fa299c8ad7..11427b2e4d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h


[snip]


@@ -1781,6 +1782,33 @@ enum rte_eth_representor_type {
RTE_ETH_REPRESENTOR_PF,   /**< representor of Physical Function. */
  };
  
+/* Flag to offload IP reassembly for IPv4 packets. */

+#define RTE_ETH_DEV_REASSEMBLY_F_IPV4 (RTE_BIT32(0))
+/* Flag to offload IP reassembly for IPv6 packets. */
+#define RTE_ETH_DEV_REASSEMBLY_F_IPV6 (RTE_BIT32(1))
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice.
+ *
+ * A structure used to set IP reassembly configuration.


In the patch the structure is used to provide capabilities,
not to set configuration.

If you are going to use the same structure in capabilities and
configuration, it could be handy, but really confusing since
interpretation of fields should be different.
As a bare minimum the difference must be specified in comments.
Right now all fields makes sense in capabilities and configuration:
maximum possible vs actual value, however, not everything could be
really configurable and it will become confusing. It is really hard
to discuss right now since the patch does not provide usage of the
structure for the configuration.


+ *
+ * If RTE_ETH_RX_OFFLOAD_IP_REASSEMBLY flag is set in offloads field,
+ * the PMD will attempt IP reassembly for the received packets as per
+ * properties defined in this structure:
+ *
+ */
+struct rte_eth_ip_reass_params {
+   /** Maximum time in ms which PMD can wait for other fragments. */
+   uint32_t reass_timeout;


Please, specify units. May be even in field name. E.g. reass_timeout_ms.


+   /** Maximum number of fragments that can be reassembled. */
+   uint16_t max_frags;
+   /**
+* Flags to enable reassembly of packet types -
+* RTE_ETH_DEV_REASSEMBLY_F_xxx.
+*/
+   uint16_t flags;


If it is just for packet types, I'd suggest to name the field more
precise. Also it will avoid flags vs frags misreading.
Just an idea. Up to you.


+};
+
  /**
   * A structure used to retrieve the contextual information of
   * an Ethernet device, such as the controlling driver of the
@@ -1841,8 +1869,10 @@ struct rte_eth_dev_info {
 * embedded managed interconnect/switch.
 */
struct rte_eth_switch_info switch_info;
+   /** IP reassembly offload capabilities that a device can support. */
+   struct rte_eth_ip_reass_params reass_capa;
  
-	uint64_t reserved_64s[2]; /**< Reserved for future fields */

+