Re: [dpdk-dev] [dpdk-dev 01/12] net/ice: initialize and set up flow director
On 09/06, Yahui Cao wrote:
>From: Beilei Xing
>
>Enable flow director, include:
> - Create control VSI
> - Queue pair allocated and set up
> - Programming packet
>
>Signed-off-by: Beilei Xing
>---
> drivers/net/ice/Makefile | 1 +
> drivers/net/ice/ice_ethdev.c | 107 +--
> drivers/net/ice/ice_ethdev.h | 19 ++
> drivers/net/ice/ice_fdir_filter.c | 139 +
> drivers/net/ice/ice_rxtx.c| 448 ++
> drivers/net/ice/ice_rxtx.h| 7 +
> drivers/net/ice/meson.build | 3 +-
document and release note updates are needed here.
> 7 files changed, 704 insertions(+), 20 deletions(-)
> create mode 100644 drivers/net/ice/ice_fdir_filter.c
>
>diff --git a/drivers/net/ice/Makefile b/drivers/net/ice/Makefile
>index ae53c2646..cbbd03fcf 100644
>--- a/drivers/net/ice/Makefile
>+++ b/drivers/net/ice/Makefile
>@@ -62,6 +62,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_rxtx_vec_sse.c
> endif
>
> SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_switch_filter.c
>+SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_fdir_filter.c
> ifeq ($(findstring
> RTE_MACHINE_CPUFLAG_AVX2,$(CFLAGS)),RTE_MACHINE_CPUFLAG_AVX2)
> CC_AVX2_SUPPORT=1
> else
>diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
>index 647aca3ed..cb32f08df 100644
>--- a/drivers/net/ice/ice_ethdev.c
>+++ b/drivers/net/ice/ice_ethdev.c
>@@ -1097,11 +1097,20 @@ ice_pf_sw_init(struct rte_eth_dev *dev)
> hw->func_caps.common_cap.num_rxq);
>
> pf->lan_nb_qps = pf->lan_nb_qp_max;
>+ if (hw->func_caps.fd_fltr_guar > 0 ||
>+ hw->func_caps.fd_fltr_best_effort > 0) {
>+ pf->flags |= ICE_FLAG_FDIR;
>+ pf->fdir_nb_qps = ICE_DEFAULT_QP_NUM_FDIR;
>+ pf->lan_nb_qps = pf->lan_nb_qp_max - pf->fdir_nb_qps;
>+ } else {
>+ pf->fdir_nb_qps = 0;
>+ }
>+ pf->fdir_qp_offset = 0;
>
> return 0;
> }
>
>-static struct ice_vsi *
>+struct ice_vsi *
> ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
> {
> struct ice_hw *hw = ICE_PF_TO_HW(pf);
>@@ -1113,6 +1122,7 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
> struct rte_ether_addr mac_addr;
> uint16_t max_txqs[ICE_MAX_TRAFFIC_CLASS] = { 0 };
> uint8_t tc_bitmap = 0x1;
>+ uint16_t cfg;
>
> /* hw->num_lports = 1 in NIC mode */
> vsi = rte_zmalloc(NULL, sizeof(struct ice_vsi), 0);
>@@ -1136,14 +1146,10 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type
>type)
> pf->flags |= ICE_FLAG_RSS_AQ_CAPABLE;
>
> memset(&vsi_ctx, 0, sizeof(vsi_ctx));
>- /* base_queue in used in queue mapping of VSI add/update command.
>- * Suppose vsi->base_queue is 0 now, don't consider SRIOV, VMDQ
>- * cases in the first stage. Only Main VSI.
>- */
>- vsi->base_queue = 0;
> switch (type) {
> case ICE_VSI_PF:
> vsi->nb_qps = pf->lan_nb_qps;
>+ vsi->base_queue = 1;
> ice_vsi_config_default_rss(&vsi_ctx.info);
> vsi_ctx.alloc_from_pool = true;
> vsi_ctx.flags = ICE_AQ_VSI_TYPE_PF;
>@@ -1157,6 +1163,18 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
> vsi_ctx.info.vlan_flags |= ICE_AQ_VSI_VLAN_EMOD_NOTHING;
> vsi_ctx.info.q_opt_rss = ICE_AQ_VSI_Q_OPT_RSS_LUT_PF |
>ICE_AQ_VSI_Q_OPT_RSS_TPLZ;
>+
>+ /* FDIR */
>+ cfg = ICE_AQ_VSI_PROP_SECURITY_VALID |
>+ ICE_AQ_VSI_PROP_FLOW_DIR_VALID;
>+ vsi_ctx.info.valid_sections |= rte_cpu_to_le_16(cfg);
>+ cfg = ICE_AQ_VSI_FD_ENABLE | ICE_AQ_VSI_FD_PROG_ENABLE;
>+ vsi_ctx.info.fd_options = rte_cpu_to_le_16(cfg);
>+ vsi_ctx.info.max_fd_fltr_dedicated =
>+ rte_cpu_to_le_16(hw->func_caps.fd_fltr_guar);
>+ vsi_ctx.info.max_fd_fltr_shared =
>+ rte_cpu_to_le_16(hw->func_caps.fd_fltr_best_effort);
>+
> /* Enable VLAN/UP trip */
> ret = ice_vsi_config_tc_queue_mapping(vsi,
> &vsi_ctx.info,
>@@ -1169,6 +1187,28 @@ ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type)
> goto fail_mem;
> }
>
>+ break;
>+ case ICE_VSI_CTRL:
>+ vsi->nb_qps = pf->fdir_nb_qps;
>+ vsi->base_queue = ICE_FDIR_QUEUE_ID;
>+ vsi_ctx.alloc_from_pool = true;
>+ vsi_ctx.flags = ICE_AQ_VSI_TYPE_PF;
>+
>+ cfg = ICE_AQ_VSI_PROP_FLOW_DIR_VALID;
>+ vsi_ctx.info.valid_sections |= rte_cpu_to_le_16(cfg);
>+ cfg = ICE_AQ_VSI_FD_ENABLE | ICE_AQ_VSI_FD_PROG_ENABLE;
>+ vsi_ctx.info.fd_options = rte_cpu_to_le_16(cfg);
>+ vsi_ctx.info.sw_id = hw->port_info->sw_id;
>+ ret = ice_vsi_config_tc_queue_mapping(vsi
Re: [dpdk-dev] [dpdk-dev 02/12] net/ice: tear down flow director
On 09/06, Yahui Cao wrote:
>From: Beilei Xing
>
>Release resources on flow director, include:
> - Release queue.
> - Release VSI.
>
>Signed-off-by: Beilei Xing
>---
> drivers/net/ice/ice_fdir_filter.c | 40 ++
> drivers/net/ice/ice_rxtx.c| 57 +++
> drivers/net/ice/ice_rxtx.h| 2 ++
Update document and release as well, and what about combine this patch with
prior patch, I think together they enable the FDIR engine.
> 3 files changed, 99 insertions(+)
>
>diff --git a/drivers/net/ice/ice_fdir_filter.c
>b/drivers/net/ice/ice_fdir_filter.c
>index 03d143058..451ef92b2 100644
>--- a/drivers/net/ice/ice_fdir_filter.c
>+++ b/drivers/net/ice/ice_fdir_filter.c
>@@ -117,6 +117,37 @@ ice_fdir_setup(struct ice_pf *pf)
> return err;
> }
>
>+/*
>+ * ice_fdir_teardown - release the Flow Director resources
>+ * @pf: board private structure
>+ */
>+static void
>+ice_fdir_teardown(struct ice_pf *pf)
>+{
>+ struct rte_eth_dev *eth_dev = pf->adapter->eth_dev;
>+ struct ice_vsi *vsi;
>+ int err;
>+
>+ vsi = pf->fdir.fdir_vsi;
>+ if (!vsi)
>+ return;
>+
>+ err = ice_fdir_tx_queue_stop(eth_dev, pf->fdir.txq->queue_id);
>+ if (err)
>+ PMD_DRV_LOG(ERR, "Failed to stop TX queue.");
>+
>+ err = ice_fdir_rx_queue_stop(eth_dev, pf->fdir.rxq->queue_id);
>+ if (err)
>+ PMD_DRV_LOG(ERR, "Failed to stop RX queue.");
>+
>+ ice_tx_queue_release(pf->fdir.txq);
>+ pf->fdir.txq = NULL;
>+ ice_rx_queue_release(pf->fdir.rxq);
>+ pf->fdir.rxq = NULL;
>+ ice_release_vsi(vsi);
>+ pf->fdir.fdir_vsi = NULL;
>+}
>+
> static int
> ice_init_fdir_filter(struct ice_adapter *ad)
> {
>@@ -128,8 +159,17 @@ ice_init_fdir_filter(struct ice_adapter *ad)
> return ret;
> }
>
>+static void
>+ice_uninit_fdir_filter(struct ice_adapter *ad)
>+{
>+ struct ice_pf *pf = &ad->pf;
>+
>+ ice_fdir_teardown(pf);
>+}
>+
> static struct ice_flow_engine ice_fdir_engine = {
> .init = ice_init_fdir_filter,
>+ .uninit = ice_uninit_fdir_filter,
> .type = ICE_FLOW_ENGINE_FDIR,
> };
>
>diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
>index bd802e350..e41fcb194 100644
>--- a/drivers/net/ice/ice_rxtx.c
>+++ b/drivers/net/ice/ice_rxtx.c
>@@ -748,6 +748,63 @@ ice_tx_queue_stop(struct rte_eth_dev *dev, uint16_t
>tx_queue_id)
> return 0;
> }
>
>+int
>+ice_fdir_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id)
>+{
>+ struct ice_rx_queue *rxq;
>+ int err;
>+ struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>+ struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
>+
>+ rxq = pf->fdir.rxq;
>+
>+ err = ice_switch_rx_queue(hw, rxq->reg_idx, FALSE);
>+ if (err) {
>+ PMD_DRV_LOG(ERR, "Failed to switch FDIR RX queue %u off",
>+ rx_queue_id);
>+ return -EINVAL;
>+ }
>+ ice_rx_queue_release_mbufs(rxq);
>+
>+ return 0;
>+}
>+
>+int
>+ice_fdir_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id)
>+{
>+ struct ice_tx_queue *txq;
>+ struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>+ struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
>+ struct ice_vsi *vsi = pf->main_vsi;
>+ enum ice_status status;
>+ uint16_t q_ids[1];
>+ uint32_t q_teids[1];
>+ uint16_t q_handle = tx_queue_id;
>+
>+ txq = pf->fdir.txq;
>+ if (!txq) {
>+ PMD_DRV_LOG(ERR, "TX queue %u is not available",
>+ tx_queue_id);
>+ return -EINVAL;
>+ }
>+ vsi = txq->vsi;
>+
>+ q_ids[0] = txq->reg_idx;
>+ q_teids[0] = txq->q_teid;
>+
>+ /* Fix me, we assume TC always 0 here */
>+ status = ice_dis_vsi_txq(hw->port_info, vsi->idx, 0, 1, &q_handle,
>+ q_ids, q_teids, ICE_NO_RESET, 0, NULL);
>+ if (status != ICE_SUCCESS) {
>+ PMD_DRV_LOG(DEBUG, "Failed to disable Lan Tx queue");
>+ return -EINVAL;
>+ }
>+
>+ ice_tx_queue_release_mbufs(txq);
>+
>+ return 0;
>+}
Better to reuse ice_rx/tx_queue_stop.
Thanks,
Xiaolong
>+
> int
> ice_rx_queue_setup(struct rte_eth_dev *dev,
> uint16_t queue_idx,
>diff --git a/drivers/net/ice/ice_rxtx.h b/drivers/net/ice/ice_rxtx.h
>index 450db0244..24376c0d5 100644
>--- a/drivers/net/ice/ice_rxtx.h
>+++ b/drivers/net/ice/ice_rxtx.h
>@@ -151,6 +151,8 @@ int ice_tx_queue_start(struct rte_eth_dev *dev, uint16_t
>tx_queue_id);
> int ice_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id);
> int ice_fdir_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);
> int ice_fdir_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id);
>+int ice_fdir_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
>+int ice_fdir_tx_queue_stop(struct rte_eth_dev *de
Re: [dpdk-dev] [dpdk-dev 03/12] net/ice: enable input set configuration
On 09/06, Yahui Cao wrote:
>From: Beilei Xing
>
>Configure input set, include:
> - Parse input set.
> - Check the segment.
> - Create profile.
I'd prefer more descriptive sentences in commit log than a few bullets.
>
>Signed-off-by: Beilei Xing
>---
> drivers/net/ice/ice_ethdev.h | 3 +
> drivers/net/ice/ice_fdir_filter.c | 245 ++
> 2 files changed, 248 insertions(+)
>
>diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
>index c43242b63..ea68858d1 100644
>--- a/drivers/net/ice/ice_ethdev.h
>+++ b/drivers/net/ice/ice_ethdev.h
>@@ -366,6 +366,9 @@ struct ice_vsi *
> ice_setup_vsi(struct ice_pf *pf, enum ice_vsi_type type);
> int
> ice_release_vsi(struct ice_vsi *vsi);
>+int
>+ice_fdir_input_set_conf(struct ice_pf *pf, enum ice_fltr_ptype flow,
>+ uint64_t input_set);
>
> static inline int
> ice_align_floor(int n)
>diff --git a/drivers/net/ice/ice_fdir_filter.c
>b/drivers/net/ice/ice_fdir_filter.c
>index 451ef92b2..0840c3b4b 100644
>--- a/drivers/net/ice/ice_fdir_filter.c
>+++ b/drivers/net/ice/ice_fdir_filter.c
>@@ -148,6 +148,251 @@ ice_fdir_teardown(struct ice_pf *pf)
> pf->fdir.fdir_vsi = NULL;
> }
>
>+static void
>+ice_fdir_rm_prof(struct ice_hw *hw, enum ice_fltr_ptype ptype)
>+{
>+ struct ice_fd_hw_prof *hw_prof = hw->fdir_prof[ptype];
>+ uint64_t prof_id;
>+ uint16_t vsi_num;
>+ int tun;
>+ int i;
>+
>+ if (!hw->fdir_prof || !hw->fdir_prof[ptype])
>+ return;
>+
>+ for (tun = 0; tun < ICE_FD_HW_SEG_MAX; tun++) {
>+ if (!hw_prof->fdir_seg[tun])
>+ break;
>+ prof_id = ptype + tun * ICE_FLTR_PTYPE_MAX;
>+ for (i = 0; i < hw_prof->cnt; i++) {
>+ if (hw_prof->entry_h[i][tun]) {
>+ vsi_num = ice_get_hw_vsi_num(hw,
>+ hw_prof->vsi_h[i]);
>+ ice_rem_prof_id_flow(hw, ICE_BLK_FD,
>+ vsi_num, ptype);
>+ ice_flow_rem_entry(hw,
>+ hw_prof->entry_h[i][tun]);
>+ hw_prof->entry_h[i][tun] = 0;
>+ }
>+ }
>+ ice_flow_rem_prof(hw, ICE_BLK_FD, prof_id);
>+ rte_free(hw_prof->fdir_seg[tun]);
>+ hw_prof->fdir_seg[tun] = NULL;
>+ }
>+ for (i = 0; i < hw_prof->cnt; i++)
>+ hw_prof->vsi_h[i] = 0;
memset(hw_prof->vsi_h, 0, hw_prof->cnt);
>+ hw_prof->cnt = 0;
>+}
>+
>+static int
>+ice_fdir_cfg_hw_tbl(struct ice_pf *pf, struct ice_vsi *vsi,
>+ struct ice_vsi *ctrl_vsi,
>+ struct ice_flow_seg_info *seg,
>+ enum ice_fltr_ptype ptype,
>+ bool is_tunnel)
>+{
>+ struct ice_hw *hw = ICE_PF_TO_HW(pf);
>+ enum ice_flow_dir dir = ICE_FLOW_RX;
>+ struct ice_flow_seg_info *ori_seg;
>+ struct ice_fd_hw_prof *hw_prof;
>+ struct ice_flow_prof *prof;
>+ uint64_t entry_1 = 0;
>+ uint64_t entry_2 = 0;
>+ uint16_t vsi_num;
>+ int ret;
>+ uint64_t prof_id;
>+
>+ if (!hw->fdir_prof) {
>+ hw->fdir_prof = (struct ice_fd_hw_prof **)
>+ ice_malloc(hw, ICE_FLTR_PTYPE_MAX *
>+ sizeof(*hw->fdir_prof));
>+ if (!hw->fdir_prof)
>+ return -ENOMEM;
>+ }
>+ if (!hw->fdir_prof[ptype]) {
>+ hw->fdir_prof[ptype] = (struct ice_fd_hw_prof *)
>+ ice_malloc(hw, sizeof(**hw->fdir_prof));
>+ if (!hw->fdir_prof[ptype])
>+ return -ENOMEM;
>+ }
when will we free hw->fdir_prof and hw->fdir_prof[ptype]?
>+
>+ hw_prof = hw->fdir_prof[ptype];
>+ ori_seg = hw_prof->fdir_seg[is_tunnel];
>+ if (ori_seg) {
>+ if (!memcmp(ori_seg, seg, sizeof(*seg)))
>+ return -EAGAIN;
>+ if (hw->fdir_fltr_cnt[ptype])
>+ return -EINVAL;
>+
>+ ice_fdir_rm_prof(hw, ptype);
>+ }
>+
>+ prof_id = ptype + is_tunnel * ICE_FLTR_PTYPE_MAX;
>+ ret = ice_flow_add_prof(hw, ICE_BLK_FD, dir, prof_id, seg,
>+ (is_tunnel) ? 2 : 1, NULL, 0, &prof);
>+ if (ret)
>+ return ret;
>+ ret = ice_flow_add_entry(hw, ICE_BLK_FD, prof_id, vsi->idx,
>+ vsi->idx, ICE_FLOW_PRIO_NORMAL,
>+ seg, NULL, 0, &entry_1);
>+ if (ret) {
>+ PMD_DRV_LOG(ERR, "Failed to add main VSI flow entry for %d.",
>+ ptype);
>+ goto err_add_prof;
>+ }
>+ ret = ice_flow_add_entry(hw, ICE_BLK_FD, prof_id, vsi->idx,
>+ ctrl_vsi->idx, ICE_FLOW_PRIO_NORMAL,
>+
Re: [dpdk-dev] [dpdk-dev 04/12] net/ice: add FDIR create and destroy
On 09/06, Yahui Cao wrote:
>Add ice_create_fdir_filter to create a rule. If a flow is matched by
>flow director filter, filter rule will be set to HW. Only basic pattern
>and queue/passthru/drop are supported.
Only basic patterns and queue/passthru/drop actions are supported?
>
>Add ice_destroy_fdir_filter to destroy a rule. If a flow is created
>before, filter rule will be removed from HW.
>
>Signed-off-by: Yahui Cao
>---
> drivers/net/ice/ice_ethdev.h | 6 +
> drivers/net/ice/ice_fdir_filter.c | 508 ++
> 2 files changed, 514 insertions(+)
>
>diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
>index ea68858d1..bb821bc41 100644
>--- a/drivers/net/ice/ice_ethdev.h
>+++ b/drivers/net/ice/ice_ethdev.h
>@@ -249,6 +249,11 @@ TAILQ_HEAD(ice_flow_list, rte_flow);
> struct ice_flow_parser;
> TAILQ_HEAD(ice_parser_list, ice_flow_parser);
>
>+struct ice_fdir_filter_conf {
>+ struct ice_fdir_fltr input;
>+ uint64_t input_set;
>+};
>+
> /**
> * A structure used to define fields of a FDIR related info.
> */
>@@ -258,6 +263,7 @@ struct ice_fdir_info {
> struct ice_rx_queue *rxq;
> void *prg_pkt; /* memory for fdir program packet */
> uint64_t dma_addr; /* physic address of packet memory*/
>+ struct ice_fdir_filter_conf conf;
> };
>
> struct ice_pf {
>diff --git a/drivers/net/ice/ice_fdir_filter.c
>b/drivers/net/ice/ice_fdir_filter.c
>index 0840c3b4b..98bc1be49 100644
>--- a/drivers/net/ice/ice_fdir_filter.c
>+++ b/drivers/net/ice/ice_fdir_filter.c
>@@ -7,6 +7,51 @@
> #include "ice_rxtx.h"
> #include "ice_generic_flow.h"
>
>+#define ICE_FDIR_INSET_ETH_IPV4 (\
>+ ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | ICE_INSET_IPV4_TOS | \
>+ ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO)
>+
>+#define ICE_FDIR_INSET_ETH_IPV4_UDP (\
>+ ICE_FDIR_INSET_ETH_IPV4 | \
>+ ICE_INSET_UDP_SRC_PORT | ICE_INSET_UDP_DST_PORT)
>+
>+#define ICE_FDIR_INSET_ETH_IPV4_TCP (\
>+ ICE_FDIR_INSET_ETH_IPV4 | \
>+ ICE_INSET_TCP_SRC_PORT | ICE_INSET_TCP_DST_PORT)
>+
>+#define ICE_FDIR_INSET_ETH_IPV4_SCTP (\
>+ ICE_FDIR_INSET_ETH_IPV4 | \
>+ ICE_INSET_SCTP_SRC_PORT | ICE_INSET_SCTP_DST_PORT)
>+
>+#define ICE_FDIR_INSET_ETH_IPV6 (\
>+ ICE_INSET_IPV6_SRC | ICE_INSET_IPV6_DST | ICE_INSET_IPV6_TC | \
>+ ICE_INSET_IPV6_HOP_LIMIT | ICE_INSET_IPV6_NEXT_HDR)
>+
>+#define ICE_FDIR_INSET_ETH_IPV6_UDP (\
>+ ICE_FDIR_INSET_ETH_IPV6 | \
>+ ICE_INSET_UDP_SRC_PORT | ICE_INSET_UDP_DST_PORT)
>+
>+#define ICE_FDIR_INSET_ETH_IPV6_TCP (\
>+ ICE_FDIR_INSET_ETH_IPV6 | \
>+ ICE_INSET_TCP_SRC_PORT | ICE_INSET_TCP_DST_PORT)
>+
>+#define ICE_FDIR_INSET_ETH_IPV6_SCTP (\
>+ ICE_FDIR_INSET_ETH_IPV6 | \
>+ ICE_INSET_SCTP_SRC_PORT | ICE_INSET_SCTP_DST_PORT)
>+
>+static struct ice_pattern_match_item ice_fdir_pattern[] = {
>+ {pattern_eth_ipv4, ICE_FDIR_INSET_ETH_IPV4,
>ICE_INSET_NONE},
>+ {pattern_eth_ipv4_udp, ICE_FDIR_INSET_ETH_IPV4_UDP,
>ICE_INSET_NONE},
>+ {pattern_eth_ipv4_tcp, ICE_FDIR_INSET_ETH_IPV4_TCP,
>ICE_INSET_NONE},
>+ {pattern_eth_ipv4_sctp,ICE_FDIR_INSET_ETH_IPV4_SCTP,
>ICE_INSET_NONE},
>+ {pattern_eth_ipv6, ICE_FDIR_INSET_ETH_IPV6,
>ICE_INSET_NONE},
>+ {pattern_eth_ipv6_udp, ICE_FDIR_INSET_ETH_IPV6_UDP,
>ICE_INSET_NONE},
>+ {pattern_eth_ipv6_tcp, ICE_FDIR_INSET_ETH_IPV6_TCP,
>ICE_INSET_NONE},
>+ {pattern_eth_ipv6_sctp,ICE_FDIR_INSET_ETH_IPV6_SCTP,
>ICE_INSET_NONE},
>+};
>+
>+static struct ice_flow_parser ice_fdir_parser;
>+
> static const struct rte_memzone *
> ice_memzone_reserve(const char *name, uint32_t len, int socket_id)
> {
>@@ -400,6 +445,10 @@ ice_init_fdir_filter(struct ice_adapter *ad)
> int ret;
>
> ret = ice_fdir_setup(pf);
>+ if (ret)
>+ return ret;
>+
>+ ret = ice_register_parser(&ice_fdir_parser, ad);
>
> return ret;
return ice_register_parser(&ice_fdir_parser, ad);
> }
>@@ -409,15 +458,474 @@ ice_uninit_fdir_filter(struct ice_adapter *ad)
> {
> struct ice_pf *pf = &ad->pf;
>
>+ ice_unregister_parser(&ice_fdir_parser, ad);
>+
> ice_fdir_teardown(pf);
> }
>
>+static int
>+ice_add_del_fdir_filter(struct ice_pf *pf,
>+ struct ice_fdir_filter_conf *filter,
>+ bool add)
>+{
>+ struct ice_fltr_desc desc;
>+ struct ice_hw *hw = ICE_PF_TO_HW(pf);
>+ unsigned char *pkt = (unsigned char *)pf->fdir.prg_pkt;
>+ int ret = 0;
>+
>+ memset(&desc, 0, sizeof(desc));
>+ ice_fdir_get_prgm_desc(hw, &filter->input, &desc, add);
>+
>+ memset(pkt, 0, ICE_FDIR_PKT_LEN);
>+ ret = ice_fdir_get_prgm_pkt(&filter->input, pkt, false);
>+ if (ret) {
>+ PMD_DRV_LOG(ERR, "Generate dummy packet failed");
>+ return -EINVAL;
>+
Re: [dpdk-dev] [dpdk-dev 07/12] net/ice: enable FDIR queue group
On 09/06, Yahui Cao wrote:
>FDIR can send packet to a group of queues and distruibte it by RSS.
>
>Signed-off-by: Yahui Cao
>---
> drivers/net/ice/ice_fdir_filter.c | 65 +++
> 1 file changed, 65 insertions(+)
>
>diff --git a/drivers/net/ice/ice_fdir_filter.c
>b/drivers/net/ice/ice_fdir_filter.c
>index df4d0329c..ebbe1bd6c 100644
>--- a/drivers/net/ice/ice_fdir_filter.c
>+++ b/drivers/net/ice/ice_fdir_filter.c
>@@ -741,6 +741,62 @@ static struct ice_flow_engine ice_fdir_engine = {
> .type = ICE_FLOW_ENGINE_FDIR,
> };
>
>+static int
>+ice_fdir_parse_action_qregion(struct ice_pf *pf,
>+struct rte_flow_error *error,
>+const struct rte_flow_action *act,
>+struct ice_fdir_filter_conf *filter)
>+{
>+ const struct rte_flow_action_rss *rss = act->conf;
>+ uint32_t i;
>+
>+ if (act->type != RTE_FLOW_ACTION_TYPE_RSS) {
>+ rte_flow_error_set(error, EINVAL,
>+ RTE_FLOW_ERROR_TYPE_ACTION, act,
>+ "Invalid action.");
>+ return -rte_errno;
>+ }
>+
>+ if (rss->queue_num <= 1) {
>+ rte_flow_error_set(error, EINVAL,
>+ RTE_FLOW_ERROR_TYPE_ACTION, act,
>+ "Queue region size can't be 0 or 1.");
>+ return -rte_errno;
>+ }
>+
>+ /* check if queue index for queue region is continuos */
s/continuos/continuous
>+ for (i = 0; i < rss->queue_num - 1; i++) {
>+ if (rss->queue[i + 1] != rss->queue[i] + 1) {
>+ rte_flow_error_set(error, EINVAL,
>+ RTE_FLOW_ERROR_TYPE_ACTION, act,
>+ "Invalid queue region indexes.");
Change the error message to "discontinuous queue region." to be more specific?
>+ return -rte_errno;
>+ }
>+ }
>+
>+ if (rss->queue[rss->queue_num - 1] >= pf->dev_data->nb_rx_queues) {
>+ rte_flow_error_set(error, EINVAL,
>+ RTE_FLOW_ERROR_TYPE_ACTION, act,
>+ "Invalid queue region indexes.");
>+ return -rte_errno;
>+ }
>+
>+ if (!(rte_is_power_of_2(rss->queue_num) && (rss->queue_num <= 128))) {
Use a macro fro the 128.
>+ rte_flow_error_set(error, EINVAL,
>+ RTE_FLOW_ERROR_TYPE_ACTION, act,
>+ "The region sizes should be any of the
>following values:"
s/sizes/size
>+ "1, 2, 4, 8, 16, 32, 64, 128 as long as the
>total number "
>+ "of queues do not exceed the VSI
>allocation.");
>+ return -rte_errno;
>+ }
>+
>+ filter->input.q_index = rss->queue[0];
>+ filter->input.q_region = rte_fls_u32(rss->queue_num) - 1;
>+ filter->input.dest_ctl = ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QGROUP;
>+
>+ return 0;
>+}
>+
> static int
> ice_fdir_parse_action(struct ice_adapter *ad,
> const struct rte_flow_action actions[],
>@@ -752,6 +808,7 @@ ice_fdir_parse_action(struct ice_adapter *ad,
> const struct rte_flow_action_mark *mark_spec = NULL;
> uint32_t dest_num = 0;
> uint32_t mark_num = 0;
>+ int ret;
>
> for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
> switch (actions->type) {
>@@ -785,6 +842,14 @@ ice_fdir_parse_action(struct ice_adapter *ad,
> ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QINDEX;
> filter->input.q_index = 0;
> break;
>+ case RTE_FLOW_ACTION_TYPE_RSS:
>+ dest_num++;
>+
>+ ret = ice_fdir_parse_action_qregion(pf,
>+ error, actions, filter);
>+ if (ret)
>+ return ret;
>+ break;
> case RTE_FLOW_ACTION_TYPE_MARK:
> mark_num++;
>
>--
>2.17.1
>
Re: [dpdk-dev] [dpdk-dev 08/12] net/ice: add FDIR dst mac support
On 09/06, Yahui Cao wrote:
>Enable FDIR ethernet destination address field matching support
>
>Signed-off-by: Yahui Cao
>---
> drivers/net/ice/ice_fdir_filter.c | 27 +++
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/net/ice/ice_fdir_filter.c
>b/drivers/net/ice/ice_fdir_filter.c
>index ebbe1bd6c..1893aa0ee 100644
>--- a/drivers/net/ice/ice_fdir_filter.c
>+++ b/drivers/net/ice/ice_fdir_filter.c
>@@ -10,6 +10,7 @@
> #include "ice_generic_flow.h"
>
> #define ICE_FDIR_INSET_ETH_IPV4 (\
>+ ICE_INSET_DMAC | \
> ICE_INSET_IPV4_SRC | ICE_INSET_IPV4_DST | ICE_INSET_IPV4_TOS | \
> ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_PROTO)
>
>@@ -387,6 +388,7 @@ ice_parse_input_set(uint64_t inset, enum ice_flow_field
>*field)
> enum ice_flow_field fld;
> };
> static const struct ice_inset_map ice_inset_map[] = {
>+ {ICE_INSET_DMAC, ICE_FLOW_FIELD_IDX_ETH_DA},
> {ICE_INSET_IPV4_SRC, ICE_FLOW_FIELD_IDX_IPV4_SA},
> {ICE_INSET_IPV4_DST, ICE_FLOW_FIELD_IDX_IPV4_DA},
> {ICE_INSET_IPV6_SRC, ICE_FLOW_FIELD_IDX_IPV6_SA},
>@@ -918,13 +920,30 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
>*ad,
> case RTE_FLOW_ITEM_TYPE_ETH:
> eth_spec = item->spec;
> eth_mask = item->mask;
>- if (eth_spec || eth_mask) {
>- rte_flow_error_set(error, EINVAL,
>+ if (eth_spec && eth_mask) {
>+ if (!rte_is_zero_ether_addr(ð_spec->src) ||
>+ !rte_is_zero_ether_addr(ð_mask->src)) {
>+ rte_flow_error_set(error, EINVAL,
> RTE_FLOW_ERROR_TYPE_ITEM,
> item,
>- "eth mac not support");
>- return -rte_errno;
>+ "Src mac not support");
>+ return -rte_errno;
>+ }
>+
>+ if
>(!rte_is_broadcast_ether_addr(ð_mask->dst)) {
>+ rte_flow_error_set(error, EINVAL,
>+ RTE_FLOW_ERROR_TYPE_ITEM,
>+ item,
>+ "Invalid mac addr mask");
>+ return -rte_errno;
>+ }
>+
>+ input_set |= ICE_INSET_DMAC;
>+ rte_memcpy(&filter->input.ext_data.dst_mac,
>+ ð_spec->dst,
>+ RTE_ETHER_ADDR_LEN);
> }
>+
Unnecessary empty line.
> break;
> case RTE_FLOW_ITEM_TYPE_IPV4:
> l3 = RTE_FLOW_ITEM_TYPE_IPV4;
>--
>2.17.1
>
Re: [dpdk-dev] [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by sessionless
Hi Arek
Only these changes looks good to me but do you have working PMD to back this?
Also, documentation updates?
Thanks
Shally
> -Original Message-
> From: Arek Kusztal
> Sent: Friday, September 6, 2019 5:28 PM
> To: dev@dpdk.org
> Cc: akhil.go...@nxp.com; fiona.tr...@intel.com; Shally Verma
> ; Anoob Joseph ; Arek
> Kusztal
> Subject: [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by
> sessionless
>
> External Email
>
> --
> This commit adds asymmetric session-less option to rte_crypto_asym_op.
> Feature flag for sessionless is added to rte_cryptodev.
>
> Signed-off-by: Arek Kusztal
> ---
> lib/librte_cryptodev/rte_crypto_asym.h | 9 +++--
> lib/librte_cryptodev/rte_cryptodev.h | 2 ++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> b/lib/librte_cryptodev/rte_crypto_asym.h
> index 4fbef2f..0d34ce8 100644
> --- a/lib/librte_cryptodev/rte_crypto_asym.h
> +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> @@ -522,8 +522,13 @@ struct rte_crypto_dsa_op_param {
> *
> */
> struct rte_crypto_asym_op {
> - struct rte_cryptodev_asym_session *session;
> - /**< Handle for the initialised session context */
> + RTE_STD_C11
> + union {
> + struct rte_cryptodev_asym_session *session;
> + /**< Handle for the initialised session context */
> + struct rte_crypto_asym_xform *xform;
> + /**< Session-less API crypto operation parameters */
> + };
>
> __extension__
> union {
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index e175b83..c6ffa3b 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -448,6 +448,8 @@ rte_cryptodev_asym_get_xform_enum(enum
> rte_crypto_asym_xform_type *xform_enum, /**< Support RSA Private Key
> OP with CRT (quintuple) Keys */
> #define RTE_CRYPTODEV_FF_DIGEST_ENCRYPTED(1ULL << 19)
> /**< Support encrypted-digest operations where digest is appended to data
> */
> +#define RTE_CRYPTODEV_FF_ASYM_SESSIONLESS(1ULL << 20)
> +/**< Support asymmetric session-less operations */
>
>
> /**
> --
> 2.1.0
Re: [dpdk-dev] [RFC] ethdev: support hairpin queue
Hi Jingjing, PSB > -Original Message- > From: Wu, Jingjing > Sent: Friday, September 6, 2019 6:08 AM > To: Ori Kam ; Thomas Monjalon > ; Yigit, Ferruh ; > arybche...@solarflare.com; Shahaf Shuler ; Slava > Ovsiienko ; Alex Rosenbaum > > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue > > Hi, Ori > > Thanks for the explanation. I have more question below. > > Thanks > Jingjing > > > -Original Message- > > From: Ori Kam [mailto:or...@mellanox.com] > > Sent: Thursday, September 5, 2019 1:45 PM > > To: Wu, Jingjing ; Thomas Monjalon > ; > > Yigit, Ferruh ; arybche...@solarflare.com; Shahaf > Shuler > > ; Slava Ovsiienko ; > Alex > > Rosenbaum > > Cc: dev@dpdk.org > > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > Hi Wu, > > Thanks for your comments PSB, > > > > Ori > > > > > -Original Message- > > > From: Wu, Jingjing > > > Sent: Thursday, September 5, 2019 7:01 AM > > > To: Ori Kam ; Thomas Monjalon > > > ; Yigit, Ferruh ; > > > arybche...@solarflare.com; Shahaf Shuler ; > Slava > > > Ovsiienko ; Alex Rosenbaum > > > > > > Cc: dev@dpdk.org > > > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > > > > > > > -Original Message- > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ori Kam > > > > Sent: Tuesday, August 13, 2019 9:38 PM > > > > To: tho...@monjalon.net; Yigit, Ferruh ; > > > > arybche...@solarflare.com; shah...@mellanox.com; > > > viachesl...@mellanox.com; > > > > al...@mellanox.com > > > > Cc: dev@dpdk.org; or...@mellanox.com > > > > Subject: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > > > > > This RFC replaces RFC[1]. > > > > > > > > The hairpin feature (different name can be forward) acts as "bump on the > > > wire", > > > > meaning that a packet that is received from the wire can be modified > using > > > > offloaded action and then sent back to the wire without application > > > intervention > > > > which save CPU cycles. > > > > > > > > The hairpin is the inverse function of loopback in which application > > > > sends a packet then it is received again by the > > > > application without being sent to the wire. > > > > > > > > The hairpin can be used by a number of different NVF, for example load > > > > balancer, gateway and so on. > > > > > > > > As can be seen from the hairpin description, hairpin is basically RX > > > > queue > > > > connected to TX queue. > > > > > > > > During the design phase I was thinking of two ways to implement this > > > > feature the first one is adding a new rte flow action. and the second > > > > one is create a special kind of queue. > > > > > > > > The advantages of using the queue approch: > > > > 1. More control for the application. queue depth (the memory size that > > > > should be used). > > > > 2. Enable QoS. QoS is normaly a parametr of queue, so in this approch it > > > > will be easy to integrate with such system. > > > > > > > > > Which kind of QoS? > > > > For example latency , packet rate those kinds of makes sense in the queue > level. > > I know we don't have any current support but I think we will have during the > next year. > > > Where would be the QoS API loading? TM API? Or propose other new? I think it will be a new API, The TM is more like limiting the bandwidth of a target flow, while in QoS should influence more the priority between the queues. > > > > > > > 3. Native integression with the rte flow API. Just setting the target > > > > queue/rss to hairpin queue, will result that the traffic will be routed > > > > to the hairpin queue. > > > > 4. Enable queue offloading. > > > > > > > Looks like the hairpin queue is just hardware queue, it has no > > > relationship > with > > > host memory. It makes the queue concept a little bit confusing. And why do > we > > > need to setup queues, maybe some info in eth_conf is enough? > > > > Like stated above it makes sense to have queue related parameters. > > For example I can think of application that most packets are going threw > > that > hairpin > > queue, but some control packets are > > from the application. So the application can configure the QoS between those > two > > queues. In addtion this will enable the application > > to use the queue like normal queue from rte_flow (see comment below) and > every other > > aspect. > > > Yes, it is typical use case. And rte_flow is used to classify to different > queue? > If I understand correct, your hairpin queue is using host memory/or on-card > memory for buffering, but CPU cannot touch it, all the packet processing is > done by NIC. > Queue is created, where the queue ID is used? Tx queue ID may be used as > action of rte_flow? I still don't understand where the hairpin Rx queue ID be > used. > In my opinion, if no rx/tx function, it should not be a true queue from host > view. > Yes rte_flow is used to classify the traffic between the queues, in order to use the hairpin feature in the basic usage, the a
