[PATCH] net/i40e: updated 23.11 recommended matching list
Signed-off-by: Simei Su --- doc/guides/nics/i40e.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index 3432eab..15689ac 100644 --- a/doc/guides/nics/i40e.rst +++ b/doc/guides/nics/i40e.rst @@ -104,6 +104,8 @@ For X710/XL710/XXV710, +--+---+--+ | DPDK version | Kernel driver version | Firmware version | +==+===+==+ + |23.11 | 2.23.17 | 9.30 | + +--+---+--+ |23.07 | 2.22.20 | 9.20 | +--+---+--+ |23.03 | 2.22.18 | 9.20 | @@ -167,6 +169,8 @@ For X722, +--+---+--+ | DPDK version | Kernel driver version | Firmware version | +==+===+==+ + |23.11 | 2.23.17 | 6.20 | + +--+---+--+ |23.07 | 2.22.20 | 6.20 | +--+---+--+ |23.03 | 2.22.18 | 6.20 | -- 2.9.5
[PATCH] net/ice: updated 23.11 recommended matching list
Signed-off-by: Simei Su --- doc/guides/nics/ice.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst index 820a385..09a4302 100644 --- a/doc/guides/nics/ice.rst +++ b/doc/guides/nics/ice.rst @@ -75,6 +75,8 @@ are listed in the Tested Platforms section of the Release Notes for each release +---+---+-+---+--+---+ |23.07 | 1.12.6| 1.3.35 | 1.3.45 |1.3.13| 4.3| +---+---+-+---+--+---+ + |23.11 | 1.13.7| 1.3.36 | 1.3.46 |1.3.14| 4.4| + +---+---+-+---+--+---+ Configuration - -- 2.9.5
[Bug 1338] [dpdk-22.11.4] vhost_virtio_user_interrupt_with_power_monitor/perf_wake_up_split_ring_vhost_user_core_with_l3fwd_power_sample：virtio-user can't receive packet
https://bugs.dpdk.org/show_bug.cgi?id=1338
Bug ID: 1338
Summary: [dpdk-22.11.4]
vhost_virtio_user_interrupt_with_power_monitor/perf_wa
ke_up_split_ring_vhost_user_core_with_l3fwd_power_samp
le：virtio-user can't receive packet
Product: DPDK
Version: 22.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: vhost/virtio
Assignee: dev@dpdk.org
Reporter: linglix.c...@intel.com
Target Milestone: ---
[Environment]
DPDK version: dpdk 22.11.4-rc3: 4307659a90
OS: Ubuntu 22.04.3 LTS/5.15.0-87-generic
Compiler: gcc version 11.4.0
Hardware platform: SPR(Intel(R) Xeon(R) Platinum 8490H)
NIC hardware: Ethernet Controller E810-C for QSFP 1592
NIC firmware: 4.40 0x8001c2f1 1.3492.0
NIC kdriver: ice-1.13.3_dirty
[Test Setup]
Steps to reproduce
1. ssh root@dpdk-yingya-spr2
Compile DPDK::
meson -Dexamples=l3fwd-power x86_64-native-linuxapp-gcc
ninja -C x86_64-native-linuxapp-gcc
2.bind NIC port to vfio-pci,
./usertools/dpdk-devbind.py -b vfio-pci 45:00.0
3. Launch virtio-user with server mode::
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 3-4 -n 8 -a :45:00.0
--vdev net_virtio_user0,path=./vhost-net,server=1,queues=1 -- -i --rxq=1
--txq=1
4. Launch vhost with l3fwd-power::
./x86_64-native-linuxapp-gcc/examples/dpdk-l3fwd-power -l 5-6 -n 8
--file-prefix=l3fwd-pwd_216146_20231228175051 --no-pci --vdev
net_vhost0,iface=./vhost-net,queues=1,client=1--log-level='user1,7' -- -p 1
--config='(0,0,5)' --parse-ptype --pmd-mgmt=monitor
5. Start virtio-user::
testpmd>start
6. Sent imix packets from TG
[Show the output from the previous commands]
pktgen: ixia packet generator: run traffic 5s to warm up ...
pktgen: begin traffic ..
tester: scp -v ixiaConfig.tcl root@dpdk-yingya-spr2:~/
pktgen: source ixiaConfig.tcl
pktgen: ixStopTransmit portList
pktgen: traffic completed.
pktgen: begin traffic ..
tester: scp -v ixiaConfig.tcl root@dpdk-yingya-spr2:~/
pktgen: source ixiaConfig.tcl
pktgen: begin get port statistic ...
pktgen: stat getRate statAllStats 1 3 4
pktgen: stat cget -framesReceived
pktgen: stat cget -bitsReceived
pktgen: stat cget -oversize
pktgen: throughput: pps_rx 0.00, bps_rx 0.00
[Expected Result]
check packets can fwd back with correct payload.
Regression
Is this issue a regression: (Y/N) Y
test on SPR only
The commit a07736eb68 will build failed
8c291d8778 tested failed (vhost: fix checking virtqueue access in stats API)
a07736eb68 build failed (vhost: fix missing lock protection in power monitor
API) (/lib/vhost/vhost.c:2171:13: error: unused variable ‘ret’
[-Werror=unused-variable])
adae353b36 tested passed (vhost: fix check on virtqueue access in in-flight
getter)
bad commit 8c291d87783d2e22e6234cddc23bee27d0f14dae (HEAD -> 22.11)
Author: Maxime Coquelin
Date: Fri Oct 20 10:48:04 2023 +0200
vhost: fix checking virtqueue access in stats API
[ upstream commit a004501a147889d608008ab6f18355e9b0ceff65 ]
Acquiring the access lock is not enough to ensure
virtqueue's metadata such as vring pointers are valid.
The access status must also be checked.
Fixes: be75dc99ea1f ("vhost: support per-virtqueue statistics")
Signed-off-by: Maxime Coquelin
Acked-by: David Marchand
--
You are receiving this mail because:
You are the assignee for the bug.
[PATCH v5 0/2] net/iavf: add diagnostics and fix error
1. Fix multi-process error in Tx path. 2. Add diagnostics to Tx path. Mingjin Ye (2): net/iavf: fix Tx path error in multi-process net/iavf: add diagnostic support in TX path doc/guides/nics/intel_vf.rst | 4 + drivers/net/iavf/iavf.h| 25 +- drivers/net/iavf/iavf_ethdev.c | 70 + drivers/net/iavf/iavf_rxtx.c | 138 - drivers/net/iavf/iavf_rxtx.h | 5 ++ 5 files changed, 238 insertions(+), 4 deletions(-) -- 2.25.1
[PATCH v5 1/2] net/iavf: fix Tx path error in multi-process
In a multi-process environment, a secondary process operates on shared
memory and changes the PMD transmit function pointer of the primary
process, causing the primary process to send pkts without being able
to find the function address, resulting in a crash.
Fixes: 5b3124a0a6ef ("net/iavf: support no polling when link down")
Cc: sta...@dpdk.org
Signed-off-by: Mingjin Ye
---
drivers/net/iavf/iavf.h | 12 +++-
drivers/net/iavf/iavf_rxtx.c | 34 +++---
drivers/net/iavf/iavf_rxtx.h | 3 +++
3 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 10868f2c30..4cd5bea167 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -313,6 +313,16 @@ struct iavf_devargs {
struct iavf_security_ctx;
+enum iavf_tx_pkt_burst_type {
+ IAVF_PKT_BURST_DEFAULT = 0,
+ IAVF_PKT_BURST_VEC = 1,
+ IAVF_PKT_BURST_VEC_AVX2 = 2,
+ IAVF_PKT_BURST_VEC_AVX2_OFFLOAD = 3,
+ IAVF_PKT_BURST_VEC_AVX512 = 4,
+ IAVF_PKT_BURST_VEC_AVX512_OFFLOAD = 5,
+ IAVF_PKT_BURST_VEC_AVX512_CTX_OFFLOAD = 6,
+};
+
/* Structure to store private data for each VF instance. */
struct iavf_adapter {
struct iavf_hw hw;
@@ -329,7 +339,7 @@ struct iavf_adapter {
bool closed;
bool no_poll;
eth_rx_burst_t rx_pkt_burst;
- eth_tx_burst_t tx_pkt_burst;
+ enum iavf_tx_pkt_burst_type tx_burst_type;
uint16_t fdir_ref_cnt;
struct iavf_devargs devargs;
};
diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index f19aa14646..0d95447054 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -425,6 +425,23 @@ struct iavf_txq_ops iavf_txq_release_mbufs_ops[] = {
};
+static const
+struct iavf_tx_burst_ops iavf_tx_pkt_burst_ops[] = {
+ [IAVF_PKT_BURST_DEFAULT].tx_pkt_burst = iavf_xmit_pkts,
+#ifdef RTE_ARCH_X86
+ [IAVF_PKT_BURST_VEC].tx_pkt_burst = iavf_xmit_pkts_vec,
+ [IAVF_PKT_BURST_VEC_AVX2].tx_pkt_burst = iavf_xmit_pkts_vec_avx2,
+ [IAVF_PKT_BURST_VEC_AVX2_OFFLOAD].tx_pkt_burst =
iavf_xmit_pkts_vec_avx2_offload,
+#ifdef CC_AVX512_SUPPORT
+ [IAVF_PKT_BURST_VEC_AVX512].tx_pkt_burst = iavf_xmit_pkts_vec_avx512,
+ [IAVF_PKT_BURST_VEC_AVX512_OFFLOAD].tx_pkt_burst =
+ iavf_xmit_pkts_vec_avx512_offload,
+ [IAVF_PKT_BURST_VEC_AVX512_CTX_OFFLOAD].tx_pkt_burst =
+ iavf_xmit_pkts_vec_avx512_ctx_offload,
+#endif
+#endif
+};
+
static inline void
iavf_rxd_to_pkt_fields_by_comms_ovs(__rte_unused struct iavf_rx_queue *rxq,
struct rte_mbuf *mb,
@@ -3724,10 +3741,13 @@ iavf_xmit_pkts_no_poll(void *tx_queue, struct rte_mbuf
**tx_pkts,
uint16_t nb_pkts)
{
struct iavf_tx_queue *txq = tx_queue;
+ enum iavf_tx_pkt_burst_type tx_burst_type =
+ txq->vsi->adapter->tx_burst_type;
+
if (!txq->vsi || txq->vsi->adapter->no_poll)
return 0;
- return txq->vsi->adapter->tx_pkt_burst(tx_queue,
+ return iavf_tx_pkt_burst_ops[tx_burst_type].tx_pkt_burst(tx_queue,
tx_pkts,
nb_pkts);
}
@@ -3975,6 +3995,7 @@ iavf_set_tx_function(struct rte_eth_dev *dev)
{
struct iavf_adapter *adapter =
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
+ enum iavf_tx_pkt_burst_type tx_burst_type;
int no_poll_on_link_down = adapter->devargs.no_poll_on_link_down;
#ifdef RTE_ARCH_X86
struct iavf_tx_queue *txq;
@@ -4011,10 +4032,12 @@ iavf_set_tx_function(struct rte_eth_dev *dev)
PMD_DRV_LOG(DEBUG, "Using Vector Tx (port %d).",
dev->data->port_id);
dev->tx_pkt_burst = iavf_xmit_pkts_vec;
+ tx_burst_type = IAVF_PKT_BURST_VEC;
}
if (use_avx2) {
if (check_ret == IAVF_VECTOR_PATH) {
dev->tx_pkt_burst = iavf_xmit_pkts_vec_avx2;
+ tx_burst_type = IAVF_PKT_BURST_VEC_AVX2;
PMD_DRV_LOG(DEBUG, "Using AVX2 Vector Tx (port
%d).",
dev->data->port_id);
} else if (check_ret == IAVF_VECTOR_CTX_OFFLOAD_PATH) {
@@ -4023,6 +4046,7 @@ iavf_set_tx_function(struct rte_eth_dev *dev)
goto normal;
} else {
dev->tx_pkt_burst =
iavf_xmit_pkts_vec_avx2_offload;
+ tx_burst_type = IAVF_PKT_BURST_VEC_AVX2_OFFLOAD;
dev->tx_pkt_prepare = iavf_prep_pkts;
PMD_DRV_LOG(DEBUG, "Using AVX2 OFFLOAD Vector
Tx (port %d).",
[PATCH v5 2/2] net/iavf: add diagnostic support in TX path
The only way to enable diagnostics for TX paths is to modify the
application source code. Making it difficult to diagnose faults.
In this patch, the devarg option "mbuf_check" is introduced and the
parameters are configured to enable the corresponding diagnostics.
supported cases: mbuf, size, segment, offload, strict.
1. mbuf: check for corrupted mbuf.
2. size: check min/max packet length according to hw spec.
3. segment: check number of mbuf segments not exceed hw limitation.
4. offload: check any unsupported offload flag.
5. strict: check protocol headers.
parameter format: mbuf_check=[mbuf,,]
eg: dpdk-testpmd -a :81:01.0,mbuf_check=[mbuf,size] -- -i
Signed-off-by: Mingjin Ye
---
v2: Remove call chain.
---
v3: Optimisation implementation.
---
v4: Fix Windows os compilation error.
---
v5: Split Patch.
---
doc/guides/nics/intel_vf.rst | 4 ++
drivers/net/iavf/iavf.h| 13 +
drivers/net/iavf/iavf_ethdev.c | 70 ++
drivers/net/iavf/iavf_rxtx.c | 104 +
drivers/net/iavf/iavf_rxtx.h | 2 +
5 files changed, 193 insertions(+)
diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst
index ad08198f0f..8e39bc831c 100644
--- a/doc/guides/nics/intel_vf.rst
+++ b/doc/guides/nics/intel_vf.rst
@@ -111,6 +111,10 @@ For more detail on SR-IOV, please refer to the following
documents:
by setting the ``devargs`` parameter like ``-a
18:01.0,no-poll-on-link-down=1``
when IAVF is backed by an Intel\ |reg| E810 device or an Intel\ |reg| 700
Series Ethernet device.
+Enable mbuf check for Tx diagnostics by setting the devargs parameter like
+``-a 18:01.0,mbuf_check=[mbuf,,]`` when IAVF is backed by an
+Intel\ |reg| E810 device or an Intel\ |reg| 700 Series Ethernet device.
+
The PCIE host-interface of Intel Ethernet Switch FM1 Series VF
infrastructure
^
diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 4cd5bea167..b81329bb56 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -113,9 +113,14 @@ struct iavf_ipsec_crypto_stats {
} ierrors;
};
+struct iavf_mbuf_stats {
+ uint64_t tx_pkt_errors;
+};
+
struct iavf_eth_xstats {
struct virtchnl_eth_stats eth_stats;
struct iavf_ipsec_crypto_stats ips_stats;
+ struct iavf_mbuf_stats mbuf_stats;
};
/* Structure that defines a VSI, associated with a adapter. */
@@ -309,10 +314,17 @@ struct iavf_devargs {
uint32_t watchdog_period;
int auto_reset;
int no_poll_on_link_down;
+ int mbuf_check;
};
struct iavf_security_ctx;
+#define IAVF_MBUF_CHECK_F_TX_MBUF(1ULL << 0)
+#define IAVF_MBUF_CHECK_F_TX_SIZE(1ULL << 1)
+#define IAVF_MBUF_CHECK_F_TX_SEGMENT (1ULL << 2)
+#define IAVF_MBUF_CHECK_F_TX_OFFLOAD (1ULL << 3)
+#define IAVF_MBUF_CHECK_F_TX_STRICT (1ULL << 4)
+
enum iavf_tx_pkt_burst_type {
IAVF_PKT_BURST_DEFAULT = 0,
IAVF_PKT_BURST_VEC = 1,
@@ -340,6 +352,7 @@ struct iavf_adapter {
bool no_poll;
eth_rx_burst_t rx_pkt_burst;
enum iavf_tx_pkt_burst_type tx_burst_type;
+ uint64_t mc_flags; /* mbuf check flags. */
uint16_t fdir_ref_cnt;
struct iavf_devargs devargs;
};
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index d1edb0dd5c..5398d2783f 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -39,6 +40,8 @@
#define IAVF_RESET_WATCHDOG_ARG"watchdog_period"
#define IAVF_ENABLE_AUTO_RESET_ARG "auto_reset"
#define IAVF_NO_POLL_ON_LINK_DOWN_ARG "no-poll-on-link-down"
+#define IAVF_MBUF_CHECK_ARG "mbuf_check"
+
uint64_t iavf_timestamp_dynflag;
int iavf_timestamp_dynfield_offset = -1;
@@ -48,6 +51,7 @@ static const char * const iavf_valid_args[] = {
IAVF_RESET_WATCHDOG_ARG,
IAVF_ENABLE_AUTO_RESET_ARG,
IAVF_NO_POLL_ON_LINK_DOWN_ARG,
+ IAVF_MBUF_CHECK_ARG,
NULL
};
@@ -174,6 +178,7 @@ static const struct rte_iavf_xstats_name_off
rte_iavf_stats_strings[] = {
{"tx_broadcast_packets", _OFF_OF(eth_stats.tx_broadcast)},
{"tx_dropped_packets", _OFF_OF(eth_stats.tx_discards)},
{"tx_error_packets", _OFF_OF(eth_stats.tx_errors)},
+ {"tx_mbuf_error_packets", _OFF_OF(mbuf_stats.tx_pkt_errors)},
{"inline_ipsec_crypto_ipackets", _OFF_OF(ips_stats.icount)},
{"inline_ipsec_crypto_ibytes", _OFF_OF(ips_stats.ibytes)},
@@ -1881,6 +1886,8 @@ static int iavf_dev_xstats_get(struct rte_eth_dev *dev,
{
int ret;
unsigned int i;
+ struct iavf_tx_queue *txq;
+ uint64_t mbuf_errors = 0;
struct iavf_adapter *adapter =
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct iav
RE: [PATCH v5 1/2] net/iavf: fix Tx path error in multi-process
> -Original Message-
> From: Mingjin Ye
> Sent: Thursday, December 28, 2023 6:26 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming ; Ye, MingjinX
> ; sta...@dpdk.org; Wu, Jingjing
> ; Xing, Beilei
> Subject: [PATCH v5 1/2] net/iavf: fix Tx path error in multi-process
>
> In a multi-process environment, a secondary process operates on shared
> memory and changes the PMD transmit function pointer of the primary
> process, causing the primary process to send pkts without being able to find
> the function address, resulting in a crash.
>
> Fixes: 5b3124a0a6ef ("net/iavf: support no polling when link down")
> Cc: sta...@dpdk.org
Should Rx also need to be fixed? please make a complete fix.
>
> Signed-off-by: Mingjin Ye
> ---
> drivers/net/iavf/iavf.h | 12 +++-
> drivers/net/iavf/iavf_rxtx.c | 34 +++---
> drivers/net/iavf/iavf_rxtx.h | 3 +++
> 3 files changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h index
> 10868f2c30..4cd5bea167 100644
> --- a/drivers/net/iavf/iavf.h
> +++ b/drivers/net/iavf/iavf.h
> @@ -313,6 +313,16 @@ struct iavf_devargs {
>
> struct iavf_security_ctx;
>
> +enum iavf_tx_pkt_burst_type {
> + IAVF_PKT_BURST_DEFAULT = 0,
> + IAVF_PKT_BURST_VEC = 1,
Better to rename with xxx_VEC_SSE
[PATCH] net/hns3: don't support QinQ insert for VF
From: Chengwen Feng
In the HIP08 platform, the PF driver will notify VF driver to update
the PVID state [1], and VF will declare support QinQ insert when PVID
is disabled.
In the later platform (e.g. HIP09), the hardware has been improved,
so the PF driver will NOT notify VF driver to update the PVID state.
However, the later platform still have constraint: PVID and QinQ insert
cannot be enabled at the same time, otherwise, the hardware discards
packets and reports an error interrupt.
Plus, as far as we known, VF driver's users don't use the QinQ insert.
Therefore, we declare that the VF driver don't support QinQ insert.
[1] commit b4e4d7ac9f09 ("net/hns3: support setting VF PVID by PF driver")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
Signed-off-by: Jie Hai
---
drivers/net/hns3/hns3_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hns3/hns3_common.c b/drivers/net/hns3/hns3_common.c
index 8f224aa00c7b..28c26b049cf9 100644
--- a/drivers/net/hns3/hns3_common.c
+++ b/drivers/net/hns3/hns3_common.c
@@ -85,7 +85,7 @@ hns3_dev_infos_get(struct rte_eth_dev *eth_dev, struct
rte_eth_dev_info *info)
RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE |
RTE_ETH_TX_OFFLOAD_VLAN_INSERT);
- if (!hw->port_base_vlan_cfg.state)
+ if (!hns->is_vf && !hw->port_base_vlan_cfg.state)
info->tx_offload_capa |= RTE_ETH_TX_OFFLOAD_QINQ_INSERT;
if (hns3_dev_get_support(hw, OUTER_UDP_CKSUM))
--
2.30.0
RE: [RFC] ethdev: fast path async flow API
Hi Stephen,
> > +/**
> > + * @internal
> > + *
> > + * Fast path async flow functions and related data are held in a flat
> > array,
> one entry per ethdev.
> > + * It is assumed that each entry is read-only and cache aligned.
> > + */
> > +struct rte_flow_fp_ops {
> > + void *ctx;
> > + rte_flow_async_create_t async_create;
> > + rte_flow_async_create_by_index_t async_create_by_index;
> > + rte_flow_async_actions_update_t async_actions_update;
> > + rte_flow_async_destroy_t async_destroy;
> > + rte_flow_push_t push;
> > + rte_flow_pull_t pull;
> > + rte_flow_async_action_handle_create_t async_action_handle_create;
> > + rte_flow_async_action_handle_destroy_t async_action_handle_destroy;
> > + rte_flow_async_action_handle_update_t async_action_handle_update;
> > + rte_flow_async_action_handle_query_t async_action_handle_query;
> > + rte_flow_async_action_handle_query_update_t
> async_action_handle_query_update;
> > + rte_flow_async_action_list_handle_create_t
> async_action_list_handle_create;
> > + rte_flow_async_action_list_handle_destroy_t
> async_action_list_handle_destroy;
> > + rte_flow_async_action_list_handle_query_update_t
> async_action_list_handle_query_update;
> > +} __rte_cache_aligned;
>
> If you go ahead with this then all usage should be const pointer.
> Still think it is bad idea and creates even more technical debt.
Could you please elaborate a bit more on why do you think it is a bad idea and
why it creates technical debt?
> > **Future considerations**
> >
> > A case can be made about converting some of the existing stable API
> > functions to fast path versions in future LTS releases.
> > I don't have any hard data on how such changes would affect
> > performance of these APIs, but I assume that the improvement would be
> > noticeable.
>
> The problem is that inline functions create future ABI problems.
Agreed, this is why such a change can only be introduced when a new major ABI
version is released.
However, even though inlining could reduce function call overhead, I'm not sure
if such a change is needed for synchronous flow API.
I mentioned it here as a thing to consider.
> Usually, there are other ways to get the same performance benefit.
> Often batching updates to hardware will do the trick.
This is true, but we still have some library-level overhead.
To elaborate more, the current state of flow API is as follows:
- With sync flow API:
- Applications cannot batch flow operations.
- With async flow APIs:
- Applications can enqueue multiple flow operations and PMDs can issue
batches to HW.
- But there is still one function call per enqueued flow operation.
The overall API overhead in datapath may be nonnegligible if we consider
that applications may enqueue a flow rule creation operation for every packet
received in SW.
This proposal specifically aims at reducing API overhead for async flow API in
a case mentioned above.
As a side note, we plan to push changes to mlx5 PMD in 24.03 which will reduce
PMD overhead in such scenarios.
This proposal's goal is to reduce overhead of async flow API at library level.
Best regards,
Dariusz Sosnowski
RE: [RFC] ethdev: fast path async flow API
Hi Dariusz,
I appreciate the proposal. You say that a reference PMD implementation
will be made available for 24.03 release. What about the applications?
Is this supposed to go to upstream code of some applications?
Thank you.
On Thu, 28 Dec 2023, Dariusz Sosnowski wrote:
Hi Stephen,
+/**
+ * @internal
+ *
+ * Fast path async flow functions and related data are held in a flat array,
one entry per ethdev.
+ * It is assumed that each entry is read-only and cache aligned.
+ */
+struct rte_flow_fp_ops {
+ void *ctx;
+ rte_flow_async_create_t async_create;
+ rte_flow_async_create_by_index_t async_create_by_index;
+ rte_flow_async_actions_update_t async_actions_update;
+ rte_flow_async_destroy_t async_destroy;
+ rte_flow_push_t push;
+ rte_flow_pull_t pull;
+ rte_flow_async_action_handle_create_t async_action_handle_create;
+ rte_flow_async_action_handle_destroy_t async_action_handle_destroy;
+ rte_flow_async_action_handle_update_t async_action_handle_update;
+ rte_flow_async_action_handle_query_t async_action_handle_query;
+ rte_flow_async_action_handle_query_update_t
async_action_handle_query_update;
+ rte_flow_async_action_list_handle_create_t
async_action_list_handle_create;
+ rte_flow_async_action_list_handle_destroy_t
async_action_list_handle_destroy;
+ rte_flow_async_action_list_handle_query_update_t
async_action_list_handle_query_update;
+} __rte_cache_aligned;
If you go ahead with this then all usage should be const pointer.
Still think it is bad idea and creates even more technical debt.
Could you please elaborate a bit more on why do you think it is a bad idea and
why it creates technical debt?
**Future considerations**
A case can be made about converting some of the existing stable API
functions to fast path versions in future LTS releases.
I don't have any hard data on how such changes would affect
performance of these APIs, but I assume that the improvement would be
noticeable.
The problem is that inline functions create future ABI problems.
Agreed, this is why such a change can only be introduced when a new major ABI
version is released.
However, even though inlining could reduce function call overhead, I'm not sure
if such a change is needed for synchronous flow API.
I mentioned it here as a thing to consider.
Usually, there are other ways to get the same performance benefit.
Often batching updates to hardware will do the trick.
This is true, but we still have some library-level overhead.
To elaborate more, the current state of flow API is as follows:
- With sync flow API:
- Applications cannot batch flow operations.
- With async flow APIs:
- Applications can enqueue multiple flow operations and PMDs can issue batches
to HW.
- But there is still one function call per enqueued flow operation.
The overall API overhead in datapath may be nonnegligible if we consider
that applications may enqueue a flow rule creation operation for every packet
received in SW.
This proposal specifically aims at reducing API overhead for async flow API in
a case mentioned above.
As a side note, we plan to push changes to mlx5 PMD in 24.03 which will reduce
PMD overhead in such scenarios.
This proposal's goal is to reduce overhead of async flow API at library level.
Best regards,
Dariusz Sosnowski
Re: [RFC] ethdev: fast path async flow API
> However, at the moment I see one problem with this approach. > It would require DPDK to expose the rte_eth_dev struct definition, > because of implied locking implemented in the flow API. This is a blocker, showstopper for me. Have you considered having something like rte_flow_create_bulk() or better yet a Linux iouring style API? A ring style API would allow for better mixed operations across the board and get rid of the I-cache overhead which is the root cause of the needing inline.
[RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW
This commit adds comments for the proposal of addition of SM2
algorithm key exchange and encryption/decryption operation.
Signed-off-by: Arkadiusz Kusztal
---
lib/cryptodev/rte_crypto_asym.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 39d3da3952..6911a14dbd 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -639,6 +639,10 @@ struct rte_crypto_asym_xform {
struct rte_crypto_sm2_op_param {
enum rte_crypto_asym_op_type op_type;
/**< Signature generation or verification. */
+ /*
+* For key exchange operation, new struct should be created.
+* Doing that, the current struct could be split into signature and
encryption.
+*/
enum rte_crypto_auth_algorithm hash;
/**< Hash algorithm used in EC op. */
@@ -672,6 +676,18 @@ struct rte_crypto_sm2_op_param {
* C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
* be overwritten by the PMD with the encrypted length.
*/
+ /* SM2 encryption algorithm relies on certain cryptographic functions,
+* that HW devices not necesseraly need to implement.
+* When C1 is a elliptic curve point, C2 and C3 need additional
+* operation like KDF and Hash. The question here is: should only
+* elliptic curve output parameters (namely C1 and PB) be returned to
the user,
+* or should encryption be, in this case, computed within the PMD using
+* software methods, or should both option be available?
+*/
+ /* Similar applies to the key exchange in the HW. The second phase of
KE, most likely,
+* will go as far as to obtain xU,yU(xV,xV), where SW can easily
calculate SA.
+* Should then both options be available?
+*/
rte_crypto_uint id;
/**< The SM2 id used by signer and verifier. */
--
2.13.6
