Process for adding a new driver?
Dear DPDK tech board, The process for adding a new library to DPDK is well documented [1]. What is the process for adding a new (NIC) driver? It seems like the task of reviewing NIC PMDs from vendors other than Broadcom/Intel/Marvell/NVIDIA falls entirely on the next-net tree maintainers, Ferruh and Andrew, which doesn't seem like a reasonable burden. The Napatech driver is too large for Ferruh to review, which in my opinion [2] is an unreasonable argument for not accepting it. And the 3SNIC driver got no attention by any reviewers [3]. (Although Stephen did provide some basic feedback after they polled for review.) Overall, I think we should put much more trust in hardware vendors to provide high quality drivers for their hardware. We want vendors to upstream their drivers, with all the benefits of having the code public. If we make it too difficult, they will simply keep their drivers private instead. @Maxime: I propose to put this on the agenda for the coming techboard meeting. [1]: https://doc.dpdk.org/guides/contributing/new_library.html [2]: http://inbox.dpdk.org/dev/98cbd80474fa8b44bf855df32c47dc35d87...@smartserver.smartshare.dk/ [3]: http://inbox.dpdk.org/dev/6df9c00f-23a0-423f-840b-4ecf20ff8...@3snic.com/ Med venlig hilsen / Kind regards, -Morten Brørup
RE: [PATCH] net/mlx5: share QUOTA indirect action
> -Original Message- > From: Gregory Etelson > Sent: Thursday, June 29, 2023 7:48 PM > To: dev@dpdk.org > Cc: Maayan Kashani ; Raslan Darawsheh > ; Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; Suanming Mou > > Subject: [PATCH] net/mlx5: share QUOTA indirect action > > Support shared indirect QUOTA action. > > flow configure 1 queues_number 4 queues_size 64 quotas_number 32 flow > configure 0 queues_number 4 queues_size 64 quotas_number 0 \ > host_port 1 flags 2 > > flow indirect_action 1 create ingress action_id 8 \ > action quota_create limit 18000 mode l3 / end > > flow actions_template 0 create ingress actions_template_id 1 \ > template shared_indirect / jump / end \ > mask quota_create / jump group 0 / end > > flow queue 0 create 0 template_table 1 \ > pattern_template 0 actions_template 0 postpone no \ > pattern eth / end \ > actions shared_indirect 1 8 / jump group 2 / end > > Signed-off-by: Gregory Etelson Acked-by: Viacheslav Ovsiienko
[PATCH] eventdev/eth_rx: fix timestamp field register in mbuf
For eventdev internal port, timestamp dynamic field registration
in mbuf is not required as that will be done from net device.
For SW eventdev, Rx timestamp field registration will be
done during Rx queue add operation as per device capabilities and
offload configuration.
Fixes: 83ab470d1259 ("eventdev/eth_rx: use timestamp as dynamic mbuf field")
Cc: sta...@dpdk.org
Signed-off-by: Rahul Bhansali
---
lib/eventdev/rte_event_eth_rx_adapter.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
b/lib/eventdev/rte_event_eth_rx_adapter.c
index 3ebfa5366d..5a5fade466 100644
--- a/lib/eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/eventdev/rte_event_eth_rx_adapter.c
@@ -2472,13 +2472,6 @@ rxa_create(uint8_t id, uint8_t dev_id,
if (conf_cb == rxa_default_conf_cb)
rx_adapter->default_cb_arg = 1;
- if (rte_mbuf_dyn_rx_timestamp_register(
- &event_eth_rx_timestamp_dynfield_offset,
- &event_eth_rx_timestamp_dynflag) != 0) {
- RTE_EDEV_LOG_ERR("Error registering timestamp field in mbuf\n");
- return -rte_errno;
- }
-
rte_eventdev_trace_eth_rx_adapter_create(id, dev_id, conf_cb,
conf_arg);
return 0;
@@ -2738,6 +2731,7 @@ rte_event_eth_rx_adapter_queue_add(uint8_t id,
1);
}
} else {
+ uint64_t dev_offloads;
rte_spinlock_lock(&rx_adapter->rx_lock);
dev_info->internal_event_port = 0;
ret = rxa_init_service(rx_adapter, id);
@@ -2749,6 +2743,17 @@ rte_event_eth_rx_adapter_queue_add(uint8_t id,
rxa_sw_adapter_queue_count(rx_adapter));
}
rte_spinlock_unlock(&rx_adapter->rx_lock);
+
+ dev_offloads = dev_info->dev->data->dev_conf.rxmode.offloads;
+ if (dev_offloads & RTE_ETH_RX_OFFLOAD_TIMESTAMP) {
+ if (rte_mbuf_dyn_rx_timestamp_register(
+ &event_eth_rx_timestamp_dynfield_offset,
+ &event_eth_rx_timestamp_dynflag) != 0) {
+ RTE_EDEV_LOG_ERR("Error registering timestamp
field in mbuf\n");
+ return -rte_errno;
+ }
+ }
+
}
rte_eventdev_trace_eth_rx_adapter_queue_add(id, eth_dev_id,
--
2.25.1
RE: [PATCH] net/mlx5: share QUOTA indirect action
Hi, > -Original Message- > From: Gregory Etelson > Sent: Thursday, June 29, 2023 7:48 PM > To: dev@dpdk.org > Cc: Maayan Kashani ; Raslan Darawsheh > ; Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; Suanming Mou > > Subject: [PATCH] net/mlx5: share QUOTA indirect action > > Support shared indirect QUOTA action. > > flow configure 1 queues_number 4 queues_size 64 quotas_number 32 flow > configure 0 queues_number 4 queues_size 64 quotas_number 0 \ > host_port 1 flags 2 > > flow indirect_action 1 create ingress action_id 8 \ > action quota_create limit 18000 mode l3 / end > > flow actions_template 0 create ingress actions_template_id 1 \ > template shared_indirect / jump / end \ > mask quota_create / jump group 0 / end > > flow queue 0 create 0 template_table 1 \ > pattern_template 0 actions_template 0 postpone no \ > pattern eth / end \ > actions shared_indirect 1 8 / jump group 2 / end > > Signed-off-by: Gregory Etelson Patch applied to next-net-mlx, Kindest regards, Raslan Darawsheh
Re: [PATCH v16 1/8] net/ntnic: initial commit which adds register defines
On 9/15/2023 7:37 PM, Morten Brørup wrote: >> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com] >> Sent: Friday, 15 September 2023 17.55 >> >> On 9/8/2023 5:07 PM, Mykola Kostenok wrote: >>> From: Christian Koue Muf >>> >>> The NTNIC PMD does not rely on a kernel space Napatech driver, >>> thus all defines related to the register layout is part of the PMD >>> code, which will be added in later commits. >>> >>> Signed-off-by: Christian Koue Muf >>> Reviewed-by: Mykola Kostenok >>> >> >> Hi Mykola, Christiam, >> >> This PMD scares me, overall it is a big drop: >> "249 files changed, 87128 insertions(+)" >> >> I think it is not possible to review all in one release cycle, and it is >> not even possible to say if all code used or not. >> >> I can see code is already developed, and it is difficult to restructure >> developed code, but restructure it into small pieces really helps for >> reviews. >> >> >> Driver supports good list of features, can it be possible to distribute >> upstream effort into multiple release. >> Starting from basic functionality and add features gradually. >> Target for this release can be providing datapath, and add more if we >> have time in the release, what do you think? >> >> >> Also there are large amount of base code (HAL / FPGA code), instead of >> adding them as a bulk, relevant ones with a feature can be added with >> the feature patch, this eliminates dead code in the base code layer, >> also helps user/review to understand the link between driver code and >> base code. > > Jumping in here with an opinion about welcoming new NIC vendors to the > community: > > Generally, if a NIC vendor supplies a PMD for their NIC, I expect the vendor > to take responsibility for the quality of the PMD, including providing a > maintainer and support backporting of fixes to the PMD in LTS releases. This > should align with the vendor's business case for upstreaming their driver. > > If the vendor provides one big patch series, which may be difficult to > understand/review, the fallout mainly hits the vendor's customers (and thus > the vendor's support organization), not the community as a whole. > Hi Morten, I was thinking same before making my above comment, what happens if vendors submit as one big patch and when a problem occurs we can ask owner to fix. Probably this makes vendor happy and makes my life (or any other maintainer's life) easier, it is always easier to say yes. But I come up with two main reasons to ask for a rework: 1- Technically any vendor can deliver their software to their customers via a public git repository, they don't have to upstream to dpdk.org, but upstreaming has many benefits. One of those benefits is upstreaming provides a quality assurance for vendor's customers (that is why customer can be asking for this, as we are having in many cases), and this quality assurance comes from additional eyes reviewing the code and guiding vendors for the DPDK quality standards (some vendors already doing pretty good, but new ones sometimes requires hand-holding). If driver is one big patch series, it is practically not possible to review it, I can catch a few bits here or there, you may some others, but practically it will be merged without review, and we will fail on our quality assurance task. 2- Make code more accessible to the rest of the world. When it is a big patch, code can be functional but lots of details, reasoning, relation between components gets lost, which makes it even harder for an external developer, like me, to understand it (I am a mere guinea pig here :). If a customer would like to add a feature themselves, or fix something, even after vendor no more working on that product anymore, customer needs to understand the code or some reasoning in the code. Or if someone wants to backport the driver to rust, or a DPDK developer wants to do a rework that requires updating all drivers, or a tester would like to analyze the code to figure out behavior difference of the devices. I think I have witness all above cases in real life. If driver is split into more patches, it makes patch easier to understand which makes code practically more accessible to other developers that are not expert in driver. Overall, yes splitting patch takes time and effort, and yes this is an overhead for a code that is already developed, but I think benefit is big so it worth doing the task. > We, the community, should not make it too difficult for vendors trying to > upstream their drivers. I certainly consider it unreasonable to ask a vendor > to postpone the release of some existing features by effectively an entire > year (considering that only LTS releases are relevant for most of us) because > we want the vendor to refactor the patch series to match our preferences > within an unrealistic timeframe. > Agree to not make upstreaming difficult for new vendors, and indeed we are encouraging more vendors to be upstream their code, this is in best interest
RE: [EXT] [PATCH 00/12] crypto/dpaax_sec: misc enhancements
> -- > This series include misc enhancements in dpaax_sec drivers. > > - improving the IPsec protocol offload features > - enhancing PDCP protocol processing > - code optimization and cleanup > > Apeksha Gupta (1): > crypto/dpaa2_sec: enhance dpaa FD FL FMT offset set > > Gagandeep Singh (3): > common/dpaax: update IPsec base descriptor length > common/dpaax: change mode to wait in shared desc > crypto/dpaax_sec: set the authdata in non-auth case > > Hemant Agrawal (7): > crypto/dpaa2_sec: supporting null cipher and auth > crypto/dpaa_sec: supporting null cipher and auth > crypto/dpaa2_sec: support copy df and dscp in proto offload > crypto/dpaa2_sec: increase the anti replay window size > crypto/dpaa2_sec: enable esn support > crypto/dpaa2_sec: add NAT-T support in IPsec offload > crypto/dpaa2_sec: add support to set df and diffserv > > Vanshika Shukla (1): > crypto/dpaa2_sec: initialize the pdcp alg to null > > drivers/common/dpaax/caamflib/desc/ipsec.h| 4 +- > drivers/common/dpaax/caamflib/desc/pdcp.h | 82 +++--- > .../dpaax/caamflib/rta/sec_run_time_asm.h | 2 +- > drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 234 ++ > drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h | 64 - > drivers/crypto/dpaa2_sec/dpaa2_sec_raw_dp.c | 47 +--- > drivers/crypto/dpaa_sec/dpaa_sec.c| 5 + > drivers/crypto/dpaa_sec/dpaa_sec.h| 42 +++- > drivers/net/dpaa2/dpaa2_rxtx.c| 3 +- > 9 files changed, 294 insertions(+), 189 deletions(-) > Please fix compilation issues. http://mails.dpdk.org/archives/test-report/2023-August/451079.html
Re: [PATCH v3 12/27] net/nfp: refact the hwinfo module
On 9/18/2023 2:39 AM, Chaoyong He wrote: > > >> -Original Message- >> From: Ferruh Yigit >> Sent: Friday, September 15, 2023 9:46 PM >> To: Chaoyong He ; dev@dpdk.org >> Cc: oss-drivers ; Niklas Soderlund >> >> Subject: Re: [PATCH v3 12/27] net/nfp: refact the hwinfo module >> >> On 9/15/2023 10:15 AM, Chaoyong He wrote: >>> Move the definition of data structure and macro into the implement file. >>> >> >> What is the motivation for this move, I can see same is done in multiple >> other >> patches? >> Header file is still included by .c file, what is the benefit of moving from >> header >> to .c file? > > We try to make the interface between modules as small as possible. > > We meet some problem when we add new features, too much content in the header > files make it difficult to form a identify dependencies among modules. > When we try to add a new data field in a structure or add a new data type in > one header file, we had to modify many unrelated files just because it > includes this header file, it's not good. > > This is the direct motivation for this move, this will make the development > easier.> If you can move a struct or data type to .c file, it means it is not shared so updating it should not cause change anyway. I am not against it, but I didn't get your reasoning. When there are 'nfp_hwinfo.c' and 'nfp_hwinfo.h' files, I think that is reasonable to have "nfp_hwinfo*" macros and structs in the .h file, it looks like you want to separate data structures that are shared and ones that are only used by 'nfp_hwinfo.c' but I am not sure how it helps. Anyway if you know what you are doing, it is OK, I just want to double check if this is done on purpose.
RE: [EXT] [PATCH v3 1/2] crypto/scheduler: support DOCSIS security protocol
Hi David,
Thanks for updating the patches based on the comments provided on previous
version. Please see inline for some comments on code.
Thanks,
Anoob
> -Original Message-
> From: David Coyle
> Sent: Thursday, September 14, 2023 8:52 PM
> To: dev@dpdk.org
> Cc: kai...@intel.com; Anoob Joseph ;
> kevin.osulli...@intel.com; David Coyle
> Subject: [EXT] [PATCH v3 1/2] crypto/scheduler: support DOCSIS security
> protocol
>
> External Email
>
> --
> Add support to the cryptodev scheduler PMD for the DOCSIS security
> protocol. This includes adding the following to the scheduler:
> - synchronization of worker's security capabilities
> - retrieval of the scheduler's synchronized security capabilities
> - retrieval of the security session size i.e. maximum session size
> across all workers
> - creation of security sessions on each worker
> - deletion of security sessions on each worker
>
> Signed-off-by: David Coyle
> Signed-off-by: Kevin O'Sullivan
> ---
> doc/guides/rel_notes/release_23_11.rst| 4 +
> drivers/crypto/scheduler/meson.build | 2 +-
> .../scheduler/rte_cryptodev_scheduler.c | 221 +-
> drivers/crypto/scheduler/scheduler_failover.c | 12 +-
> .../crypto/scheduler/scheduler_multicore.c| 10 +-
> .../scheduler/scheduler_pkt_size_distr.c | 54 +--
> drivers/crypto/scheduler/scheduler_pmd.c | 33 ++
> drivers/crypto/scheduler/scheduler_pmd_ops.c | 381 +-
> .../crypto/scheduler/scheduler_pmd_private.h | 159 +---
> .../crypto/scheduler/scheduler_roundrobin.c | 6 +-
> 10 files changed, 653 insertions(+), 229 deletions(-)
>
> diff --git a/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
> b/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
> index 258d6f8c43..e8b905af2f 100644
> --- a/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
> +++ b/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
> @@ -5,11 +5,14 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "rte_cryptodev_scheduler.h"
> #include "scheduler_pmd_private.h"
>
> +#define MAX_CAPS 256
> +
> /** update the scheduler pmd's capability with attaching device's
> * capability.
> * For each device to be attached, the scheduler's capability should be @@ -
> 59,7 +62,6 @@ sync_caps(struct rte_cryptodev_capabilities *caps,
> cap->sym.auth.digest_size.max ?
> s_cap->sym.auth.digest_size.max :
> cap->sym.auth.digest_size.max;
> -
> }
>
> if (s_cap->sym.xform_type ==
> @@ -81,25 +83,176 @@ sync_caps(struct rte_cryptodev_capabilities *caps,
>
> memset(&caps[sync_nb_caps - 1], 0, sizeof(*cap));
> sync_nb_caps--;
> + i--;
> }
>
> return sync_nb_caps;
> }
>
> static int
> -update_scheduler_capability(struct scheduler_ctx *sched_ctx)
> +check_sec_cap_equal(const struct rte_security_capability *sec_cap1,
> + struct rte_security_capability *sec_cap2) {
> + if (sec_cap1->action != sec_cap2->action ||
> + sec_cap1->protocol != sec_cap2->protocol ||
> + sec_cap1->ol_flags != sec_cap2->ol_flags)
> + return 0;
> +
> + if (sec_cap1->protocol == RTE_SECURITY_PROTOCOL_DOCSIS)
> + return !memcmp(&sec_cap1->docsis, &sec_cap2->docsis,
> + sizeof(sec_cap1->docsis));
> + else
> + return 0;
> +}
> +
> +static void
> +copy_sec_cap(struct rte_security_capability *dst_sec_cap,
> + struct rte_security_capability *src_sec_cap) {
> + dst_sec_cap->action = src_sec_cap->action;
> + dst_sec_cap->protocol = src_sec_cap->protocol;
> + if (src_sec_cap->protocol == RTE_SECURITY_PROTOCOL_DOCSIS)
> + dst_sec_cap->docsis = src_sec_cap->docsis;
> + dst_sec_cap->ol_flags = src_sec_cap->ol_flags; }
> +
> +static uint32_t
> +sync_sec_crypto_caps(struct rte_cryptodev_capabilities
> *tmp_sec_crypto_caps,
> + const struct rte_cryptodev_capabilities *sec_crypto_caps,
> + const struct rte_cryptodev_capabilities
> *worker_sec_crypto_caps) {
> + uint8_t nb_caps = 0;
> +
> + nb_caps = sync_caps(tmp_sec_crypto_caps, nb_caps,
> sec_crypto_caps);
> + sync_caps(tmp_sec_crypto_caps, nb_caps,
> worker_sec_crypto_caps);
> +
> + return nb_caps;
> +}
> +
> +/** update the scheduler pmd's security capability with attaching
> +device's
> + * security capability.
> + * For each device to be attached, the scheduler's security capability
> +should
> + * be the common capability set of all workers **/ static uint32_t
> +sync_sec_caps(uint32_t worker_idx,
> + struct rte_security_capability *sec_caps,
> + struct rte_cryptodev_capabilities
> sec_crypto_caps[][MAX
RE: [PATCH v1 1/2] dmadev: offload to free source buffer
Hi Amit,
Thanks for adding the feature. Please see inline.
With the mentioned fixes,
Acked-by: Anoob Joseph
Thanks,
Anoob
> -Original Message-
> From: Amit Prakash Shukla
> Sent: Thursday, September 7, 2023 1:41 PM
> To: Chengwen Feng ; Kevin Laatz
> ; Bruce Richardson
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> conor.wa...@intel.com; Vamsi Krishna Attunuru ;
> g.si...@nxp.com; sachin.sax...@oss.nxp.com; hemant.agra...@nxp.com;
> cheng1.ji...@intel.com; Nithin Kumar Dabilpuram
> ; Anoob Joseph ; Amit
> Prakash Shukla ; Morten Brørup
>
> Subject: [PATCH v1 1/2] dmadev: offload to free source buffer
>
> This changeset adds support in DMA library to free source DMA buffer by
> hardware. On a supported hardware, application can pass on the mempool
> information as part of vchan config when the DMA transfer direction is
> configured as RTE_DMA_DIR_MEM_TO_DEV.
>
> Signed-off-by: Amit Prakash Shukla
> Acked-by: Morten Brørup
> ---
> lib/dmadev/rte_dmadev.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h index
> b157ab7600..d6a685907f 100644
> --- a/lib/dmadev/rte_dmadev.h
> +++ b/lib/dmadev/rte_dmadev.h
> @@ -278,6 +278,13 @@ int16_t rte_dma_next_dev(int16_t start_dev_id);
> #define RTE_DMA_CAPA_OPS_COPY_SG RTE_BIT64(33)
> /** Support fill operation. */
> #define RTE_DMA_CAPA_OPS_FILLRTE_BIT64(34)
> +/** Support for source buffer free for mem to dev transfer.
> + *
> + * @note Even though the DMA driver has this capability, it may not
> +support all
> + * mempool drivers. If the mempool is not supported by the DMA driver,
> + * rte_dma_vchan_setup() will fail.
> + **/
[Anoob] I think you can remove the note. It is mentioned below also, right?
That should be sufficient I guess. Not a strong comment. You can decide.
> +#define RTE_DMA_CAPA_MEM_TO_DEV_SOURCE_BUFFER_FREE
> RTE_BIT64(35)
> /**@}*/
>
> /**
> @@ -581,6 +588,19 @@ struct rte_dma_vchan_conf {
>* @see struct rte_dma_port_param
>*/
> struct rte_dma_port_param dst_port;
> + /** mempool from which source buffer is allocated. mempool info is
[Anoob] Mempool -> Mempool (in both places)
> used
> + * for freeing source buffer by hardware when configured direction is
> + * RTE_DMA_DIR_MEM_TO_DEV. To free the source buffer by
> hardware,
> + * RTE_DMA_OP_FLAG_FREE_SBUF must be set while calling
> rte_dma_copy and
> + * rte_dma_copy_sg().
> + *
> + * @note If the mempool is not supported by the DMA driver,
> + * rte_dma_vchan_setup() will fail.
[Anoob] "If the mempool is not supported by the DMA device, ..."
driver -> device.
> + *
> + * @see RTE_DMA_OP_FLAG_FREE_SBUF
> + */
> + struct rte_mempool *mem_to_dev_src_buf_pool;
> +
> };
>
> /**
> @@ -818,6 +838,13 @@ struct rte_dma_sge {
> * capability bit for this, driver should not return error if this flag was
> set.
> */
> #define RTE_DMA_OP_FLAG_LLC RTE_BIT64(2)
> +/** Mem to dev source buffer free flag.
> + * Used for freeing source DMA buffer by hardware when the transfer
> +direction is
> + * configured as RTE_DMA_DIR_MEM_TO_DEV.
> + *
> + * @see struct rte_dma_vchan_conf::mem_to_dev_src_buf_pool
> + */
> +#define RTE_DMA_OP_FLAG_FREE_SBUFRTE_BIT64(3)
> /**@}*/
>
> /**
> --
> 2.25.1
RE: [PATCH 31/36] net/softnic: fix Rx and Tx queue state
> -Original Message-
> From: Jie Hai
> Sent: Friday, September 8, 2023 12:29 PM
> To: dev@dpdk.org; Dumitrescu, Cristian ;
> Lijun Ou ; Konstantin Ananyev
> <"konstantin.v.ananyev@yandex.rukonstantin.ananyev"@huawei.com>;
> Thomas Monjalon ; Ferruh Yigit
> ; Chengwen Feng
> Cc: haij...@huawei.com; lihuis...@huawei.com
> Subject: [PATCH 31/36] net/softnic: fix Rx and Tx queue state
>
> The DPDK framework reports the queue state, which is stored in
> dev->data->tx_queue_state and dev->data->rx_queue_state. The
> state is maintained by the driver. Users may determine whether
> a queue participates in packet forwarding based on the state.
> Therefore, the driver needs to modify the queue state in time
> according to the actual situation.
>
> Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jie Hai
> ---
Acked-by: Cristian Dumitrescu
[PATCH 1/2] common/cnxk: reserve last LMT line for control ops
As rte_eth_dev_configure() can be called from any EAL or non-EAL cores.
And in case of non-EAL core, LMT address will not be a valid. So,
reserving last LMT line 2047 for control path specific functionality.
Signed-off-by: Rahul Bhansali
---
drivers/common/cnxk/roc_dev.c | 5 +
drivers/common/cnxk/roc_nix_inl.c | 6 --
drivers/common/cnxk/roc_platform.c | 25 +
drivers/common/cnxk/roc_platform.h | 5 +
drivers/common/cnxk/version.map| 2 ++
5 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/common/cnxk/roc_dev.c b/drivers/common/cnxk/roc_dev.c
index 18d7981825..3815da078a 100644
--- a/drivers/common/cnxk/roc_dev.c
+++ b/drivers/common/cnxk/roc_dev.c
@@ -1369,6 +1369,11 @@ dev_init(struct dev *dev, struct plt_pci_device *pci_dev)
if (!dev_cache_line_size_valid())
return -EFAULT;
+ if (!roc_plt_lmt_validate()) {
+ plt_err("Failed to validate LMT line");
+ return -EFAULT;
+ }
+
bar2 = (uintptr_t)pci_dev->mem_resource[2].addr;
bar4 = (uintptr_t)pci_dev->mem_resource[4].addr;
if (bar2 == 0 || bar4 == 0) {
diff --git a/drivers/common/cnxk/roc_nix_inl.c
b/drivers/common/cnxk/roc_nix_inl.c
index 5cb1f11f53..750fd08355 100644
--- a/drivers/common/cnxk/roc_nix_inl.c
+++ b/drivers/common/cnxk/roc_nix_inl.c
@@ -779,8 +779,10 @@ nix_inl_eng_caps_get(struct nix *nix)
hw_res->cn10k.compcode = CPT_COMP_NOT_DONE;
- /* Use this lcore's LMT line as no one else is using it */
- ROC_LMT_BASE_ID_GET(lmt_base, lmt_id);
+ /* Use this reserved LMT line as no one else is using it */
+ lmt_id = roc_plt_control_lmt_id_get();
+ lmt_base += ((uint64_t)lmt_id << ROC_LMT_LINE_SIZE_LOG2);
+
memcpy((void *)lmt_base, &inst, sizeof(inst));
lmt_arg = ROC_CN10K_CPT_LMT_ARG | (uint64_t)lmt_id;
diff --git a/drivers/common/cnxk/roc_platform.c
b/drivers/common/cnxk/roc_platform.c
index f91b95ceab..ffc82720b0 100644
--- a/drivers/common/cnxk/roc_platform.c
+++ b/drivers/common/cnxk/roc_platform.c
@@ -21,6 +21,31 @@ roc_plt_init_cb_register(roc_plt_init_cb_t cb)
return 0;
}
+uint16_t
+roc_plt_control_lmt_id_get(void)
+{
+ uint32_t lcore_id = plt_lcore_id();
+ if (lcore_id != LCORE_ID_ANY)
+ return lcore_id << ROC_LMT_LINES_PER_CORE_LOG2;
+ else
+ /* Return Last LMT ID to be use in control path functionality */
+ return ROC_NUM_LMT_LINES - 1;
+}
+
+uint16_t
+roc_plt_lmt_validate(void)
+{
+ if (!roc_model_is_cn9k()) {
+ /* Last LMT line is reserved for control specific operation and
can be
+* use from any EAL or non EAL cores.
+*/
+ if ((RTE_MAX_LCORE << ROC_LMT_LINES_PER_CORE_LOG2) >
+ (ROC_NUM_LMT_LINES - 1))
+ return 0;
+ }
+ return 1;
+}
+
int
roc_plt_init(void)
{
diff --git a/drivers/common/cnxk/roc_platform.h
b/drivers/common/cnxk/roc_platform.h
index e7a6564163..7605eed33d 100644
--- a/drivers/common/cnxk/roc_platform.h
+++ b/drivers/common/cnxk/roc_platform.h
@@ -314,6 +314,11 @@ extern int cnxk_logtype_ree;
__rte_internal
int roc_plt_init(void);
+__rte_internal
+uint16_t roc_plt_control_lmt_id_get(void);
+__rte_internal
+uint16_t roc_plt_lmt_validate(void);
+
/* Init callbacks */
typedef int (*roc_plt_init_cb_t)(void);
int __roc_api roc_plt_init_cb_register(roc_plt_init_cb_t cb);
diff --git a/drivers/common/cnxk/version.map b/drivers/common/cnxk/version.map
index 43c3d9ed77..04f8fabfcb 100644
--- a/drivers/common/cnxk/version.map
+++ b/drivers/common/cnxk/version.map
@@ -463,6 +463,8 @@ INTERNAL {
roc_ot_ipsec_outb_sa_init;
roc_plt_init;
roc_plt_init_cb_register;
+ roc_plt_lmt_validate;
+ roc_plt_control_lmt_id_get;
roc_sso_dev_fini;
roc_sso_dev_init;
roc_sso_dump;
--
2.25.1
RE: [PATCH v2 2/2] app/testpmd: add random item support
Hi Michael,
> -Original Message-
> From: Michael Baum
> Sent: Monday, September 11, 2023 10:42 AM
>
> Add support for random item, usage example:
>
> pattern random spec value 0x1 mask value 0x3 / eth / end
>
> Flow rule with above pattern matching 25% of the traffic, it hits only
> when random value suffix is "01" and miss the others ("00", "10", "11").
>
> Signed-off-by: Michael Baum
> ---
Acked-by: Ori Kam
Best,
Ori
Re: Process for adding a new driver?
On 9/18/2023 8:08 AM, Morten Brørup wrote: > Dear DPDK tech board, > > The process for adding a new library to DPDK is well documented [1]. > > What is the process for adding a new (NIC) driver? > > It seems like the task of reviewing NIC PMDs from vendors other than > Broadcom/Intel/Marvell/NVIDIA falls entirely on the next-net tree > maintainers, Ferruh and Andrew, which doesn't seem like a reasonable burden. > Ack. Also for the vendors that has specific tree, new drivers are still reviewed by next-net maintainers. > The Napatech driver is too large for Ferruh to review, which in my opinion > [2] is an unreasonable argument for not accepting it. > Nope, this is not the exact reason for not accepting. I tried explain on reply to below thread, but briefly main reason is, it is a big chunk of code to be consumed by anyone, not just me, like the consumers of that device. Target is to improve the quality, if the driver split into per feature patches, even if I can't find review comments to improve the quality, it enables others (more smarter reviewers) to improve the code. > And the 3SNIC driver got no attention by any reviewers [3]. (Although Stephen > did provide some basic feedback after they polled for review.) > True, unfortunately. This is different issue from the Napatech one, and this is more a bandwidth issue, so I think we can discuss these two separately. I mentioned about this on DPDK summit meeting, it helps to have pipeline of reviewers, like when I am not available I should know that Morten will be doing the driver reviews. There are many vendors actively contributing to DPDK, their support to add more reviewers to next-net is appreciated. > Overall, I think we should put much more trust in hardware vendors to provide > high quality drivers for their hardware. We want vendors to upstream their > drivers, with all the benefits of having the code public. If we make it too > difficult, they will simply keep their drivers private instead. > Agree that this is another approach worth considering. This may work for some cases, the vendor trees are sample of it already, but those are the ones already part of the community for a while and have their track record, do we want to give same level of trust by default? Or we can even lower the bar to accept any code from any vendor by default, assuming CI checks are in place, this still won't help on discussions like if driver should have side channel socket interface or not etc.. And in this approach, for long run, how it will be different vendor sharing driver via a public git repo or upstreamed to dpdk.org? I think we can add value in dpdk.org which may sometimes means requesting more work from vendor. > @Maxime: I propose to put this on the agenda for the coming techboard meeting. > Please invite me too :) > > [1]: https://doc.dpdk.org/guides/contributing/new_library.html > [2]: > http://inbox.dpdk.org/dev/98cbd80474fa8b44bf855df32c47dc35d87...@smartserver.smartshare.dk/ > [3]: http://inbox.dpdk.org/dev/6df9c00f-23a0-423f-840b-4ecf20ff8...@3snic.com/ > > > Med venlig hilsen / Kind regards, > -Morten Brørup >
[PATCH 2/5] net/mlx5/hws: support additional 4 C registers
New connectX devices have 4 additional registers which can be
used by the application. This support will allow matching on
these new registers.
Signed-off-by: Itamar Gozlan
---
drivers/common/mlx5/mlx5_prm.h| 4
drivers/net/mlx5/hws/mlx5dr_definer.c | 16
drivers/net/mlx5/hws/mlx5dr_definer.h | 4
3 files changed, 24 insertions(+)
diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index 51f426c614..4ead9ba2c7 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -857,6 +857,10 @@ enum modify_reg {
REG_C_5,
REG_C_6,
REG_C_7,
+ REG_C_8,
+ REG_C_9,
+ REG_C_10,
+ REG_C_11,
};
/* Modification sub command. */
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index b82af9d102..2f6f91892b 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -1412,6 +1412,22 @@ mlx5dr_definer_get_register_fc(struct
mlx5dr_definer_conv_data *cd, int reg)
fc = &cd->fc[MLX5DR_DEFINER_FNAME_REG_7];
DR_CALC_SET_HDR(fc, registers, register_c_7);
break;
+ case REG_C_8:
+ fc = &cd->fc[MLX5DR_DEFINER_FNAME_REG_8];
+ DR_CALC_SET_HDR(fc, registers, register_c_8);
+ break;
+ case REG_C_9:
+ fc = &cd->fc[MLX5DR_DEFINER_FNAME_REG_9];
+ DR_CALC_SET_HDR(fc, registers, register_c_9);
+ break;
+ case REG_C_10:
+ fc = &cd->fc[MLX5DR_DEFINER_FNAME_REG_10];
+ DR_CALC_SET_HDR(fc, registers, register_c_10);
+ break;
+ case REG_C_11:
+ fc = &cd->fc[MLX5DR_DEFINER_FNAME_REG_11];
+ DR_CALC_SET_HDR(fc, registers, register_c_11);
+ break;
case REG_A:
fc = &cd->fc[MLX5DR_DEFINER_FNAME_REG_A];
DR_CALC_SET_HDR(fc, metadata, general_purpose);
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.h
b/drivers/net/mlx5/hws/mlx5dr_definer.h
index bf026fa6bb..f5a541bc17 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.h
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.h
@@ -100,6 +100,10 @@ enum mlx5dr_definer_fname {
MLX5DR_DEFINER_FNAME_REG_5,
MLX5DR_DEFINER_FNAME_REG_6,
MLX5DR_DEFINER_FNAME_REG_7,
+ MLX5DR_DEFINER_FNAME_REG_8,
+ MLX5DR_DEFINER_FNAME_REG_9,
+ MLX5DR_DEFINER_FNAME_REG_10,
+ MLX5DR_DEFINER_FNAME_REG_11,
MLX5DR_DEFINER_FNAME_REG_A,
MLX5DR_DEFINER_FNAME_REG_B,
MLX5DR_DEFINER_FNAME_GRE_KEY_PRESENT,
--
2.38.1
[PATCH 3/5] net/mlx5/hws: supporting add_field action
Supporting a new modify action: ADD_FIELD.
The new action allows the summing of the packet source field
and destination field/meta-data. The result is stored in the
destination field.
This new action is supported only on capable devices.
Signed-off-by: Itamar Gozlan
---
drivers/common/mlx5/mlx5_prm.h| 2 ++
drivers/net/mlx5/hws/mlx5dr_action.c | 6 +-
drivers/net/mlx5/hws/mlx5dr_cmd.c | 4 +++-
drivers/net/mlx5/hws/mlx5dr_pat_arg.c | 3 ++-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index 4ead9ba2c7..6df7ca20af 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -761,6 +761,7 @@ enum {
MLX5_MODIFICATION_TYPE_REMOVE = 0x5,
MLX5_MODIFICATION_TYPE_NOP = 0x6,
MLX5_MODIFICATION_TYPE_REMOVE_WORDS = 0x7,
+ MLX5_MODIFICATION_TYPE_ADD_FIELD = 0x8,
MLX5_MODIFICATION_TYPE_MAX,
};
@@ -3442,6 +3443,7 @@ enum mlx5_ifc_stc_action_type {
MLX5_IFC_STC_ACTION_TYPE_ACC_MODIFY_LIST = 0x0e,
MLX5_IFC_STC_ACTION_TYPE_ASO = 0x12,
MLX5_IFC_STC_ACTION_TYPE_COUNTER = 0x14,
+ MLX5_IFC_STC_ACTION_TYPE_ADD_FIELD = 0x1b,
MLX5_IFC_STC_ACTION_TYPE_JUMP_TO_STE_TABLE = 0x80,
MLX5_IFC_STC_ACTION_TYPE_JUMP_TO_TIR = 0x81,
MLX5_IFC_STC_ACTION_TYPE_JUMP_TO_FT = 0x82,
diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c
b/drivers/net/mlx5/hws/mlx5dr_action.c
index 920099ba5b..1a03431706 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.c
+++ b/drivers/net/mlx5/hws/mlx5dr_action.c
@@ -481,6 +481,8 @@ static uint32_t mlx5dr_action_get_mh_stc_type(__be64
pattern)
return MLX5_IFC_STC_ACTION_TYPE_ADD;
case MLX5_MODIFICATION_TYPE_COPY:
return MLX5_IFC_STC_ACTION_TYPE_COPY;
+ case MLX5_MODIFICATION_TYPE_ADD_FIELD:
+ return MLX5_IFC_STC_ACTION_TYPE_ADD_FIELD;
default:
assert(false);
DR_LOG(ERR, "Unsupported action type: 0x%x", action_type);
@@ -1958,7 +1960,9 @@ mlx5dr_action_setter_modify_header(struct
mlx5dr_actions_apply_data *apply,
if (action->modify_header.num_of_actions == 1) {
if (action->modify_header.single_action_type ==
- MLX5_MODIFICATION_TYPE_COPY) {
+ MLX5_MODIFICATION_TYPE_COPY ||
+ action->modify_header.single_action_type ==
+ MLX5_MODIFICATION_TYPE_ADD_FIELD) {
apply->wqe_data[MLX5DR_ACTION_OFFSET_DW7] = 0;
return;
}
diff --git a/drivers/net/mlx5/hws/mlx5dr_cmd.c
b/drivers/net/mlx5/hws/mlx5dr_cmd.c
index f9f220cc6a..98d4b3bd3b 100644
--- a/drivers/net/mlx5/hws/mlx5dr_cmd.c
+++ b/drivers/net/mlx5/hws/mlx5dr_cmd.c
@@ -426,6 +426,7 @@ mlx5dr_cmd_stc_modify_set_stc_param(struct
mlx5dr_cmd_stc_modify_attr *stc_attr,
case MLX5_IFC_STC_ACTION_TYPE_COPY:
case MLX5_IFC_STC_ACTION_TYPE_SET:
case MLX5_IFC_STC_ACTION_TYPE_ADD:
+ case MLX5_IFC_STC_ACTION_TYPE_ADD_FIELD:
*(__be64 *)stc_parm = stc_attr->modify_action.data;
break;
case MLX5_IFC_STC_ACTION_TYPE_JUMP_TO_VPORT:
@@ -599,7 +600,8 @@ mlx5dr_cmd_header_modify_pattern_create(struct ibv_context
*ctx,
int type;
type = MLX5_GET(set_action_in, &pattern_data[i], action_type);
- if (type != MLX5_MODIFICATION_TYPE_COPY)
+ if (type != MLX5_MODIFICATION_TYPE_COPY &&
+ type != MLX5_MODIFICATION_TYPE_ADD_FIELD)
/* Action typ-copy use all bytes for control */
MLX5_SET(set_action_in, &pattern_data[i], data, 0);
}
diff --git a/drivers/net/mlx5/hws/mlx5dr_pat_arg.c
b/drivers/net/mlx5/hws/mlx5dr_pat_arg.c
index 309a61d477..0cec46cf17 100644
--- a/drivers/net/mlx5/hws/mlx5dr_pat_arg.c
+++ b/drivers/net/mlx5/hws/mlx5dr_pat_arg.c
@@ -80,7 +80,8 @@ static bool mlx5dr_pat_compare_pattern(enum
mlx5dr_action_type cur_type,
u8 action_id =
MLX5_GET(set_action_in, &actions[i], action_type);
- if (action_id == MLX5_MODIFICATION_TYPE_COPY) {
+ if (action_id == MLX5_MODIFICATION_TYPE_COPY ||
+ action_id == MLX5_MODIFICATION_TYPE_ADD_FIELD) {
if (actions[i] != cur_actions[i])
return false;
} else {
--
2.38.1
[PATCH 1/5] net/mlx5/hws: add support for matching on bth_a bit
RTE_FLOW_ITEM_TYPE_IB_BTH matches an InfiniBand base transport
header. We extend the match on the acknowledgment bit (BTH_A).
Signed-off-by: Itamar Gozlan
---
drivers/net/mlx5/hws/mlx5dr_definer.c | 12 ++--
drivers/net/mlx5/hws/mlx5dr_definer.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index 33d0f2d18e..b82af9d102 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -177,7 +177,8 @@ struct mlx5dr_definer_conv_data {
X(SET_BE32, ipsec_spi, v->hdr.spi,
rte_flow_item_esp) \
X(SET_BE32, ipsec_sequence_number, v->hdr.seq,
rte_flow_item_esp) \
X(SET, ib_l4_udp_port, UDP_ROCEV2_PORT,
rte_flow_item_ib_bth) \
- X(SET, ib_l4_opcode, v->hdr.opcode,
rte_flow_item_ib_bth)
+ X(SET, ib_l4_opcode, v->hdr.opcode,
rte_flow_item_ib_bth) \
+ X(SET, ib_l4_bth_a,v->hdr.a,
rte_flow_item_ib_bth) \
/* Item set function format */
#define X(set_type, func_name, value, item_type) \
@@ -2148,7 +2149,7 @@ mlx5dr_definer_conv_item_ib_l4(struct
mlx5dr_definer_conv_data *cd,
if (m->hdr.se || m->hdr.m || m->hdr.padcnt || m->hdr.tver ||
m->hdr.pkey || m->hdr.f || m->hdr.b || m->hdr.rsvd0 ||
- m->hdr.a || m->hdr.rsvd1 || !is_mem_zero(m->hdr.psn, 3)) {
+ m->hdr.rsvd1 || !is_mem_zero(m->hdr.psn, 3)) {
rte_errno = ENOTSUP;
return rte_errno;
}
@@ -2167,6 +2168,13 @@ mlx5dr_definer_conv_item_ib_l4(struct
mlx5dr_definer_conv_data *cd,
DR_CALC_SET_HDR(fc, ib_l4, qp);
}
+ if (m->hdr.a) {
+ fc = &cd->fc[MLX5DR_DEFINER_FNAME_IB_L4_A];
+ fc->item_idx = item_idx;
+ fc->tag_set = &mlx5dr_definer_ib_l4_bth_a_set;
+ DR_CALC_SET_HDR(fc, ib_l4, ackreq);
+ }
+
return 0;
}
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.h
b/drivers/net/mlx5/hws/mlx5dr_definer.h
index 6b645f4cf0..bf026fa6bb 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.h
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.h
@@ -136,6 +136,7 @@ enum mlx5dr_definer_fname {
MLX5DR_DEFINER_FNAME_OKS2_MPLS4_I,
MLX5DR_DEFINER_FNAME_IB_L4_OPCODE,
MLX5DR_DEFINER_FNAME_IB_L4_QPN,
+ MLX5DR_DEFINER_FNAME_IB_L4_A,
MLX5DR_DEFINER_FNAME_MAX,
};
--
2.38.1
[PATCH 5/5] net/mlx5/hws: fix field copy bind
From: Alex Vesker
Fix an issue with binding for unused DW selectors,
these selectors are set to zero but zero is also
a valid value used for DMAC_47_16.
Fixes: c55c2bf35333 ("net/mlx5/hws: add definer layer")
Reviewed-by: Erez Shitrit
Signed-off-by: Alex Vesker
---
drivers/net/mlx5/hws/mlx5dr_definer.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index 2f6f91892b..70e46736ec 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -2375,11 +2375,15 @@ mlx5dr_definer_find_byte_in_tag(struct mlx5dr_definer
*definer,
uint32_t *tag_byte_off)
{
uint8_t byte_offset;
- int i;
+ int i, dw_to_scan;
+
+ /* Avoid accessing unused DW selectors */
+ dw_to_scan = mlx5dr_definer_is_jumbo(definer) ?
+ DW_SELECTORS : DW_SELECTORS_MATCH;
/* Add offset since each DW covers multiple BYTEs */
byte_offset = hl_byte_off % DW_SIZE;
- for (i = 0; i < DW_SELECTORS; i++) {
+ for (i = 0; i < dw_to_scan; i++) {
if (definer->dw_selector[i] == hl_byte_off / DW_SIZE) {
*tag_byte_off = byte_offset + DW_SIZE * (DW_SELECTORS -
i - 1);
return 0;
--
2.38.1
[PATCH 4/5] net/mlx5/hws: supporting default miss table in HWS
A default miss table is a way to define what happens to traffic that does
not match any rule in a specific table. In hws, this is done by connecting
the source table to the target table using the RTC.
This ensures that traffic that does not match any rule in the source table
is forwarded to the target table.
Issue: 3441251
Signed-off-by: Itamar Gozlan
---
drivers/common/mlx5/mlx5_prm.h| 5 +-
drivers/net/mlx5/hws/mlx5dr.h | 12 ++
drivers/net/mlx5/hws/mlx5dr_cmd.c | 7 +-
drivers/net/mlx5/hws/mlx5dr_cmd.h | 1 +
drivers/net/mlx5/hws/mlx5dr_debug.c | 5 +-
drivers/net/mlx5/hws/mlx5dr_matcher.c | 176 -
drivers/net/mlx5/hws/mlx5dr_matcher.h | 5 +
drivers/net/mlx5/hws/mlx5dr_table.c | 218 +-
drivers/net/mlx5/hws/mlx5dr_table.h | 23 +++
9 files changed, 366 insertions(+), 86 deletions(-)
diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index 6df7ca20af..d46d4094b1 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -2085,7 +2085,10 @@ struct mlx5_ifc_flow_table_prop_layout_bits {
u8 reparse[0x1];
u8 reserved_at_6b[0x1];
u8 cross_vhca_object[0x1];
- u8 reserved_at_6d[0xb];
+ u8 reformat_l2_to_l3_audp_tunnel[0x1];
+ u8 reformat_l3_audp_tunnel_to_l2[0x1];
+ u8 ignore_flow_level_rtc_valid[0x1];
+ u8 reserved_at_70[0x8];
u8 log_max_ft_num[0x8];
u8 reserved_at_80[0x10];
u8 log_max_flow_counter[0x8];
diff --git a/drivers/net/mlx5/hws/mlx5dr.h b/drivers/net/mlx5/hws/mlx5dr.h
index ec2230d136..54aa9fd6dd 100644
--- a/drivers/net/mlx5/hws/mlx5dr.h
+++ b/drivers/net/mlx5/hws/mlx5dr.h
@@ -237,6 +237,18 @@ mlx5dr_table_create(struct mlx5dr_context *ctx,
*/
int mlx5dr_table_destroy(struct mlx5dr_table *tbl);
+/* Set default miss table for mlx5dr_table by using another mlx5dr_table
+ * Traffic which all table matchers miss will be forwarded to miss table.
+ *
+ * @param[in] tbl
+ * source mlx5dr table
+ * @param[in] miss_tbl
+ * target (miss) mlx5dr table, or NULL to remove current miss table
+ * @return zero on success non zero otherwise.
+ */
+int mlx5dr_table_set_default_miss(struct mlx5dr_table *tbl,
+ struct mlx5dr_table *miss_tbl);
+
/* Create new match template based on items mask, the match template
* will be used for matcher creation.
*
diff --git a/drivers/net/mlx5/hws/mlx5dr_cmd.c
b/drivers/net/mlx5/hws/mlx5dr_cmd.c
index 98d4b3bd3b..63b47f4617 100644
--- a/drivers/net/mlx5/hws/mlx5dr_cmd.c
+++ b/drivers/net/mlx5/hws/mlx5dr_cmd.c
@@ -581,7 +581,6 @@ mlx5dr_cmd_header_modify_pattern_create(struct ibv_context
*ctx,
rte_errno = ENOMEM;
return NULL;
}
-
attr = MLX5_ADDR_OF(create_header_modify_pattern_in, in, hdr);
MLX5_SET(general_obj_in_cmd_hdr,
attr, opcode, MLX5_CMD_OP_CREATE_GENERAL_OBJECT);
@@ -1032,6 +1031,12 @@ int mlx5dr_cmd_query_caps(struct ibv_context *ctx,
capability.flow_table_nic_cap.
flow_table_properties_nic_receive.reparse);
+ caps->nic_ft.ignore_flow_level_rtc_valid =
+ MLX5_GET(query_hca_cap_out,
+out,
+capability.flow_table_nic_cap.
+
flow_table_properties_nic_receive.ignore_flow_level_rtc_valid);
+
/* check cross-VHCA support in flow table properties */
res =
MLX5_GET(query_hca_cap_out, out,
diff --git a/drivers/net/mlx5/hws/mlx5dr_cmd.h
b/drivers/net/mlx5/hws/mlx5dr_cmd.h
index e57013c309..8a495db9b3 100644
--- a/drivers/net/mlx5/hws/mlx5dr_cmd.h
+++ b/drivers/net/mlx5/hws/mlx5dr_cmd.h
@@ -158,6 +158,7 @@ struct mlx5dr_cmd_allow_other_vhca_access_attr {
struct mlx5dr_cmd_query_ft_caps {
uint8_t max_level;
uint8_t reparse;
+ uint8_t ignore_flow_level_rtc_valid;
};
struct mlx5dr_cmd_query_vport_caps {
diff --git a/drivers/net/mlx5/hws/mlx5dr_debug.c
b/drivers/net/mlx5/hws/mlx5dr_debug.c
index 48810142a0..89529944a3 100644
--- a/drivers/net/mlx5/hws/mlx5dr_debug.c
+++ b/drivers/net/mlx5/hws/mlx5dr_debug.c
@@ -331,11 +331,12 @@ static int mlx5dr_debug_dump_table(FILE *f, struct
mlx5dr_table *tbl)
}
}
- ret = fprintf(f, ",0x%" PRIx64 ",0x%" PRIx64 ",0x%" PRIx64 ",0x%"
PRIx64 "\n",
+ ret = fprintf(f, ",0x%" PRIx64 ",0x%" PRIx64 ",0x%" PRIx64 ",0x%"
PRIx64 ",0x%" PRIx64 "\n",
mlx5dr_debug_icm_to_idx(icm_addr_0),
mlx5dr_debug_icm_to_idx(icm_addr_1),
mlx5dr_debug_icm_to_idx(local_icm_addr_0),
- mlx5dr_debug_icm_to_idx(local_icm_addr_1));
+ mlx5dr_debug_icm_to_idx(local_icm_addr_1),
+ (uint64_t)(uintptr_t)tbl->default_miss.miss_tbl);
if (ret < 0)
RE: [PATCH v1] net/mlx5: add test for hot upgrade
Hi Thomas: BR Rongwei > -Original Message- > From: Thomas Monjalon > Sent: Tuesday, June 27, 2023 04:23 > To: Rongwei Liu ; Raslan Darawsheh > > Cc: dev@dpdk.org; Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; Maayan Kashani > > Subject: Re: [PATCH v1] net/mlx5: add test for hot upgrade > > External email: Use caution opening links or attachments > > > 16/05/2023 07:41, Rongwei Liu: > > This patch adds testpmd app a runtime function to test the hot upgrade > > API. > > > > testpmd> mlx5 set flow_engine <0|1> (flag) > > 0 stands for active mode while 1 for standby mode. > > > > Signed-off-by: Rongwei Liu > > Acked-by: Viacheslav Ovsiienko > > --- > > --- a/doc/guides/nics/mlx5.rst > > +++ b/doc/guides/nics/mlx5.rst > > @@ -2057,3 +2057,13 @@ where: > > * ``sw_queue_id``: queue index in range [64536, 65535]. > >This range is the highest 1000 numbers. > > * ``hw_queue_id``: queue index given by HW in queue creation. > > + > > +Set Flow Engine Mode > > + > > The title is made as a sub-section of "port map external Rx queue", which > looks wrong. > Will change the "" to "", totally in parallel with " port map external Rx queue " > > + > > +Set the flow engine to active(0) or standby(1) mode with specific flags:: > > + testpmd> mlx5 set flow_engine <0|1> (flags) > > It should be said it is for testing live migration. > Sure. > Also the flags are not described. Should we pass an integer? > There is information to describe mode, like active(0)/standby(1). Or we can change to this style: "mlx5 set flow_engine []" > > + > > +This command works for software steering only. > > +Default FDB jump should be disabled if switchdev is enabled. > > +The mode will propagate to all the probed ports. > > For the reasons above, I prefer not pulling this patch in the main branch. > This command line is a good starting point to play with mlx5 live migration feature. Keeping it is user-friendly per my view.
Re: [PATCH v3 19/27] net/nfp: refact the nsp module
On 9/15/2023 10:15 AM, Chaoyong He wrote:
> Move the definition of data structure into the implement file.
> Also sync the logic from kernel driver and remove the unneeded header
> file include statements.
>
> Signed-off-by: Chaoyong He
> Reviewed-by: Niklas Söderlund
<...>
> @@ -381,6 +478,43 @@ nfp_nsp_command_buf(struct nfp_nsp *nsp,
> return ret;
> }
>
> +#define SZ_1M 0x0010
> +#define SZ_4K 0x1000
> +
> +static int
> +nfp_nsp_command_buf(struct nfp_nsp *nsp,
> + struct nfp_nsp_command_buf_arg *arg)
> +{
> + int err;
> + uint64_t reg;
> + uint32_t size;
> + uint32_t max_size;
>
One of the previous patches, patch 3/27, updates variable type
'unsigned int max_size;' -> 'size_t max_size;'
Now it is updated again to 'uint32_t max_size;', I assume by mistake
that previous patch updated by this one didn't.
If it is by mistake can you please check all patches that moves code, if
they are aligned with previous cleanups.
Or if this is intentional, can you please update the first patch to set
the variable correct at first place?
[PATCH v1 1/2] dmadev: add DMA operation structure
For the event based DMA transfer, all the required parameters are to
be sent as part of a structure. This patch adds a structure
containing the parameters for event based DMA operation.
Signed-off-by: Amit Prakash Shukla
---
lib/dmadev/rte_dmadev.h | 12
1 file changed, 12 insertions(+)
diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
index b157ab7600..bf8db2d28d 100644
--- a/lib/dmadev/rte_dmadev.h
+++ b/lib/dmadev/rte_dmadev.h
@@ -794,6 +794,18 @@ struct rte_dma_sge {
uint32_t length; /**< The DMA operation length. */
};
+/**
+ * A structure used to hold event based DMA operation request entry.
+ */
+struct rte_dma_op {
+ struct rte_dma_sge *src_seg; /**< Source segments. */
+ struct rte_dma_sge *dst_seg; /**< Destination segments. */
+ uint16_t nb_src; /**< Number of source segments. */
+ uint16_t nb_dst; /**< Number of destination segments.
*/
+ uint64_t flags; /**< Flags related to the operation.
*/
+ struct rte_mempool *op_mp;/**< Mempool from which op is
allocated. */
+};
+
#include "rte_dmadev_core.h"
/**@{@name DMA operation flag
--
2.25.1
[PATCH v1 2/2] dmadev: get DMA device using device ID
Added a function that lookup for the dma device using device id and
returns the pointer to the same.
Signed-off-by: Amit Prakash Shukla
---
lib/dmadev/rte_dmadev.c | 9 +
lib/dmadev/rte_dmadev_pmd.h | 16
lib/dmadev/version.map | 1 +
3 files changed, 26 insertions(+)
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index bf7d5ec519..f1783c971b 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -121,6 +121,15 @@ dma_find_by_name(const char *name)
return NULL;
}
+struct rte_dma_dev*
+rte_dma_pmd_dev_get(uint8_t dev_id)
+{
+ if (rte_dma_devices == NULL)
+ return NULL;
+
+ return &rte_dma_devices[dev_id];
+}
+
static void dma_fp_object_dummy(struct rte_dma_fp_object *obj);
static int
diff --git a/lib/dmadev/rte_dmadev_pmd.h b/lib/dmadev/rte_dmadev_pmd.h
index c61cedfb23..f8dd970b88 100644
--- a/lib/dmadev/rte_dmadev_pmd.h
+++ b/lib/dmadev/rte_dmadev_pmd.h
@@ -167,6 +167,22 @@ struct rte_dma_dev *rte_dma_pmd_allocate(const char *name,
int numa_node,
__rte_internal
int rte_dma_pmd_release(const char *name);
+/**
+ * @internal
+ *
+ * Get the rte_dma_dev structure device pointer for the device. Assumes a
+ * valid device index.
+ *
+ * @param dev_id
+ * Device ID value to select the device structure.
+ *
+ * @return
+ * - rte_dma_dev structure pointer for the given device ID on success, NULL
+ * otherwise
+ */
+__rte_internal
+struct rte_dma_dev *rte_dma_pmd_dev_get(uint8_t dev_id);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/dmadev/version.map b/lib/dmadev/version.map
index 7031d6b335..cdad39044d 100644
--- a/lib/dmadev/version.map
+++ b/lib/dmadev/version.map
@@ -26,6 +26,7 @@ INTERNAL {
rte_dma_fp_objs;
rte_dma_pmd_allocate;
rte_dma_pmd_release;
+ rte_dma_pmd_dev_get;
local: *;
};
--
2.25.1
Re: [PATCH v3 19/27] net/nfp: refact the nsp module
On 9/18/2023 1:31 PM, Ferruh Yigit wrote:
> On 9/15/2023 10:15 AM, Chaoyong He wrote:
>> Move the definition of data structure into the implement file.
>> Also sync the logic from kernel driver and remove the unneeded header
>> file include statements.
>>
>> Signed-off-by: Chaoyong He
>> Reviewed-by: Niklas Söderlund
>
> <...>
>
>> @@ -381,6 +478,43 @@ nfp_nsp_command_buf(struct nfp_nsp *nsp,
>> return ret;
>> }
>>
>> +#define SZ_1M 0x0010
>> +#define SZ_4K 0x1000
>> +
>> +static int
>> +nfp_nsp_command_buf(struct nfp_nsp *nsp,
>> +struct nfp_nsp_command_buf_arg *arg)
>> +{
>> +int err;
>> +uint64_t reg;
>> +uint32_t size;
>> +uint32_t max_size;
>>
>
> One of the previous patches, patch 3/27, updates variable type
> 'unsigned int max_size;' -> 'size_t max_size;'
>
> Now it is updated again to 'uint32_t max_size;', I assume by mistake
> that previous patch updated by this one didn't.
>
> If it is by mistake can you please check all patches that moves code, if
> they are aligned with previous cleanups.
> Or if this is intentional, can you please update the first patch to set
> the variable correct at first place?
>
This comment is for v4, I replied to wrong version.
Re:Re: [PATCH v1] examples/l3fwd: relax the RSS/Offload requirement
Hi Konstantin:
Please see my comments inline.
Thanks.
Trevor
At 2023-09-18 02:04:19, "Konstantin Ananyev"
wrote:
>03/09/2023 05:01, Trevor Tao пишет:
>> Now the port Rx mq_mode had been set to RTE_ETH_MQ_RX_RSS, and offload
>> mode set to RTE_ETH_RX_OFFLOAD_CHECKSUM by default, but some hardware
>> and/or virtual interface does not support the RSS and offload mode
>> presupposed, e.g., some virtio interfaces in the cloud don't support
>> RSS and may only partly support RTE_ETH_RX_OFFLOAD_UDP_CKSUM/
>> RTE_ETH_RX_OFFLOAD_TCP_CKSUM,
>> but not RTE_ETH_RX_OFFLOAD_IPV4_CKSUM, and the error msg here:
>>
>> virtio_dev_configure(): RSS support requested but not supported by
>> the device
>> Port0 dev_configure = -95
>>
>> and:
>> Ethdev port_id=0 requested Rx offloads 0xe does not match Rx offloads
>> capabilities 0x201d in rte_eth_dev_configure()
>>
>> So to enable the l3fwd running in that environment, the Rx mode requirement
>> can be relaxed to reflect the hardware feature reality here, and the l3fwd
>> can run smoothly then.
>> A warning msg would be provided to user in case it happens here.
>>
>> On the other side, enabling the software cksum check in case the
>> hw support missing.
>>
>> Fixes: af75078fece3 ("first public release")
>> Cc: sta...@dpdk.org
>
>I don't think there was abug here.
>We are talking about changing current requirements for the app.
>So not sure it is a real fix and that such change can be
>propagated to stable releases.
Trevor: I think it's not a bug fix but a feature enhancement, it would enable
l3fwd to work smoothly on the HW/virtual interfaces which don't support RSS
and/or cksum offloading.
>
>>
>> Signed-off-by: Trevor Tao
>> ---
>> examples/l3fwd/l3fwd.h | 12 +++-
>> examples/l3fwd/main.c | 21 +++--
>> 2 files changed, 30 insertions(+), 3 deletions(-)
>>
>> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
>> index b55855c932..cc10643c4b 100644
>> --- a/examples/l3fwd/l3fwd.h
>> +++ b/examples/l3fwd/l3fwd.h
>> @@ -115,6 +115,8 @@ extern struct acl_algorithms acl_alg[];
>>
>> extern uint32_t max_pkt_len;
>>
>> +extern struct rte_eth_conf port_conf;
>> +
>> /* Send burst of packets on an output interface */
>> static inline int
>> send_burst(struct lcore_conf *qconf, uint16_t n, uint16_t port)
>> @@ -170,7 +172,15 @@ is_valid_ipv4_pkt(struct rte_ipv4_hdr *pkt, uint32_t
>> link_len)
>> return -1;
>>
>> /* 2. The IP checksum must be correct. */
>> -/* this is checked in H/W */
>> +/* if this is not checked in H/W, check it. */
>> +if ((port_conf.rxmode.offloads & RTE_ETH_RX_OFFLOAD_IPV4_CKSUM) == 0) {
>
>Might be better to check particular mbuf flag:
>if ((mbuf->ol_flags & RTE_MBUF_F_RX_IP_CKSUM_MASK) ==
>TE_MBUF_F_RX_IP_CKSUM_UNKNOWN) {...}
Trevor: the utility function is_valid_ipv4_pkt is just against an IPv4 pkt, and
there's no mbuf information, and if needed, there would be an extra ol_flags
added here to check if it was already done by the ethernet device, but look for
a sample in:
https://github.com/DPDK/dpdk/blob/main/examples/l3fwd-power/main.c#L487
so I think it's ok to just use the port_conf here. If you still think it's
better to use m->ol_flags, please tell me.
>
>> +uint16_t actual_cksum, expected_cksum;
>> +actual_cksum = pkt->hdr_checksum;
>> +pkt->hdr_checksum = 0;
>> +expected_cksum = rte_ipv4_cksum(pkt);
>> +if (actual_cksum != expected_cksum)
>> +return -2;
>> +}
>>
>> /*
>> * 3. The IP version number must be 4. If the version number is not 4
>> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
>> index 6063eb1399..37aec64718 100644
>> --- a/examples/l3fwd/main.c
>> +++ b/examples/l3fwd/main.c
>> @@ -117,7 +117,7 @@ static struct lcore_params * lcore_params =
>> lcore_params_array_default;
>> static uint16_t nb_lcore_params = sizeof(lcore_params_array_default) /
>> sizeof(lcore_params_array_default[0]);
>>
>> -static struct rte_eth_conf port_conf = {
>> +struct rte_eth_conf port_conf = {
>> .rxmode = {
>> .mq_mode = RTE_ETH_MQ_RX_RSS,
>> .offloads = RTE_ETH_RX_OFFLOAD_CHECKSUM,
>> @@ -1257,8 +1257,12 @@ l3fwd_poll_resource_setup(void)
>> local_port_conf.rx_adv_conf.rss_conf.rss_hf &=
>> dev_info.flow_type_rss_offloads;
>>
>> -if (dev_info.max_rx_queues == 1)
>> +/* relax the rx rss requirement */
>> +if (dev_info.max_rx_queues == 1 ||
>> !local_port_conf.rx_adv_conf.rss_conf.rss_hf) {
>> +printf("warning: modified the rx mq_mode to
>> RTE_ETH_MQ_RX_NONE base on"
>> +" device capability\n");
>> local_port_conf.rxmode.mq_mode = RTE_ETH_MQ_RX_NONE;
>
>Should we probably instead have a new commnad-line option to explicitly
>disable RSS?
Re: [PATCH v4 02/26] net/nfp: unify the indent coding style
Hi Chaoyong,
On 2023-09-18 10:45:48 +0800, Chaoyong He wrote:
> Each parameter of function should occupy one line, and indent two TAB
> character.
> All the statement which span multi line should indent two TAB character.
>
> Signed-off-by: Chaoyong He
> Reviewed-by: Niklas Söderlund
Nacked-by: Niklas Söderlund
I have not reviewed this rebase, I'm sure it's fine, but I have not
reviewed it. Please drop my R-b from any future postings.
> ---
> drivers/net/nfp/nfpcore/nfp_cpp.h | 80 +-
> drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 152 ++
> drivers/net/nfp/nfpcore/nfp_cppcore.c | 173 +
> drivers/net/nfp/nfpcore/nfp_crc.c | 19 ++-
> drivers/net/nfp/nfpcore/nfp_hwinfo.c | 23 +--
> drivers/net/nfp/nfpcore/nfp_mip.c | 21 ++-
> drivers/net/nfp/nfpcore/nfp_mip.h | 2 +-
> drivers/net/nfp/nfpcore/nfp_mutex.c| 25 +--
> drivers/net/nfp/nfpcore/nfp_nffw.c | 12 +-
> drivers/net/nfp/nfpcore/nfp_nsp.c | 108 +++--
> drivers/net/nfp/nfpcore/nfp_nsp.h | 19 +--
> drivers/net/nfp/nfpcore/nfp_nsp_cmds.c | 4 +-
> drivers/net/nfp/nfpcore/nfp_nsp_eth.c | 72 +
> drivers/net/nfp/nfpcore/nfp_resource.c | 29 ++--
> drivers/net/nfp/nfpcore/nfp_resource.h | 2 +-
> drivers/net/nfp/nfpcore/nfp_rtsym.c| 38 +++--
> drivers/net/nfp/nfpcore/nfp_rtsym.h| 15 +-
> 17 files changed, 463 insertions(+), 331 deletions(-)
>
> diff --git a/drivers/net/nfp/nfpcore/nfp_cpp.h
> b/drivers/net/nfp/nfpcore/nfp_cpp.h
> index 8f87c09327..54bef3cb6b 100644
> --- a/drivers/net/nfp/nfpcore/nfp_cpp.h
> +++ b/drivers/net/nfp/nfpcore/nfp_cpp.h
> @@ -56,7 +56,8 @@ struct nfp_cpp_operations {
> size_t area_priv_size;
>
> /* Instance an NFP CPP */
> - int (*init)(struct nfp_cpp *cpp, struct rte_pci_device *dev);
> + int (*init)(struct nfp_cpp *cpp,
> + struct rte_pci_device *dev);
>
> /*
>* Free the bus.
> @@ -69,9 +70,9 @@ struct nfp_cpp_operations {
>* NOTE: This is _not_ serialized
>*/
> int (*area_init)(struct nfp_cpp_area *area,
> - uint32_t dest,
> - unsigned long long address,
> - unsigned long size);
> + uint32_t dest,
> + unsigned long long address,
> + unsigned long size);
> /*
>* Clean up a NFP CPP area before it is freed
>* NOTE: This is _not_ serialized
> @@ -101,17 +102,17 @@ struct nfp_cpp_operations {
>* Serialized
>*/
> int (*area_read)(struct nfp_cpp_area *area,
> - void *kernel_vaddr,
> - unsigned long offset,
> - unsigned int length);
> + void *kernel_vaddr,
> + unsigned long offset,
> + unsigned int length);
> /*
>* Perform a write to a NFP CPP area
>* Serialized
>*/
> int (*area_write)(struct nfp_cpp_area *area,
> - const void *kernel_vaddr,
> - unsigned long offset,
> - unsigned int length);
> + const void *kernel_vaddr,
> + unsigned long offset,
> + unsigned int length);
> };
>
> /*
> @@ -239,7 +240,7 @@ void nfp_cpp_interface_set(struct nfp_cpp *cpp, uint32_t
> interface);
> * @param len Length of the serial byte array
> */
> int nfp_cpp_serial_set(struct nfp_cpp *cpp, const uint8_t *serial,
> -size_t serial_len);
> + size_t serial_len);
>
> /*
> * Set the private data of the nfp_cpp instance
> @@ -279,7 +280,7 @@ uint32_t __nfp_cpp_model_autodetect(struct nfp_cpp *cpp,
> uint32_t *model);
> * @return NFP CPP handle, or NULL on failure.
> */
> struct nfp_cpp *nfp_cpp_from_device_name(struct rte_pci_device *dev,
> - int driver_lock_needed);
> + int driver_lock_needed);
>
> /*
> * Free a NFP CPP handle
> @@ -397,8 +398,7 @@ int nfp_cpp_serial(struct nfp_cpp *cpp, const uint8_t
> **serial);
> * @return NFP CPP handle, or NULL on failure.
> */
> struct nfp_cpp_area *nfp_cpp_area_alloc(struct nfp_cpp *cpp, uint32_t cpp_id,
> - unsigned long long address,
> - unsigned long size);
> + unsigned long long address, unsigned long size);
>
> /*
> * Allocate a NFP CPP area handle, as an offset into a CPP ID, by a named
> owner
> @@ -411,10 +411,8 @@ struct nfp_cpp_area *nfp_cpp_area_alloc(struct nfp_cpp
> *cpp, uint32_t cpp_id,
> * @return NFP CPP handle, or NULL on failure.
> */
> struct nfp_cpp_area *nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp,
> - uint32_
RE: [PATCH 1/3] net/mlx5: extend send to kernel action support
Hi, > -Original Message- > From: Jiawei(Jonny) Wang > Sent: Friday, September 8, 2023 12:21 PM > To: Suanming Mou ; Ori Kam ; > NBU-Contact-Thomas Monjalon (EXTERNAL) > Cc: dev@dpdk.org; Raslan Darawsheh > Subject: [PATCH 1/3] net/mlx5: extend send to kernel action support > > The send to kernel action was supported in NIC and FDB tables, Currently, the > send to kernel action is created in NIC RX only. > > With some TC rules (example: roce packets, redirects into rep ports) and DPDK > RTE rules for the rest of the traffic. Then it needs the specific rule to > re-route > the packets into the kernel through the FDB table. > > This patch adds the FDB and NIC-TX tables support for sending to the kernel > action. > > Signed-off-by: Jiawei Wang Series applied to next-net-mlx, Kindest regards, Raslan Darawsheh
Re: [PATCH v1 1/2] dmadev: add DMA operation structure
On Mon, Sep 18, 2023 at 06:02:26PM +0530, Amit Prakash Shukla wrote:
> For the event based DMA transfer, all the required parameters are to
> be sent as part of a structure. This patch adds a structure
> containing the parameters for event based DMA operation.
>
> Signed-off-by: Amit Prakash Shukla
> ---
> lib/dmadev/rte_dmadev.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
> index b157ab7600..bf8db2d28d 100644
> --- a/lib/dmadev/rte_dmadev.h
> +++ b/lib/dmadev/rte_dmadev.h
> @@ -794,6 +794,18 @@ struct rte_dma_sge {
> uint32_t length; /**< The DMA operation length. */
> };
>
> +/**
> + * A structure used to hold event based DMA operation request entry.
> + */
> +struct rte_dma_op {
Would it be better called rte_dma_event_op, if it's just for use with
eventdev?
> + struct rte_dma_sge *src_seg; /**< Source segments. */
> + struct rte_dma_sge *dst_seg; /**< Destination segments. */
> + uint16_t nb_src; /**< Number of source segments. */
> + uint16_t nb_dst; /**< Number of destination segments.
> */
> + uint64_t flags; /**< Flags related to the operation.
> */
> + struct rte_mempool *op_mp;/**< Mempool from which op is
> allocated. */
> +};
> +
> #include "rte_dmadev_core.h"
>
> /**@{@name DMA operation flag
> --
> 2.25.1
>
[RFC PATCH v2 1/5] buildtools/dpdk-cmdline-gen: generate boilerplate for simple cmds
Provide a script for application developers to quickly generate the
boilerplate code necessary for using the cmdline library.
This initial version works only with commands using simple strings and
numbers, but this is sufficient for many use-cases. Future extensions
could, no doubt, expand support to expose more capabilities of the
library.
Example of use:
The script takes an input file with a list of commands the user wants in
the app, where the parameter variables are tagged with the type.
For example:
$ cat commands.list
list
add x y
echo message
add socket path
quit
When run through the script as "./dpdk-cmdline-gen.py commands.list",
the output will be the contents of a header file with all the
boilerplate necessary for a commandline instance with those commands.
If the flag --stubs is passed, an output header filename must also be
passed, in which case both a header file with the definitions and a C
file with function stubs in it is written to disk. The separation is so
that the header file can be rewritten at any future point to add more
commands, while the C file can be kept as-is and extended by the user
with any additional functions needed.
Signed-off-by: Bruce Richardson
---
buildtools/dpdk-cmdline-gen.py | 146 +
buildtools/meson.build | 7 ++
2 files changed, 153 insertions(+)
create mode 100755 buildtools/dpdk-cmdline-gen.py
diff --git a/buildtools/dpdk-cmdline-gen.py b/buildtools/dpdk-cmdline-gen.py
new file mode 100755
index 00..1ddd8b6bbb
--- /dev/null
+++ b/buildtools/dpdk-cmdline-gen.py
@@ -0,0 +1,146 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2023 Intel Corporation
+#
+
+import sys
+import os
+import argparse
+
+PARSE_FN_PARAMS = "void *parsed_result, struct cmdline *cl, void *data"
+PARSE_FN_BODY = """
+/* TODO: command action */
+RTE_SET_USED(parsed_result);
+RTE_SET_USED(cl);
+RTE_SET_USED(data);
+"""
+
+def process_command(tokens, cfile):
+name = []
+
+if tokens[0].startswith('<'):
+print("Error: each command must start with at least one literal
string",
+file=sys.stderr)
+sys.exit(1)
+for t in tokens:
+if t.startswith('<'):
+break;
+name.append(t)
+name = "_".join(name)
+
+result_struct = []
+initializers = []
+token_list = []
+for t in tokens:
+if t.startswith('<'):
+t_type, t_name = t[1:].split('>')
+t_val = "NULL"
+else:
+t_type = "STRING"
+t_name = t
+t_val = f'"{t}"'
+
+if t_type == "STRING":
+result_struct.append(f"\tcmdline_fixed_string_t {t_name};")
+initializers.append(f"static cmdline_parse_token_string_t
cmd_{name}_{t_name}_tok =\n"
++ f"\tTOKEN_STRING_INITIALIZER(struct cmd_{name}_result,
{t_name}, {t_val});")
+elif t_type in ['UINT8', 'UINT16', 'UINT32', 'UINT64',
+'INT8', 'INT16', 'INT32', 'INT64']:
+result_struct.append(f"\t{t_type.lower()}_t {t_name};")
+initializers.append(f"static cmdline_parse_token_num_t
cmd_{name}_{t_name}_tok =\n"
++ f"\tTOKEN_NUM_INITIALIZER(struct cmd_{name}_result,
{t_name}, RTE_{t_type});")
+else:
+print(f"Error: unknown token-type {t}", file=sys.stderr)
+sys.exit(1)
+token_list.append(f"cmd_{name}_{t_name}_tok")
+
+print(f"/* Auto-generated handling for command '{' '.join(tokens)}' */")
+# output function prototype
+func_sig = f"void\ncmd_{name}_parsed({PARSE_FN_PARAMS})"
+print(f"extern {func_sig};\n")
+# output function template if C file being written
+if (cfile):
+print(f"{func_sig}\n{{{PARSE_FN_BODY}}}\n", file=cfile)
+# output result data structure
+print(f"struct cmd_{name}_result {{\n"
++ '\n'.join(result_struct)
++ "\n};\n")
+# output the initializer tokens
+print("\n".join(initializers) + '\n')
+# output the instance structure
+print(f"static cmdline_parse_inst_t cmd_{name} = {{\n"
++ f'\t.f = cmd_{name}_parsed,\n'
++ f'\t.data = NULL,\n'
++ f'\t.help_str = "",\n'
++ f'\t.tokens = {{')
+for t in token_list:
+print(f"\t\t(void *)&{t},")
+print("\t\tNULL\n"
++ "\t}\n"
++ "};\n")
+
+# return the instance structure name
+return f"cmd_{name}"
+
+def process_commands(infile, hfile, cfile, ctxname):
+instances = []
+
+# redirect stdout to output the header, to save passing file= each print
+old_sys_stdout = sys.stdout
+sys.stdout = hfile
+
+print(f"/* File autogenerated by {sys.argv[0]} */")
+print('#ifndef GENERATED_COMMANDS_H')
+print('#define GENERATED_COMMANDS_H')
+print("#include ")
+print("#include ")
+print("#include ")
+
[RFC PATCH v2 0/5] use script to simplify use of cmdline lib
The DPDK commandline library is widely used by apps and examples within DPDK, but requires a lot of boilerplate code definitions in order to used. We can improve this situation by creating a simple python script to automatically generate the boilerplate from a list of commands. This RFC v2 contains the (slightly enhanced from v1) script, as well as a set of three patches showing its use, by converting three examples to use the script instead of having the hard-coded boilerplate. Once the script is used, adding a new command becomes as simple as adding the desired command to the .list file, and then writing the required function which will be called for that command. No other boilerplate coding is necessary. Script obviously does not cover the full range of capabilities of the commandline lib, but does cover the most used parts - with one exception: it does not yet support defining the help text for a command (hence the fact this is another RFC). If there is a general acceptance that this is worthwhile, that gap can be closed, making the shortened boiler-plate-free examples fully equivalent to the original code. V2-RFC: * Add support for IP addresses in commands * Move to buildtools directory and make installable * Convert 3 examples to use script, and eliminate their boilerplate Bruce Richardson (5): buildtools/dpdk-cmdline-gen: generate boilerplate for simple cmds examples/simple_mp: convert to use cmdline script examples/hotplug_mp: auto-generate cmdline boilerplate buildtools/dpdk-cmdline-gen: add IP address support examples/bond: auto-generate cmdline boilerplate buildtools/dpdk-cmdline-gen.py| 151 buildtools/meson.build| 7 + examples/bond/Makefile| 10 +- examples/bond/commands.list | 6 + examples/bond/main.c | 161 ++ examples/bond/main.h | 10 -- examples/bond/meson.build | 8 + examples/multi_process/hotplug_mp/Makefile| 10 +- examples/multi_process/hotplug_mp/commands.c | 147 ++-- examples/multi_process/hotplug_mp/commands.h | 10 -- .../multi_process/hotplug_mp/commands.list| 5 + examples/multi_process/hotplug_mp/meson.build | 9 + examples/multi_process/simple_mp/Makefile | 10 +- examples/multi_process/simple_mp/meson.build | 9 + .../multi_process/simple_mp/mp_commands.c | 106 ++-- .../multi_process/simple_mp/mp_commands.h | 14 -- .../multi_process/simple_mp/mp_commands.list | 3 + 17 files changed, 257 insertions(+), 419 deletions(-) create mode 100755 buildtools/dpdk-cmdline-gen.py create mode 100644 examples/bond/commands.list delete mode 100644 examples/bond/main.h delete mode 100644 examples/multi_process/hotplug_mp/commands.h create mode 100644 examples/multi_process/hotplug_mp/commands.list delete mode 100644 examples/multi_process/simple_mp/mp_commands.h create mode 100644 examples/multi_process/simple_mp/mp_commands.list -- 2.39.2
[RFC PATCH v2 2/5] examples/simple_mp: auto-generate cmdline boilerplate
Use the dpdk-cmdline-gen script to autogenerate all the boilerplate
structs and defines for the commandline part of the app.
Signed-off-by: Bruce Richardson
---
examples/multi_process/simple_mp/Makefile | 10 +-
examples/multi_process/simple_mp/meson.build | 9 ++
.../multi_process/simple_mp/mp_commands.c | 106 ++
.../multi_process/simple_mp/mp_commands.h | 14 ---
.../multi_process/simple_mp/mp_commands.list | 3 +
5 files changed, 29 insertions(+), 113 deletions(-)
delete mode 100644 examples/multi_process/simple_mp/mp_commands.h
create mode 100644 examples/multi_process/simple_mp/mp_commands.list
diff --git a/examples/multi_process/simple_mp/Makefile
b/examples/multi_process/simple_mp/Makefile
index 1d0a260e64..b460f53ece 100644
--- a/examples/multi_process/simple_mp/Makefile
+++ b/examples/multi_process/simple_mp/Makefile
@@ -6,6 +6,7 @@ APP = simple_mp
# all source are stored in SRCS-y
SRCS-y := main.c mp_commands.c
+SRC-DEPS := build/mp_commands.h
PKGCONF ?= pkg-config
@@ -22,10 +23,13 @@ static: build/$(APP)-static
ln -sf $(APP)-static build/$(APP)
PC_FILE := $(shell $(PKGCONF) --path libdpdk 2>/dev/null)
-CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk)
+CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk) -I build/
LDFLAGS_SHARED = $(shell $(PKGCONF) --libs libdpdk)
LDFLAGS_STATIC = $(shell $(PKGCONF) --static --libs libdpdk)
+build/mp_commands.h: mp_commands.list Makefile
+ dpdk-cmdline-gen.py -o $@ --context-name=simple_mp_ctx $<
+
ifeq ($(MAKECMDGOALS),static)
# check for broken pkg-config
ifeq ($(shell echo $(LDFLAGS_STATIC) | grep
'whole-archive.*l:lib.*no-whole-archive'),)
@@ -36,10 +40,10 @@ endif
CFLAGS += -DALLOW_EXPERIMENTAL_API
-build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
+build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build $(SRC-DEPS)
$(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED)
-build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
+build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build $(SRC-DEPS)
$(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC)
build:
diff --git a/examples/multi_process/simple_mp/meson.build
b/examples/multi_process/simple_mp/meson.build
index 359af4384d..e99b7a3f6f 100644
--- a/examples/multi_process/simple_mp/meson.build
+++ b/examples/multi_process/simple_mp/meson.build
@@ -7,7 +7,16 @@
# DPDK instance, use 'make'
allow_experimental_apis = true
+
+cmd_h = custom_target('commands_hdr',
+ output: 'mp_commands.h',
+ input: files('mp_commands.list'),
+ capture: true,
+ command: [cmdline_gen_cmd, '--context-name=simple_mp_ctx', '@INPUT@']
+)
+
sources = files(
'mp_commands.c',
'main.c',
)
+sources += cmd_h
diff --git a/examples/multi_process/simple_mp/mp_commands.c
b/examples/multi_process/simple_mp/mp_commands.c
index a5f91b00be..df9fa94208 100644
--- a/examples/multi_process/simple_mp/mp_commands.c
+++ b/examples/multi_process/simple_mp/mp_commands.c
@@ -1,44 +1,18 @@
/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2010-2014 Intel Corporation
+ * Copyright(c) 2010-2023 Intel Corporation
*/
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
#include
#include
-#include
-#include
-#include
-#include
-#include
#include "mp_commands.h"
-/**/
-
-struct cmd_send_result {
- cmdline_fixed_string_t action;
- cmdline_fixed_string_t message;
-};
+extern struct rte_ring *send_ring, *recv_ring;
+extern struct rte_mempool *message_pool;
+extern volatile int quit;
-static void cmd_send_parsed(void *parsed_result,
+void
+cmd_send_parsed(void *parsed_result,
__rte_unused struct cmdline *cl,
__rte_unused void *data)
{
@@ -54,29 +28,8 @@ static void cmd_send_parsed(void *parsed_result,
}
}
-cmdline_parse_token_string_t cmd_send_action =
- TOKEN_STRING_INITIALIZER(struct cmd_send_result, action, "send");
-cmdline_parse_token_string_t cmd_send_message =
- TOKEN_STRING_INITIALIZER(struct cmd_send_result, message, NULL);
-
-cmdline_parse_inst_t cmd_send = {
- .f = cmd_send_parsed, /* function to call */
- .data = NULL, /* 2nd arg of func */
- .help_str = "send a string to another process",
- .tokens = {/* token list, NULL terminated */
- (void *)&cmd_send_action,
- (void *)&cmd_send_message,
- NULL,
- },
-};
-
-/**/
-
-struct cmd_quit_result {
- cmdline_fixed_string_t quit;
-};
-
-static void cmd_quit_parsed(__rte_unused void *parsed_result,
+void
+cmd_quit_parsed(__rte_unused void *parsed_result,
[RFC PATCH v2 3/5] examples/hotplug_mp: auto-generate cmdline boilerplate
Use the dpdk-cmdline-gen script to autogenerate all the boilerplate
structs and defines for the commandline part of the app.
Signed-off-by: Bruce Richardson
---
examples/multi_process/hotplug_mp/Makefile| 10 +-
examples/multi_process/hotplug_mp/commands.c | 147 ++
examples/multi_process/hotplug_mp/commands.h | 10 --
.../multi_process/hotplug_mp/commands.list| 5 +
examples/multi_process/hotplug_mp/meson.build | 9 ++
5 files changed, 34 insertions(+), 147 deletions(-)
delete mode 100644 examples/multi_process/hotplug_mp/commands.h
create mode 100644 examples/multi_process/hotplug_mp/commands.list
diff --git a/examples/multi_process/hotplug_mp/Makefile
b/examples/multi_process/hotplug_mp/Makefile
index 6b20d6e49a..77e8fe2737 100644
--- a/examples/multi_process/hotplug_mp/Makefile
+++ b/examples/multi_process/hotplug_mp/Makefile
@@ -6,6 +6,7 @@ APP = hotplug_mp
# all source are stored in SRCS-y
SRCS-y := main.c commands.c
+SRC-DEPS := build/commands.h
PKGCONF ?= pkg-config
@@ -22,10 +23,13 @@ static: build/$(APP)-static
ln -sf $(APP)-static build/$(APP)
PC_FILE := $(shell $(PKGCONF) --path libdpdk 2>/dev/null)
-CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk)
+CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk) -I build/
LDFLAGS_SHARED = $(shell $(PKGCONF) --libs libdpdk)
LDFLAGS_STATIC = $(shell $(PKGCONF) --static --libs libdpdk)
+build/commands.h: commands.list Makefile
+ dpdk-cmdline-gen.py -o $@ --context-name=main_ctx $<
+
ifeq ($(MAKECMDGOALS),static)
# check for broken pkg-config
ifeq ($(shell echo $(LDFLAGS_STATIC) | grep
'whole-archive.*l:lib.*no-whole-archive'),)
@@ -36,10 +40,10 @@ endif
CFLAGS += -DALLOW_EXPERIMENTAL_API
-build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
+build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build $(SRC-DEPS)
$(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED)
-build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
+build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build $(SRC-DEPS)
$(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC)
build:
diff --git a/examples/multi_process/hotplug_mp/commands.c
b/examples/multi_process/hotplug_mp/commands.c
index 88f44e00a0..900eb9f774 100644
--- a/examples/multi_process/hotplug_mp/commands.c
+++ b/examples/multi_process/hotplug_mp/commands.c
@@ -1,24 +1,12 @@
/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2018 Intel Corporation.
+ * Copyright(c) 2018-2023 Intel Corporation.
*/
-#include
-#include
-#include
-#include
-#include
-#include
-
#include
#include
+#include "commands.h"
-/**/
-
-struct cmd_help_result {
- cmdline_fixed_string_t help;
-};
-
-static void cmd_help_parsed(__rte_unused void *parsed_result,
+void cmd_help_parsed(__rte_unused void *parsed_result,
struct cmdline *cl,
__rte_unused void *data)
{
@@ -29,52 +17,16 @@ static void cmd_help_parsed(__rte_unused void
*parsed_result,
"- list\n\n");
}
-cmdline_parse_token_string_t cmd_help_help =
- TOKEN_STRING_INITIALIZER(struct cmd_help_result, help, "help");
-
-cmdline_parse_inst_t cmd_help = {
- .f = cmd_help_parsed, /* function to call */
- .data = NULL, /* 2nd arg of func */
- .help_str = "show help",
- .tokens = {/* token list, NULL terminated */
- (void *)&cmd_help_help,
- NULL,
- },
-};
-
-/**/
-
-struct cmd_quit_result {
- cmdline_fixed_string_t quit;
-};
-
-static void cmd_quit_parsed(__rte_unused void *parsed_result,
+void
+cmd_quit_parsed(__rte_unused void *parsed_result,
struct cmdline *cl,
__rte_unused void *data)
{
cmdline_quit(cl);
}
-cmdline_parse_token_string_t cmd_quit_quit =
- TOKEN_STRING_INITIALIZER(struct cmd_quit_result, quit, "quit");
-
-cmdline_parse_inst_t cmd_quit = {
- .f = cmd_quit_parsed, /* function to call */
- .data = NULL, /* 2nd arg of func */
- .help_str = "quit",
- .tokens = {/* token list, NULL terminated */
- (void *)&cmd_quit_quit,
- NULL,
- },
-};
-
-/**/
-
-struct cmd_list_result {
- cmdline_fixed_string_t list;
-};
-
-static void cmd_list_parsed(__rte_unused void *parsed_result,
+void
+cmd_list_parsed(__rte_unused void *parsed_result,
struct cmdline *cl,
__rte_unused void *data)
{
@@ -92,31 +44,12 @@ static void cmd_list_parsed(__rte_unused void
*parsed_result,
}
}
-cmdline_parse_token_string_t cmd_list_list =
- TOKEN_STRING_INITIALIZER(struct cmd_list_result, list, "list");
-
-cmdline_parse_inst_t cmd_l
[RFC PATCH v2 4/5] buildtools/dpdk-cmdline-gen: add IP address support
Add support for apps to have IP addresses as command parameters
Signed-off-by: Bruce Richardson
---
buildtools/dpdk-cmdline-gen.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/buildtools/dpdk-cmdline-gen.py b/buildtools/dpdk-cmdline-gen.py
index 1ddd8b6bbb..c1f8a6f1da 100755
--- a/buildtools/dpdk-cmdline-gen.py
+++ b/buildtools/dpdk-cmdline-gen.py
@@ -49,6 +49,10 @@ def process_command(tokens, cfile):
result_struct.append(f"\t{t_type.lower()}_t {t_name};")
initializers.append(f"static cmdline_parse_token_num_t
cmd_{name}_{t_name}_tok =\n"
+ f"\tTOKEN_NUM_INITIALIZER(struct cmd_{name}_result,
{t_name}, RTE_{t_type});")
+elif t_type in ['IP', 'IP_ADDR', 'IPADDR']:
+result_struct.append(f"\tcmdline_ipaddr_t {t_name};")
+initializers.append(f"cmdline_parse_token_ipaddr_t
cmd_{name}_{t_name}_tok =\n"
++ f"\tTOKEN_IPV4_INITIALIZER(struct cmd_{name}_result,
{t_name});")
else:
print(f"Error: unknown token-type {t}", file=sys.stderr)
sys.exit(1)
@@ -96,6 +100,7 @@ def process_commands(infile, hfile, cfile, ctxname):
print("#include ")
print("#include ")
print("#include ")
+print("#include ")
print("")
for line in infile.readlines():
--
2.39.2
[RFC PATCH v2 5/5] examples/bond: auto-generate cmdline boilerplate
Use the dpdk-cmdline-gen script to autogenerate all the boilerplate
structs and defines for the commandline part of the app.
Signed-off-by: Bruce Richardson
---
examples/bond/Makefile | 10 ++-
examples/bond/commands.list | 6 ++
examples/bond/main.c| 161
examples/bond/main.h| 10 ---
examples/bond/meson.build | 8 ++
5 files changed, 36 insertions(+), 159 deletions(-)
create mode 100644 examples/bond/commands.list
delete mode 100644 examples/bond/main.h
diff --git a/examples/bond/Makefile b/examples/bond/Makefile
index ad711a5bee..0a559ad82b 100644
--- a/examples/bond/Makefile
+++ b/examples/bond/Makefile
@@ -6,6 +6,7 @@ APP = bond_app
# all source are stored in SRCS-y
SRCS-y := main.c
+SRC-DEPS := build/commands.h
PKGCONF ?= pkg-config
@@ -24,10 +25,13 @@ static: build/$(APP)-static
LDFLAGS += -lrte_net_bond
PC_FILE := $(shell $(PKGCONF) --path libdpdk 2>/dev/null)
-CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk)
+CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk) -I build/
LDFLAGS_SHARED = $(shell $(PKGCONF) --libs libdpdk)
LDFLAGS_STATIC = $(shell $(PKGCONF) --static --libs libdpdk)
+build/commands.h: commands.list Makefile
+ dpdk-cmdline-gen.py -o $@ --context-name=main_ctx $<
+
ifeq ($(MAKECMDGOALS),static)
# check for broken pkg-config
ifeq ($(shell echo $(LDFLAGS_STATIC) | grep
'whole-archive.*l:lib.*no-whole-archive'),)
@@ -38,10 +42,10 @@ endif
CFLAGS += -DALLOW_EXPERIMENTAL_API
-build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
+build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build $(SRC-DEPS)
$(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED)
-build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
+build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build $(SRC-DEPS)
$(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC)
build:
diff --git a/examples/bond/commands.list b/examples/bond/commands.list
new file mode 100644
index 00..08e1a3fea8
--- /dev/null
+++ b/examples/bond/commands.list
@@ -0,0 +1,6 @@
+send ip
+start
+stop
+show
+help
+quit
\ No newline at end of file
diff --git a/examples/bond/main.c b/examples/bond/main.c
index 9b076bb39f..e893005701 100644
--- a/examples/bond/main.c
+++ b/examples/bond/main.c
@@ -45,16 +45,8 @@
#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
-
-#include "main.h"
+#include "commands.h"
#define RTE_LOGTYPE_DCB RTE_LOGTYPE_USER1
@@ -462,11 +454,7 @@ static int lcore_main(__rte_unused void *arg1)
return 0;
}
-struct cmd_obj_send_result {
- cmdline_fixed_string_t action;
- cmdline_ipaddr_t ip;
-};
-static inline void get_string(struct cmd_obj_send_result *res, char *buf,
uint8_t size)
+static inline void get_string(struct cmd_send_result *res, char *buf, uint8_t
size)
{
snprintf(buf, size, NIPQUAD_FMT,
((unsigned)((unsigned char *)&(res->ip.addr.ipv4))[0]),
@@ -475,12 +463,11 @@ static inline void get_string(struct cmd_obj_send_result
*res, char *buf, uint8_
((unsigned)((unsigned char *)&(res->ip.addr.ipv4))[3])
);
}
-static void cmd_obj_send_parsed(void *parsed_result,
- __rte_unused struct cmdline *cl,
- __rte_unused void *data)
+void
+cmd_send_parsed(void *parsed_result, __rte_unused struct cmdline *cl,
__rte_unused void *data)
{
- struct cmd_obj_send_result *res = parsed_result;
+ struct cmd_send_result *res = parsed_result;
char ip_str[INET6_ADDRSTRLEN];
struct rte_ether_addr bond_mac_addr;
@@ -544,29 +531,8 @@ static void cmd_obj_send_parsed(void *parsed_result,
cmdline_printf(cl, "\n");
}
-cmdline_parse_token_string_t cmd_obj_action_send =
- TOKEN_STRING_INITIALIZER(struct cmd_obj_send_result, action, "send");
-cmdline_parse_token_ipaddr_t cmd_obj_ip =
- TOKEN_IPV4_INITIALIZER(struct cmd_obj_send_result, ip);
-
-cmdline_parse_inst_t cmd_obj_send = {
- .f = cmd_obj_send_parsed, /* function to call */
- .data = NULL, /* 2nd arg of func */
- .help_str = "send client_ip",
- .tokens = {/* token list, NULL terminated */
- (void *)&cmd_obj_action_send,
- (void *)&cmd_obj_ip,
- NULL,
- },
-};
-
-struct cmd_start_result {
- cmdline_fixed_string_t start;
-};
-
-static void cmd_start_parsed(__rte_unused void *parsed_result,
- struct cmdline *cl,
- __rte_unused void *data)
+void
+cmd_start_parsed(__rte_unused void *parsed_result, struct cmdline *cl,
__rte_unused void *data)
{
int worker_core_id = rte_lcore_id();
@@ -605,26 +571,8 @@ static void cmd_start_parsed(__rte_unused void
*parsed_result,
);
}
-cmdline_parse_token_string_t cmd_start_start =
- TOKEN_STRING_INIT
Re: [PATCH v1 2/2] dmadev: get DMA device using device ID
On Mon, Sep 18, 2023 at 6:02 PM Amit Prakash Shukla
wrote:
> dmadev: get DMA device using device ID
dmadev: add PMD API to get DMA device using device ID
or so
>
> Added a function that lookup for the dma device using device id and
internal function that
> returns the pointer to the same.
>
> Signed-off-by: Amit Prakash Shukla
> #endif
> diff --git a/lib/dmadev/version.map b/lib/dmadev/version.map
> index 7031d6b335..cdad39044d 100644
> --- a/lib/dmadev/version.map
> +++ b/lib/dmadev/version.map
> @@ -26,6 +26,7 @@ INTERNAL {
> rte_dma_fp_objs;
> rte_dma_pmd_allocate;
> rte_dma_pmd_release;
> + rte_dma_pmd_dev_get;
Move after rte_dma_pmd_allocate() to sort in alphabetical order.
>
> local: *;
> };
> --
> 2.25.1
>
RE: [EXT] Re: [PATCH v1 1/2] dmadev: add DMA operation structure
Hi Bruce,
Thanks for the review. Please see my reply in-line.
> -Original Message-
> From: Bruce Richardson
> Sent: Monday, September 18, 2023 6:30 PM
> To: Amit Prakash Shukla
> Cc: Chengwen Feng ; Kevin Laatz
> ; dev@dpdk.org; Jerin Jacob Kollanukkaran
> ; m...@smartsharesystems.com;
> conor.wa...@intel.com; Vamsi Krishna Attunuru ;
> g.si...@nxp.com; sachin.sax...@oss.nxp.com; hemant.agra...@nxp.com;
> cheng1.ji...@intel.com; Nithin Kumar Dabilpuram
> ; Anoob Joseph
> Subject: [EXT] Re: [PATCH v1 1/2] dmadev: add DMA operation structure
>
> External Email
>
> --
> On Mon, Sep 18, 2023 at 06:02:26PM +0530, Amit Prakash Shukla wrote:
> > For the event based DMA transfer, all the required parameters are to
> > be sent as part of a structure. This patch adds a structure containing
> > the parameters for event based DMA operation.
> >
> > Signed-off-by: Amit Prakash Shukla
> > ---
> > lib/dmadev/rte_dmadev.h | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h index
> > b157ab7600..bf8db2d28d 100644
> > --- a/lib/dmadev/rte_dmadev.h
> > +++ b/lib/dmadev/rte_dmadev.h
> > @@ -794,6 +794,18 @@ struct rte_dma_sge {
> > uint32_t length; /**< The DMA operation length. */ };
> >
> > +/**
> > + * A structure used to hold event based DMA operation request entry.
> > + */
> > +struct rte_dma_op {
>
> Would it be better called rte_dma_event_op, if it's just for use with
> eventdev?
Yeah, this is used only for the eventdev. I will rename it to
rte_event_dma_adapter_op and move this structure to rte_event_dma_adapter
header file as part of dma adapter eventdev series.
I will send v2 for this series. Thanks!
>
> > + struct rte_dma_sge *src_seg; /**< Source segments. */
> > + struct rte_dma_sge *dst_seg; /**< Destination segments. */
> > + uint16_t nb_src; /**< Number of source segments. */
> > + uint16_t nb_dst; /**< Number of destination segments.
> > */
> > + uint64_t flags; /**< Flags related to the operation.
> > */
> > + struct rte_mempool *op_mp;/**< Mempool from which op is
> allocated. */
> > +};
> > +
> > #include "rte_dmadev_core.h"
> >
> > /**@{@name DMA operation flag
> > --
> > 2.25.1
> >
RE: [EXT] Re: [PATCH v1 2/2] dmadev: get DMA device using device ID
> -Original Message-
> From: Jerin Jacob
> Sent: Monday, September 18, 2023 7:12 PM
> To: Amit Prakash Shukla
> Cc: Chengwen Feng ; Kevin Laatz
> ; Bruce Richardson ;
> dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> m...@smartsharesystems.com; conor.wa...@intel.com; Vamsi Krishna
> Attunuru ; g.si...@nxp.com;
> sachin.sax...@oss.nxp.com; hemant.agra...@nxp.com;
> cheng1.ji...@intel.com; Nithin Kumar Dabilpuram
> ; Anoob Joseph
> Subject: [EXT] Re: [PATCH v1 2/2] dmadev: get DMA device using device ID
>
> External Email
>
> --
> On Mon, Sep 18, 2023 at 6:02 PM Amit Prakash Shukla
> wrote:
> > dmadev: get DMA device using device ID
>
> dmadev: add PMD API to get DMA device using device ID or so
>
> >
> > Added a function that lookup for the dma device using device id and
>
> internal function that
>
> > returns the pointer to the same.
> >
> > Signed-off-by: Amit Prakash Shukla #endif
> > diff --git a/lib/dmadev/version.map b/lib/dmadev/version.map index
> > 7031d6b335..cdad39044d 100644
> > --- a/lib/dmadev/version.map
> > +++ b/lib/dmadev/version.map
> > @@ -26,6 +26,7 @@ INTERNAL {
> > rte_dma_fp_objs;
> > rte_dma_pmd_allocate;
> > rte_dma_pmd_release;
> > + rte_dma_pmd_dev_get;
>
> Move after rte_dma_pmd_allocate() to sort in alphabetical order.
Ack. I will change it as part of V2. Thanks.
>
>
> >
> > local: *;
> > };
> > --
> > 2.25.1
> >
RE: [PATCH v2] common/qat: enable QAT 2.0c devices
Hi Ciara,
> -Original Message-
> From: Ciara Power
> Sent: Monday, August 21, 2023 10:34 AM
> To: dev@dpdk.org
> Cc: Kusztal, ArkadiuszX ;
> david.march...@redhat.com; Power, Ciara ; Ji, Kai
>
> Subject: [PATCH v2] common/qat: enable QAT 2.0c devices
>
> This commit enables QAT 2.0c devices in the Intel QuickAssist Technology
> PMD.
> These are 4th Generation QAT, 402xx devices.
>
> Signed-off-by: Ciara Power
>
> ---
> v2:
> - Fixed kernel module.
> - Modified commit to align naming of new QAT device.
> ---
> doc/guides/cryptodevs/qat.rst | 4
> doc/guides/rel_notes/release_23_11.rst | 4
> drivers/common/qat/qat_device.c| 4
> 3 files changed, 12 insertions(+)
>
> diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
> index afdfb0bd22..730113da33 100644
> --- a/doc/guides/cryptodevs/qat.rst
> +++ b/doc/guides/cryptodevs/qat.rst
> @@ -457,6 +457,10 @@ to see the full table)
>
> +-+-+-+-+--+---+---++---
> -+--+++
> | Yes | No | No | 4 | 401xxx | IDZ/ N/A | qat_401xxx| 4xxx
> |
> 4942 | 2| 4943 | 16 |
>
> +-+-+-+-+--+---+---++---
> -+--+++
> + | Yes | Yes | Yes | 4 | 402xx| linux/6.4+| qat_4xxx | 4xxx
> | 4944
> | 2| 4945 | 16 |
> +
> +-+-+-+-+--+---+---++--
> --+--+++
> + | Yes | No | No | 4 | 402xx| IDZ/ N/A | qat_4xxx | 4xxx
> | 4944
> | 2| 4945 | 16 |
> +
> + +-+-+-+-+--+---+---+--
> + --++--+++
>
> * Note: Symmetric mixed crypto algorithms feature on Gen 2 works only with
> IDZ driver version 4.9.0+
>
> diff --git a/doc/guides/rel_notes/release_23_11.rst
> b/doc/guides/rel_notes/release_23_11.rst
> index 4411bb32c1..72dfb3fbf0 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -72,6 +72,10 @@ New Features
> Also, make sure to start the actual text at the margin.
> ===
>
> +* **Added support for QAT 2.0c devices to Intel QuickAssist Technology
> +PMD.**
> +
> + * QAT 2.0c (4944) devices are now enabled for QAT.
> +
>
> Removed Items
> -
> diff --git a/drivers/common/qat/qat_device.c
> b/drivers/common/qat/qat_device.c index 2675f0d9d1..cbf1e6a988 100644
> --- a/drivers/common/qat/qat_device.c
> +++ b/drivers/common/qat/qat_device.c
> @@ -50,6 +50,9 @@ static const struct rte_pci_id pci_id_qat_map[] = {
> {
> RTE_PCI_DEVICE(0x8086, 0x4943),
> },
> + {
> + RTE_PCI_DEVICE(0x8086, 0x4945),
> + },
> {.device_id = 0},
> };
>
> @@ -202,6 +205,7 @@ qat_pci_device_allocate(struct rte_pci_device
> *pci_dev,
> break;
> case 0x4941:
> case 0x4943:
> + case 0x4945:
> qat_dev_gen = QAT_GEN4;
> break;
> default:
> --
> 2.25.1
Acked-by: Brian Dooley
RE: Process for adding a new driver?
> -Original Message- > From: Morten Brørup > Sent: Monday, September 18, 2023 2:08 AM > To: techbo...@dpdk.org; maxime.coque...@redhat.com > Cc: dev@dpdk.org; Ferruh Yigit ; > andrew.rybche...@oktetlabs.ru; Christian Koue Muf ; > Renyong Wan > Subject: Process for adding a new driver? > > Dear DPDK tech board, > > The process for adding a new library to DPDK is well documented [1]. > > What is the process for adding a new (NIC) driver? > > It seems like the task of reviewing NIC PMDs from vendors other than > Broadcom/Intel/Marvell/NVIDIA falls entirely on the next-net tree > maintainers, Ferruh and Andrew, which doesn't seem like a reasonable > burden. > > The Napatech driver is too large for Ferruh to review, which in my opinion [2] > is an unreasonable argument for not accepting it. > > And the 3SNIC driver got no attention by any reviewers [3]. (Although > Stephen did provide some basic feedback after they polled for review.) > > Overall, I think we should put much more trust in hardware vendors to > provide high quality drivers for their hardware. We want vendors to upstream > their drivers, with all the benefits of having the code public. If we make it > too > difficult, they will simply keep their drivers private instead. Difficulty vs quality control? IMO, it is good to add more drivers. May be we need to control quality through testing reports? > > @Maxime: I propose to put this on the agenda for the coming techboard > meeting. > > > [1]: https://doc.dpdk.org/guides/contributing/new_library.html > [2]: > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87BAF > @smartserver.smartshare.dk/ > [3]: http://inbox.dpdk.org/dev/6df9c00f-23a0-423f-840b- > 4ecf20ff8...@3snic.com/ > > > Med venlig hilsen / Kind regards, > -Morten Brørup
Re: [PATCH v2 0/2] check illegal packets
On Tue, Sep 27, 2022 at 9:24 AM Kevin Liu wrote: > > Check whether the data packet is illegal of ice and iavf driver. > > v2: > Change the scheme, check the data_len and update commit log. > > Kevin Liu (2): > net/iavf: check illegal packets > net/ice: check illegal packets > > drivers/net/iavf/iavf_rxtx.c | 9 + > drivers/net/iavf/iavf_rxtx.h | 2 ++ > drivers/net/ice/ice_rxtx.c | 11 +++ > drivers/net/ice/ice_rxtx.h | 2 ++ > 4 files changed, 24 insertions(+) This series looks wrong to me. - What happens if the application requests TSO to the nic? - Checking data_len of a mbuf means only checking the size of the first segment, so if any limitation applies to the packet size, it should by checking pkt_len. I will probably send reverts for the two patches. -- David Marchand
Re: [PATCH 1/3] ethdev: add frequency adjustment API
On 8/9/2023 6:06 AM, Simei Su wrote:
> This patch introduces a new timesync API "rte_eth_timesync_adjust_fine"
> which enables finer adjustment of the PHC clock. During PTP timesync,
> "rte_eth_timesync_adjust_time" focuses on phase adjustment while
> "rte_eth_timesync_adjust_fine" focuses on frequency adjustment.
>
Hi Simei,
The patch adds new API and new dev_ops, mechanics of it mostly looks
good, there is minor comment below.
But there is not much comment on it because concept may be not well
known as it is not much known to me. Can you please try to add more
details and documentations to help users and driver developers?
I have some understanding based on your comments, can you please check
if it is correct:
In PTP protocol master and client synchronize clocks periodically, and
adjust the delta with 'rte_eth_timesync_adjust_time()' API, which simply
use this delta as offset in its time function.
But new API added by this patch, 'rte_eth_timesync_adjust_fine()', adds
a new synchronization method by saying device to change its HW timer
frequency.
The name of the API says this is a finer adjustment method, I wonder
why? I don't know much about timer HW but my understanding is they are
pretty accurate, why changing frequency gives a finer adjustment? Is it
common that difference frequency of HW timers cause drift by time?
Btw, what is PHC clock? Is it "Pulse Hollow Cathode" (as chatGPT
suggests :), is there any significance of this type of clock? Is this
API valid only for this type of clock?
And for users, assuming the HW supports both methods, how should they
decide which one to use? Can we provide some guidance to them? I can see
API suggest to use 'rte_eth_timesync_adjust_fine()' when time diff
offset is less than a threshold but what is the threshold and what
happens if user only uses 'rte_eth_timesync_adjust_time()'?
Is there a more real life numbers to provide as samples, maybe can
provide them in the commit log as sample if we can't provide them in API
documentation?
> This new function gets the scaled_ppm (desired frequency offset from
> nominal frequency in parts per million, but with a 16 bit binary
> fractional field).
>
What is "scaled parts per million"? I think I understand what parameter
does, but not sure about what is the unit here?
Also PTP client sample mentions about algorithms to use for frequency
adjustment, like PI servo algorithm next patch uses, what are these
algorithms?
Should we mention from algorithms or specifically from "PI servo
algorithm" in the API documentation?
> Signed-off-by: Simei Su
> Signed-off-by: Wenjun Wu
> ---
> lib/ethdev/ethdev_driver.h | 5 +
> lib/ethdev/ethdev_trace.h| 9 +
> lib/ethdev/ethdev_trace_points.c | 3 +++
> lib/ethdev/rte_ethdev.c | 19 +++
> lib/ethdev/rte_ethdev.h | 38 ++
'version.map' also should be updated to export the API, so that DPDK
applications linked with shared DPDK library can use it.
CI already complaining about this:
https://mails.dpdk.org/archives/test-report/2023-August/435936.html
> 5 files changed, 74 insertions(+)
>
> diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> index 980f837..4c39c3d 100644
> --- a/lib/ethdev/ethdev_driver.h
> +++ b/lib/ethdev/ethdev_driver.h
> @@ -636,6 +636,9 @@ typedef int (*eth_timesync_read_tx_timestamp_t)(struct
> rte_eth_dev *dev,
> /** @internal Function used to adjust the device clock. */
> typedef int (*eth_timesync_adjust_time)(struct rte_eth_dev *dev, int64_t);
>
> +/** @internal Function used to adjust the clock increment rate. */
> +typedef int (*eth_timesync_adjust_fine)(struct rte_eth_dev *dev, int64_t);
> +
> /** @internal Function used to get time from the device clock. */
> typedef int (*eth_timesync_read_time)(struct rte_eth_dev *dev,
> struct timespec *timestamp);
> @@ -1347,6 +1350,8 @@ struct eth_dev_ops {
> eth_timesync_read_tx_timestamp_t timesync_read_tx_timestamp;
> /** Adjust the device clock */
> eth_timesync_adjust_time timesync_adjust_time;
> + /** Adjust the clock increment rate */
> + eth_timesync_adjust_fine timesync_adjust_fine;
> /** Get the device clock time */
> eth_timesync_read_time timesync_read_time;
> /** Set the device clock time */
> diff --git a/lib/ethdev/ethdev_trace.h b/lib/ethdev/ethdev_trace.h
> index 423e712..d613eb2 100644
> --- a/lib/ethdev/ethdev_trace.h
> +++ b/lib/ethdev/ethdev_trace.h
> @@ -2175,6 +2175,15 @@ RTE_TRACE_POINT_FP(
> rte_trace_point_emit_int(ret);
> )
>
> +/* Called in loop in examples/ptpclient */
> +RTE_TRACE_POINT_FP(
> + rte_eth_trace_timesync_adjust_fine,
> + RTE_TRACE_POINT_ARGS(uint16_t port_id, int64_t scaled_ppm, int ret),
> + rte_trace_point_emit_u16(port_id);
> + rte_trace_point_emit_i64(scaled_ppm);
> + rte_trace_point_emit_int(ret);
> +)
> +
> /* Calle
Re: [PATCH v2 0/2] check illegal packets
On 18/09/2023 15:42, David Marchand wrote:
On Tue, Sep 27, 2022 at 9:24 AM Kevin Liu wrote:
Check whether the data packet is illegal of ice and iavf driver.
v2:
Change the scheme, check the data_len and update commit log.
Kevin Liu (2):
net/iavf: check illegal packets
net/ice: check illegal packets
drivers/net/iavf/iavf_rxtx.c | 9 +
drivers/net/iavf/iavf_rxtx.h | 2 ++
drivers/net/ice/ice_rxtx.c | 11 +++
drivers/net/ice/ice_rxtx.h | 2 ++
4 files changed, 24 insertions(+)
This series looks wrong to me.
- What happens if the application requests TSO to the nic?
- Checking data_len of a mbuf means only checking the size of the
first segment, so if any limitation applies to the packet size, it
should by checking pkt_len.
I will probably send reverts for the two patches.
there is a fix also that needs to be checked:
688cb2f2c61e ("net/ice: fix scalar Tx path segment")
Re: [PATCH 3/3] examples/ptpclient: add frequency adjustment support
On 8/9/2023 6:07 AM, Simei Su wrote: > This patch applys PI servo algorithm to leverage frequency adjustment > API to improve PTP timesync accuracy. > > The command for starting ptpclient with PI algorithm is: > ./build/examples/dpdk-ptpclient -a :81:00.0 -c 1 -n 3 -- -T 0 -p 0x1 > --controller=pi > Is there a sample application documentation to document new command line argument and document logic to select which API to use, perhaps document what is 'pi servo' algorithm is? If there is no documentation, what do you think adding one?
Re: [PATCH v2 1/5] bbdev: add operation type for MLDTS procession
On 6/15/23 18:48, Nicolas Chautru wrote: Extended bbdev operations to support MLDTS based operations. Signed-off-by: Nicolas Chautru --- doc/guides/prog_guide/bbdev.rst | 53 +++ lib/bbdev/rte_bbdev.c | 11 ++- lib/bbdev/rte_bbdev.h | 76 + lib/bbdev/rte_bbdev_op.h| 116 +++- lib/bbdev/version.map | 5 ++ 5 files changed, 259 insertions(+), 2 deletions(-) diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst index 549f1d002a..8e384015ee 100644 --- a/doc/guides/prog_guide/bbdev.rst +++ b/doc/guides/prog_guide/bbdev.rst @@ -1165,6 +1165,59 @@ either as 2 INT16 or as 2 FP16 based when the option supported. The data layout is based on contiguous concatenation of output data first by cyclic shift then by antenna. +BBDEV MLD-TS Operation +~~ + +This operation allows to run the Tree Search (TS) portion of a Maximum Likelihood processing (MLD). + +This alternate equalization option accelerates the exploration of the best combination of +transmitted symbols across layers minimizing the Euclidean distance between the received and +reconstructed signal, then generates the LLRs to be used by the LDPC Decoder. +The input is the results of the Q R decomposition: Q^Hy signal and R matrix. + +The structure passed for each MLD-TS operation is given below, +with the operation flags forming a bitmask in the ``op_flags`` field. + + **NOTE:** The actual operation flags that may be used with a specific + bbdev PMD are dependent on the driver capabilities as reported via + ``rte_bbdev_info_get()``, and may be a subset of those below. + +.. literalinclude:: ../../../lib/bbdev/rte_bbdev_op.h + :language: c + :start-after: Structure rte_bbdev_op_mldts 8< + :end-before: >8 End of structure rte_bbdev_op_mldts. + +++ +|Description of MLD-TS capability flags | +++ +|RTE_BBDEV_MLDTS_REP | +| Set if the option to use repeated data from R channel is supported | +++ + +The MLD-TS parameters are set out in the table below. + ++-+--+ +|Parameter|Description | ++=+==+ +|qhy_input|input data qHy | ++-+--+ +|r_input |input data R triangular matrix | ++-+--+ +|output |output data (LLRs) | ++-+--+ +|op_flags |bitmask of all active operation capabilities | ++-+--+ +|num_rbs |number of Resource Blocks | ++-+--+ +|num_layers |number of overlapping layers | ++-+--+ +|q_m |array of modulation order for each layer | ++-+--+ +|r_rep|optional row repetition for the R matrix (subcarriers)| ++-+--+ +|c_rep|optional column repetition for the R matrix (symbols) | ++-+--+ + Sample code --- diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index 1521cdbc53..26fc077bdc 100644 --- a/lib/bbdev/rte_bbdev.c +++ b/lib/bbdev/rte_bbdev.c @@ -24,7 +24,7 @@ #define DEV_NAME "BBDEV" /* Number of supported operation types in *rte_bbdev_op_type*. */ -#define BBDEV_OP_TYPE_COUNT 6 +#define BBDEV_OP_TYPE_COUNT 7 /* BBDev library logging ID */ RTE_LOG_REGISTER_DEFAULT(bbdev_logtype, NOTICE); @@ -857,6 +857,9 @@ get_bbdev_op_size(enum rte_bbdev_op_type type) case RTE_BBDEV_OP_FFT: result = sizeof(struct rte_bbdev_fft_op); break; + case RTE_BBDEV_OP_MLDTS: +
Re: [PATCH v2 2/5] bbdev: add new capabilities for FFT processing
On 6/15/23 18:48, Nicolas Chautru wrote:
Extending existing FFT operation for new capabilities.
Optional frequency domain dewindowing, frequency resampling,
timing error correction and time offset per CS.
Signed-off-by: Nicolas Chautru
---
doc/guides/prog_guide/bbdev.rst | 24
lib/bbdev/rte_bbdev_op.h| 23 ++-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 8e384015ee..95b33562fe 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -,6 +,18 @@ with the operation flags forming a bitmask in the
``op_flags`` field.
|RTE_BBDEV_FFT_FP16_OUTPUT |
| Set if the output data shall use FP16 format instead of INT16 |
++
+|RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS |
+| Set if device supports adjusting time offset per CS|
+++
+|RTE_BBDEV_FFT_TIMING_ERROR |
+| Set if device supports correcting for timing error |
+++
+|RTE_BBDEV_FFT_DEWINDOWING |
+| Set if enabling the option FFT Dewindowing in Frequency domain |
+++
+|RTE_BBDEV_FFT_FREQ_RESAMPLING |
+| Set if device supports the optional frequency resampling |
+++
The FFT parameters are set out in the table below.
@@ -1121,6 +1133,8 @@ The FFT parameters are set out in the table below.
+-+--+
|base_output |output data
|
+-+--+
+|dewindowing_input|optional frequency domain dewindowing input data
|
++-+--+
|power_meas_output|optional output data with power measurement on DFT
output |
+-+--+
|op_flags |bitmask of all active operation capabilities
|
@@ -1155,6 +1169,16 @@ The FFT parameters are set out in the table below.
+-+--+
|fp16_exp_adjust |value added to FP16 exponent at conversion from
INT16 |
+-+--+
+|freq_resample_mode |frequency ressampling mode (0:transparent, 1-2:
resample) |
++-+--+
+| output_depadded_size|output depadded size prior to frequency resampling
|
++-+--+
+|cs_theta_0 |timing error correction initial phase
|
++-+--+
+|cs_theta_d |timing error correction phase increment
|
++-+--+
+|time_offset |time offset per CS of time domain samples
|
++-+--+
The mbuf input ``base_input`` is mandatory for all bbdev PMDs and
is the incoming data for the processing. Its size may not fit into an actual
mbuf,
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 990d110fa7..682e265327 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -50,6 +50,7 @@ extern "C" {
#define RTE_BBDEV_LDPC_MAX_CODE_BLOCKS (256)
/* 12 CS maximum */
#define RTE_BBDEV_MAX_CS_2 (6)
+#define RTE_BBDEV_MAX_CS (12)
/* MLD-TS up to 4 layers */
#define RTE_BBDEV_MAX_MLD_LAYERS (4)
/* 12 SB per RB */
@@ -242,7 +243,15 @@ enum rte_bbdev_op_fft_flag_bitmasks {
/** Set if the input data used FP16 format. */
RTE_BBDEV_FFT_FP16_INPUT = (1ULL << 6),
/** Set if the output data uses FP16 format. */
- RTE_BBDEV_FFT_FP16_OUTPUT = (1ULL << 7)
+ RTE_BBDEV_FFT_FP16_OUTPUT = (1ULL << 7),
+ /** Flexible adjustment of Timing offset adjustment per CS. */
+ RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS = (1ULL << 8),
+ /** Flexible
Re: [PATCH v2 3/5] bbdev: add new capability for FEC 5G UL processing
On 6/15/23 18:48, Nicolas Chautru wrote:
Extending existing LDPC UL operation for new capability.
Option to compress HARQ memory to 4 bits per LLR.
Signed-off-by: Nicolas Chautru
---
doc/guides/prog_guide/bbdev.rst | 6 ++
lib/bbdev/rte_bbdev_op.h| 4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 95b33562fe..c43e478eda 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -903,6 +903,12 @@ given below.
|RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK|
| Set if a device supports loopback access to HARQ internal memory |
++
+|RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS |
+| Set if a device includes LLR filler bits in HARQ circular buffer |
+++
+|RTE_BBDEV_LDPC_HARQ_4BIT_COMPRESSION|
+|Set if a device supports input/output 4 bits HARQ compression |
+++
The structure passed for each LDPC decode operation is given below,
with the operation flags forming a bitmask in the ``op_flags`` field.
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 682e265327..a4a2ae1440 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -203,7 +203,9 @@ enum rte_bbdev_op_ldpcdec_flag_bitmasks {
* for HARQ memory. If not set, it is assumed the filler bits are not
* in HARQ memory and handled directly by the LDPC decoder.
*/
- RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS = (1ULL << 19)
+ RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS = (1ULL << 19),
+ /** Set if a device supports input/output HARQ 4bits compression. */
+ RTE_BBDEV_LDPC_HARQ_4BIT_COMPRESSION = (1ULL << 20)
};
/** Flags for LDPC encoder operation and capability structure */
Reviewed-by: Maxime Coquelin
Maxime
RE: [PATCH 1/3] common/qat: limit configuration to the primary process
Hi Arek,
> -Original Message-
> From: Kusztal, ArkadiuszX
> Sent: Sunday, September 17, 2023 4:43 PM
> To: dev@dpdk.org
> Cc: gak...@marvell.com; Ji, Kai ; Power, Ciara
> ; Kusztal, ArkadiuszX
>
> Subject: [PATCH 1/3] common/qat: limit configuration to the primary process
>
> This change prevents certain configuration functions from being called by the
> secondary process.
>
> Signed-off-by: Arkadiusz Kusztal
> ---
> drivers/common/qat/qat_device.c | 113 +++---
> --
> drivers/common/qat/qat_device.h | 2 +
> 2 files changed, 66 insertions(+), 49 deletions(-)
>
> +static enum qat_device_gen
> +pick_gen(struct rte_pci_device *pci_dev) {
> + switch (pci_dev->id.device_id) {
> + case 0x0443:
> + return QAT_GEN1;
> + case 0x37c9:
> + case 0x19e3:
> + case 0x6f55:
> + case 0x18ef:
> + return QAT_GEN2;
> + case 0x18a1:
> + return QAT_GEN3;
> + case 0x4941:
> + case 0x4943:
> + return QAT_GEN4;
> + default:
> + QAT_LOG(ERR, "Invalid dev_id, can't determine generation");
> + return QAT_N_GENS;
> + }
> +}
> +
> struct qat_pci_device *
> qat_pci_device_allocate(struct rte_pci_device *pci_dev,
> struct qat_dev_cmd_param *qat_dev_cmd_param) @@ -
> 187,24 +218,8 @@ qat_pci_device_allocate(struct rte_pci_device *pci_dev,
> rte_pci_device_name(&pci_dev->addr, name, sizeof(name));
> snprintf(name+strlen(name), QAT_DEV_NAME_MAX_LEN-
> strlen(name), "_qat");
>
> - switch (pci_dev->id.device_id) {
> - case 0x0443:
> - qat_dev_gen = QAT_GEN1;
> - break;
> - case 0x37c9:
> - case 0x19e3:
> - case 0x6f55:
> - case 0x18ef:
> - qat_dev_gen = QAT_GEN2;
> - break;
> - case 0x18a1:
> - qat_dev_gen = QAT_GEN3;
> - break;
> - case 0x4941:
> - case 0x4943:
> - qat_dev_gen = QAT_GEN4;
> - break;
> - default:
> + qat_dev_gen = pick_gen(pci_dev);
> + if (qat_dev_gen == QAT_N_GENS) {
> QAT_LOG(ERR, "Invalid dev_id, can't determine generation");
> return NULL;
> }
The above log is duplicated, once in pick_gen() and once here.
> @@ -261,20 +276,15 @@ qat_pci_device_allocate(struct rte_pci_device
> *pci_dev,
> qat_dev->dev_private = qat_dev + 1;
> strlcpy(qat_dev->name, name, QAT_DEV_NAME_MAX_LEN);
> qat_dev->qat_dev_id = qat_dev_id;
> - qat_pci_devs[qat_dev_id].pci_dev = pci_dev;
> qat_dev->qat_dev_gen = qat_dev_gen;
>
> ops_hw = qat_dev_hw_spec[qat_dev->qat_dev_gen];
> - if (ops_hw->qat_dev_get_misc_bar == NULL) {
> - QAT_LOG(ERR, "qat_dev_get_misc_bar function pointer not
> set");
> - rte_memzone_free(qat_dev_mz);
> - return NULL;
> - }
> + NOT_NULL(ops_hw->qat_dev_reset_ring_pairs, goto error,
> + "QAT internal error! qat_dev_get_misc_bar function not set");
This check should be for ops_hw->qat_dev_get_misc_bar as mentioned in log.
Thanks,
Ciara
Re: [PATCH v2 4/5] bbdev: improving error handling for queue configuration
On 6/15/23 18:49, Nicolas Chautru wrote:
Refactor of the error handling based on available priority
queue to be more generic.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
index 26fc077bdc..589b796ea3 100644
--- a/lib/bbdev/rte_bbdev.c
+++ b/lib/bbdev/rte_bbdev.c
@@ -441,6 +441,7 @@ rte_bbdev_queue_configure(uint16_t dev_id, uint16_t
queue_id,
const struct rte_bbdev_op_cap *p;
struct rte_bbdev_queue_conf *stored_conf;
const char *op_type_str;
+ unsigned int max_priority;
VALID_DEV_OR_RET_ERR(dev, dev_id);
VALID_DEV_OPS_OR_RET_ERR(dev, dev_id);
@@ -494,20 +495,16 @@ rte_bbdev_queue_configure(uint16_t dev_id, uint16_t
queue_id,
conf->queue_size, queue_id, dev_id);
return -EINVAL;
}
- if (conf->op_type == RTE_BBDEV_OP_TURBO_DEC &&
- conf->priority > dev_info.max_ul_queue_priority) {
+ if ((uint8_t)conf->op_type >= RTE_BBDEV_OP_TYPE_SIZE_MAX) {
rte_bbdev_log(ERR,
- "Priority (%u) of queue %u of bbdev %u must be
<= %u",
- conf->priority, queue_id, dev_id,
- dev_info.max_ul_queue_priority);
+ "Invalid operation type (%u) ",
conf->op_type);
return -EINVAL;
}
- if (conf->op_type == RTE_BBDEV_OP_TURBO_ENC &&
- conf->priority > dev_info.max_dl_queue_priority) {
+ max_priority = dev_info.queue_priority[conf->op_type];
+ if (conf->priority > max_priority) {
rte_bbdev_log(ERR,
"Priority (%u) of queue %u of bbdev %u must be
<= %u",
- conf->priority, queue_id, dev_id,
- dev_info.max_dl_queue_priority);
+ conf->priority, queue_id, dev_id,
max_priority);
return -EINVAL;
}
}
Reviewed-by: Maxime Coquelin
Maxime
Re: [PATCH v2 5/5] devtools: ignore changes into bbdev experimental API
On 6/15/23 18:49, Nicolas Chautru wrote: Developpers are warned that the related fft experimental functions do not preserve ABI, hence these can be waived. Signed-off-by: Nicolas Chautru --- devtools/libabigail.abignore | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore index 7a93de3ba1..09b8f156b5 100644 --- a/devtools/libabigail.abignore +++ b/devtools/libabigail.abignore @@ -30,7 +30,9 @@ [suppress_type] type_kind = enum changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END - +; Ignore changes to bbdev FFT API which is experimental +[suppress_type] +name = rte_bbdev_fft_op ; Temporary exceptions till next major ABI version ; With Hemmant's typo fix suggestion: Reviewed-by: Maxime Coquelin
Re: [PATCH v2 2/5] bbdev: add new capabilities for FFT processing
On 9/18/23 17:08, Maxime Coquelin wrote:
On 6/15/23 18:48, Nicolas Chautru wrote:
Extending existing FFT operation for new capabilities.
Optional frequency domain dewindowing, frequency resampling,
timing error correction and time offset per CS.
Signed-off-by: Nicolas Chautru
---
doc/guides/prog_guide/bbdev.rst | 24
lib/bbdev/rte_bbdev_op.h | 23 ++-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/bbdev.rst
b/doc/guides/prog_guide/bbdev.rst
index 8e384015ee..95b33562fe 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -,6 +,18 @@ with the operation flags forming a bitmask in
the ``op_flags`` field.
|RTE_BBDEV_FFT_FP16_OUTPUT |
| Set if the output data shall use FP16 format instead of INT16 |
++
+|RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS |
+| Set if device supports adjusting time offset per CS |
+++
+|RTE_BBDEV_FFT_TIMING_ERROR |
+| Set if device supports correcting for timing error |
+++
+|RTE_BBDEV_FFT_DEWINDOWING |
+| Set if enabling the option FFT Dewindowing in Frequency domain |
+++
+|RTE_BBDEV_FFT_FREQ_RESAMPLING |
+| Set if device supports the optional frequency resampling |
+++
The FFT parameters are set out in the table below.
@@ -1121,6 +1133,8 @@ The FFT parameters are set out in the table below.
+-+--+
|base_output |output
data |
+-+--+
+|dewindowing_input |optional frequency domain dewindowing
input data |
++-+--+
|power_meas_output |optional output data with power
measurement on DFT output |
+-+--+
|op_flags |bitmask of all active operation
capabilities |
@@ -1155,6 +1169,16 @@ The FFT parameters are set out in the table below.
+-+--+
|fp16_exp_adjust |value added to FP16 exponent at
conversion from INT16 |
+-+--+
+|freq_resample_mode |frequency ressampling mode (0:transparent,
1-2: resample) |
++-+--+
+| output_depadded_size |output depadded size prior to frequency
resampling |
++-+--+
+|cs_theta_0 |timing error correction initial
phase |
++-+--+
+|cs_theta_d |timing error correction phase
increment |
++-+--+
+|time_offset |time offset per CS of time domain
samples |
++-+--+
The mbuf input ``base_input`` is mandatory for all bbdev PMDs and
is the incoming data for the processing. Its size may not fit into
an actual mbuf,
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 990d110fa7..682e265327 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -50,6 +50,7 @@ extern "C" {
#define RTE_BBDEV_LDPC_MAX_CODE_BLOCKS (256)
/* 12 CS maximum */
#define RTE_BBDEV_MAX_CS_2 (6)
+#define RTE_BBDEV_MAX_CS (12)
/* MLD-TS up to 4 layers */
#define RTE_BBDEV_MAX_MLD_LAYERS (4)
/* 12 SB per RB */
@@ -242,7 +243,15 @@ enum rte_bbdev_op_fft_flag_bitmasks {
/** Set if the input data used FP16 format. */
RTE_BBDEV_FFT_FP16_INPUT = (1ULL << 6),
/** Set if the output data uses FP16 format. */
- RTE_BBDEV_FFT_FP16_OUTPUT = (1ULL << 7)
+ RTE_BBDEV_FFT_FP16_OUTPUT = (1ULL << 7),
+ /** Flexible adjustment of Timing offset adjustment per CS. */
+ RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS = (1ULL <<
RE: [PATCH 2/3] common/qat: move command line params to the device struct
Hi Arek, > -Original Message- > From: Kusztal, ArkadiuszX > Sent: Sunday, September 17, 2023 4:43 PM > To: dev@dpdk.org > Cc: gak...@marvell.com; Ji, Kai ; Power, Ciara > ; Kusztal, ArkadiuszX > > Subject: [PATCH 2/3] common/qat: move command line params to the device > struct > > Command line parameters was moved to the device struct. > > Signed-off-by: Arkadiusz Kusztal > --- > drivers/common/qat/qat_device.c | 54 ++-- > - > drivers/common/qat/qat_device.h | 35 > drivers/compress/qat/qat_comp_pmd.c | 9 +++ > drivers/compress/qat/qat_comp_pmd.h | 3 +-- > drivers/crypto/qat/qat_asym.c | 13 + > drivers/crypto/qat/qat_sym.c| 23 > 6 files changed, 66 insertions(+), 71 deletions(-) > > diff --git a/drivers/common/qat/qat_device.c > b/drivers/common/qat/qat_device.c index 93aef9aeb1..d9604e666d > 100644 > --- a/drivers/common/qat/qat_device.c > +++ b/drivers/common/qat/qat_device.c > @@ -22,6 +22,16 @@ > diff --git a/drivers/common/qat/qat_device.h > b/drivers/common/qat/qat_device.h index 23d7f54b61..dcb5a42c89 > 100644 > --- a/drivers/common/qat/qat_device.h > +++ b/drivers/common/qat/qat_device.h > @@ -17,14 +17,21 @@ > > #define QAT_DEV_NAME_MAX_LEN 64 > > -#define QAT_LEGACY_CAPA "qat_legacy_capa" > +#define QAT_LEGACY_CAPA_NAME "qat_legacy_capa" > #define SYM_ENQ_THRESHOLD_NAME "qat_sym_enq_threshold" > #define ASYM_ENQ_THRESHOLD_NAME "qat_asym_enq_threshold" > #define COMP_ENQ_THRESHOLD_NAME "qat_comp_enq_threshold" > #define SYM_CIPHER_CRC_ENABLE_NAME "qat_sym_cipher_crc_enable" > -#define QAT_CMD_SLICE_MAP "qat_cmd_slice_disable" > -#define QAT_CMD_SLICE_MAP_POS5 > -#define MAX_QP_THRESHOLD_SIZE32 > +#define QAT_CMD_SLICE_MAP_NAME "qat_cmd_slice_disable" > +#define QAT_LEGACY_CAPA_POS 0 > +#define SYM_ENQ_THRESHOLD_POS1 > +#define ASYM_ENQ_THRESHOLD_POS 2 > +#define COMP_ENQ_THRESHOLD_POS 3 > +#define SYM_CIPHER_CRC_ENABLE_POS4 > +#define QAT_CMD_SLICE_MAP_POS5 Small suggestion, maybe an enum could be used to group the above position macros together. Acked-by: Ciara Power
Re: [PATCH v5 03/32] net/sssnic: support probe and remove
On Mon, 4 Sep 2023 12:56:29 +0800
wrote:
> +static int
> +sssnic_ethdev_init(struct rte_eth_dev *ethdev)
> +{
> + RTE_SET_USED(ethdev);
> + PMD_INIT_FUNC_TRACE();
> +
> + return -EINVAL;
> +}
Since device does not support secondary process, should
check and return error here.
[PATCH v3 0/4] changes for 23.11
v3: Made changes requested during review. v2: Targeting 23.11. Update in commits 1,2 based on review comments. v1: Targeting 23.07 if possible. Add support for AGX100 (N6000) and corner case fixes. Hernan Vargas (4): baseband/fpga_5gnr_fec: renaming for consistency baseband/fpga_5gnr_fec: add Vista Creek variant baseband/fpga_5gnr_fec: add AGX100 support baseband/fpga_5gnr_fec: cosmetic comment changes doc/guides/bbdevs/fpga_5gnr_fec.rst | 72 +- drivers/baseband/fpga_5gnr_fec/agx100_pmd.h | 273 ++ .../baseband/fpga_5gnr_fec/fpga_5gnr_fec.h| 353 +-- .../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 2292 - .../fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h | 27 +- drivers/baseband/fpga_5gnr_fec/vc_5gnr_pmd.h | 140 + 6 files changed, 2194 insertions(+), 963 deletions(-) create mode 100644 drivers/baseband/fpga_5gnr_fec/agx100_pmd.h create mode 100644 drivers/baseband/fpga_5gnr_fec/vc_5gnr_pmd.h -- 2.37.1
[PATCH v3 1/4] baseband/fpga_5gnr_fec: renaming for consistency
Rename generic functions and constants using the FPGA 5GNR prefix naming
to prepare for code reuse for new FPGA implementation variant.
No functional impact.
Signed-off-by: Hernan Vargas
Reviewed-by: Maxime Coquelin
---
.../baseband/fpga_5gnr_fec/fpga_5gnr_fec.h| 117 +++--
.../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 455 --
.../fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h | 17 +-
3 files changed, 269 insertions(+), 320 deletions(-)
diff --git a/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
b/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
index e3038112fabb..9300349a731b 100644
--- a/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
+++ b/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
@@ -31,26 +31,26 @@
#define FPGA_5GNR_FEC_VF_DEVICE_ID (0x0D90)
/* Align DMA descriptors to 256 bytes - cache-aligned */
-#define FPGA_RING_DESC_ENTRY_LENGTH (8)
+#define FPGA_5GNR_RING_DESC_ENTRY_LENGTH (8)
/* Ring size is in 256 bits (32 bytes) units */
#define FPGA_RING_DESC_LEN_UNIT_BYTES (32)
/* Maximum size of queue */
-#define FPGA_RING_MAX_SIZE (1024)
+#define FPGA_5GNR_RING_MAX_SIZE (1024)
#define FPGA_NUM_UL_QUEUES (32)
#define FPGA_NUM_DL_QUEUES (32)
#define FPGA_TOTAL_NUM_QUEUES (FPGA_NUM_UL_QUEUES + FPGA_NUM_DL_QUEUES)
#define FPGA_NUM_INTR_VEC (FPGA_TOTAL_NUM_QUEUES - RTE_INTR_VEC_RXTX_OFFSET)
-#define FPGA_INVALID_HW_QUEUE_ID (0x)
+#define FPGA_5GNR_INVALID_HW_QUEUE_ID (0x)
-#define FPGA_QUEUE_FLUSH_TIMEOUT_US (1000)
-#define FPGA_HARQ_RDY_TIMEOUT (10)
-#define FPGA_TIMEOUT_CHECK_INTERVAL (5)
-#define FPGA_DDR_OVERFLOW (0x10)
+#define FPGA_5GNR_QUEUE_FLUSH_TIMEOUT_US (1000)
+#define FPGA_5GNR_HARQ_RDY_TIMEOUT (10)
+#define FPGA_5GNR_TIMEOUT_CHECK_INTERVAL (5)
+#define FPGA_5GNR_DDR_OVERFLOW (0x10)
-#define FPGA_5GNR_FEC_DDR_WR_DATA_LEN_IN_BYTES 8
-#define FPGA_5GNR_FEC_DDR_RD_DATA_LEN_IN_BYTES 8
+#define FPGA_5GNR_DDR_WR_DATA_LEN_IN_BYTES 8
+#define FPGA_5GNR_DDR_RD_DATA_LEN_IN_BYTES 8
/* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */
#define N_ZC_1 66 /* N = 66 Zc for BG 1 */
@@ -152,7 +152,7 @@ struct __rte_packed fpga_dma_enc_desc {
};
uint8_t sw_ctxt[FPGA_RING_DESC_LEN_UNIT_BYTES *
- (FPGA_RING_DESC_ENTRY_LENGTH - 1)];
+ (FPGA_5GNR_RING_DESC_ENTRY_LENGTH - 1)];
};
};
@@ -197,7 +197,7 @@ struct __rte_packed fpga_dma_dec_desc {
uint8_t cbs_in_op;
};
- uint32_t sw_ctxt[8 * (FPGA_RING_DESC_ENTRY_LENGTH - 1)];
+ uint32_t sw_ctxt[8 * (FPGA_5GNR_RING_DESC_ENTRY_LENGTH - 1)];
};
};
@@ -207,8 +207,8 @@ union fpga_dma_desc {
struct fpga_dma_dec_desc dec_req;
};
-/* FPGA 5GNR FEC Ring Control Register */
-struct __rte_packed fpga_ring_ctrl_reg {
+/* FPGA 5GNR Ring Control Register. */
+struct __rte_packed fpga_5gnr_ring_ctrl_reg {
uint64_t ring_base_addr;
uint64_t ring_head_addr;
uint16_t ring_size:11;
@@ -226,38 +226,37 @@ struct __rte_packed fpga_ring_ctrl_reg {
uint16_t rsrvd3;
uint16_t head_point;
uint16_t rsrvd4;
-
};
-/* Private data structure for each FPGA FEC device */
+/* Private data structure for each FPGA 5GNR device. */
struct fpga_5gnr_fec_device {
- /** Base address of MMIO registers (BAR0) */
+ /** Base address of MMIO registers (BAR0). */
void *mmio_base;
- /** Base address of memory for sw rings */
+ /** Base address of memory for sw rings. */
void *sw_rings;
- /** Physical address of sw_rings */
+ /** Physical address of sw_rings. */
rte_iova_t sw_rings_phys;
/** Number of bytes available for each queue in device. */
uint32_t sw_ring_size;
- /** Max number of entries available for each queue in device */
+ /** Max number of entries available for each queue in device. */
uint32_t sw_ring_max_depth;
- /** Base address of response tail pointer buffer */
+ /** Base address of response tail pointer buffer. */
uint32_t *tail_ptrs;
- /** Physical address of tail pointers */
+ /** Physical address of tail pointers. */
rte_iova_t tail_ptr_phys;
- /** Queues flush completion flag */
+ /** Queues flush completion flag. */
uint64_t *flush_queue_status;
- /* Bitmap capturing which Queues are bound to the PF/VF */
+ /** Bitmap capturing which Queues are bound to the PF/VF. */
uint64_t q_bound_bit_map;
- /* Bitmap capturing which Queues have already been assigned */
+ /** Bitmap capturing which Queues have already been assigned. */
uint64_t q_assigned_bit_map;
- /** True if this is a PF FPGA FEC device */
+ /** True if this is a PF FPGA 5GNR device. */
bool pf_device;
};
-/* Structure associated with each queue. */
-struct __rte_cache_aligned fpga_queue {
[PATCH v3 2/4] baseband/fpga_5gnr_fec: add Vista Creek variant
Create a new file vc_5gnr_pmd.h to store structures and macros specific
to Vista Creek 5G FPGA implementation and rename functions specific to
the Vista Creek variant.
Signed-off-by: Hernan Vargas
---
.../baseband/fpga_5gnr_fec/fpga_5gnr_fec.h| 183 +-
.../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 531 +-
drivers/baseband/fpga_5gnr_fec/vc_5gnr_pmd.h | 140 +
3 files changed, 426 insertions(+), 428 deletions(-)
create mode 100644 drivers/baseband/fpga_5gnr_fec/vc_5gnr_pmd.h
diff --git a/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
b/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
index 9300349a731b..982e956dc819 100644
--- a/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
+++ b/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
@@ -8,6 +8,8 @@
#include
#include
+#include "vc_5gnr_pmd.h"
+
/* Helper macro for logging */
#define rte_bbdev_log(level, fmt, ...) \
rte_log(RTE_LOG_ ## level, fpga_5gnr_fec_logtype, fmt "\n", \
@@ -25,32 +27,20 @@
#define FPGA_5GNR_FEC_PF_DRIVER_NAME intel_fpga_5gnr_fec_pf
#define FPGA_5GNR_FEC_VF_DRIVER_NAME intel_fpga_5gnr_fec_vf
-/* FPGA 5GNR FEC PCI vendor & device IDs */
-#define FPGA_5GNR_FEC_VENDOR_ID (0x8086)
-#define FPGA_5GNR_FEC_PF_DEVICE_ID (0x0D8F)
-#define FPGA_5GNR_FEC_VF_DEVICE_ID (0x0D90)
-
-/* Align DMA descriptors to 256 bytes - cache-aligned */
-#define FPGA_5GNR_RING_DESC_ENTRY_LENGTH (8)
-/* Ring size is in 256 bits (32 bytes) units */
-#define FPGA_RING_DESC_LEN_UNIT_BYTES (32)
-/* Maximum size of queue */
-#define FPGA_5GNR_RING_MAX_SIZE (1024)
-
-#define FPGA_NUM_UL_QUEUES (32)
-#define FPGA_NUM_DL_QUEUES (32)
-#define FPGA_TOTAL_NUM_QUEUES (FPGA_NUM_UL_QUEUES + FPGA_NUM_DL_QUEUES)
-#define FPGA_NUM_INTR_VEC (FPGA_TOTAL_NUM_QUEUES - RTE_INTR_VEC_RXTX_OFFSET)
-
#define FPGA_5GNR_INVALID_HW_QUEUE_ID (0x)
-
#define FPGA_5GNR_QUEUE_FLUSH_TIMEOUT_US (1000)
#define FPGA_5GNR_HARQ_RDY_TIMEOUT (10)
#define FPGA_5GNR_TIMEOUT_CHECK_INTERVAL (5)
#define FPGA_5GNR_DDR_OVERFLOW (0x10)
-
#define FPGA_5GNR_DDR_WR_DATA_LEN_IN_BYTES 8
#define FPGA_5GNR_DDR_RD_DATA_LEN_IN_BYTES 8
+/* Align DMA descriptors to 256 bytes - cache-aligned. */
+#define FPGA_5GNR_RING_DESC_ENTRY_LENGTH (8)
+/* Maximum size of queue. */
+#define FPGA_5GNR_RING_MAX_SIZE (1024)
+
+#define VC_5GNR_FPGA_VARIANT 0
+#define AGX100_FPGA_VARIANT1
/* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */
#define N_ZC_1 66 /* N = 66 Zc for BG 1 */
@@ -62,32 +52,7 @@
#define K0_3_1 56 /* K0 fraction numerator for rv 3 and BG 1 */
#define K0_3_2 43 /* K0 fraction numerator for rv 3 and BG 2 */
-/* FPGA 5GNR FEC Register mapping on BAR0 */
-enum {
- FPGA_5GNR_FEC_VERSION_ID = 0x, /* len: 4B */
- FPGA_5GNR_FEC_CONFIGURATION = 0x0004, /* len: 2B */
- FPGA_5GNR_FEC_QUEUE_PF_VF_MAP_DONE = 0x0008, /* len: 1B */
- FPGA_5GNR_FEC_LOAD_BALANCE_FACTOR = 0x000a, /* len: 2B */
- FPGA_5GNR_FEC_RING_DESC_LEN = 0x000c, /* len: 2B */
- FPGA_5GNR_FEC_VFQ_FLUSH_STATUS_LW = 0x0018, /* len: 4B */
- FPGA_5GNR_FEC_VFQ_FLUSH_STATUS_HI = 0x001c, /* len: 4B */
- FPGA_5GNR_FEC_QUEUE_MAP = 0x0040, /* len: 256B */
- FPGA_5GNR_FEC_RING_CTRL_REGS = 0x0200, /* len: 2048B */
- FPGA_5GNR_FEC_DDR4_WR_ADDR_REGS = 0x0A00, /* len: 4B */
- FPGA_5GNR_FEC_DDR4_WR_DATA_REGS = 0x0A08, /* len: 8B */
- FPGA_5GNR_FEC_DDR4_WR_DONE_REGS = 0x0A10, /* len: 1B */
- FPGA_5GNR_FEC_DDR4_RD_ADDR_REGS = 0x0A18, /* len: 4B */
- FPGA_5GNR_FEC_DDR4_RD_DONE_REGS = 0x0A20, /* len: 1B */
- FPGA_5GNR_FEC_DDR4_RD_RDY_REGS = 0x0A28, /* len: 1B */
- FPGA_5GNR_FEC_DDR4_RD_DATA_REGS = 0x0A30, /* len: 8B */
- FPGA_5GNR_FEC_DDR4_ADDR_RDY_REGS = 0x0A38, /* len: 1B */
- FPGA_5GNR_FEC_HARQ_BUF_SIZE_RDY_REGS = 0x0A40, /* len: 1B */
- FPGA_5GNR_FEC_HARQ_BUF_SIZE_REGS = 0x0A48, /* len: 4B */
- FPGA_5GNR_FEC_MUTEX = 0x0A60, /* len: 4B */
- FPGA_5GNR_FEC_MUTEX_RESET = 0x0A68 /* len: 4B */
-};
-
-/* FPGA 5GNR FEC Ring Control Registers */
+/* FPGA 5GNR Ring Control Registers. */
enum {
FPGA_5GNR_FEC_RING_HEAD_ADDR = 0x0008,
FPGA_5GNR_FEC_RING_SIZE = 0x0010,
@@ -98,113 +63,27 @@ enum {
FPGA_5GNR_FEC_RING_HEAD_POINT = 0x001C
};
-/* FPGA 5GNR FEC DESCRIPTOR ERROR */
+/* VC 5GNR and AGX100 common register mapping on BAR0. */
enum {
- DESC_ERR_NO_ERR = 0x0,
- DESC_ERR_K_P_OUT_OF_RANGE = 0x1,
- DESC_ERR_Z_C_NOT_LEGAL = 0x2,
- DESC_ERR_DESC_OFFSET_ERR = 0x3,
- DESC_ERR_DESC_READ_FAIL = 0x8,
- DESC_ERR_DESC_READ_TIMEOUT = 0x9,
- DESC_ERR_DESC_READ_TLP_POISONED = 0xA,
- DESC_ERR_HARQ_INPUT_LEN = 0xB,
- DESC_ERR_CB_READ_FAIL = 0xC,
- DESC_ERR_CB_READ_TIMEOUT = 0xD,
- DESC_ERR_CB_READ_TLP_POISONED = 0xE,
- DESC_ERR_HBSTORE_ERR = 0xF
-};
-
-
-/* FPGA 5GNR FEC DMA Encoding Request Descrip
[PATCH v3 3/4] baseband/fpga_5gnr_fec: add AGX100 support
Add support for new FPGA variant AGX100 (on Arrow Creek N6000). Signed-off-by: Hernan Vargas --- doc/guides/bbdevs/fpga_5gnr_fec.rst | 72 +- drivers/baseband/fpga_5gnr_fec/agx100_pmd.h | 273 .../baseband/fpga_5gnr_fec/fpga_5gnr_fec.h| 12 +- .../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1214 +++-- 4 files changed, 1429 insertions(+), 142 deletions(-) create mode 100644 drivers/baseband/fpga_5gnr_fec/agx100_pmd.h diff --git a/doc/guides/bbdevs/fpga_5gnr_fec.rst b/doc/guides/bbdevs/fpga_5gnr_fec.rst index 9d71585e9e18..c27db695a834 100644 --- a/doc/guides/bbdevs/fpga_5gnr_fec.rst +++ b/doc/guides/bbdevs/fpga_5gnr_fec.rst @@ -6,12 +6,13 @@ Intel(R) FPGA 5GNR FEC Poll Mode Driver The BBDEV FPGA 5GNR FEC poll mode driver (PMD) supports an FPGA implementation of a VRAN LDPC Encode / Decode 5GNR wireless acceleration function, using Intel's PCI-e and FPGA -based Vista Creek device. +based Vista Creek (N3000, referred to as VC_5GNR in the code) as well as Arrow Creek (N6000, +referred to as AGX100 in the code). Features -FPGA 5GNR FEC PMD supports the following features: +FPGA 5GNR FEC PMD supports the following BBDEV capabilities: - LDPC Encode in the DL - LDPC Decode in the UL @@ -67,10 +68,18 @@ Initialization When the device first powers up, its PCI Physical Functions (PF) can be listed through this command: +Vista Creek (N3000) + .. code-block:: console sudo lspci -vd8086:0d8f +Arrow Creek (N6000) + +.. code-block:: console + + sudo lspci -vd8086:5799 + The physical and virtual functions are compatible with Linux UIO drivers: ``vfio`` and ``igb_uio``. However, in order to work the FPGA 5GNR FEC device firstly needs to be bound to one of these linux drivers through DPDK. @@ -85,24 +94,34 @@ Install the DPDK igb_uio driver, bind it with the PF PCI device ID and use The igb_uio driver may be bound to the PF PCI device using one of two methods: -1. PCI functions (physical or virtual, depending on the use case) can be bound to -the UIO driver by repeating this command for every function. +1. PCI functions (physical or virtual, depending on the use case) can be bound to the UIO driver by repeating this command for every function. -.. code-block:: console + .. code-block:: console + +insmod igb_uio.ko + + Bind N3000 to igb_uio + + .. code-block:: console - insmod igb_uio.ko - echo "8086 0d8f" > /sys/bus/pci/drivers/igb_uio/new_id - lspci -vd8086:0d8f +echo "8086 0d8f" > /sys/bus/pci/drivers/igb_uio/new_id +lspci -vd8086:0d8f + Bind N6000 to igb_uio + + .. code-block:: console + +echo "8086 5799" > /sys/bus/pci/drivers/igb_uio/new_id +lspci -vd8086:5799 2. Another way to bind PF with DPDK UIO driver is by using the ``dpdk-devbind.py`` tool -.. code-block:: console + .. code-block:: console - cd - ./usertools/dpdk-devbind.py -b igb_uio :06:00.0 +cd +./usertools/dpdk-devbind.py -b igb_uio :06:00.0 -where the PCI device ID (example: :06:00.0) is obtained using lspci -vd8086:0d8f +where the PCI device ID (example: :06:00.0) is obtained using lspci -vd8086:0d8f for N3000 or lspci -vd8086:5799 for N6000 In the same way the FPGA 5GNR FEC PF can be bound with vfio, but vfio driver does not @@ -165,7 +184,6 @@ parameters defined in ``rte_fpga_5gnr_fec_conf`` structure: uint8_t dl_bandwidth; uint8_t ul_load_balance; uint8_t dl_load_balance; - uint16_t flr_time_out; }; - ``pf_mode_en``: identifies whether only PF is to be used, or the VFs. PF and @@ -176,12 +194,12 @@ parameters defined in ``rte_fpga_5gnr_fec_conf`` structure: - ``vf_*l_queues_number``: defines the hardware queue mapping for every VF. -- ``*l_bandwidth``: in case of congestion on PCIe interface. The device - allocates different bandwidth to UL and DL. The weight is configured by this - setting. The unit of weight is 3 code blocks. For example, if the code block - cbps (code block per second) ratio between UL and DL is 12:1, then the - configuration value should be set to 36:3. The schedule algorithm is based - on code block regardless the length of each block. +- ``*l_bandwidth``: Only used for the Vista Creek schedule algorithm in case of + congestion on PCIe interface. The device allocates different bandwidth to UL + and DL. The weight is configured by this setting. The unit of weight is 3 code + blocks. For example, if the code block cbps (code block per second) ratio between + UL and DL is 12:1, then the configuration value should be set to 36:3. + The schedule algorithm is based on code block regardless the length of each block. - ``*l_load_balance``: hardware queues are load-balanced in a round-robin fashion. Queues get filled first-in first-out until they reach a pre-defined @@ -191,10 +209,6 @@ parameters defined in ``rte_fpga_5gnr_fec_conf`` structure: If all hardware queues exceeds the watermark, no code blocks w
[PATCH v3 4/4] baseband/fpga_5gnr_fec: cosmetic comment changes
Cosmetic changes for comments.
No functional impact.
Signed-off-by: Hernan Vargas
---
.../baseband/fpga_5gnr_fec/fpga_5gnr_fec.h| 49 ++--
.../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 246 +-
.../fpga_5gnr_fec/rte_pmd_fpga_5gnr_fec.h | 16 +-
3 files changed, 154 insertions(+), 157 deletions(-)
diff --git a/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
b/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
index 224684902569..6e97a3e9e2d4 100644
--- a/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
+++ b/drivers/baseband/fpga_5gnr_fec/fpga_5gnr_fec.h
@@ -11,7 +11,7 @@
#include "agx100_pmd.h"
#include "vc_5gnr_pmd.h"
-/* Helper macro for logging */
+/* Helper macro for logging. */
#define rte_bbdev_log(level, fmt, ...) \
rte_log(RTE_LOG_ ## level, fpga_5gnr_fec_logtype, fmt "\n", \
##__VA_ARGS__)
@@ -24,7 +24,7 @@
#define rte_bbdev_log_debug(fmt, ...)
#endif
-/* FPGA 5GNR FEC driver names */
+/* FPGA 5GNR FEC driver names. */
#define FPGA_5GNR_FEC_PF_DRIVER_NAME intel_fpga_5gnr_fec_pf
#define FPGA_5GNR_FEC_VF_DRIVER_NAME intel_fpga_5gnr_fec_vf
@@ -43,15 +43,15 @@
#define VC_5GNR_FPGA_VARIANT 0
#define AGX100_FPGA_VARIANT1
-/* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */
-#define N_ZC_1 66 /* N = 66 Zc for BG 1 */
-#define N_ZC_2 50 /* N = 50 Zc for BG 2 */
-#define K0_1_1 17 /* K0 fraction numerator for rv 1 and BG 1 */
-#define K0_1_2 13 /* K0 fraction numerator for rv 1 and BG 2 */
-#define K0_2_1 33 /* K0 fraction numerator for rv 2 and BG 1 */
-#define K0_2_2 25 /* K0 fraction numerator for rv 2 and BG 2 */
-#define K0_3_1 56 /* K0 fraction numerator for rv 3 and BG 1 */
-#define K0_3_2 43 /* K0 fraction numerator for rv 3 and BG 2 */
+/* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2. */
+#define N_ZC_1 66 /**< N = 66 Zc for BG 1. */
+#define N_ZC_2 50 /**< N = 50 Zc for BG 2. */
+#define K0_1_1 17 /**< K0 fraction numerator for rv 1 and BG 1. */
+#define K0_1_2 13 /**< K0 fraction numerator for rv 1 and BG 2. */
+#define K0_2_1 33 /**< K0 fraction numerator for rv 2 and BG 1. */
+#define K0_2_2 25 /**< K0 fraction numerator for rv 2 and BG 2. */
+#define K0_3_1 56 /**< K0 fraction numerator for rv 3 and BG 1. */
+#define K0_3_2 43 /**< K0 fraction numerator for rv 3 and BG 2. */
/* FPGA 5GNR Ring Control Registers. */
enum {
@@ -93,7 +93,7 @@ struct __rte_packed fpga_5gnr_ring_ctrl_reg {
uint64_t ring_head_addr;
uint16_t ring_size:11;
uint16_t rsrvd0;
- union { /* Miscellaneous register */
+ union { /* Miscellaneous register. */
uint8_t misc;
uint8_t max_ul_dec:5,
max_ul_dec_en:1,
@@ -140,26 +140,23 @@ struct fpga_5gnr_fec_device {
/** Structure associated with each queue. */
struct __rte_cache_aligned fpga_5gnr_queue {
- struct fpga_5gnr_ring_ctrl_reg ring_ctrl_reg; /**< Ring Control
Register */
+ struct fpga_5gnr_ring_ctrl_reg ring_ctrl_reg; /**< Ring Control
Register. */
union {
/** Virtual address of VC 5GNR software ring. */
union vc_5gnr_dma_desc *vc_5gnr_ring_addr;
/** Virtual address of AGX100 software ring. */
union agx100_dma_desc *agx100_ring_addr;
};
- uint64_t *ring_head_addr; /* Virtual address of completion_head */
- uint64_t shadow_completion_head; /* Shadow completion head value */
- uint16_t head_free_desc; /* Ring head */
- uint16_t tail; /* Ring tail */
- /* Mask used to wrap enqueued descriptors on the sw ring */
- uint32_t sw_ring_wrap_mask;
- uint32_t irq_enable; /* Enable ops dequeue interrupts if set to 1 */
- uint8_t q_idx; /* Queue index */
- /** uuid used for MUTEX acquision for DDR */
- uint16_t ddr_mutex_uuid;
- struct fpga_5gnr_fec_device *d;
- /* MMIO register of shadow_tail used to enqueue descriptors */
- void *shadow_tail_addr;
+ uint64_t *ring_head_addr; /**< Virtual address of completion_head. */
+ uint64_t shadow_completion_head; /**< Shadow completion head value. */
+ uint16_t head_free_desc; /**< Ring head. */
+ uint16_t tail; /**< Ring tail. */
+ uint32_t sw_ring_wrap_mask; /**< Mask used to wrap enqueued descriptors
on the sw ring. */
+ uint32_t irq_enable; /**< Enable ops dequeue interrupts if set to 1. */
+ uint8_t q_idx; /**< Queue index. */
+ uint16_t ddr_mutex_uuid; /**< uuid used for MUTEX acquision for DDR. */
+ struct fpga_5gnr_fec_device *d; /**< FPGA 5GNR device structure. */
+ void *shadow_tail_addr; /**< MMIO register of shadow_tail used to
enqueue descriptors. */
};
/* Write to 16 bit MMIO register address. */
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 5c88f84d581a..f57a92bbe809 100644
--- a/drivers/baseband/fpga_5
[PATCH v3 0/2] Enable apps to use external memory as native
Sometimes apps (or perhaps DPDK driver components) may want to allow use of "external" i.e. non EAL allocated, memory as though it were standard DPDK memory. This patchset provides the ability to do this, by: firstly, adding an explicit flag to indicate non-EAL memory, rather than relying on the socket_id implicitly, and then secondly, allowing heaps to be swapped, so an external heap can be used as the default heap for socket 0 or 1, etc. V3: * Expand to 2 patch set, adding patch to tag external memory explicitly, before adding the swap function * Add locks to improve thread safety of the swap opperation. * Add additional notes to function to clarify usage. V2: * Fix doxygen comment issue on doc builds Bruce Richardson (2): eal: add flag to indicate non-EAL malloc heaps eal: allow swapping of malloc heaps lib/eal/common/malloc_heap.c | 46 lib/eal/common/malloc_heap.h | 1 + lib/eal/common/malloc_mp.c | 5 ++-- lib/eal/common/rte_malloc.c | 14 ++- lib/eal/include/rte_malloc.h | 34 ++ lib/eal/version.map | 2 ++ 6 files changed, 83 insertions(+), 19 deletions(-) -- 2.39.2
[PATCH v3 2/2] eal: allow swapping of malloc heaps
The external memory functions in DPDK allow the addition of externally
access memory to malloc heaps, but with one major restriction - the
memory must be allocated to an application-created heap, not one of the
standard DPDK heaps for a NUMA node.
This restriction makes it difficult - if not impossible - to use
externally allocated memory for DPDK by default. However, even if the
restriction is relaxed, so we can add external memory to e.g. the socket
0 heap, there would be no way to guarantee that the external memory
would be used in preference to the standard DPDK hugepage memory for a
given allocation.
To give appropriately defined behaviour, a better solution is to allow
the application to explicitly swap a pair of heaps. With this one new
API in place, it allows the user to configure a new malloc heap, add
external memory to it, and then replace a standard socket heap with the
newly created one - thereby guaranteeing future allocations from the
external memory.
Signed-off-by: Bruce Richardson
---
lib/eal/common/malloc_heap.c | 24
lib/eal/include/rte_malloc.h | 34 ++
lib/eal/version.map | 2 ++
3 files changed, 60 insertions(+)
diff --git a/lib/eal/common/malloc_heap.c b/lib/eal/common/malloc_heap.c
index 4fa38fcd44..eba75111ca 100644
--- a/lib/eal/common/malloc_heap.c
+++ b/lib/eal/common/malloc_heap.c
@@ -1320,6 +1320,30 @@ malloc_heap_add_external_memory(struct malloc_heap *heap,
return 0;
}
+int
+rte_malloc_heap_swap_socket(int socket1, int socket2)
+{
+ const int h1 = malloc_socket_to_heap_id(socket1);
+ if (h1 < 0 || h1 > RTE_MAX_HEAPS)
+ return -1;
+
+ const int h2 = malloc_socket_to_heap_id(socket2);
+ if (h2 < 0 || h2 > RTE_MAX_HEAPS)
+ return -1;
+
+
+ rte_mcfg_mem_write_lock();
+ do {
+ struct rte_mem_config *mcfg =
rte_eal_get_configuration()->mem_config;
+ int tmp = mcfg->malloc_heaps[h1].socket_id;
+ mcfg->malloc_heaps[h1].socket_id =
mcfg->malloc_heaps[h2].socket_id;
+ mcfg->malloc_heaps[h2].socket_id = tmp;
+ } while (0);
+ rte_mcfg_mem_write_unlock();
+
+ return 0;
+}
+
int
malloc_heap_remove_external_memory(struct malloc_heap *heap, void *va_addr,
size_t len)
diff --git a/lib/eal/include/rte_malloc.h b/lib/eal/include/rte_malloc.h
index 54a8ac211e..df356a5efe 100644
--- a/lib/eal/include/rte_malloc.h
+++ b/lib/eal/include/rte_malloc.h
@@ -490,6 +490,40 @@ rte_malloc_heap_get_socket(const char *name);
int
rte_malloc_heap_socket_is_external(int socket_id);
+/**
+ * Swap the heaps for the given socket ids
+ *
+ * This causes the heaps for the given socket ids to be swapped, allowing
+ * external memory registered as a malloc heap to become the new default memory
+ * for a standard numa node. For example, to have allocations on socket 0 come
+ * from external memory, the following sequence of API calls can be used:
+ * @code
+ * rte_malloc_heap_create()
+ * rte_malloc_heap_memory_add(,)
+ * id = rte_malloc_heap_get_socket()
+ * rte_malloc_heap_swap_socket(0, id)
+ * @endcode
+ *
+ * Following these calls, allocations for the old memory allocated on socket 0,
+ * can be made by passing "id" as the socket_id parameter.
+ *
+ * @note: It is recommended that this function be used only after EAL
initialization,
+ * before any temporary objects are created from the DPDK heaps.
+ * @note: Since any objects allocated using rte_malloc and similar functions,
track
+ * the heaps via pointers, any already-allocated objects will be returned to
their
+ * original heaps, even after a call to this function.
+ *
+ * @param socket1
+ * The socket id of the first heap to swap
+ * @param socket2
+ * The socket id of the second heap to swap
+ * @return
+ * 0 on success, -1 on error
+ */
+__rte_experimental
+int
+rte_malloc_heap_swap_socket(int socket1, int socket2);
+
/**
* Dump statistics.
*
diff --git a/lib/eal/version.map b/lib/eal/version.map
index 7940431e5a..b06ee7219e 100644
--- a/lib/eal/version.map
+++ b/lib/eal/version.map
@@ -417,6 +417,8 @@ EXPERIMENTAL {
# added in 23.07
rte_memzone_max_get;
rte_memzone_max_set;
+
+ rte_malloc_heap_swap_socket;
};
INTERNAL {
--
2.39.2
[PATCH v3 1/2] eal: add flag to indicate non-EAL malloc heaps
Rather than relying implicitly on the socket_id value to identify
external heaps vs internal ones that can be expanded on demand by adding
more hugepages, we add an "is_external" flag to the heap structure. As
we do so, we change the heap initialization to use designated
initializers to guarantee as we add new fields that they are properly
zeroed on init. As it stands, many fields are not explicitly set on
first init of the internal malloc heaps.
Signed-off-by: Bruce Richardson
---
lib/eal/common/malloc_heap.c | 22 --
lib/eal/common/malloc_heap.h | 1 +
lib/eal/common/malloc_mp.c | 5 ++---
lib/eal/common/rte_malloc.c | 14 --
4 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/lib/eal/common/malloc_heap.c b/lib/eal/common/malloc_heap.c
index 6b6cf9174c..4fa38fcd44 100644
--- a/lib/eal/common/malloc_heap.c
+++ b/lib/eal/common/malloc_heap.c
@@ -668,7 +668,7 @@ malloc_heap_alloc_on_heap_id(const char *type, size_t size,
* we just need to request more memory first.
*/
- socket_id = rte_socket_id_by_idx(heap_id);
+ socket_id = heap->is_external ? -1 : rte_socket_id_by_idx(heap_id);
/*
* if socket ID is negative, we cannot find a socket ID for this heap -
* which means it's an external heap. those can have unexpected page
@@ -1362,19 +1362,17 @@ malloc_heap_create(struct malloc_heap *heap, const char
*heap_name)
}
/* initialize empty heap */
- heap->alloc_count = 0;
- heap->first = NULL;
- heap->last = NULL;
+ *heap = (struct malloc_heap) {
+ .is_external = 1,
+ .socket_id = next_socket_id,
+ .lock = RTE_SPINLOCK_INITIALIZER,
+ };
LIST_INIT(heap->free_head);
- rte_spinlock_init(&heap->lock);
- heap->total_size = 0;
- heap->socket_id = next_socket_id;
+ strlcpy(heap->name, heap_name, RTE_HEAP_NAME_MAX_LEN);
/* we hold a global mem hotplug writelock, so it's safe to increment */
mcfg->next_socket_id++;
- /* set up name */
- strlcpy(heap->name, heap_name, RTE_HEAP_NAME_MAX_LEN);
return 0;
}
@@ -1425,8 +1423,12 @@ rte_eal_malloc_heap_init(void)
snprintf(heap_name, sizeof(heap_name),
"socket_%i", socket_id);
+
+ *heap = (struct malloc_heap){
+ .lock = RTE_SPINLOCK_INITIALIZER,
+ .socket_id = socket_id,
+ };
strlcpy(heap->name, heap_name, RTE_HEAP_NAME_MAX_LEN);
- heap->socket_id = socket_id;
}
}
diff --git a/lib/eal/common/malloc_heap.h b/lib/eal/common/malloc_heap.h
index 8f3ab57154..e23cc01fb3 100644
--- a/lib/eal/common/malloc_heap.h
+++ b/lib/eal/common/malloc_heap.h
@@ -23,6 +23,7 @@ struct malloc_elem;
*/
struct malloc_heap {
rte_spinlock_t lock;
+ uint32_t is_external:1;
LIST_HEAD(, malloc_elem) free_head[RTE_HEAP_NUM_FREELISTS];
struct malloc_elem *volatile first;
struct malloc_elem *volatile last;
diff --git a/lib/eal/common/malloc_mp.c b/lib/eal/common/malloc_mp.c
index 7270c2ec90..d5ab6d8351 100644
--- a/lib/eal/common/malloc_mp.c
+++ b/lib/eal/common/malloc_mp.c
@@ -242,10 +242,9 @@ handle_alloc_request(const struct malloc_mp_req *m,
/*
* for allocations, we must only use internal heaps, but since the
* rte_malloc_heap_socket_is_external() is thread-safe and we're already
-* read-locked, we'll have to take advantage of the fact that internal
-* socket ID's are always lower than RTE_MAX_NUMA_NODES.
+* read-locked, we'll check directly here.
*/
- if (heap->socket_id >= RTE_MAX_NUMA_NODES) {
+ if (heap->is_external == 1) {
RTE_LOG(ERR, EAL, "Attempting to allocate from external
heap\n");
return -1;
}
diff --git a/lib/eal/common/rte_malloc.c b/lib/eal/common/rte_malloc.c
index ebafef3f6c..5f40acabee 100644
--- a/lib/eal/common/rte_malloc.c
+++ b/lib/eal/common/rte_malloc.c
@@ -314,7 +314,7 @@ rte_malloc_heap_socket_is_external(int socket_id)
if ((int)tmp->socket_id == socket_id) {
/* external memory always has large socket ID's */
- ret = tmp->socket_id >= RTE_MAX_NUMA_NODES;
+ ret = tmp->is_external;
break;
}
}
@@ -421,7 +421,7 @@ rte_malloc_heap_memory_add(const char *heap_name, void
*va_addr, size_t len,
ret = -1;
goto unlock;
}
- if (heap->socket_id < RTE_MAX_NUMA_NODES) {
+ if (heap->is_external == 0) {
/* cannot add memory to internal heaps */
rte_errno = EPERM;
ret = -1;
@@ -469,7 +469,7 @@ rte_malloc_heap_mem
Re: [PATCH v3 0/2] Enable apps to use external memory as native
On Mon, 18 Sep 2023 17:32:04 +0100 Bruce Richardson wrote: > Sometimes apps (or perhaps DPDK driver components) may want to allow > use of "external" i.e. non EAL allocated, memory as though it were > standard DPDK memory. This patchset provides the ability to do this, > by: firstly, adding an explicit flag to indicate non-EAL memory, > rather than relying on the socket_id implicitly, and then secondly, > allowing heaps to be swapped, so an external heap can be used as the > default heap for socket 0 or 1, etc. > > V3: > * Expand to 2 patch set, adding patch to tag external memory > explicitly, before adding the swap function > * Add locks to improve thread safety of the swap opperation. > * Add additional notes to function to clarify usage. > > V2: > * Fix doxygen comment issue on doc builds > > Bruce Richardson (2): > eal: add flag to indicate non-EAL malloc heaps > eal: allow swapping of malloc heaps > > lib/eal/common/malloc_heap.c | 46 > lib/eal/common/malloc_heap.h | 1 + > lib/eal/common/malloc_mp.c | 5 ++-- > lib/eal/common/rte_malloc.c | 14 ++- > lib/eal/include/rte_malloc.h | 34 ++ > lib/eal/version.map | 2 ++ > 6 files changed, 83 insertions(+), 19 deletions(-) > > -- > 2.39.2 > Series-Acked-by: Stephen Hemminger
Re: [PATCH 00/36] fix Rx and Tx queue state
On 9/8/2023 12:50 PM, David Marchand wrote:
> On Fri, Sep 8, 2023 at 1:32 PM Jie Hai wrote:
>>
>> The DPDK framework reports the queue state, which is stored in
>> dev->data->tx_queue_state and dev->data->rx_queue_state. The
>> state is maintained by the driver. Users may determine whether
>> a queue participates in packet forwarding based on the state,
>> for example,
>
> The driver is maintaining this state in dev_start / dev_stop and per
> queue start/stop handlers.
>
>>
>> [1] 5028f207a4fa ("app/testpmd: fix secondary process packet forwarding"
>> [2] 141a520b35f7 ("app/testpmd: fix primary process not polling all queues")
>>
>> Therefore, the drivers need to modify the queue state in time
>> according to the actual situation, especially when dev_start
>> and dev_stop are called. see [3] for more information.
>>
>> [3] https://inbox.dpdk.org/dev/20230721160422.3848154-1-ferruh.yi...@amd.com/
>>
>> This patchset also resubmit the patch [2] and makes some fixes on the patch.
>
> I just had a quick look at some patches and I wonder if a better fix
> would be at the ethdev level, rather than fixing all drivers.
>
>
I came here to make the same comment,
Jie, I forgot if we discuss this already but,
does it work if we update queue state in 'rte_eth_dev_start()' &
'rte_eth_dev_stop()' when 'dev_start' & 'dev_stop' dev_ops succeeds?
This solves the case driver forgets to update the queue state.
Re: [PATCH v2 1/1] net/mana: enable 32 bit build for mana driver
On 9/13/2023 1:23 PM, Wei Hu wrote: > Enable 32 bit build on x86 Linux. Fixed build warnings and errors > when building in 32 bit. > > Cc: sta...@dpdk.org > This is not a fix, but adding 32bit support to the driver, so not sure about backporting. cc'ed Kevin & Luca for guidance. I will drop the tag while merging unles otherwise suggested by LTS maintainers. > Signed-off-by: Wei Hu > Hi Wei, Patch looks good, but it basically fixes the format specifiers that will cause build error for 32 bit. Is there any other change required to make driver functional for 32 bit, or does it become functional with this change? And if it does can you please confirm explicityly that driver tested on 32 bit with this patch?
Re: [PATCH 1/1] net/mana: add 32 bit short doorbell
On 9/9/2023 1:23 PM, Wei Hu wrote: > Add 32 bit short doorbell support. Ring short doorbell when running > in 32 bit applicactions. > Hi Wei, Is this performance improvement for 32 bit, or is short doorbell support required for 32 bit support? This patch is using RTE_ARCH_32 compile time macro to enable short doorbell support, so need to decide to support 32 bit or 64 bit in compile time. Also I guess 32 bit driver can run on 64 bit arch, what will be the result in that case? My point is, instead of using compile time flag, what do you think to detect execution platform on runtime and use preferred doorbell according platform? I can see short descriptor support touches multiple functions, can the support be abstracted to let to use it based on runtime detection? > Cc: sta...@dpdk.org > Similar comment as previous patch, this patch is not a fix but adding new support, not sure about backporting it. > Signed-off-by: Wei Hu > <...> > @@ -97,6 +110,7 @@ mana_alloc_and_post_rx_wqe(struct mana_rxq *rxq) > /* update queue for tracking pending packets */ > desc->pkt = mbuf; > desc->wqe_size_in_bu = wqe_size_in_bu; > + rxq->wqe_cnt_to_short_db += wqe_size_in_bu; > This variable always used within RTE_ARCH_32 block, but set here without RTE_ARCH_32 ifdef, is this intentional?
RFC - handling kvargs options without value
There is a problem in current devargs/kvargs code for cases where the device argument expects a value but none is given. There are a several possible ways to address the problem and would like some feedback before finalizing a fix. Options: 0 - do nothing, if no option is given but device expects one then the driver will crash dereferencing NULL. Not best user experience but if argument is needed, any error handling only just going to print error anyway. 1 - fix all the drivers. There is a patch series in patchwork already that does most of this. Downside is that it is largish patchset and not sure if everything is covered and may break with new drivers. 2 - enforce that value must be present in kvargs. Change the places where driver is not expecting a value now, to instead take 1/0 as true/false. I.e in TUN driver persist flag, make it so persist is now: persist=1. Downside is that change is visible to application startup. 3 - variation of #2. Enforce in kvargs, but let driver make exception. Add special character to the keys for the case of presence option. I.e in TUN driver persist flag, set "persist:" and make : be indicator that no value is expected. Downside is that it is an API change, that may break applications using kvargs. But I doubt that any external apps would use this API anyway. 4. - add new richer api for parsing. Introduce rte_kvargs_getopt() which takes a structure with three value flag similar to getopt_long for required_argument, no_argument, optional_argument. Replace all usage of old API rte_kvargs_parse() , and deprecate it. This is the most complete change. But requires modifying lots places that call rte_kvargs_parse(). 5. - change rte_kvargs_parse() to take option structure and version the API. same as #4 but keep the same function name. Have a start on Option 4. But doing 3 seems easiest.
[Bug 1290] rte_exit will hang if called from worker or service thread
https://bugs.dpdk.org/show_bug.cgi?id=1290
Bug ID: 1290
Summary: rte_exit will hang if called from worker or service
thread
Product: DPDK
Version: 23.07
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: core
Assignee: dev@dpdk.org
Reporter: step...@networkplumber.org
Target Milestone: ---
Calling rte_exit in a thread other than main thread won't work because
the cleanup code is calling rte_eal_cleanup, and inside that it ends
up waiting for all workers. Since the thread you are calling from
is a worker, it ends up waiting for itself.
rte_exit()
rte_eal_cleanup()
rte_service_finalize()
rte_eal_mp_wait_lcore()
void
rte_eal_mp_wait_lcore(void)
{
unsigned lcore_id;
RTE_LCORE_FOREACH_WORKER(lcore_id) {
rte_eal_wait_lcore(lcore_id);
}
}
Either service handling needs to be smarter, the rte_exit() function
check if it is called from main lcore, and/or documentation needs update.
Not a simple fix because in order to safely do the cleanup logic
all threads have to gone to a quiescent state.
--
You are receiving this mail because:
You are the assignee for the bug.
Re: Process for adding a new driver?
18/09/2023 16:36, Honnappa Nagarahalli: > From: Morten Brørup > > > > The process for adding a new library to DPDK is well documented [1]. > > > > What is the process for adding a new (NIC) driver? > > > > It seems like the task of reviewing NIC PMDs from vendors other than > > Broadcom/Intel/Marvell/NVIDIA falls entirely on the next-net tree > > maintainers, Ferruh and Andrew, which doesn't seem like a reasonable > > burden. > > > > The Napatech driver is too large for Ferruh to review, which in my opinion > > [2] > > is an unreasonable argument for not accepting it. > > > > And the 3SNIC driver got no attention by any reviewers [3]. (Although > > Stephen did provide some basic feedback after they polled for review.) > > > > Overall, I think we should put much more trust in hardware vendors to > > provide high quality drivers for their hardware. We want vendors to upstream > > their drivers, with all the benefits of having the code public. If we make > > it too > > difficult, they will simply keep their drivers private instead. > > Difficulty vs quality control? IMO, it is good to add more drivers. May be we > need to control quality through testing reports? There are different kind of quality aspects. Functional testing is one quality criteria. Grouping code in something understandable with clear explanations is another one. Being consistent with the rest of the codebase (design or code style) may be other quality criteria. The difficult exercise is to ask the right level of investment from the vendor. Don't forget that adding a driver is a win-win situation.
RE: [PATCH 1/1] net/mana: add 32 bit short doorbell
> Subject: [PATCH 1/1] net/mana: add 32 bit short doorbell
>
> Add 32 bit short doorbell support. Ring short doorbell when running in 32 bit
> applicactions.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Hu
> ---
> drivers/net/mana/gdma.c | 95
> +
> drivers/net/mana/mana.h | 25 +++
> drivers/net/mana/rx.c | 52 ++
> drivers/net/mana/tx.c | 28
> 4 files changed, 200 insertions(+)
>
> diff --git a/drivers/net/mana/gdma.c b/drivers/net/mana/gdma.c index
> 65685fe236..d1da025d1b 100644
> --- a/drivers/net/mana/gdma.c
> +++ b/drivers/net/mana/gdma.c
> @@ -166,6 +166,97 @@ gdma_post_work_request(struct
> mana_gdma_queue *queue,
> return 0;
> }
>
> +#ifdef RTE_ARCH_32
> +union gdma_short_doorbell_entry {
> + uint32_t as_uint32;
> +
> + struct {
> + uint32_t tail_ptr_incr : 16; /* Number of CQEs */
> + uint32_t id : 12;
> + uint32_t reserved : 3;
> + uint32_t arm: 1;
> + } cq;
> +
> + struct {
> + uint32_t tail_ptr_incr : 16; /* In number of bytes */
> + uint32_t id : 12;
> + uint32_t reserved : 4;
> + } rq;
> +
> + struct {
> + uint32_t tail_ptr_incr : 16; /* In number of bytes */
> + uint32_t id : 12;
> + uint32_t reserved : 4;
> + } sq;
> +
> + struct {
> + uint32_t tail_ptr_incr : 16; /* Number of EQEs */
> + uint32_t id : 12;
> + uint32_t reserved : 3;
> + uint32_t arm: 1;
> + } eq;
> +}; /* HW DATA */
> +
> +enum {
> + DOORBELL_SHORT_OFFSET_SQ = 0x10,
> + DOORBELL_SHORT_OFFSET_RQ = 0x410,
> + DOORBELL_SHORT_OFFSET_CQ = 0x810,
> + DOORBELL_SHORT_OFFSET_EQ = 0xFF0,
> +};
> +
> +/*
> + * Write to hardware doorbell to notify new activity.
> + */
> +int
> +mana_ring_short_doorbell(void *db_page, enum gdma_queue_types
> queue_type,
> + uint32_t queue_id, uint32_t tail_incr, uint8_t arm) {
> + uint8_t *addr = db_page;
> + union gdma_short_doorbell_entry e = {};
> +
> + if ((queue_id & ~GDMA_SHORT_DB_QID_MASK) ||
> + (tail_incr & ~GDMA_SHORT_DB_INC_MASK)) {
> + DP_LOG(ERR, "%s: queue_id %u or "
> +"tail_incr %u overflowed, queue type %d",
> +__func__, queue_id, tail_incr, queue_type);
> + return -EINVAL;
> + }
> +
> + switch (queue_type) {
> + case GDMA_QUEUE_SEND:
> + e.sq.id = queue_id;
> + e.sq.tail_ptr_incr = tail_incr;
> + addr += DOORBELL_SHORT_OFFSET_SQ;
> + break;
> +
> + case GDMA_QUEUE_RECEIVE:
> + e.rq.id = queue_id;
> + e.rq.tail_ptr_incr = tail_incr;
> + addr += DOORBELL_SHORT_OFFSET_RQ;
> + break;
> +
> + case GDMA_QUEUE_COMPLETION:
> + e.cq.id = queue_id;
> + e.cq.tail_ptr_incr = tail_incr;
> + e.cq.arm = arm;
> + addr += DOORBELL_SHORT_OFFSET_CQ;
> + break;
> +
> + default:
> + DP_LOG(ERR, "Unsupported queue type %d", queue_type);
> + return -1;
> + }
> +
> + /* Ensure all writes are done before ringing doorbell */
> + rte_wmb();
> +
> + DP_LOG(DEBUG, "db_page %p addr %p queue_id %u type %u tail %u
> arm %u",
> +db_page, addr, queue_id, queue_type, tail_incr, arm);
> +
> + rte_write32(e.as_uint32, addr);
> + return 0;
> +}
> +#else
> union gdma_doorbell_entry {
> uint64_t as_uint64;
>
> @@ -248,6 +339,7 @@ mana_ring_doorbell(void *db_page, enum
> gdma_queue_types queue_type,
> rte_write64(e.as_uint64, addr);
> return 0;
> }
> +#endif
>
> /*
> * Poll completion queue for completions.
> @@ -287,6 +379,9 @@ gdma_poll_completion_queue(struct
> mana_gdma_queue *cq,
> num_comp++;
>
> cq->head++;
> +#ifdef RTE_ARCH_32
> + cq->head_incr_to_short_db++;
> +#endif
>
> DP_LOG(DEBUG, "comp new 0x%x old 0x%x cqe 0x%x wq %u
> sq %u head %u",
> new_owner_bits, old_owner_bits, cqe_owner_bits, diff --
> git a/drivers/net/mana/mana.h b/drivers/net/mana/mana.h index
> 5801491d75..848d87c096 100644
> --- a/drivers/net/mana/mana.h
> +++ b/drivers/net/mana/mana.h
> @@ -50,6 +50,19 @@ struct mana_shared_data { #define
> MAX_TX_WQE_SIZE 512 #define MAX_RX_WQE_SIZE 256
>
> +/* For 32 bit only */
> +#ifdef RTE_ARCH_32
> +#define GDMA_SHORT_DB_INC_MASK 0x
> +#define GDMA_SHORT_DB_QID_MASK 0xfff
> +
> +#define GDMA_SHORT_DB_MAX_WQE(0x1 /
> GDMA_WQE_ALIGNMENT_UNIT_SIZE)
> +
> +#define TX_WQE_SHORT_DB_THRESHOLD \
> + (GDMA_SHORT_DB_MAX_WQE - (2 * MAX_TX_WQE_SIZE)) #define
> +RX_WQE_SHORT_DB_THRESHOLD \
GDMA_SHORT_DB_MAX_WQE is in BU, MA
Technical board meeting agenda for 2023-09-20
Dear DPDK community, Following topics are planned to be discussed at the next Technical board meeting, which will take place on Sept. 20th @3PM UTC: 1- Memarea library inclusion 2- Power management brainstorming 3- Bugzilla maintenance: request for volunteers 4- Process to add new drivers The order the topics will be discussed may change based on their priority/urgency. Some topics might have to be postponed to the following meeting if time does not allow to cover them. If time permits, below recurring items will be checked: - Security process - Community Lab - Doc maintenance - Bugzilla status - Examples to drop or move
RE: [PATCH v2 2/5] bbdev: add new capabilities for FFT processing
Thanks Maxime.
> -Original Message-
> From: Maxime Coquelin
> Sent: Monday, September 18, 2023 8:43 AM
> To: Chautru, Nicolas ; dev@dpdk.org
> Cc: Rix, Tom ; hemant.agra...@nxp.com;
> david.march...@redhat.com; Vargas, Hernan
> Subject: Re: [PATCH v2 2/5] bbdev: add new capabilities for FFT processing
>
>
>
> On 9/18/23 17:08, Maxime Coquelin wrote:
> >
> >
> > On 6/15/23 18:48, Nicolas Chautru wrote:
> >> Extending existing FFT operation for new capabilities.
> >> Optional frequency domain dewindowing, frequency resampling, timing
> >> error correction and time offset per CS.
> >>
> >> Signed-off-by: Nicolas Chautru
> >> ---
> >> doc/guides/prog_guide/bbdev.rst | 24
> >> lib/bbdev/rte_bbdev_op.h | 23 ++-
> >> 2 files changed, 46 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/doc/guides/prog_guide/bbdev.rst
> >> b/doc/guides/prog_guide/bbdev.rst index 8e384015ee..95b33562fe
> 100644
> >> --- a/doc/guides/prog_guide/bbdev.rst
> >> +++ b/doc/guides/prog_guide/bbdev.rst
> >> @@ -,6 +,18 @@ with the operation flags forming a bitmask in
> >> the ``op_flags`` field.
> >> |RTE_BBDEV_FFT_FP16_OUTPUT
> >> |
> >> | Set if the output data shall use FP16 format instead of INT16
> >> |
> >>
> >> +
> >> +
> >> +|RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS
> >> +|| Set if device supports adjusting time offset per CS
> >> +||
> >> +++
> >> +|RTE_BBDEV_FFT_TIMING_ERROR
> >> +|| Set if device supports correcting for timing error
> >> +||
> >> +++
> >> +|RTE_BBDEV_FFT_DEWINDOWING
> >> +|| Set if enabling the option FFT Dewindowing in Frequency domain
> >> +||
> >> +++
> >> +|RTE_BBDEV_FFT_FREQ_RESAMPLING
> >> +|| Set if device supports the optional frequency resampling
> >> +||
> >> +++
> >> The FFT parameters are set out in the table below.
> >> @@ -1121,6 +1133,8 @@ The FFT parameters are set out in the table
> below.
> >>
> >> +-+--+
> >> |base_output |output
> >> data |
> >>
> >> +-+--+
> >> +|dewindowing_input |optional frequency domain dewindowing
> >> input data |
> >> ++-+--+
> >> |power_meas_output |optional output data with power
> >> measurement on DFT output |
> >>
> >> +-+--+
> >> |op_flags |bitmask of all active operation
> >> capabilities | @@ -1155,6 +1169,16 @@ The FFT
> >> parameters are set out in the table below.
> >>
> >> +-+--+
> >> |fp16_exp_adjust |value added to FP16 exponent at
> >> conversion from INT16 |
> >>
> >> +-+--+
> >> +|freq_resample_mode |frequency ressampling mode
> >> +|(0:transparent,
> >> 1-2: resample) |
> >> ++-+--+
> >> +| output_depadded_size |output depadded size prior to frequency
> >> resampling |
> >> ++-+--+
> >> +|cs_theta_0 |timing error correction initial
> >> phase |
> >> ++-+--+
> >> +|cs_theta_d |timing error correction phase
> >> increment |
> >> ++-+--+
> >> +|time_offset |time offset per CS of time domain
> >> samples |
> >> ++-+--+
> >> The mbuf input ``base_input`` is mandatory for all bbdev PMDs and
> >> is the incoming data for the processing. Its size may not fit into
> >> an actual mbuf, diff --git a/lib/bbdev/rte_bbdev_op.h
> >> b/lib/bbdev/rte_bbdev_op.h index 990d110fa7..682e265327 100644
> >> --- a/lib/bbdev/rte_bbdev_op.h
> >> +++ b/lib/bbdev/rte_bbdev_op.h
> >> @@ -50,6 +50,7 @@ extern "C" {
> >> #define RTE_BBDEV_LDPC_MAX_CODE_BLOCKS (256)
> >> /* 12 CS maximum */
> >> #define RTE_BBDEV_MAX_CS_2 (6)
> >> +#define RTE_BBDEV_MAX_CS (12)
> >>
[PATCH v1 0/7] VRB2 BBDEV PMD introduction
This serie includes includes changes to the VRB BBDEV PMD for 23.11. This relies on the previous serie that Maxime is about to apply (https://patches.dpdk.org/project/dpdk/list/?series=28544). I did not include documentationa just yet but I will in next revision. This allows the VRB unified driver to support the new VRB2 implementation variant on GNR-D. This also include minor change to the dev_info to expose FFT version flexibility to expose information to the application on what is configured dynamically on the device. Nicolas Chautru (7): bbdev: add FFT version member in driver info baseband/acc: add FFT version in the VRM PMD baseband/acc: remove the 4G SO capability for VRB1 baseband/acc: allocate FCW memory separately baseband/acc: add support for MLD operation baseband/acc: introduce the new VRB2 variant baseband/acc: add configure helper for VRB2 drivers/baseband/acc/acc100_pmd.h |2 + drivers/baseband/acc/acc_common.h | 97 +- drivers/baseband/acc/rte_acc100_pmd.c | 10 +- drivers/baseband/acc/rte_vrb_pmd.c| 1967 ++--- drivers/baseband/acc/vrb1_pf_enum.h | 17 +- drivers/baseband/acc/vrb2_pf_enum.h | 124 ++ drivers/baseband/acc/vrb2_vf_enum.h | 121 ++ drivers/baseband/acc/vrb_cfg.h| 16 + drivers/baseband/acc/vrb_pmd.h| 173 ++- lib/bbdev/rte_bbdev.h |2 + 10 files changed, 2297 insertions(+), 232 deletions(-) create mode 100644 drivers/baseband/acc/vrb2_pf_enum.h create mode 100644 drivers/baseband/acc/vrb2_vf_enum.h -- 2.34.1
[PATCH v1 1/7] bbdev: add FFT version member in driver info
This can be used to distinguish different version of the
flexible pointwise windowing applied to the FFT and expose
this to the application.
Signed-off-by: Nicolas Chautru
---
lib/bbdev/rte_bbdev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index a5bcc09f10..d6e54ee9a4 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -349,6 +349,8 @@ struct rte_bbdev_driver_info {
const struct rte_bbdev_op_cap *capabilities;
/** Device cpu_flag requirements */
const enum rte_cpu_flag_t *cpu_flag_reqs;
+ /** Versioning number for the FFT operation type. */
+ uint16_t fft_version;
};
/** Macro used at end of bbdev PMD list */
--
2.34.1
[PATCH v1 2/7] baseband/acc: add FFT version in the VRM PMD
This allows to exposes the flexible version of the poitwise
flexible operation being dynamically configured on the device.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc/acc_common.h | 1 +
drivers/baseband/acc/rte_vrb_pmd.c | 22 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/baseband/acc/acc_common.h
b/drivers/baseband/acc/acc_common.h
index 5bb00746c3..df18506e75 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -512,6 +512,7 @@ struct acc_deq_intr_details {
enum {
ACC_VF2PF_STATUS_REQUEST = 1,
ACC_VF2PF_USING_VF = 2,
+ ACC_VF2PF_LUT_VER_REQUEST = 3,
};
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index 9e5a73c9c7..3c8f3409ed 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -298,6 +298,27 @@ vrb_device_status(struct rte_bbdev *dev)
return reg;
}
+/* Request device FFT related version information. */
+static inline uint32_t
+vrb_device_fft_ver(struct rte_bbdev *dev)
+{
+ struct acc_device *d = dev->data->dev_private;
+ uint32_t reg, time_out = 0;
+
+ if (d->pf_device)
+ return 0;
+
+ vrb_vf2pf(d, ACC_VF2PF_LUT_VER_REQUEST);
+ reg = acc_reg_read(d, d->reg_addr->pf2vf_doorbell);
+ while ((time_out < ACC_STATUS_TO) && (reg == RTE_BBDEV_DEV_NOSTATUS)) {
+ usleep(ACC_STATUS_WAIT); /*< Wait or VF->PF->VF Comms */
+ reg = acc_reg_read(d, d->reg_addr->pf2vf_doorbell);
+ time_out++;
+ }
+
+ return reg;
+}
+
/* Checks PF Info Ring to find the interrupt cause and handles it accordingly.
*/
static inline void
vrb_check_ir(struct acc_device *acc_dev)
@@ -1100,6 +1121,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct
rte_bbdev_driver_info *dev_info)
fetch_acc_config(dev);
/* Check the status of device. */
dev_info->device_status = vrb_device_status(dev);
+ dev_info->fft_version = vrb_device_fft_ver(dev);
/* Exposed number of queues. */
dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
--
2.34.1
[PATCH v1 3/7] baseband/acc: remove the 4G SO capability for VRB1
This removes the specific capability and support of LTE Decoder Soft Output option on the VRB1 PMD. Signed-off-by: Nicolas Chautru --- drivers/baseband/acc/rte_vrb_pmd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/baseband/acc/rte_vrb_pmd.c b/drivers/baseband/acc/rte_vrb_pmd.c index 3c8f3409ed..e0f50460bd 100644 --- a/drivers/baseband/acc/rte_vrb_pmd.c +++ b/drivers/baseband/acc/rte_vrb_pmd.c @@ -1019,14 +1019,11 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info) RTE_BBDEV_TURBO_CRC_TYPE_24B | RTE_BBDEV_TURBO_DEC_CRC_24B_DROP | RTE_BBDEV_TURBO_EQUALIZER | - RTE_BBDEV_TURBO_SOFT_OUT_SATURATE | RTE_BBDEV_TURBO_HALF_ITERATION_EVEN | RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH | - RTE_BBDEV_TURBO_SOFT_OUTPUT | RTE_BBDEV_TURBO_EARLY_TERMINATION | RTE_BBDEV_TURBO_DEC_INTERRUPTS | RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN | - RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT | RTE_BBDEV_TURBO_MAP_DEC | RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP | RTE_BBDEV_TURBO_DEC_SCATTER_GATHER, @@ -1975,6 +1972,9 @@ enqueue_dec_one_op_cb(struct acc_queue *q, struct rte_bbdev_dec_op *op, struct rte_mbuf *input, *h_output_head, *h_output, *s_output_head, *s_output; + /* Disable explictly SO for VRB 1. */ + op->turbo_dec.op_flags &= ~RTE_BBDEV_TURBO_SOFT_OUTPUT; + desc = acc_desc(q, total_enqueued_cbs); vrb_fcw_td_fill(op, &desc->req.fcw_td); -- 2.34.1
[PATCH v1 4/7] baseband/acc: allocate FCW memory separately
This allows more flexibility to the FCW size for the
unified driver. No actual functional change.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc/acc_common.h | 4 +++-
drivers/baseband/acc/rte_vrb_pmd.c | 25 -
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/baseband/acc/acc_common.h
b/drivers/baseband/acc/acc_common.h
index df18506e75..b5ee113faf 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -101,6 +101,7 @@
#define ACC_NUM_QGRPS_PER_WORD 8
#define ACC_MAX_NUM_QGRPS 32
#define ACC_RING_SIZE_GRANULARITY 64
+#define ACC_MAX_FCW_SIZE 128
/* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */
#define ACC_N_ZC_1 66 /* N = 66 Zc for BG 1 */
@@ -582,13 +583,14 @@ struct __rte_cache_aligned acc_queue {
uint32_t aq_enqueued; /* Count how many "batches" have been enqueued */
uint32_t aq_dequeued; /* Count how many "batches" have been dequeued */
uint32_t irq_enable; /* Enable ops dequeue interrupts if set to 1 */
- struct rte_mempool *fcw_mempool; /* FCW mempool */
enum rte_bbdev_op_type op_type; /* Type of this Queue: TE or TD */
/* Internal Buffers for loopback input */
uint8_t *lb_in;
uint8_t *lb_out;
+ uint8_t *fcw_ring;
rte_iova_t lb_in_addr_iova;
rte_iova_t lb_out_addr_iova;
+ rte_iova_t fcw_ring_addr_iova;
int8_t *derm_buffer; /* interim buffer for de-rm in SDK */
struct acc_device *d;
};
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index e0f50460bd..78f465b25b 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -883,6 +883,25 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
goto free_companion_ring_addr;
}
+ q->fcw_ring = rte_zmalloc_socket(dev->device->driver->name,
+ ACC_MAX_FCW_SIZE * d->sw_ring_max_depth,
+ RTE_CACHE_LINE_SIZE, conf->socket);
+ if (q->fcw_ring == NULL) {
+ rte_bbdev_log(ERR, "Failed to allocate fcw_ring memory");
+ ret = -ENOMEM;
+ goto free_companion_ring_addr;
+ }
+ q->fcw_ring_addr_iova = rte_malloc_virt2iova(q->fcw_ring);
+
+ /* For FFT we need to store the FCW separately */
+ if (conf->op_type == RTE_BBDEV_OP_FFT) {
+ for (desc_idx = 0; desc_idx < d->sw_ring_max_depth; desc_idx++)
{
+ desc = q->ring_addr + desc_idx;
+ desc->req.data_ptrs[0].address = q->fcw_ring_addr_iova +
+ desc_idx * ACC_MAX_FCW_SIZE;
+ }
+ }
+
q->qgrp_id = (q_idx >> VRB1_GRP_ID_SHIFT) & 0xF;
q->vf_id = (q_idx >> VRB1_VF_ID_SHIFT) & 0x3F;
q->aq_id = q_idx & 0xF;
@@ -994,6 +1013,7 @@ vrb_queue_release(struct rte_bbdev *dev, uint16_t q_id)
if (q != NULL) {
/* Mark the Queue as un-assigned. */
d->q_assigned_bit_map[q->qgrp_id] &= (~0ULL - (1 << (uint64_t)
q->aq_id));
+ rte_free(q->fcw_ring);
rte_free(q->companion_ring_addr);
rte_free(q->lb_in);
rte_free(q->lb_out);
@@ -3225,7 +3245,10 @@ vrb_enqueue_fft_one_op(struct acc_queue *q, struct
rte_bbdev_fft_op *op,
output = op->fft.base_output.data;
in_offset = op->fft.base_input.offset;
out_offset = op->fft.base_output.offset;
- fcw = &desc->req.fcw_fft;
+
+ fcw = (struct acc_fcw_fft *) (q->fcw_ring +
+ ((q->sw_ring_head + total_enqueued_cbs) &
q->sw_ring_wrap_mask)
+ * ACC_MAX_FCW_SIZE);
vrb1_fcw_fft_fill(op, fcw);
vrb1_dma_desc_fft_fill(op, &desc->req, input, output, &in_offset,
&out_offset);
--
2.34.1
[PATCH v1 5/7] baseband/acc: add support for MLD operation
There is no functionality related to the MLD operation
but allows the unified PMD to support the operation
being added moving forward.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc/acc_common.h | 1 +
drivers/baseband/acc/rte_vrb_pmd.c | 39 --
drivers/baseband/acc/vrb_pmd.h | 12 +
3 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/baseband/acc/acc_common.h
b/drivers/baseband/acc/acc_common.h
index b5ee113faf..5de58dbe36 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -87,6 +87,7 @@
#define ACC_FCW_LE_BLEN32
#define ACC_FCW_LD_BLEN36
#define ACC_FCW_FFT_BLEN 28
+#define ACC_FCW_MLDTS_BLEN 32
#define ACC_5GUL_SIZE_016
#define ACC_5GUL_SIZE_140
#define ACC_5GUL_OFFSET_0 36
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index 78f465b25b..0a634d62f6 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -37,7 +37,7 @@ vrb1_queue_offset(bool pf_device, uint8_t vf_id, uint8_t
qgrp_id, uint16_t aq_id
return ((qgrp_id << 7) + (aq_id << 3) + VRB1_VfQmgrIngressAq);
}
-enum {UL_4G = 0, UL_5G, DL_4G, DL_5G, FFT, NUM_ACC};
+enum {UL_4G = 0, UL_5G, DL_4G, DL_5G, FFT, MLD, NUM_ACC};
/* Return the accelerator enum for a Queue Group Index. */
static inline int
@@ -53,6 +53,7 @@ accFromQgid(int qg_idx, const struct rte_acc_conf *acc_conf)
NumQGroupsPerFn[DL_4G] = acc_conf->q_dl_4g.num_qgroups;
NumQGroupsPerFn[DL_5G] = acc_conf->q_dl_5g.num_qgroups;
NumQGroupsPerFn[FFT] = acc_conf->q_fft.num_qgroups;
+ NumQGroupsPerFn[MLD] = acc_conf->q_mld.num_qgroups;
for (acc = UL_4G; acc < NUM_ACC; acc++)
for (qgIdx = 0; qgIdx < NumQGroupsPerFn[acc]; qgIdx++)
accQg[qgIndex++] = acc;
@@ -83,6 +84,9 @@ qtopFromAcc(struct rte_acc_queue_topology **qtop, int
acc_enum, struct rte_acc_c
case FFT:
p_qtop = &(acc_conf->q_fft);
break;
+ case MLD:
+ p_qtop = &(acc_conf->q_mld);
+ break;
default:
/* NOTREACHED. */
rte_bbdev_log(ERR, "Unexpected error evaluating %s using %d",
__func__, acc_enum);
@@ -139,6 +143,9 @@ initQTop(struct rte_acc_conf *acc_conf)
acc_conf->q_fft.num_aqs_per_groups = 0;
acc_conf->q_fft.num_qgroups = 0;
acc_conf->q_fft.first_qgroup_index = -1;
+ acc_conf->q_mld.num_aqs_per_groups = 0;
+ acc_conf->q_mld.num_qgroups = 0;
+ acc_conf->q_mld.first_qgroup_index = -1;
}
static inline void
@@ -250,7 +257,7 @@ fetch_acc_config(struct rte_bbdev *dev)
}
rte_bbdev_log_debug(
- "%s Config LLR SIGN IN/OUT %s %s QG %u %u %u %u %u AQ
%u %u %u %u %u Len %u %u %u %u %u\n",
+ "%s Config LLR SIGN IN/OUT %s %s QG %u %u %u %u %u %u
AQ %u %u %u %u %u %u Len %u %u %u %u %u %u\n",
(d->pf_device) ? "PF" : "VF",
(acc_conf->input_pos_llr_1_bit) ? "POS" : "NEG",
(acc_conf->output_pos_llr_1_bit) ? "POS" : "NEG",
@@ -259,16 +266,19 @@ fetch_acc_config(struct rte_bbdev *dev)
acc_conf->q_ul_5g.num_qgroups,
acc_conf->q_dl_5g.num_qgroups,
acc_conf->q_fft.num_qgroups,
+ acc_conf->q_mld.num_qgroups,
acc_conf->q_ul_4g.num_aqs_per_groups,
acc_conf->q_dl_4g.num_aqs_per_groups,
acc_conf->q_ul_5g.num_aqs_per_groups,
acc_conf->q_dl_5g.num_aqs_per_groups,
acc_conf->q_fft.num_aqs_per_groups,
+ acc_conf->q_mld.num_aqs_per_groups,
acc_conf->q_ul_4g.aq_depth_log2,
acc_conf->q_dl_4g.aq_depth_log2,
acc_conf->q_ul_5g.aq_depth_log2,
acc_conf->q_dl_5g.aq_depth_log2,
- acc_conf->q_fft.aq_depth_log2);
+ acc_conf->q_fft.aq_depth_log2,
+ acc_conf->q_mld.aq_depth_log2);
}
static inline void
@@ -332,7 +342,7 @@ vrb_check_ir(struct acc_device *acc_dev)
while (ring_data->valid) {
if ((ring_data->int_nb < ACC_PF_INT_DMA_DL_DESC_IRQ) || (
- ring_data->int_nb >
ACC_PF_INT_DMA_DL5G_DESC_IRQ)) {
+ ring_data->int_nb >
ACC_PF_INT_DMA_MLD_DESC_IRQ)) {
rte_bbdev_log(WARNING, "InfoRing: ITR:%d Info:0x%x",
ring_data->int_nb,
ring_data->detailed_info);
/* Initialize Info Ring entry and move forward. */
@@ -366,6 +376,7 @@ vrb_dev_interrup
[PATCH v1 7/7] baseband/acc: add configure helper for VRB2
This allows to configure the VRB2 device using a
companion configuration function within the DPDK
bbdev-test environment.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc/acc100_pmd.h | 2 +
drivers/baseband/acc/acc_common.h | 7 +
drivers/baseband/acc/rte_acc100_pmd.c | 6 +-
drivers/baseband/acc/rte_vrb_pmd.c| 322 ++
drivers/baseband/acc/vrb_cfg.h| 16 ++
5 files changed, 352 insertions(+), 1 deletion(-)
diff --git a/drivers/baseband/acc/acc100_pmd.h
b/drivers/baseband/acc/acc100_pmd.h
index a48298650c..5a8965fa53 100644
--- a/drivers/baseband/acc/acc100_pmd.h
+++ b/drivers/baseband/acc/acc100_pmd.h
@@ -34,6 +34,8 @@
#define ACC100_VENDOR_ID (0x8086)
#define ACC100_PF_DEVICE_ID(0x0d5c)
#define ACC100_VF_DEVICE_ID(0x0d5d)
+#define VRB1_PF_DEVICE_ID (0x57C0)
+#define VRB2_PF_DEVICE_ID (0x57C2)
/* Values used in writing to the registers */
#define ACC100_REG_IRQ_EN_ALL 0x1FF83FF /* Enable all interrupts */
diff --git a/drivers/baseband/acc/acc_common.h
b/drivers/baseband/acc/acc_common.h
index 56578c43ba..8c2f1db262 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -1480,6 +1480,13 @@ get_num_cbs_in_tb_ldpc_enc(struct rte_bbdev_op_ldpc_enc
*ldpc_enc)
return cbs_in_tb;
}
+static inline void
+acc_reg_fast_write(struct acc_device *d, uint32_t offset, uint32_t value)
+{
+ void *reg_addr = RTE_PTR_ADD(d->mmio_base, offset);
+ mmio_write(reg_addr, value);
+}
+
#ifdef RTE_LIBRTE_BBDEV_DEBUG
static inline void
acc_memdump(const char *string, void *buf, uint16_t bytes)
diff --git a/drivers/baseband/acc/rte_acc100_pmd.c
b/drivers/baseband/acc/rte_acc100_pmd.c
index 7f8d05b5a9..699a227d13 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -5187,6 +5187,10 @@ rte_acc_configure(const char *dev_name, struct
rte_acc_conf *conf)
return acc100_configure(dev_name, conf);
else if (pci_dev->id.device_id == ACC101_PF_DEVICE_ID)
return acc101_configure(dev_name, conf);
- else
+ else if (pci_dev->id.device_id == VRB1_PF_DEVICE_ID)
return vrb1_configure(dev_name, conf);
+ else if (pci_dev->id.device_id == VRB2_PF_DEVICE_ID)
+ return vrb2_configure(dev_name, conf);
+
+ return -ENXIO;
}
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c
b/drivers/baseband/acc/rte_vrb_pmd.c
index 36d2c8173d..76efc8faf1 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -5073,3 +5073,325 @@ vrb1_configure(const char *dev_name, struct
rte_acc_conf *conf)
rte_bbdev_log_debug("PF Tip configuration complete for %s", dev_name);
return 0;
}
+
+
+/* Initial configuration of a VRB2 device prior to running configure(). */
+int
+vrb2_configure(const char *dev_name, struct rte_acc_conf *conf)
+{
+ rte_bbdev_log(INFO, "vrb2_configure");
+ uint32_t value, address, status;
+ int qg_idx, template_idx, vf_idx, acc, i, aq_reg, static_allocation,
numEngines;
+ int numQgs, numQqsAcc, totalQgs;
+ int qman_func_id[8] = {0, 2, 1, 3, 4, 5, 0, 0};
+ struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
+ int rlim, alen, timestamp;
+
+ /* Compile time checks */
+ RTE_BUILD_BUG_ON(sizeof(struct acc_dma_req_desc) != 256);
+ RTE_BUILD_BUG_ON(sizeof(union acc_dma_desc) != 256);
+ RTE_BUILD_BUG_ON(sizeof(struct acc_fcw_td) != 24);
+ RTE_BUILD_BUG_ON(sizeof(struct acc_fcw_te) != 32);
+
+ if (bbdev == NULL) {
+ rte_bbdev_log(ERR,
+ "Invalid dev_name (%s), or device is not yet initialised",
+ dev_name);
+ return -ENODEV;
+ }
+ struct acc_device *d = bbdev->data->dev_private;
+
+ /* Store configuration */
+ rte_memcpy(&d->acc_conf, conf, sizeof(d->acc_conf));
+
+ /* Explicitly releasing AXI as this may be stopped after PF FLR/BME */
+ address = VRB2_PfDmaAxiControl;
+ value = 1;
+ acc_reg_write(d, address, value);
+
+ /* Set the fabric mode */
+ address = VRB2_PfFabricM2iBufferReg;
+ value = VRB2_FABRIC_MODE;
+ acc_reg_write(d, address, value);
+
+ /* Set default descriptor signature */
+ address = VRB2_PfDmaDescriptorSignature;
+ value = 0;
+ acc_reg_write(d, address, value);
+
+ /* Enable the Error Detection in DMA */
+ value = VRB2_CFG_DMA_ERROR;
+ address = VRB2_PfDmaErrorDetectionEn;
+ acc_reg_write(d, address, value);
+
+ /* AXI Cache configuration */
+ value = VRB2_CFG_AXI_CACHE;
+ address = VRB2_PfDmaAxcacheReg;
+ acc_reg_write(d, address, value);
+
+ /* AXI Response configuration */
+ acc_reg_write(d, VRB2_PfDmaCfgRrespBresp, 0x0);
+
+ /* Default DMA Configuration (Qmgr Enabled) */
+ a
[PATCH v1 6/7] baseband/acc: introduce the new VRB2 variant
This extends the unified driver to support both the
VRB1 and VRB2 implentation of Intel vRAN Boost.
Signed-off-by: Nicolas Chautru
---
drivers/baseband/acc/acc_common.h | 84 +-
drivers/baseband/acc/rte_acc100_pmd.c |4 +-
drivers/baseband/acc/rte_vrb_pmd.c| 1441 ++---
drivers/baseband/acc/vrb1_pf_enum.h | 17 +-
drivers/baseband/acc/vrb2_pf_enum.h | 124 +++
drivers/baseband/acc/vrb2_vf_enum.h | 121 +++
drivers/baseband/acc/vrb_pmd.h| 161 ++-
7 files changed, 1789 insertions(+), 163 deletions(-)
create mode 100644 drivers/baseband/acc/vrb2_pf_enum.h
create mode 100644 drivers/baseband/acc/vrb2_vf_enum.h
diff --git a/drivers/baseband/acc/acc_common.h
b/drivers/baseband/acc/acc_common.h
index 5de58dbe36..56578c43ba 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -18,6 +18,7 @@
#define ACC_DMA_BLKID_OUT_HARQ 3
#define ACC_DMA_BLKID_IN_HARQ 3
#define ACC_DMA_BLKID_IN_MLD_R 3
+#define ACC_DMA_BLKID_DEWIN_IN 3
/* Values used in filling in decode FCWs */
#define ACC_FCW_TD_VER 1
@@ -103,6 +104,9 @@
#define ACC_MAX_NUM_QGRPS 32
#define ACC_RING_SIZE_GRANULARITY 64
#define ACC_MAX_FCW_SIZE 128
+#define ACC_IQ_SIZE4
+
+#define ACC_FCW_FFT_BLEN_3 28
/* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */
#define ACC_N_ZC_1 66 /* N = 66 Zc for BG 1 */
@@ -132,6 +136,11 @@
#define ACC_LIM_21 14 /* 0.21 */
#define ACC_LIM_31 20 /* 0.31 */
#define ACC_MAX_E (128 * 1024 - 2)
+#define ACC_MAX_CS 12
+
+#define ACC100_VARIANT 0
+#define VRB1_VARIANT 2
+#define VRB2_VARIANT 3
/* Helper macro for logging */
#define rte_acc_log(level, fmt, ...) \
@@ -332,6 +341,37 @@ struct __rte_packed acc_fcw_fft {
res:19;
};
+/* FFT Frame Control Word */
+struct __rte_packed acc_fcw_fft_3 {
+ uint32_t in_frame_size:16,
+ leading_pad_size:16;
+ uint32_t out_frame_size:16,
+ leading_depad_size:16;
+ uint32_t cs_window_sel;
+ uint32_t cs_window_sel2:16,
+ cs_enable_bmap:16;
+ uint32_t num_antennas:8,
+ idft_size:8,
+ dft_size:8,
+ cs_offset:8;
+ uint32_t idft_shift:8,
+ dft_shift:8,
+ cs_multiplier:16;
+ uint32_t bypass:2,
+ fp16_in:1, /* Not supported in VRB1 */
+ fp16_out:1,
+ exp_adj:4,
+ power_shift:4,
+ power_en:1,
+ enable_dewin:1,
+ freq_resample_mode:2,
+ depad_ouput_size:16;
+ uint16_t cs_theta_0[ACC_MAX_CS];
+ uint32_t cs_theta_d[ACC_MAX_CS];
+ int8_t cs_time_offset[ACC_MAX_CS];
+};
+
+
/* MLD-TS Frame Control Word */
struct __rte_packed acc_fcw_mldts {
uint32_t fcw_version:4,
@@ -473,14 +513,14 @@ union acc_info_ring_data {
uint16_t valid: 1;
};
struct {
- uint32_t aq_id_3: 6;
- uint32_t qg_id_3: 5;
- uint32_t vf_id_3: 6;
- uint32_t int_nb_3: 6;
- uint32_t msi_0_3: 1;
- uint32_t vf2pf_3: 6;
- uint32_t loop_3: 1;
- uint32_t valid_3: 1;
+ uint32_t aq_id_vrb2: 6;
+ uint32_t qg_id_vrb2: 5;
+ uint32_t vf_id_vrb2: 6;
+ uint32_t int_nb_vrb2: 6;
+ uint32_t msi_0_vrb2: 1;
+ uint32_t vf2pf_vrb2: 6;
+ uint32_t loop_vrb2: 1;
+ uint32_t valid_vrb2: 1;
};
} __rte_packed;
@@ -765,16 +805,20 @@ alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct
acc_device *d,
*/
static inline uint16_t
get_queue_id_from_ring_info(struct rte_bbdev_data *data,
- const union acc_info_ring_data ring_data)
+ const union acc_info_ring_data ring_data, uint16_t
device_variant)
{
uint16_t queue_id;
+ struct acc_queue *acc_q;
+ uint16_t vf_id = (device_variant == VRB2_VARIANT) ?
ring_data.vf_id_vrb2 : ring_data.vf_id;
+ uint16_t aq_id = (device_variant == VRB2_VARIANT) ?
ring_data.aq_id_vrb2 : ring_data.aq_id;
+ uint16_t qg_id = (device_variant == VRB2_VARIANT) ?
ring_data.qg_id_vrb2 : ring_data.qg_id;
for (queue_id = 0; queue_id < data->num_queues; ++queue_id) {
- struct acc_queue *acc_q =
- data->queues[queue_id].queue_private;
- if (acc_q != NULL && acc_q->aq_id == ring_data.aq_id &&
- acc_q->qgrp_id == ring_data.qg_id &&
- acc_q->vf_id == ring_data.vf_id)
+ acc_q = data->queues[queue_id].queue_private;
+
+ if (acc_q != NULL && acc_q->aq_id == aq_id &&
+ acc_q->qgrp_id == qg_id &&
+
Re: [PATCH v5 03/32] net/sssnic: support probe and remove
Hello Stephen,
This patch is just a minimum probe frame, it does nothing and always
return error. The error check will apear in the subsequent patch([PATCH
v5 04/32]), in that patch, hardware base is initialized, so secondary
process check is added logically.
Thanks.
On 2023/9/19 0:08, Stephen Hemminger wrote:
On Mon, 4 Sep 2023 12:56:29 +0800
wrote:
+static int
+sssnic_ethdev_init(struct rte_eth_dev *ethdev)
+{
+ RTE_SET_USED(ethdev);
+ PMD_INIT_FUNC_TRACE();
+
+ return -EINVAL;
+}
Since device does not support secondary process, should
check and return error here.
--
Regards,
Renyong Wan
RE: [PATCH 1/1] net/mana: add 32 bit short doorbell
> -Original Message-
> From: Long Li
> Sent: Tuesday, September 19, 2023 4:02 AM
> To: Wei Hu ; dev@dpdk.org
> Cc: sta...@dpdk.org; Ferruh Yigit ; Luca Boccassi
> ; Kevin Traynor
> Subject: RE: [PATCH 1/1] net/mana: add 32 bit short doorbell
>
> > Subject: [PATCH 1/1] net/mana: add 32 bit short doorbell
> >
> > Add 32 bit short doorbell support. Ring short doorbell when running in
> > 32 bit applicactions.
> >
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Hu
> > ---
> > drivers/net/mana/gdma.c | 95
> > +
> > drivers/net/mana/mana.h | 25 +++
> > drivers/net/mana/rx.c | 52 ++
> > drivers/net/mana/tx.c | 28
> > 4 files changed, 200 insertions(+)
> >
> > diff --git a/drivers/net/mana/gdma.c b/drivers/net/mana/gdma.c index
> > 65685fe236..d1da025d1b 100644
> > --- a/drivers/net/mana/gdma.c
> > +++ b/drivers/net/mana/gdma.c
> > @@ -166,6 +166,97 @@ gdma_post_work_request(struct
> mana_gdma_queue
> > *queue,
> > return 0;
> > }
> >
> > +#ifdef RTE_ARCH_32
> > +union gdma_short_doorbell_entry {
> > + uint32_t as_uint32;
> > +
> > + struct {
> > + uint32_t tail_ptr_incr : 16; /* Number of CQEs */
> > + uint32_t id : 12;
> > + uint32_t reserved : 3;
> > + uint32_t arm: 1;
> > + } cq;
> > +
> > + struct {
> > + uint32_t tail_ptr_incr : 16; /* In number of bytes */
> > + uint32_t id : 12;
> > + uint32_t reserved : 4;
> > + } rq;
> > +
> > + struct {
> > + uint32_t tail_ptr_incr : 16; /* In number of bytes */
> > + uint32_t id : 12;
> > + uint32_t reserved : 4;
> > + } sq;
> > +
> > + struct {
> > + uint32_t tail_ptr_incr : 16; /* Number of EQEs */
> > + uint32_t id : 12;
> > + uint32_t reserved : 3;
> > + uint32_t arm: 1;
> > + } eq;
> > +}; /* HW DATA */
> > +
> > +enum {
> > + DOORBELL_SHORT_OFFSET_SQ = 0x10,
> > + DOORBELL_SHORT_OFFSET_RQ = 0x410,
> > + DOORBELL_SHORT_OFFSET_CQ = 0x810,
> > + DOORBELL_SHORT_OFFSET_EQ = 0xFF0,
> > +};
> > +
> > +/*
> > + * Write to hardware doorbell to notify new activity.
> > + */
> > +int
> > +mana_ring_short_doorbell(void *db_page, enum gdma_queue_types
> > queue_type,
> > +uint32_t queue_id, uint32_t tail_incr, uint8_t arm) {
> > + uint8_t *addr = db_page;
> > + union gdma_short_doorbell_entry e = {};
> > +
> > + if ((queue_id & ~GDMA_SHORT_DB_QID_MASK) ||
> > + (tail_incr & ~GDMA_SHORT_DB_INC_MASK)) {
> > + DP_LOG(ERR, "%s: queue_id %u or "
> > + "tail_incr %u overflowed, queue type %d",
> > + __func__, queue_id, tail_incr, queue_type);
> > + return -EINVAL;
> > + }
> > +
> > + switch (queue_type) {
> > + case GDMA_QUEUE_SEND:
> > + e.sq.id = queue_id;
> > + e.sq.tail_ptr_incr = tail_incr;
> > + addr += DOORBELL_SHORT_OFFSET_SQ;
> > + break;
> > +
> > + case GDMA_QUEUE_RECEIVE:
> > + e.rq.id = queue_id;
> > + e.rq.tail_ptr_incr = tail_incr;
> > + addr += DOORBELL_SHORT_OFFSET_RQ;
> > + break;
> > +
> > + case GDMA_QUEUE_COMPLETION:
> > + e.cq.id = queue_id;
> > + e.cq.tail_ptr_incr = tail_incr;
> > + e.cq.arm = arm;
> > + addr += DOORBELL_SHORT_OFFSET_CQ;
> > + break;
> > +
> > + default:
> > + DP_LOG(ERR, "Unsupported queue type %d", queue_type);
> > + return -1;
> > + }
> > +
> > + /* Ensure all writes are done before ringing doorbell */
> > + rte_wmb();
> > +
> > + DP_LOG(DEBUG, "db_page %p addr %p queue_id %u type %u tail %u
> > arm %u",
> > + db_page, addr, queue_id, queue_type, tail_incr, arm);
> > +
> > + rte_write32(e.as_uint32, addr);
> > + return 0;
> > +}
> > +#else
> > union gdma_doorbell_entry {
> > uint64_t as_uint64;
> >
> > @@ -248,6 +339,7 @@ mana_ring_doorbell(void *db_page, enum
> > gdma_queue_types queue_type,
> > rte_write64(e.as_uint64, addr);
> > return 0;
> > }
> > +#endif
> >
> > /*
> > * Poll completion queue for completions.
> > @@ -287,6 +379,9 @@ gdma_poll_completion_queue(struct
> mana_gdma_queue
> > *cq,
> > num_comp++;
> >
> > cq->head++;
> > +#ifdef RTE_ARCH_32
> > + cq->head_incr_to_short_db++;
> > +#endif
> >
> > DP_LOG(DEBUG, "comp new 0x%x old 0x%x cqe 0x%x wq %u
> sq %u head
> > %u",
> >new_owner_bits, old_owner_bits, cqe_owner_bits, diff --
> git
> > a/drivers/net/mana/mana.h b/drivers/net/mana/mana.h index
> > 5801491d75..848d87c096 100644
> > --- a/drivers/net/mana/mana.h
> > +++ b/drivers/net/mana/mana.h
> > @@ -50,6 +50,19 @@ struct mana_shared_data { #define
> MAX_TX_WQE_SIZE
> > 512 #define MAX_RX_WQE_SIZE 2
RE: [PATCH v2 04/15] bus/pci: find PCI capability
Hi David,
> -Original Message-
> From: David Marchand
> Sent: Thursday, September 14, 2023 8:29 PM
> To: Xia, Chenbo ; Maxime Coquelin
>
> Cc: dev@dpdk.org; tho...@monjalon.net; ferruh.yi...@amd.com;
> nipun.gu...@amd.com; Richardson, Bruce ;
> Burakov, Anatoly ; Jay Zhou
> ; McDaniel, Timothy ;
> Julien Aube ; Rahul Lakkireddy
> ; Guo, Junfeng ;
> Jeroen de Borst ; Rushil Gupta ;
> Joshua Washington ; Dongdong Liu
> ; Yisen Zhuang ; Gaetan
> Rivet
> Subject: Re: [PATCH v2 04/15] bus/pci: find PCI capability
>
> Hello Chenbo,
>
> On Thu, Sep 7, 2023 at 2:43 PM Xia, Chenbo wrote:
> > > Introduce two helpers so that drivers stop reinventing the wheel when
> it
> > > comes to finding capabilities in a device PCI configuration space.
> > > Use it in existing drivers.
> > >
> > > Note:
> > > - base/ drivers code is left untouched, only some wrappers in cxgbe
> > > are touched,
> > > - bnx2x maintained a per device cache of capabilities, this code has
> been
> > > reworked to only cache the capabilities used in this driver,
> > >
> > > Signed-off-by: David Marchand
> > > Acked-by: Bruce Richardson
> > > ---
> > > Changes since v1:
> > > - updated commitlog,
> > > - separated VFIO changes for using standard PCI helper in a separate
> > > patch,
> > > - marked new experimental symbols with current version,
> > > - reordered defines in rte_pci.h,
> > >
> > > ---
> > > drivers/bus/pci/linux/pci_vfio.c | 74 --
> > > drivers/bus/pci/pci_common.c | 45 +++
> > > drivers/bus/pci/rte_bus_pci.h | 31
> > > drivers/bus/pci/version.map| 4 +
> > > drivers/crypto/virtio/virtio_pci.c | 57 +-
> > > drivers/event/dlb2/pf/dlb2_main.c | 42 +-
> > > drivers/net/bnx2x/bnx2x.c | 41 +-
> > > drivers/net/cxgbe/base/adapter.h | 28 +--
> > > drivers/net/gve/gve_ethdev.c | 46 ++-
> > > drivers/net/gve/gve_ethdev.h | 4 -
> > > drivers/net/hns3/hns3_ethdev_vf.c | 79 +++
> > > drivers/net/virtio/virtio_pci.c| 121 +---
> -
> > > lib/pci/rte_pci.h | 11 +++
> > > 13 files changed, 186 insertions(+), 397 deletions(-)
> > >
> > > diff --git a/drivers/bus/pci/linux/pci_vfio.c
> > > b/drivers/bus/pci/linux/pci_vfio.c
> > > index 958f8b3b52..614ed5d696 100644
> > > --- a/drivers/bus/pci/linux/pci_vfio.c
> > > +++ b/drivers/bus/pci/linux/pci_vfio.c
> > > @@ -110,74 +110,34 @@ static int
> > > pci_vfio_get_msix_bar(const struct rte_pci_device *dev,
> > > struct pci_msix_table *msix_table)
> > > {
> > > - int ret;
> > > - uint32_t reg;
> > > - uint16_t flags;
> > > - uint8_t cap_id, cap_offset;
> > > + off_t cap_offset;
> > >
> > > - /* read PCI capability pointer from config space */
> > > - ret = rte_pci_read_config(dev, ®, sizeof(reg),
> > > PCI_CAPABILITY_LIST);
> > > - if (ret != sizeof(reg)) {
> > > - RTE_LOG(ERR, EAL,
> > > - "Cannot read capability pointer from PCI config
> > > space!\n");
> > > + cap_offset = rte_pci_find_capability(dev, PCI_CAP_ID_MSIX);
> >
> > I notice in some cases we use rte_pci_has_capability_list() to check
> first,
> > then looking for specific cap, in other cases we don't use
> > rte_pci_has_capability_list(). Since we define this API, should we
> always do
> > the check?
>
> Hum, I am not sure of what you suggest here.
>
> I tried to do a 1:1 conversion of what existed.
> Do you mean there are places where I missed converting some
> rte_pci_read_config(PCI_CAPABILITY_LIST) to
> rte_pci_has_capability_list()?
> If so, could you point at them?
>
> Or are you suggesting to have this check as part of
> rte_pci_find_capability() ?
Your conversion is correct. I was saying about the usage of
rte_pci_has_capability_list/rte_pci_find_capability, logically should we
always call rte_pci_has_capability_list first before find capability?
I don't have strong opinion on this. You can choose to keep the same or
call rte_pci_has_capability_list more.
Thanks!
Chenbo
>
>
> I'll respin a v3 soon (to fix the nasty issue you pointed out below).
> A v4 may be needed depending on your replies to above questions.
>
>
> >
> >
> > > + if (cap_offset < 0)
> > > return -1;
> > > - }
> > >
> > > - /* we need first byte */
> > > - cap_offset = reg & 0xFF;
> > > + if (cap_offset != 0) {
> > > + uint16_t flags;
> > > + uint32_t reg;
> > >
> > > - while (cap_offset) {
> > > -
> > > - /* read PCI capability ID */
> > > - ret = rte_pci_read_config(dev, ®, sizeof(reg),
> cap_offset);
> > > - if (ret != sizeof(reg)) {
> > > + /* table offset resides in the next 4 bytes */
> > > + if (rte_pci_read_config(dev, ®, sizeof(reg),
> cap_offset + 4)
> > > < 0) {
> > > RTE_LOG(ERR, EAL,
> > > -
RE: [PATCH v3 04/15] bus/pci: find PCI capability
> -Original Message- > From: David Marchand > Sent: Thursday, September 14, 2023 8:36 PM > To: dev@dpdk.org > Cc: tho...@monjalon.net; ferruh.yi...@amd.com; Xia, Chenbo > ; nipun.gu...@amd.com; Richardson, Bruce > ; Burakov, Anatoly ; > Jay Zhou ; Sevincer, Abdullah > ; Julien Aube ; Rahul > Lakkireddy ; Guo, Junfeng > ; Jeroen de Borst ; Rushil > Gupta ; Joshua Washington ; > Dongdong Liu ; Yisen Zhuang > ; Maxime Coquelin ; > Gaetan Rivet > Subject: [PATCH v3 04/15] bus/pci: find PCI capability > > Introduce two helpers so that drivers stop reinventing the wheel when it > comes to finding capabilities in a device PCI configuration space. > Use it in existing drivers. > > Note: > - base/ drivers code is left untouched, only some wrappers in cxgbe > are touched, > - bnx2x maintained a per device cache of capabilities, this code has been > reworked to only cache the capabilities used in this driver, > > Acked-by: Bruce Richardson > Signed-off-by: David Marchand > --- > Changes since v2: > - added rte_pci_find_next_capability for vendor capa used with virtio, > > Changes since v1: > - updated commitlog, > - separated VFIO changes for using standard PCI helper in a separate > patch, > - marked new experimental symbols with current version, > - reordered defines in rte_pci.h, > > --- > drivers/bus/pci/linux/pci_vfio.c | 74 -- > drivers/bus/pci/pci_common.c | 54 + > drivers/bus/pci/rte_bus_pci.h | 53 + > drivers/bus/pci/version.map| 5 ++ > drivers/crypto/virtio/virtio_pci.c | 57 +- > drivers/event/dlb2/pf/dlb2_main.c | 42 +- > drivers/net/bnx2x/bnx2x.c | 41 +- > drivers/net/cxgbe/base/adapter.h | 28 +-- > drivers/net/gve/gve_ethdev.c | 46 ++- > drivers/net/gve/gve_ethdev.h | 4 - > drivers/net/hns3/hns3_ethdev_vf.c | 79 +++ > drivers/net/virtio/virtio_pci.c| 121 ++--- > lib/pci/rte_pci.h | 12 +++ > 13 files changed, 223 insertions(+), 393 deletions(-) > Reviewed-by: Chenbo Xia
RE: [PATCH v3 12/15] pci: define some ACS constants
> -Original Message-
> From: David Marchand
> Sent: Thursday, September 14, 2023 8:36 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; ferruh.yi...@amd.com; Xia, Chenbo
> ; nipun.gu...@amd.com; Richardson, Bruce
> ; Sevincer, Abdullah
> ; Gaetan Rivet
> Subject: [PATCH v3 12/15] pci: define some ACS constants
>
> Define some PCI ACS extended feature constants and use them in existing
> drivers.
>
> Signed-off-by: David Marchand
> Acked-by: Bruce Richardson
> ---
> drivers/event/dlb2/pf/dlb2_main.c | 23 ---
> lib/pci/rte_pci.h | 9 +
> 2 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/event/dlb2/pf/dlb2_main.c
> b/drivers/event/dlb2/pf/dlb2_main.c
> index 29e3001627..8e729d1964 100644
> --- a/drivers/event/dlb2/pf/dlb2_main.c
> +++ b/drivers/event/dlb2/pf/dlb2_main.c
> @@ -33,13 +33,6 @@
> #define DLB2_PCI_ERR_ROOT_STATUS 0x30
> #define DLB2_PCI_ERR_COR_STATUS 0x10
> #define DLB2_PCI_ERR_UNCOR_STATUS0x4
> -#define DLB2_PCI_ACS_CAP 0x4
> -#define DLB2_PCI_ACS_CTRL0x6
> -#define DLB2_PCI_ACS_SV 0x1
> -#define DLB2_PCI_ACS_RR 0x4
> -#define DLB2_PCI_ACS_CR 0x8
> -#define DLB2_PCI_ACS_UF 0x10
> -#define DLB2_PCI_ACS_EC 0x20
>
> static int
> dlb2_pf_init_driver_state(struct dlb2_dev *dlb2_dev)
> @@ -492,16 +485,16 @@ dlb2_pf_reset(struct dlb2_dev *dlb2_dev)
>
> if (acs_cap_offset >= 0) {
> uint16_t acs_cap, acs_ctrl, acs_mask;
> - off = acs_cap_offset + DLB2_PCI_ACS_CAP;
> + off = acs_cap_offset + RTE_PCI_ACS_CAP;
> if (rte_pci_read_config(pdev, &acs_cap, 2, off) != 2)
> acs_cap = 0;
>
> - off = acs_cap_offset + DLB2_PCI_ACS_CTRL;
> + off = acs_cap_offset + RTE_PCI_ACS_CTRL;
> if (rte_pci_read_config(pdev, &acs_ctrl, 2, off) != 2)
> acs_ctrl = 0;
>
> - acs_mask = DLB2_PCI_ACS_SV | DLB2_PCI_ACS_RR;
> - acs_mask |= (DLB2_PCI_ACS_CR | DLB2_PCI_ACS_UF);
> + acs_mask = RTE_PCI_ACS_SV | RTE_PCI_ACS_RR;
> + acs_mask |= (RTE_PCI_ACS_CR | RTE_PCI_ACS_UF);
> acs_ctrl |= (acs_cap & acs_mask);
>
> ret = rte_pci_write_config(pdev, &acs_ctrl, 2, off);
> @@ -511,15 +504,15 @@ dlb2_pf_reset(struct dlb2_dev *dlb2_dev)
> return ret;
> }
>
> - off = acs_cap_offset + DLB2_PCI_ACS_CTRL;
> + off = acs_cap_offset + RTE_PCI_ACS_CTRL;
> if (rte_pci_read_config(pdev, &acs_ctrl, 2, off) != 2)
> acs_ctrl = 0;
>
> - acs_mask = DLB2_PCI_ACS_RR | DLB2_PCI_ACS_CR;
> - acs_mask |= DLB2_PCI_ACS_EC;
> + acs_mask = RTE_PCI_ACS_RR | RTE_PCI_ACS_CR;
> + acs_mask |= RTE_PCI_ACS_EC;
> acs_ctrl &= ~acs_mask;
>
> - off = acs_cap_offset + DLB2_PCI_ACS_CTRL;
> + off = acs_cap_offset + RTE_PCI_ACS_CTRL;
> ret = rte_pci_write_config(pdev, &acs_ctrl, 2, off);
> if (ret != 2) {
> DLB2_LOG_ERR("[%s()] failed to write the pcie config
> space at offset %d\n",
> diff --git a/lib/pci/rte_pci.h b/lib/pci/rte_pci.h
> index 1fdca91f8b..a6c52a232d 100644
> --- a/lib/pci/rte_pci.h
> +++ b/lib/pci/rte_pci.h
> @@ -102,6 +102,15 @@ extern "C" {
> #define RTE_PCI_EXT_CAP_ID_SRIOV 0x10/* SR-IOV */
> #define RTE_PCI_EXT_CAP_ID_PRI 0x13/* Page Request
> Interface
> */
>
> +/* Access Control Service (RTE_PCI_EXT_CAP_ID_ACS) */
> +#define RTE_PCI_ACS_CAP 0x04/* ACS Capability
> Register
> */
> +#define RTE_PCI_ACS_CTRL 0x06/* ACS Control Register */
> +#define RTE_PCI_ACS_SV 0x0001 /* Source Validation */
> +#define RTE_PCI_ACS_RR 0x0004 /* P2P Request Redirect
> */
> +#define RTE_PCI_ACS_CR 0x0008 /* P2P Completion
> Redirect
> */
> +#define RTE_PCI_ACS_UF 0x0010 /* Upstream Forwarding
> */
> +#define RTE_PCI_ACS_EC 0x0020 /* P2P Egress Control */
> +
> /* Single Root I/O Virtualization (RTE_PCI_EXT_CAP_ID_SRIOV) */
> #define RTE_PCI_SRIOV_CAP0x04/* SR-IOV Capabilities */
> #define RTE_PCI_SRIOV_CTRL 0x08/* SR-IOV Control */
> --
> 2.41.0
Reviewed-by: Chenbo Xia
RE: [PATCH v3 13/15] pci: define some PRI constants
> -Original Message-
> From: David Marchand
> Sent: Thursday, September 14, 2023 8:36 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; ferruh.yi...@amd.com; Xia, Chenbo
> ; nipun.gu...@amd.com; Richardson, Bruce
> ; Sevincer, Abdullah
> ; Gaetan Rivet
> Subject: [PATCH v3 13/15] pci: define some PRI constants
>
> Define some PCI PRI extended feature constants and use them in existing
> drivers.
>
> Signed-off-by: David Marchand
> Acked-by: Bruce Richardson
> ---
> drivers/event/dlb2/pf/dlb2_main.c | 11 ---
> lib/pci/rte_pci.h | 5 +
> 2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/event/dlb2/pf/dlb2_main.c
> b/drivers/event/dlb2/pf/dlb2_main.c
> index 8e729d1964..187a356c24 100644
> --- a/drivers/event/dlb2/pf/dlb2_main.c
> +++ b/drivers/event/dlb2/pf/dlb2_main.c
> @@ -27,9 +27,6 @@
> #define NO_OWNER_VF 0/* PF ONLY! */
> #define NOT_VF_REQ false /* PF ONLY! */
>
> -#define DLB2_PCI_PRI_CTRL_ENABLE 0x1
> -#define DLB2_PCI_PRI_ALLOC_REQ 0xC
> -#define DLB2_PCI_PRI_CTRL0x4
> #define DLB2_PCI_ERR_ROOT_STATUS 0x30
> #define DLB2_PCI_ERR_COR_STATUS 0x10
> #define DLB2_PCI_ERR_UNCOR_STATUS0x4
> @@ -257,7 +254,7 @@ dlb2_pf_reset(struct dlb2_dev *dlb2_dev)
> pri_cap_offset = rte_pci_find_ext_capability(pdev, off);
>
> if (pri_cap_offset >= 0) {
> - off = pri_cap_offset + DLB2_PCI_PRI_ALLOC_REQ;
> + off = pri_cap_offset + RTE_PCI_PRI_ALLOC_REQ;
> if (rte_pci_read_config(pdev, &pri_reqs_dword, 4, off) != 4)
> pri_reqs_dword = 0;
> }
> @@ -377,9 +374,9 @@ dlb2_pf_reset(struct dlb2_dev *dlb2_dev)
> }
>
> if (pri_cap_offset >= 0) {
> - pri_ctrl_word = DLB2_PCI_PRI_CTRL_ENABLE;
> + pri_ctrl_word = RTE_PCI_PRI_CTRL_ENABLE;
>
> - off = pri_cap_offset + DLB2_PCI_PRI_ALLOC_REQ;
> + off = pri_cap_offset + RTE_PCI_PRI_ALLOC_REQ;
> ret = rte_pci_write_config(pdev, &pri_reqs_dword, 4, off);
> if (ret != 4) {
> DLB2_LOG_ERR("[%s()] failed to write the pcie config
> space at offset %d\n",
> @@ -387,7 +384,7 @@ dlb2_pf_reset(struct dlb2_dev *dlb2_dev)
> return ret;
> }
>
> - off = pri_cap_offset + DLB2_PCI_PRI_CTRL;
> + off = pri_cap_offset + RTE_PCI_PRI_CTRL;
> ret = rte_pci_write_config(pdev, &pri_ctrl_word, 2, off);
> if (ret != 2) {
> DLB2_LOG_ERR("[%s()] failed to write the pcie config
> space at offset %d\n",
> diff --git a/lib/pci/rte_pci.h b/lib/pci/rte_pci.h
> index a6c52a232d..6bbcad20f2 100644
> --- a/lib/pci/rte_pci.h
> +++ b/lib/pci/rte_pci.h
> @@ -123,6 +123,11 @@ extern "C" {
> #define RTE_PCI_SRIOV_VF_DID 0x1a/* VF Device ID */
> #define RTE_PCI_SRIOV_SUP_PGSIZE 0x1c/* Supported Page Sizes */
>
> +/* Page Request Interface (RTE_PCI_EXT_CAP_ID_PRI) */
> +#define RTE_PCI_PRI_CTRL 0x04/* PRI control register */
> +#define RTE_PCI_PRI_CTRL_ENABLE 0x0001 /* Enable */
> +#define RTE_PCI_PRI_ALLOC_REQ0x0c/* PRI max reqs allowed
> */
> +
> /** Formatting string for PCI device identifier: Ex: :00:01.0 */
> #define PCI_PRI_FMT "%.4" PRIx32 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
> #define PCI_PRI_STR_SIZE sizeof(":XX:XX.X")
> --
> 2.41.0
Reviewed-by: Chenbo Xia
RE: [PATCH v3 14/15] pci: define some AER constants
> -Original Message-
> From: David Marchand
> Sent: Thursday, September 14, 2023 8:36 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; ferruh.yi...@amd.com; Xia, Chenbo
> ; nipun.gu...@amd.com; Richardson, Bruce
> ; Sevincer, Abdullah
> ; Gaetan Rivet
> Subject: [PATCH v3 14/15] pci: define some AER constants
>
> Define some Advanced Error Reporting constants and use them in existing
> drivers.
>
> Signed-off-by: David Marchand
> Acked-by: Bruce Richardson
> ---
> drivers/event/dlb2/pf/dlb2_main.c | 10 +++---
> lib/pci/rte_pci.h | 5 +
> 2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/event/dlb2/pf/dlb2_main.c
> b/drivers/event/dlb2/pf/dlb2_main.c
> index 187a356c24..aa03e4c311 100644
> --- a/drivers/event/dlb2/pf/dlb2_main.c
> +++ b/drivers/event/dlb2/pf/dlb2_main.c
> @@ -27,10 +27,6 @@
> #define NO_OWNER_VF 0/* PF ONLY! */
> #define NOT_VF_REQ false /* PF ONLY! */
>
> -#define DLB2_PCI_ERR_ROOT_STATUS 0x30
> -#define DLB2_PCI_ERR_COR_STATUS 0x10
> -#define DLB2_PCI_ERR_UNCOR_STATUS0x4
> -
> static int
> dlb2_pf_init_driver_state(struct dlb2_dev *dlb2_dev)
> {
> @@ -399,7 +395,7 @@ dlb2_pf_reset(struct dlb2_dev *dlb2_dev)
> if (err_cap_offset >= 0) {
> uint32_t tmp;
>
> - off = err_cap_offset + DLB2_PCI_ERR_ROOT_STATUS;
> + off = err_cap_offset + RTE_PCI_ERR_ROOT_STATUS;
> if (rte_pci_read_config(pdev, &tmp, 4, off) != 4)
> tmp = 0;
>
> @@ -410,7 +406,7 @@ dlb2_pf_reset(struct dlb2_dev *dlb2_dev)
> return ret;
> }
>
> - off = err_cap_offset + DLB2_PCI_ERR_COR_STATUS;
> + off = err_cap_offset + RTE_PCI_ERR_COR_STATUS;
> if (rte_pci_read_config(pdev, &tmp, 4, off) != 4)
> tmp = 0;
>
> @@ -421,7 +417,7 @@ dlb2_pf_reset(struct dlb2_dev *dlb2_dev)
> return ret;
> }
>
> - off = err_cap_offset + DLB2_PCI_ERR_UNCOR_STATUS;
> + off = err_cap_offset + RTE_PCI_ERR_UNCOR_STATUS;
> if (rte_pci_read_config(pdev, &tmp, 4, off) != 4)
> tmp = 0;
>
> diff --git a/lib/pci/rte_pci.h b/lib/pci/rte_pci.h
> index 6bbcad20f2..69e932d910 100644
> --- a/lib/pci/rte_pci.h
> +++ b/lib/pci/rte_pci.h
> @@ -102,6 +102,11 @@ extern "C" {
> #define RTE_PCI_EXT_CAP_ID_SRIOV 0x10/* SR-IOV */
> #define RTE_PCI_EXT_CAP_ID_PRI 0x13/* Page Request
> Interface
> */
>
> +/* Advanced Error Reporting (RTE_PCI_EXT_CAP_ID_ERR) */
> +#define RTE_PCI_ERR_UNCOR_STATUS 0x04/* Uncorrectable Error Status */
> +#define RTE_PCI_ERR_COR_STATUS 0x10/* Correctable Error
> Status */
> +#define RTE_PCI_ERR_ROOT_STATUS 0x30
> +
> /* Access Control Service (RTE_PCI_EXT_CAP_ID_ACS) */
> #define RTE_PCI_ACS_CAP 0x04/* ACS Capability
> Register
> */
> #define RTE_PCI_ACS_CTRL 0x06/* ACS Control Register */
> --
> 2.41.0
Reviewed-by: Chenbo Xia
RE: [PATCH v2 1/1] net/mana: enable 32 bit build for mana driver
> -Original Message- > From: Ferruh Yigit > Sent: Tuesday, September 19, 2023 1:41 AM > To: Wei Hu ; dev@dpdk.org; Long Li > > Cc: sta...@dpdk.org; Kevin Traynor ; Luca Boccassi > > Subject: Re: [PATCH v2 1/1] net/mana: enable 32 bit build for mana driver > > On 9/13/2023 1:23 PM, Wei Hu wrote: > > Enable 32 bit build on x86 Linux. Fixed build warnings and errors when > > building in 32 bit. > > > > Cc: sta...@dpdk.org > > > > This is not a fix, but adding 32bit support to the driver, so not sure about > backporting. cc'ed Kevin & Luca for guidance. > > I will drop the tag while merging unles otherwise suggested by LTS > maintainers. Hi Ferruh, We have a customer who needs it to be on 22.11.x. That is why I put "Cc: sta...@dpdk.org" in it. > > > Signed-off-by: Wei Hu > > > > Hi Wei, > > Patch looks good, but it basically fixes the format specifiers that will cause > build error for 32 bit. > > Is there any other change required to make driver functional for 32 bit, or > does > it become functional with this change? > And if it does can you please confirm explicityly that driver tested on > 32 bit with this patch? Another patch, " net/mana: add 32 bit short doorbell", is required to make mana fully functional with 32 bit applications. This patch is to fix some build time errors and warnings when build in 32 bit. These patches can be independently built and they are addressing two different issues. So, I put them into two independent patches. I have tested it on 32 bit applications. They can run with this patch. Just mana would not work as the applications still use 64 bit long door bells, which do not work for 32 bit apps. Thanks, Wei
Re: [PATCH v5 00/32] Introduce sssnic PMD for 3SNIC's 9x0 serials Ethernet adapters
On Mon, 4 Sep 2023 12:56:26 +0800 wrote: > From: Renyong Wan > > The sssnic PMD (**librte_pmd_sssnic**) provides poll mode driver support > for 3SNIC 9x0 serials family of Ethernet adapters. > > Supported NICs are: > > - 3S910 Dual Port SFP28 10/25GbE Ethernet adapter > - 3S920 Quad Port SFP28 10/25GbE Ethernet adapter > - 3S920 Quad Port QSFP28 100GbE Ethernet adapter > > Features of sssnic PMD are: > > - Link status > - Link status event > - Queue start/stop > - Rx interrupt > - Scattered Rx > - TSO > - LRO > - Promiscuous mode > - Allmulticast mode > - Unicast MAC filter > - Multicast MAC filte > - RSS hash > - RSS key update > - RSS reta update > - Inner RSS > - VLAN filter > - VLAN offload > - L3 checksum offload > - L4 checksum offload > - Inner L3 checksum > - Inner L4 checksum > - Basic stats > - Extended stats > - Stats per queue > - Flow control > - FW version > - Generic flow API > > --- > v2: > * Fixed 'Title underline too short' in doc/guides/nics/sssnic.rst. > * Removed error.h from including files. > * Fixed variable 'cmd_len' is uninitialized when used. > * Fixed 'EINVAL' undeclared. > * Fixed wrong format of printing uint64_t. > * Fixed 'mask->hdr.src_addr' will always evaluate to 'true'. > > v3: > * Fixed dereferencing type-punned pointer in base/sssnic_mbox.c. > > v4: > * Fixed dereferencing type-punned pointer in base/sssnic_eventq.c. > * Fixed coding style issue of COMPLEX_MACRO. > * Fixed coding style issue of REPEATED_WORD. > > v5: > * Fixed rebase mistake. > * Fixed incorrect path in MAINTAINERS file. > --- > > Renyong Wan (32): > net/sssnic: add build and doc infrastructure > net/sssnic: add log type and log macros > net/sssnic: support probe and remove > net/sssnic: initialize hardware base > net/sssnic: add event queue > net/sssnic/base: add message definition and utility > net/sssnic/base: add mailbox support > net/sssnic/base: add work queue > net/sssnic/base: add control queue > net/sssnic: add dev configure and infos get > net/sssnic: add dev MAC ops > net/sssnic: support dev link status > net/sssnic: support link status event > net/sssnic: support Rx queue setup and release > net/sssnic: support Tx queue setup and release > net/sssnic: support Rx queue start and stop > net/sssnic: support Tx queue start and stop > net/sssnic: add Rx interrupt support > net/sssnic: support dev start and stop > net/sssnic: support dev close and reset > net/sssnic: add allmulticast and promiscuous ops > net/sssnic: add basic and extended stats ops > net/sssnic: support Rx packet burst > net/sssnic: support Tx packet burst > net/sssnic: add RSS support > net/sssnic: support dev MTU set > net/sssnic: support dev queue info get > net/sssnic: support dev firmware version get > net/sssnic: add dev flow control ops > net/sssnic: support VLAN offload and filter > net/sssnic: add generic flow ops > net/sssnic: add VF dev support > > .mailmap |2 + > MAINTAINERS|7 + > doc/guides/nics/features/sssnic.ini| 47 + > doc/guides/nics/index.rst |1 + > doc/guides/nics/sssnic.rst | 73 + > drivers/net/meson.build|1 + > drivers/net/sssnic/base/meson.build| 20 + > drivers/net/sssnic/base/sssnic_api.c | 1943 > drivers/net/sssnic/base/sssnic_api.h | 498 + > drivers/net/sssnic/base/sssnic_cmd.h | 514 ++ > drivers/net/sssnic/base/sssnic_ctrlq.c | 521 ++ > drivers/net/sssnic/base/sssnic_ctrlq.h | 58 + > drivers/net/sssnic/base/sssnic_eventq.c| 461 + > drivers/net/sssnic/base/sssnic_eventq.h| 84 + > drivers/net/sssnic/base/sssnic_exception.c | 116 ++ > drivers/net/sssnic/base/sssnic_exception.h | 10 + > drivers/net/sssnic/base/sssnic_hw.c| 486 + > drivers/net/sssnic/base/sssnic_hw.h| 117 ++ > drivers/net/sssnic/base/sssnic_mbox.c | 615 +++ > drivers/net/sssnic/base/sssnic_mbox.h | 45 + > drivers/net/sssnic/base/sssnic_misc.h | 52 + > drivers/net/sssnic/base/sssnic_msg.c | 254 +++ > drivers/net/sssnic/base/sssnic_msg.h | 166 ++ > drivers/net/sssnic/base/sssnic_reg.h | 267 +++ > drivers/net/sssnic/base/sssnic_workq.c | 141 ++ > drivers/net/sssnic/base/sssnic_workq.h | 108 ++ > drivers/net/sssnic/meson.build | 28 + > drivers/net/sssnic/sssnic_ethdev.c | 1139 > drivers/net/sssnic/sssnic_ethdev.h | 102 + > drivers/net/sssnic/sssnic_ethdev_fdir.c| 1017 ++ > drivers/net/sssnic/sssnic_ethdev_fdir.h| 332 > drivers/net/sssnic/sssnic_ethdev_flow.c| 981 ++ > drivers/net/sssnic/sssnic_ethdev_flow.h| 11 + > drivers/net/sssnic/sssnic_ethdev_link.c| 209 +++ > drivers/net/sssnic/sssnic_ethdev_link.h| 14 + > drivers/net/sssn
Re: [PATCH v5 00/32] Introduce sssnic PMD for 3SNIC's 9x0 serials Ethernet adapters
On Mon, 4 Sep 2023 12:56:26 +0800 wrote: > From: Renyong Wan > > The sssnic PMD (**librte_pmd_sssnic**) provides poll mode driver support > for 3SNIC 9x0 serials family of Ethernet adapters. > > Supported NICs are: > > - 3S910 Dual Port SFP28 10/25GbE Ethernet adapter > - 3S920 Quad Port SFP28 10/25GbE Ethernet adapter > - 3S920 Quad Port QSFP28 100GbE Ethernet adapter > > Features of sssnic PMD are: > > - Link status > - Link status event > - Queue start/stop > - Rx interrupt > - Scattered Rx > - TSO > - LRO > - Promiscuous mode > - Allmulticast mode > - Unicast MAC filter > - Multicast MAC filte > - RSS hash > - RSS key update > - RSS reta update > - Inner RSS > - VLAN filter > - VLAN offload > - L3 checksum offload > - L4 checksum offload > - Inner L3 checksum > - Inner L4 checksum > - Basic stats > - Extended stats > - Stats per queue > - Flow control > - FW version > - Generic flow API > > --- > v2: > * Fixed 'Title underline too short' in doc/guides/nics/sssnic.rst. > * Removed error.h from including files. > * Fixed variable 'cmd_len' is uninitialized when used. > * Fixed 'EINVAL' undeclared. > * Fixed wrong format of printing uint64_t. > * Fixed 'mask->hdr.src_addr' will always evaluate to 'true'. > > v3: > * Fixed dereferencing type-punned pointer in base/sssnic_mbox.c. > > v4: > * Fixed dereferencing type-punned pointer in base/sssnic_eventq.c. > * Fixed coding style issue of COMPLEX_MACRO. > * Fixed coding style issue of REPEATED_WORD. > > v5: > * Fixed rebase mistake. > * Fixed incorrect path in MAINTAINERS file. > --- > > Renyong Wan (32): > net/sssnic: add build and doc infrastructure > net/sssnic: add log type and log macros > net/sssnic: support probe and remove > net/sssnic: initialize hardware base > net/sssnic: add event queue > net/sssnic/base: add message definition and utility > net/sssnic/base: add mailbox support > net/sssnic/base: add work queue > net/sssnic/base: add control queue > net/sssnic: add dev configure and infos get > net/sssnic: add dev MAC ops > net/sssnic: support dev link status > net/sssnic: support link status event > net/sssnic: support Rx queue setup and release > net/sssnic: support Tx queue setup and release > net/sssnic: support Rx queue start and stop > net/sssnic: support Tx queue start and stop > net/sssnic: add Rx interrupt support > net/sssnic: support dev start and stop > net/sssnic: support dev close and reset > net/sssnic: add allmulticast and promiscuous ops > net/sssnic: add basic and extended stats ops > net/sssnic: support Rx packet burst > net/sssnic: support Tx packet burst > net/sssnic: add RSS support > net/sssnic: support dev MTU set > net/sssnic: support dev queue info get > net/sssnic: support dev firmware version get > net/sssnic: add dev flow control ops > net/sssnic: support VLAN offload and filter > net/sssnic: add generic flow ops > net/sssnic: add VF dev support > > .mailmap |2 + > MAINTAINERS|7 + > doc/guides/nics/features/sssnic.ini| 47 + > doc/guides/nics/index.rst |1 + > doc/guides/nics/sssnic.rst | 73 + > drivers/net/meson.build|1 + > drivers/net/sssnic/base/meson.build| 20 + > drivers/net/sssnic/base/sssnic_api.c | 1943 > drivers/net/sssnic/base/sssnic_api.h | 498 + > drivers/net/sssnic/base/sssnic_cmd.h | 514 ++ > drivers/net/sssnic/base/sssnic_ctrlq.c | 521 ++ > drivers/net/sssnic/base/sssnic_ctrlq.h | 58 + > drivers/net/sssnic/base/sssnic_eventq.c| 461 + > drivers/net/sssnic/base/sssnic_eventq.h| 84 + > drivers/net/sssnic/base/sssnic_exception.c | 116 ++ > drivers/net/sssnic/base/sssnic_exception.h | 10 + > drivers/net/sssnic/base/sssnic_hw.c| 486 + > drivers/net/sssnic/base/sssnic_hw.h| 117 ++ > drivers/net/sssnic/base/sssnic_mbox.c | 615 +++ > drivers/net/sssnic/base/sssnic_mbox.h | 45 + > drivers/net/sssnic/base/sssnic_misc.h | 52 + > drivers/net/sssnic/base/sssnic_msg.c | 254 +++ > drivers/net/sssnic/base/sssnic_msg.h | 166 ++ > drivers/net/sssnic/base/sssnic_reg.h | 267 +++ > drivers/net/sssnic/base/sssnic_workq.c | 141 ++ > drivers/net/sssnic/base/sssnic_workq.h | 108 ++ > drivers/net/sssnic/meson.build | 28 + > drivers/net/sssnic/sssnic_ethdev.c | 1139 > drivers/net/sssnic/sssnic_ethdev.h | 102 + > drivers/net/sssnic/sssnic_ethdev_fdir.c| 1017 ++ > drivers/net/sssnic/sssnic_ethdev_fdir.h| 332 > drivers/net/sssnic/sssnic_ethdev_flow.c| 981 ++ > drivers/net/sssnic/sssnic_ethdev_flow.h| 11 + > drivers/net/sssnic/sssnic_ethdev_link.c| 209 +++ > drivers/net/sssnic/sssnic_ethdev_link.h| 14 + > drivers/net/sssn
Re: [PATCH v5 00/32] Introduce sssnic PMD for 3SNIC's 9x0 serials Ethernet adapters
On Mon, 4 Sep 2023 12:56:26 +0800 wrote: > From: Renyong Wan > > The sssnic PMD (**librte_pmd_sssnic**) provides poll mode driver support > for 3SNIC 9x0 serials family of Ethernet adapters. > > Supported NICs are: > > - 3S910 Dual Port SFP28 10/25GbE Ethernet adapter > - 3S920 Quad Port SFP28 10/25GbE Ethernet adapter > - 3S920 Quad Port QSFP28 100GbE Ethernet adapter > > Features of sssnic PMD are: > > - Link status > - Link status event > - Queue start/stop > - Rx interrupt > - Scattered Rx > - TSO > - LRO > - Promiscuous mode > - Allmulticast mode > - Unicast MAC filter > - Multicast MAC filte > - RSS hash > - RSS key update > - RSS reta update > - Inner RSS > - VLAN filter > - VLAN offload > - L3 checksum offload > - L4 checksum offload > - Inner L3 checksum > - Inner L4 checksum > - Basic stats > - Extended stats > - Stats per queue > - Flow control > - FW version > - Generic flow API > > --- > v2: > * Fixed 'Title underline too short' in doc/guides/nics/sssnic.rst. > * Removed error.h from including files. > * Fixed variable 'cmd_len' is uninitialized when used. > * Fixed 'EINVAL' undeclared. > * Fixed wrong format of printing uint64_t. > * Fixed 'mask->hdr.src_addr' will always evaluate to 'true'. > > v3: > * Fixed dereferencing type-punned pointer in base/sssnic_mbox.c. > > v4: > * Fixed dereferencing type-punned pointer in base/sssnic_eventq.c. > * Fixed coding style issue of COMPLEX_MACRO. > * Fixed coding style issue of REPEATED_WORD. > > v5: > * Fixed rebase mistake. > * Fixed incorrect path in MAINTAINERS file. > --- > > Renyong Wan (32): > net/sssnic: add build and doc infrastructure > net/sssnic: add log type and log macros > net/sssnic: support probe and remove > net/sssnic: initialize hardware base > net/sssnic: add event queue > net/sssnic/base: add message definition and utility > net/sssnic/base: add mailbox support > net/sssnic/base: add work queue > net/sssnic/base: add control queue > net/sssnic: add dev configure and infos get > net/sssnic: add dev MAC ops > net/sssnic: support dev link status > net/sssnic: support link status event > net/sssnic: support Rx queue setup and release > net/sssnic: support Tx queue setup and release > net/sssnic: support Rx queue start and stop > net/sssnic: support Tx queue start and stop > net/sssnic: add Rx interrupt support > net/sssnic: support dev start and stop > net/sssnic: support dev close and reset > net/sssnic: add allmulticast and promiscuous ops > net/sssnic: add basic and extended stats ops > net/sssnic: support Rx packet burst > net/sssnic: support Tx packet burst > net/sssnic: add RSS support > net/sssnic: support dev MTU set > net/sssnic: support dev queue info get > net/sssnic: support dev firmware version get > net/sssnic: add dev flow control ops > net/sssnic: support VLAN offload and filter > net/sssnic: add generic flow ops > net/sssnic: add VF dev support > > .mailmap |2 + > MAINTAINERS|7 + > doc/guides/nics/features/sssnic.ini| 47 + > doc/guides/nics/index.rst |1 + > doc/guides/nics/sssnic.rst | 73 + > drivers/net/meson.build|1 + > drivers/net/sssnic/base/meson.build| 20 + > drivers/net/sssnic/base/sssnic_api.c | 1943 > drivers/net/sssnic/base/sssnic_api.h | 498 + > drivers/net/sssnic/base/sssnic_cmd.h | 514 ++ > drivers/net/sssnic/base/sssnic_ctrlq.c | 521 ++ > drivers/net/sssnic/base/sssnic_ctrlq.h | 58 + > drivers/net/sssnic/base/sssnic_eventq.c| 461 + > drivers/net/sssnic/base/sssnic_eventq.h| 84 + > drivers/net/sssnic/base/sssnic_exception.c | 116 ++ > drivers/net/sssnic/base/sssnic_exception.h | 10 + > drivers/net/sssnic/base/sssnic_hw.c| 486 + > drivers/net/sssnic/base/sssnic_hw.h| 117 ++ > drivers/net/sssnic/base/sssnic_mbox.c | 615 +++ > drivers/net/sssnic/base/sssnic_mbox.h | 45 + > drivers/net/sssnic/base/sssnic_misc.h | 52 + > drivers/net/sssnic/base/sssnic_msg.c | 254 +++ > drivers/net/sssnic/base/sssnic_msg.h | 166 ++ > drivers/net/sssnic/base/sssnic_reg.h | 267 +++ > drivers/net/sssnic/base/sssnic_workq.c | 141 ++ > drivers/net/sssnic/base/sssnic_workq.h | 108 ++ > drivers/net/sssnic/meson.build | 28 + > drivers/net/sssnic/sssnic_ethdev.c | 1139 > drivers/net/sssnic/sssnic_ethdev.h | 102 + > drivers/net/sssnic/sssnic_ethdev_fdir.c| 1017 ++ > drivers/net/sssnic/sssnic_ethdev_fdir.h| 332 > drivers/net/sssnic/sssnic_ethdev_flow.c| 981 ++ > drivers/net/sssnic/sssnic_ethdev_flow.h| 11 + > drivers/net/sssnic/sssnic_ethdev_link.c| 209 +++ > drivers/net/sssnic/sssnic_ethdev_link.h| 14 + > drivers/net/sssn
RE: [PATCH 1/1] net/mana: add 32 bit short doorbell
> -Original Message- > From: Ferruh Yigit > Sent: Tuesday, September 19, 2023 2:03 AM > To: Wei Hu ; dev@dpdk.org; Long Li > > Cc: sta...@dpdk.org; Kevin Traynor ; Luca Boccassi > > Subject: Re: [PATCH 1/1] net/mana: add 32 bit short doorbell > > On 9/9/2023 1:23 PM, Wei Hu wrote: > > Add 32 bit short doorbell support. Ring short doorbell when running in > > 32 bit applicactions. > > > > Hi Wei, > > Is this performance improvement for 32 bit, or is short doorbell support > required for 32 bit support? > > Hi Ferruh, This it not a performance improvement patch. Without this patch, 32 bit applications do not function. > This patch is using RTE_ARCH_32 compile time macro to enable short doorbell > support, so need to decide to support 32 bit or 64 bit in compile time. > > Also I guess 32 bit driver can run on 64 bit arch, what will be the result in > that > case? The patch is for those applications compiled in 32 bit, but running on a 64 bit Linux kernels. There is no 64 bit mana kernel driver available. So the kernel still needs to be in 64 bit. > > My point is, instead of using compile time flag, what do you think to detect > execution platform on runtime and use preferred doorbell according platform? > > I can see short descriptor support touches multiple functions, can the support > be abstracted to let to use it based on runtime detection? The 32 bit support request is from a specific customer who only has 32 bit applications. The customer needs to build and link its applications into 32bit libraries and drivers. Therefore, the DPDK mana driver needs to be in 32 bit anyway. 32bit applications cannot use 64bit doorbells. 64bit applications can use 32bit doorbells, however the performance would suffer and it definitely not recommended. IMHO, there is not much difference between compile time flag and "if...then...else" statement at runtime, except for in the latter case, a few more extra runtime instructions and maybe some branch overhead in either 64bit or 32bit case. Given we have limited 32bit use cases, I chose to just use the compile time flag, which seems to be simpler to implement and less work for our verification team. > > > Cc: sta...@dpdk.org > > > > Similar comment as previous patch, this patch is not a fix but adding new > support, not sure about backporting it. > The customer who needs 32bit support wants it to be on 22.11.x. That is why I put "Cc: sta...@dpdk.org" in it. > > Signed-off-by: Wei Hu > > > > <...> > > > @@ -97,6 +110,7 @@ mana_alloc_and_post_rx_wqe(struct mana_rxq *rxq) > > /* update queue for tracking pending packets */ > > desc->pkt = mbuf; > > desc->wqe_size_in_bu = wqe_size_in_bu; > > + rxq->wqe_cnt_to_short_db += wqe_size_in_bu; > > > > This variable always used within RTE_ARCH_32 block, but set here without > RTE_ARCH_32 ifdef, is this intentional? No, it is not intentional. Thanks for pointing this out. I will add ifdef in next round. Thanks, Wei
[PATCH] maintainers: update email address
I am leaving Intel, so replace my Intel email with personal one temporarily. Signed-off-by: Chenbo Xia --- .mailmap| 2 +- MAINTAINERS | 12 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/.mailmap b/.mailmap index 864d33ee46..8cb3c1e80f 100644 --- a/.mailmap +++ b/.mailmap @@ -209,7 +209,7 @@ Charles Brett Charles Myers Charles Stoll Chas Williams <3ch...@gmail.com> -Chenbo Xia +Chenbo Xia Chengchang Tang Chengfeng Ye Chenghu Yao diff --git a/MAINTAINERS b/MAINTAINERS index 698608cdb2..ef0f52f1ef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -50,7 +50,7 @@ T: git://dpdk.org/next/dpdk-next-net-mlx Next-virtio Tree M: Maxime Coquelin -M: Chenbo Xia +M: Chenbo Xia T: git://dpdk.org/next/dpdk-next-virtio Next-crypto Tree @@ -590,7 +590,7 @@ F: drivers/bus/dpaa/ F: drivers/bus/fslmc/ PCI bus driver -M: Chenbo Xia +M: Chenbo Xia M: Nipun Gupta F: drivers/bus/pci/ @@ -980,7 +980,7 @@ F: doc/guides/nics/features/vmxnet3.ini Vhost-user M: Maxime Coquelin -M: Chenbo Xia +M: Chenbo Xia T: git://dpdk.org/next/dpdk-next-virtio F: lib/vhost/ F: doc/guides/prog_guide/vhost_lib.rst @@ -994,7 +994,7 @@ F: doc/guides/sample_app_ug/vdpa.rst Vhost PMD M: Maxime Coquelin -M: Chenbo Xia +M: Chenbo Xia T: git://dpdk.org/next/dpdk-next-virtio F: drivers/net/vhost/ F: doc/guides/nics/vhost.rst @@ -1002,7 +1002,7 @@ F: doc/guides/nics/features/vhost.ini Virtio PMD M: Maxime Coquelin -M: Chenbo Xia +M: Chenbo Xia T: git://dpdk.org/next/dpdk-next-virtio F: drivers/net/virtio/ F: doc/guides/nics/virtio.rst @@ -1655,7 +1655,7 @@ F: app/test/test_rcu* F: doc/guides/prog_guide/rcu_lib.rst PCI -M: Chenbo Xia +M: Chenbo Xia M: Gaetan Rivet F: lib/pci/ -- 2.25.1
[PATCH] net/mlx5: reuse reformat and modify header actions in a table
If application defined several actions templates with non-shared
reformat or modify headers actions AND used these templates to create
a table, HWS could share reformat or modify headers resources,
instead of creating a resource for each action template.
The patch activates HWS code in a way that provides reformat or
modify header resources sharing.
The patch updates modify field and raw encap template actions
validations:
- modify field does not allow empty action template masks.
- raw encap added action template mask validation.
Signed-off-by: Gregory Etelson
---
Depends-on: patch-129406 ("net/mlx5/hws: add support for multi pattern")
---
drivers/net/mlx5/mlx5_flow.h| 8 +-
drivers/net/mlx5/mlx5_flow_dv.c | 3 +-
drivers/net/mlx5/mlx5_flow_hw.c | 568 +---
3 files changed, 452 insertions(+), 127 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 3a97975d69..68fa6cf46d 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1318,7 +1318,9 @@ struct mlx5_hw_jump_action {
struct mlx5_hw_encap_decap_action {
struct mlx5dr_action *action; /* Action object. */
/* Is header_reformat action shared across flows in table. */
- bool shared;
+ uint32_t shared:1;
+ uint32_t multi_pattern:1;
+ volatile uint32_t *multi_pattern_refcnt;
size_t data_size; /* Action metadata size. */
uint8_t data[]; /* Action data. */
};
@@ -1332,7 +1334,9 @@ struct mlx5_hw_modify_header_action {
/* Modify header action position in action rule table. */
uint16_t pos;
/* Is MODIFY_HEADER action shared across flows in table. */
- bool shared;
+ uint32_t shared:1;
+ uint32_t multi_pattern:1;
+ volatile uint32_t *multi_pattern_refcnt;
/* Amount of modification commands stored in the precompiled buffer. */
uint32_t mhdr_cmds_num;
/* Precompiled modification commands. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 3f4325c5c8..d3e002ec41 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -4573,7 +4573,8 @@ flow_dv_convert_encap_data(const struct rte_flow_item
*items, uint8_t *buf,
(void *)items->type,
"items total size is too big"
" for encap action");
- rte_memcpy((void *)&buf[temp_size], items->spec, len);
+ if (items->spec)
+ rte_memcpy(&buf[temp_size], items->spec, len);
switch (items->type) {
case RTE_FLOW_ITEM_TYPE_ETH:
eth = (struct rte_ether_hdr *)&buf[temp_size];
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 83910c097d..04f1095c9c 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -58,6 +58,95 @@
#define MLX5_HW_VLAN_PUSH_VID_IDX 1
#define MLX5_HW_VLAN_PUSH_PCP_IDX 2
+#define MLX5_CONST_ENCAP_ITEM(encap_type, ptr) \
+(((const struct encap_type *)(ptr))->definition)
+
+struct mlx5_multi_pattern_ctx {
+ union {
+ struct mlx5dr_action_reformat_header reformat_hdr;
+ struct mlx5dr_action_mh_pattern mh_pattern;
+ };
+ union {
+ /* action template auxiliary structures for object destruction
*/
+ struct mlx5_hw_encap_decap_action *encap;
+ struct mlx5_hw_modify_header_action *mhdr;
+ };
+ /* multi pattern action */
+ struct mlx5dr_rule_action *rule_action;
+};
+
+#define MLX5_MULTIPATTERN_ENCAP_NUM 4
+
+struct mlx5_tbl_multi_pattern_ctx {
+ struct {
+ uint32_t elements_num;
+ struct mlx5_multi_pattern_ctx
ctx[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
+ } reformat[MLX5_MULTIPATTERN_ENCAP_NUM];
+
+ struct {
+ uint32_t elements_num;
+ struct mlx5_multi_pattern_ctx
ctx[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
+ } mh;
+};
+
+#define MLX5_EMPTY_MULTI_PATTERN_CTX {{{0,}},}
+
+static int
+mlx5_tbl_multi_pattern_process(struct rte_eth_dev *dev,
+ struct rte_flow_template_table *tbl,
+ struct mlx5_tbl_multi_pattern_ctx *mpat,
+ struct rte_flow_error *error);
+
+static __rte_always_inline int
+mlx5_multi_pattern_reformat_to_index(enum mlx5dr_action_type type)
+{
+ switch (type) {
+ case MLX5DR_ACTION_TYP_REFORMAT_TNL_L2_TO_L2:
+ return 0;
+ case MLX5DR_ACTION_TYP_REFORMAT_L2_TO_TNL_L2:
+ return 1;
+ case MLX5DR_ACTION_TYP_REFORMAT_TNL_L3_TO_L2:
+ return 2;
+ case MLX5DR_ACTION_TYP_REFORMAT_L2_TO_TNL_L3:
+ return 3;
+ default:
+ break;
+ }
+ return
Re: [PATCH v5 00/32] Introduce sssnic PMD for 3SNIC's 9x0 serials Ethernet adapters
Hello Stephen, I'll fix it in next version of patch. Thanks. On 2023/9/19 11:19, Stephen Hemminger wrote: On Mon, 4 Sep 2023 12:56:26 +0800 wrote: From: Renyong Wan The sssnic PMD (**librte_pmd_sssnic**) provides poll mode driver support for 3SNIC 9x0 serials family of Ethernet adapters. Supported NICs are: - 3S910 Dual Port SFP28 10/25GbE Ethernet adapter - 3S920 Quad Port SFP28 10/25GbE Ethernet adapter - 3S920 Quad Port QSFP28 100GbE Ethernet adapter Features of sssnic PMD are: - Link status - Link status event - Queue start/stop - Rx interrupt - Scattered Rx - TSO - LRO - Promiscuous mode - Allmulticast mode - Unicast MAC filter - Multicast MAC filte - RSS hash - RSS key update - RSS reta update - Inner RSS - VLAN filter - VLAN offload - L3 checksum offload - L4 checksum offload - Inner L3 checksum - Inner L4 checksum - Basic stats - Extended stats - Stats per queue - Flow control - FW version - Generic flow API --- v2: * Fixed 'Title underline too short' in doc/guides/nics/sssnic.rst. * Removed error.h from including files. * Fixed variable 'cmd_len' is uninitialized when used. * Fixed 'EINVAL' undeclared. * Fixed wrong format of printing uint64_t. * Fixed 'mask->hdr.src_addr' will always evaluate to 'true'. v3: * Fixed dereferencing type-punned pointer in base/sssnic_mbox.c. v4: * Fixed dereferencing type-punned pointer in base/sssnic_eventq.c. * Fixed coding style issue of COMPLEX_MACRO. * Fixed coding style issue of REPEATED_WORD. v5: * Fixed rebase mistake. * Fixed incorrect path in MAINTAINERS file. --- Renyong Wan (32): net/sssnic: add build and doc infrastructure net/sssnic: add log type and log macros net/sssnic: support probe and remove net/sssnic: initialize hardware base net/sssnic: add event queue net/sssnic/base: add message definition and utility net/sssnic/base: add mailbox support net/sssnic/base: add work queue net/sssnic/base: add control queue net/sssnic: add dev configure and infos get net/sssnic: add dev MAC ops net/sssnic: support dev link status net/sssnic: support link status event net/sssnic: support Rx queue setup and release net/sssnic: support Tx queue setup and release net/sssnic: support Rx queue start and stop net/sssnic: support Tx queue start and stop net/sssnic: add Rx interrupt support net/sssnic: support dev start and stop net/sssnic: support dev close and reset net/sssnic: add allmulticast and promiscuous ops net/sssnic: add basic and extended stats ops net/sssnic: support Rx packet burst net/sssnic: support Tx packet burst net/sssnic: add RSS support net/sssnic: support dev MTU set net/sssnic: support dev queue info get net/sssnic: support dev firmware version get net/sssnic: add dev flow control ops net/sssnic: support VLAN offload and filter net/sssnic: add generic flow ops net/sssnic: add VF dev support .mailmap |2 + MAINTAINERS|7 + doc/guides/nics/features/sssnic.ini| 47 + doc/guides/nics/index.rst |1 + doc/guides/nics/sssnic.rst | 73 + drivers/net/meson.build|1 + drivers/net/sssnic/base/meson.build| 20 + drivers/net/sssnic/base/sssnic_api.c | 1943 drivers/net/sssnic/base/sssnic_api.h | 498 + drivers/net/sssnic/base/sssnic_cmd.h | 514 ++ drivers/net/sssnic/base/sssnic_ctrlq.c | 521 ++ drivers/net/sssnic/base/sssnic_ctrlq.h | 58 + drivers/net/sssnic/base/sssnic_eventq.c| 461 + drivers/net/sssnic/base/sssnic_eventq.h| 84 + drivers/net/sssnic/base/sssnic_exception.c | 116 ++ drivers/net/sssnic/base/sssnic_exception.h | 10 + drivers/net/sssnic/base/sssnic_hw.c| 486 + drivers/net/sssnic/base/sssnic_hw.h| 117 ++ drivers/net/sssnic/base/sssnic_mbox.c | 615 +++ drivers/net/sssnic/base/sssnic_mbox.h | 45 + drivers/net/sssnic/base/sssnic_misc.h | 52 + drivers/net/sssnic/base/sssnic_msg.c | 254 +++ drivers/net/sssnic/base/sssnic_msg.h | 166 ++ drivers/net/sssnic/base/sssnic_reg.h | 267 +++ drivers/net/sssnic/base/sssnic_workq.c | 141 ++ drivers/net/sssnic/base/sssnic_workq.h | 108 ++ drivers/net/sssnic/meson.build | 28 + drivers/net/sssnic/sssnic_ethdev.c | 1139 drivers/net/sssnic/sssnic_ethdev.h | 102 + drivers/net/sssnic/sssnic_ethdev_fdir.c| 1017 ++ drivers/net/sssnic/sssnic_ethdev_fdir.h| 332 drivers/net/sssnic/sssnic_ethdev_flow.c| 981 ++ drivers/net/sssnic/sssnic_ethdev_flow.h| 11 + drivers/net/sssnic/sssnic_ethdev_link.c| 209 +++ drivers/net/sssnic/sssnic_ethdev_link.h| 14 + drivers/net/sssnic/sssnic_ethdev_rss.c | 377 drivers/net/sssnic/sssnic_ethdev_rss.h |
Re: [PATCH v5 00/32] Introduce sssnic PMD for 3SNIC's 9x0 serials Ethernet adapters
Hello Stephen, I'll fix it in next version of patch. Thanks. On 2023/9/19 11:21, Stephen Hemminger wrote: On Mon, 4 Sep 2023 12:56:26 +0800 wrote: From: Renyong Wan The sssnic PMD (**librte_pmd_sssnic**) provides poll mode driver support for 3SNIC 9x0 serials family of Ethernet adapters. Supported NICs are: - 3S910 Dual Port SFP28 10/25GbE Ethernet adapter - 3S920 Quad Port SFP28 10/25GbE Ethernet adapter - 3S920 Quad Port QSFP28 100GbE Ethernet adapter Features of sssnic PMD are: - Link status - Link status event - Queue start/stop - Rx interrupt - Scattered Rx - TSO - LRO - Promiscuous mode - Allmulticast mode - Unicast MAC filter - Multicast MAC filte - RSS hash - RSS key update - RSS reta update - Inner RSS - VLAN filter - VLAN offload - L3 checksum offload - L4 checksum offload - Inner L3 checksum - Inner L4 checksum - Basic stats - Extended stats - Stats per queue - Flow control - FW version - Generic flow API --- v2: * Fixed 'Title underline too short' in doc/guides/nics/sssnic.rst. * Removed error.h from including files. * Fixed variable 'cmd_len' is uninitialized when used. * Fixed 'EINVAL' undeclared. * Fixed wrong format of printing uint64_t. * Fixed 'mask->hdr.src_addr' will always evaluate to 'true'. v3: * Fixed dereferencing type-punned pointer in base/sssnic_mbox.c. v4: * Fixed dereferencing type-punned pointer in base/sssnic_eventq.c. * Fixed coding style issue of COMPLEX_MACRO. * Fixed coding style issue of REPEATED_WORD. v5: * Fixed rebase mistake. * Fixed incorrect path in MAINTAINERS file. --- Renyong Wan (32): net/sssnic: add build and doc infrastructure net/sssnic: add log type and log macros net/sssnic: support probe and remove net/sssnic: initialize hardware base net/sssnic: add event queue net/sssnic/base: add message definition and utility net/sssnic/base: add mailbox support net/sssnic/base: add work queue net/sssnic/base: add control queue net/sssnic: add dev configure and infos get net/sssnic: add dev MAC ops net/sssnic: support dev link status net/sssnic: support link status event net/sssnic: support Rx queue setup and release net/sssnic: support Tx queue setup and release net/sssnic: support Rx queue start and stop net/sssnic: support Tx queue start and stop net/sssnic: add Rx interrupt support net/sssnic: support dev start and stop net/sssnic: support dev close and reset net/sssnic: add allmulticast and promiscuous ops net/sssnic: add basic and extended stats ops net/sssnic: support Rx packet burst net/sssnic: support Tx packet burst net/sssnic: add RSS support net/sssnic: support dev MTU set net/sssnic: support dev queue info get net/sssnic: support dev firmware version get net/sssnic: add dev flow control ops net/sssnic: support VLAN offload and filter net/sssnic: add generic flow ops net/sssnic: add VF dev support .mailmap |2 + MAINTAINERS|7 + doc/guides/nics/features/sssnic.ini| 47 + doc/guides/nics/index.rst |1 + doc/guides/nics/sssnic.rst | 73 + drivers/net/meson.build|1 + drivers/net/sssnic/base/meson.build| 20 + drivers/net/sssnic/base/sssnic_api.c | 1943 drivers/net/sssnic/base/sssnic_api.h | 498 + drivers/net/sssnic/base/sssnic_cmd.h | 514 ++ drivers/net/sssnic/base/sssnic_ctrlq.c | 521 ++ drivers/net/sssnic/base/sssnic_ctrlq.h | 58 + drivers/net/sssnic/base/sssnic_eventq.c| 461 + drivers/net/sssnic/base/sssnic_eventq.h| 84 + drivers/net/sssnic/base/sssnic_exception.c | 116 ++ drivers/net/sssnic/base/sssnic_exception.h | 10 + drivers/net/sssnic/base/sssnic_hw.c| 486 + drivers/net/sssnic/base/sssnic_hw.h| 117 ++ drivers/net/sssnic/base/sssnic_mbox.c | 615 +++ drivers/net/sssnic/base/sssnic_mbox.h | 45 + drivers/net/sssnic/base/sssnic_misc.h | 52 + drivers/net/sssnic/base/sssnic_msg.c | 254 +++ drivers/net/sssnic/base/sssnic_msg.h | 166 ++ drivers/net/sssnic/base/sssnic_reg.h | 267 +++ drivers/net/sssnic/base/sssnic_workq.c | 141 ++ drivers/net/sssnic/base/sssnic_workq.h | 108 ++ drivers/net/sssnic/meson.build | 28 + drivers/net/sssnic/sssnic_ethdev.c | 1139 drivers/net/sssnic/sssnic_ethdev.h | 102 + drivers/net/sssnic/sssnic_ethdev_fdir.c| 1017 ++ drivers/net/sssnic/sssnic_ethdev_fdir.h| 332 drivers/net/sssnic/sssnic_ethdev_flow.c| 981 ++ drivers/net/sssnic/sssnic_ethdev_flow.h| 11 + drivers/net/sssnic/sssnic_ethdev_link.c| 209 +++ drivers/net/sssnic/sssnic_ethdev_link.h| 14 + drivers/net/sssnic/sssnic_ethdev_rss.c | 377 drivers/net/sssnic/sssnic_ethdev_rss.h |
Re: [PATCH v5 00/32] Introduce sssnic PMD for 3SNIC's 9x0 serials Ethernet adapters
Hello Stephen, I'll fix it in next version of patch. Thanks. On 2023/9/19 11:23, Stephen Hemminger wrote: On Mon, 4 Sep 2023 12:56:26 +0800 wrote: From: Renyong Wan The sssnic PMD (**librte_pmd_sssnic**) provides poll mode driver support for 3SNIC 9x0 serials family of Ethernet adapters. Supported NICs are: - 3S910 Dual Port SFP28 10/25GbE Ethernet adapter - 3S920 Quad Port SFP28 10/25GbE Ethernet adapter - 3S920 Quad Port QSFP28 100GbE Ethernet adapter Features of sssnic PMD are: - Link status - Link status event - Queue start/stop - Rx interrupt - Scattered Rx - TSO - LRO - Promiscuous mode - Allmulticast mode - Unicast MAC filter - Multicast MAC filte - RSS hash - RSS key update - RSS reta update - Inner RSS - VLAN filter - VLAN offload - L3 checksum offload - L4 checksum offload - Inner L3 checksum - Inner L4 checksum - Basic stats - Extended stats - Stats per queue - Flow control - FW version - Generic flow API --- v2: * Fixed 'Title underline too short' in doc/guides/nics/sssnic.rst. * Removed error.h from including files. * Fixed variable 'cmd_len' is uninitialized when used. * Fixed 'EINVAL' undeclared. * Fixed wrong format of printing uint64_t. * Fixed 'mask->hdr.src_addr' will always evaluate to 'true'. v3: * Fixed dereferencing type-punned pointer in base/sssnic_mbox.c. v4: * Fixed dereferencing type-punned pointer in base/sssnic_eventq.c. * Fixed coding style issue of COMPLEX_MACRO. * Fixed coding style issue of REPEATED_WORD. v5: * Fixed rebase mistake. * Fixed incorrect path in MAINTAINERS file. --- Renyong Wan (32): net/sssnic: add build and doc infrastructure net/sssnic: add log type and log macros net/sssnic: support probe and remove net/sssnic: initialize hardware base net/sssnic: add event queue net/sssnic/base: add message definition and utility net/sssnic/base: add mailbox support net/sssnic/base: add work queue net/sssnic/base: add control queue net/sssnic: add dev configure and infos get net/sssnic: add dev MAC ops net/sssnic: support dev link status net/sssnic: support link status event net/sssnic: support Rx queue setup and release net/sssnic: support Tx queue setup and release net/sssnic: support Rx queue start and stop net/sssnic: support Tx queue start and stop net/sssnic: add Rx interrupt support net/sssnic: support dev start and stop net/sssnic: support dev close and reset net/sssnic: add allmulticast and promiscuous ops net/sssnic: add basic and extended stats ops net/sssnic: support Rx packet burst net/sssnic: support Tx packet burst net/sssnic: add RSS support net/sssnic: support dev MTU set net/sssnic: support dev queue info get net/sssnic: support dev firmware version get net/sssnic: add dev flow control ops net/sssnic: support VLAN offload and filter net/sssnic: add generic flow ops net/sssnic: add VF dev support .mailmap |2 + MAINTAINERS|7 + doc/guides/nics/features/sssnic.ini| 47 + doc/guides/nics/index.rst |1 + doc/guides/nics/sssnic.rst | 73 + drivers/net/meson.build|1 + drivers/net/sssnic/base/meson.build| 20 + drivers/net/sssnic/base/sssnic_api.c | 1943 drivers/net/sssnic/base/sssnic_api.h | 498 + drivers/net/sssnic/base/sssnic_cmd.h | 514 ++ drivers/net/sssnic/base/sssnic_ctrlq.c | 521 ++ drivers/net/sssnic/base/sssnic_ctrlq.h | 58 + drivers/net/sssnic/base/sssnic_eventq.c| 461 + drivers/net/sssnic/base/sssnic_eventq.h| 84 + drivers/net/sssnic/base/sssnic_exception.c | 116 ++ drivers/net/sssnic/base/sssnic_exception.h | 10 + drivers/net/sssnic/base/sssnic_hw.c| 486 + drivers/net/sssnic/base/sssnic_hw.h| 117 ++ drivers/net/sssnic/base/sssnic_mbox.c | 615 +++ drivers/net/sssnic/base/sssnic_mbox.h | 45 + drivers/net/sssnic/base/sssnic_misc.h | 52 + drivers/net/sssnic/base/sssnic_msg.c | 254 +++ drivers/net/sssnic/base/sssnic_msg.h | 166 ++ drivers/net/sssnic/base/sssnic_reg.h | 267 +++ drivers/net/sssnic/base/sssnic_workq.c | 141 ++ drivers/net/sssnic/base/sssnic_workq.h | 108 ++ drivers/net/sssnic/meson.build | 28 + drivers/net/sssnic/sssnic_ethdev.c | 1139 drivers/net/sssnic/sssnic_ethdev.h | 102 + drivers/net/sssnic/sssnic_ethdev_fdir.c| 1017 ++ drivers/net/sssnic/sssnic_ethdev_fdir.h| 332 drivers/net/sssnic/sssnic_ethdev_flow.c| 981 ++ drivers/net/sssnic/sssnic_ethdev_flow.h| 11 + drivers/net/sssnic/sssnic_ethdev_link.c| 209 +++ drivers/net/sssnic/sssnic_ethdev_link.h| 14 + drivers/net/sssnic/sssnic_ethdev_rss.c | 377 drivers/net/sssnic/sssnic_ethdev_rss.h |
RE: [EXT] [PATCH v2] common/qat: enable QAT 2.0c devices
> This commit enables QAT 2.0c devices in the
> Intel QuickAssist Technology PMD.
> These are 4th Generation QAT, 402xx devices.
>
> Signed-off-by: Ciara Power
>
> ---
> v2:
> - Fixed kernel module.
> - Modified commit to align naming of new QAT device.
> ---
> doc/guides/cryptodevs/qat.rst | 4
> doc/guides/rel_notes/release_23_11.rst | 4
> drivers/common/qat/qat_device.c| 4
> 3 files changed, 12 insertions(+)
>
> diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
> index afdfb0bd22..730113da33 100644
> --- a/doc/guides/cryptodevs/qat.rst
> +++ b/doc/guides/cryptodevs/qat.rst
> @@ -457,6 +457,10 @@ to see the full table)
>
> +-+-+-+-+--+---+---++
> +--+++
> | Yes | No | No | 4 | 401xxx | IDZ/ N/A | qat_401xxx| 4xxx
> | 4942
> | 2| 4943 | 16 |
>
> +-+-+-+-+--+---+---++
> +--+++
> + | Yes | Yes | Yes | 4 | 402xx| linux/6.4+| qat_4xxx | 4xxx
> | 4944
> | 2| 4945 | 16 |
> +
> +-+-+-+-+--+---+---++
> +--+++
> + | Yes | No | No | 4 | 402xx| IDZ/ N/A | qat_4xxx | 4xxx
> | 4944
> | 2| 4945 | 16 |
> +
> +-+-+-+-+--+---+---++
> +--+++
>
> * Note: Symmetric mixed crypto algorithms feature on Gen 2 works only with
> IDZ driver version 4.9.0+
>
> diff --git a/doc/guides/rel_notes/release_23_11.rst
> b/doc/guides/rel_notes/release_23_11.rst
> index 4411bb32c1..72dfb3fbf0 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -72,6 +72,10 @@ New Features
> Also, make sure to start the actual text at the margin.
> ===
>
> +* **Added support for QAT 2.0c devices to Intel QuickAssist Technology
> PMD.**
> +
> + * QAT 2.0c (4944) devices are now enabled for QAT.
Is it 4944 or 4945? In the code below, the PCI device added is 4945
> +
>
> Removed Items
> -
> diff --git a/drivers/common/qat/qat_device.c
> b/drivers/common/qat/qat_device.c
> index 2675f0d9d1..cbf1e6a988 100644
> --- a/drivers/common/qat/qat_device.c
> +++ b/drivers/common/qat/qat_device.c
> @@ -50,6 +50,9 @@ static const struct rte_pci_id pci_id_qat_map[] = {
> {
> RTE_PCI_DEVICE(0x8086, 0x4943),
> },
> + {
> + RTE_PCI_DEVICE(0x8086, 0x4945),
> + },
> {.device_id = 0},
> };
>
> @@ -202,6 +205,7 @@ qat_pci_device_allocate(struct rte_pci_device *pci_dev,
> break;
> case 0x4941:
> case 0x4943:
> + case 0x4945:
> qat_dev_gen = QAT_GEN4;
> break;
> default:
> --
> 2.25.1
RE: [EXT] [PATCH 1/2] crypto/dpaa2_sec: fix debug prints
> RTE_LIBRTE_SECURITY has been replaced with RTE_LIB_SECURITY for a
> while now.
>
> Fixes: 84bb24bd058c ("crypto/dpaa2_sec: add debug prints")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
Series applied to dpdk-next-crypto
Thanks.
RE: [PATCH v2] cryptodev: add missing doc
> Subject: [PATCH v2] cryptodev: add missing doc
Title updated as "cryptodev: fix missing doc"
>
> Description for rte_cryptodev_get_sec_ctx is missing. Add the same.
>
> Fixes: eadb4fa1e1fe ("cryptodev: support security APIs")
>
> Signed-off-by: Anoob Joseph
Acked-by: Akhil Goyal
Cc: sta...@dpdk.org
Applied to dpdk-next-crypto
RE: [EXT] [PATCH v8 1/3] crypto/ipsec_mb: add digest encrypted feature
> -- > AESNI_MB PMD does not support Digest Encrypted. This patch adds a check and > support for this feature. > > Acked-by: Ciara Power > Signed-off-by: Brian Dooley > --- > v2: > Fixed CHECKPATCH warning > v3: > Add Digest encrypted support to docs > v4: > Add comments and small refactor > v5: > Fix checkpatch warnings > v6: > Add skipping tests for synchronous crypto > v7: > Separate synchronous fix into separate commit > --- > doc/guides/cryptodevs/features/aesni_mb.ini | 1 + > drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 109 +++- > 2 files changed, 105 insertions(+), 5 deletions(-) Release notes??
RE: [EXT] Re: [PATCH] test/security: fix buffer leaks in error path
> > +#define FREE_PKTS(j, m) { \
> > + while (j--) \
> > + rte_pktmbuf_free(m[j]); \
> > +}
> > +
>
> Changes looks good. However do you want to define a static inline
> function here instead of macro?
Any specific reason for changing to inline function?
In this case macro is as good as inline function.
