Re: [dpdk-dev] [PATCH] net/mlx5: fix eagain on admin down
Hi, Mike
> -Original Message-
> From: Mike Manning
> Sent: Friday, December 13, 2019 17:12
> To: Slava Ovsiienko ; Thomas Monjalon
> ; dev@dpdk.org
> Cc: Nélio Laranjeiro ; Matan Azrad
> ; Shahaf Shuler ; Raslan
> Darawsheh
> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix eagain on admin down
>
> Hi Slava,
> Thanks, you are right - I retract my patch, as this was fixed in v19.08 by
> 6fd05da9efbd ("net/mlx5: fix link speed info when link is down") as per the
> line you indicate.
>
> I should explain that we are using Debian 10 which uses v18.11, here we had a
> painful issue with the combination of this -EAGAIN and use of netlink to
> obtain the ifindex resulting in concurrent use of the netlink socket causing
> the
> calling thread to block indefinitely.
JFYI, there is the patch: http://patches.dpdk.org/patch/56813/
It provides caching for ifindex, netlink is not involved anymore.
With best regards, Slava
>
> Regards
> Mike
>
> On 13/12/2019 14:43, Slava Ovsiienko wrote:
> > Hi, Mike
> >
> > In the mlx5_link_update_unlocked_gs() the dev_link.link_speed is set like
> this:
> >
> > dev_link.link_speed = (ecmd->speed == UINT32_MAX) ?
> ETH_SPEED_NUM_NONE
> > : ecmd->speed;
> >
> > So, dev_link.link_speed can't be assigned with -1. Do I misunderstand you
> commit message?
> >
> > With best regards, Slava
> >
> >> -Original Message-
> >> From: Thomas Monjalon
> >> Sent: Friday, December 13, 2019 0:31
> >> To: dev@dpdk.org
> >> Cc: Mike Manning ; Nélio Laranjeiro
> >> ; Matan Azrad ;
> Slava
> >> Ovsiienko ; Shahaf Shuler
> >> ; Raslan Darawsheh
> >> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix eagain on admin down
> >>
> >> +Cc maintainers
> >>
> >> 09/12/2019 19:23, Mike Manning:
> >>> The check in mlx5_link_update_unlocked_gs() returns -EAGAIN if link
> >>> status does not correspond to link speed. If status is DOWN, the
> >>> speed is expected to be ETH_SPEED_NUM_NONE (0). But as the link
> >>> speed is -1 on admin down, modify the check to account for this.
> >>>
> >>> Fixes: cfee94752b8f ("net/mlx5: fix link status to use wait to
> >>> complete")
> >>> Cc: Nélio Laranjeiro
> >>>
> >>> Signed-off-by: Mike Manning
> >>> ---
> >>> drivers/net/mlx5/mlx5_ethdev.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/net/mlx5/mlx5_ethdev.c
> >>> b/drivers/net/mlx5/mlx5_ethdev.c index d80ae458b..6ef2dfd74 100644
> >>> --- a/drivers/net/mlx5/mlx5_ethdev.c
> >>> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> >>> @@ -1031,8 +1031,8 @@ mlx5_link_update_unlocked_gs(struct
> >> rte_eth_dev *dev,
> >>> ETH_LINK_HALF_DUPLEX :
> >> ETH_LINK_FULL_DUPLEX);
> >>> dev_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
> >>> ETH_LINK_SPEED_FIXED);
> >>> - if (((dev_link.link_speed && !dev_link.link_status) ||
> >>> - (!dev_link.link_speed && dev_link.link_status))) {
> >>> + if int)dev_link.link_speed > 0 && !dev_link.link_status) ||
> >>> + ((int)dev_link.link_speed <= 0 && dev_link.link_status))) {
> >>> rte_errno = EAGAIN;
> >>> return -rte_errno;
> >>> }
> >>>
> >>
> >>
> >>
Re: [dpdk-dev] [PATCH 2/9] net/hns3: get link state change through mailbox
Hi, Ferruh Yigit
On 2019/12/3 21:19, Ferruh Yigit wrote:
On 12/3/2019 1:16 PM, Ferruh Yigit wrote:
On 12/2/2019 2:51 AM, Wei Hu (Xavier) wrote:
From: Hongbo Zheng
When link down occurs, firmware adds the function of sending message
to PF driver through mailbox, hns3 PMD driver can recognize link state
change faster through the message.
Hi Xavier,
As far as I can see the 'link_update' dev_ops (hns3_dev_link_update()), is just
copying data from internal structure to "struct rte_eth_link". And you have
timers set to regularly (ever second?) update the internal structure for link
status.
Instead, unless you are not using or need those status internally, you can pull
the internal link status in the 'hns3_dev_link_update()', this way it can be
possible to get rid of the timers. Also in current implementation, when used
asked for the link status, it can be outdated regarding the status of the
timers.
In this patch, interrupt seems used to update the internal link status, this
fixes the problem above that user is getting out of date link status. But
instead of this, what do you think updating "struct rte_eth_link" too in the
interrupt handler and advertising 'RTE_ETH_DEV_INTR_LSC' capability ("Link
status event" feature in .ini file), so user can enable the lsc interrupt
('dev_conf.intr_conf.lsc') and gets the link status quicker because of the
support in the API ('rte_eth_link_get')?
Thanks,
ferruh
'Wei Hu (Xavier) ' email address is failing, not sure what
it is, adding the @huawei.com addresses.
Sorry, there is something wrong for the email service:
xavier.hu...@tom.com,
Now I use the current mailbox that can provide relatively stable
services as an alternative.
Thanks,
Xavier
Signed-off-by: Hongbo Zheng
Signed-off-by: Wei Hu (Xavier)
---
drivers/net/hns3/hns3_ethdev.c | 8 ++--
drivers/net/hns3/hns3_ethdev.h | 1 +
drivers/net/hns3/hns3_mbx.c| 37 ++
drivers/net/hns3/hns3_mbx.h| 8
4 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index bf0ab458f..3c591be51 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -218,6 +218,8 @@ hns3_interrupt_handler(void *param)
hns3_schedule_reset(hns);
} else if (event_cause == HNS3_VECTOR0_EVENT_RST)
hns3_schedule_reset(hns);
+ else if (event_cause == HNS3_VECTOR0_EVENT_MBX)
+ hns3_dev_handle_mbx_msg(hw);
else
hns3_err(hw, "Received unknown event");
@@ -3806,14 +3808,16 @@ hns3_get_mac_link_status(struct hns3_hw *hw)
return !!link_status;
}
-static void
+void
hns3_update_link_status(struct hns3_hw *hw)
{
int state;
state = hns3_get_mac_link_status(hw);
- if (state != hw->mac.link_status)
+ if (state != hw->mac.link_status) {
hw->mac.link_status = state;
+ hns3_warn(hw, "Link status change to %s!", state ? "up" :
"down");
+ }
}
static void
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index e9a3fe410..004cd75a9 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -631,6 +631,7 @@ int hns3_dev_filter_ctrl(struct rte_eth_dev *dev,
enum rte_filter_op filter_op, void *arg);
bool hns3_is_reset_pending(struct hns3_adapter *hns);
bool hns3vf_is_reset_pending(struct hns3_adapter *hns);
+void hns3_update_link_status(struct hns3_hw *hw);
static inline bool
is_reset_pending(struct hns3_adapter *hns)
diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
index c1647af4b..26807bc4b 100644
--- a/drivers/net/hns3/hns3_mbx.c
+++ b/drivers/net/hns3/hns3_mbx.c
@@ -282,6 +282,40 @@ hns3_update_resp_position(struct hns3_hw *hw, uint32_t
resp_msg)
resp->tail = tail;
}
+static void
+hns3_link_fail_parse(struct hns3_hw *hw, uint8_t link_fail_code)
+{
+ switch (link_fail_code) {
+ case HNS3_MBX_LF_NORMAL:
+ break;
+ case HNS3_MBX_LF_REF_CLOCK_LOST:
+ hns3_warn(hw, "Reference clock lost!");
+ break;
+ case HNS3_MBX_LF_XSFP_TX_DISABLE:
+ hns3_warn(hw, "SFP tx is disabled!");
+ break;
+ case HNS3_MBX_LF_XSFP_ABSENT:
+ hns3_warn(hw, "SFP is absent!");
+ break;
+ default:
+ hns3_warn(hw, "Unknown fail code:%u!", link_fail_code);
+ break;
+ }
+}
+
+static void
+hns3_handle_link_change_event(struct hns3_hw *hw,
+ struct hns3_mbx_pf_to_vf_cmd *req)
+{
+#define LINK_STATUS_OFFSET 1
+#define LINK_FAIL_CODE_OFFSET 2
+
+ if (!req->msg[LINK_STATUS_OFFSET])
+ hns3_link_fail_parse(hw, req->msg[LINK_FAIL_CODE_OFFSET]);
+
+ hns3_update_link_status(hw);
+}
+
void
hns3_dev_handle_mbx_msg(struct
Re: [dpdk-dev] [PATCH 2/9] net/hns3: get link state change through mailbox
Hi, Ferruh Yigit
On 2019/12/3 21:16, Ferruh Yigit wrote:
On 12/2/2019 2:51 AM, Wei Hu (Xavier) wrote:
From: Hongbo Zheng
When link down occurs, firmware adds the function of sending message
to PF driver through mailbox, hns3 PMD driver can recognize link state
change faster through the message.
Hi Xavier,
As far as I can see the 'link_update' dev_ops (hns3_dev_link_update()), is just
copying data from internal structure to "struct rte_eth_link". And you have
timers set to regularly (ever second?) update the internal structure for link
status.
Instead, unless you are not using or need those status internally, you can pull
the internal link status in the 'hns3_dev_link_update()', this way it can be
possible to get rid of the timers. Also in current implementation, when used
asked for the link status, it can be outdated regarding the status of the
timers.
We will use the internal link status in the driver, the relevent patch
will be sent later.
In this patch, interrupt seems used to update the internal link status, this
fixes the problem above that user is getting out of date link status. But
instead of this, what do you think updating "struct rte_eth_link" too in the
interrupt handler and advertising 'RTE_ETH_DEV_INTR_LSC' capability ("Link
status event" feature in .ini file), so user can enable the lsc interrupt
('dev_conf.intr_conf.lsc') and gets the link status quicker because of the
support in the API ('rte_eth_link_get')?
Currently, firmware adds the function of sending message to PF driver
through mailbox when the link status is changed, hns3 PMD driver can
usually recognize link state change faster through the message.
And in some extreme cases, this way is not faster than existing method
regularly updating link status by issing the command every second in PF
driver, because of the parallel processing of mailbox and command
messages in firmware. So we reserve updating link status using timers in
PF driver and don't advertising 'RTE_ETH_DEV_INTR_LSC' capability.
And we will add querying link status by issuing command to the firmware
in '.link_update' ops implementation function named hns3_dev_link_update
to solve the out of date link status in patch V2.
Thanks,
Xavier
Thanks,
ferruh
Signed-off-by: Hongbo Zheng
Signed-off-by: Wei Hu (Xavier)
---
drivers/net/hns3/hns3_ethdev.c | 8 ++--
drivers/net/hns3/hns3_ethdev.h | 1 +
drivers/net/hns3/hns3_mbx.c| 37 ++
drivers/net/hns3/hns3_mbx.h| 8
4 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index bf0ab458f..3c591be51 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -218,6 +218,8 @@ hns3_interrupt_handler(void *param)
hns3_schedule_reset(hns);
} else if (event_cause == HNS3_VECTOR0_EVENT_RST)
hns3_schedule_reset(hns);
+ else if (event_cause == HNS3_VECTOR0_EVENT_MBX)
+ hns3_dev_handle_mbx_msg(hw);
else
hns3_err(hw, "Received unknown event");
@@ -3806,14 +3808,16 @@ hns3_get_mac_link_status(struct hns3_hw *hw)
return !!link_status;
}
-static void
+void
hns3_update_link_status(struct hns3_hw *hw)
{
int state;
state = hns3_get_mac_link_status(hw);
- if (state != hw->mac.link_status)
+ if (state != hw->mac.link_status) {
hw->mac.link_status = state;
+ hns3_warn(hw, "Link status change to %s!", state ? "up" :
"down");
+ }
}
static void
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index e9a3fe410..004cd75a9 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -631,6 +631,7 @@ int hns3_dev_filter_ctrl(struct rte_eth_dev *dev,
enum rte_filter_op filter_op, void *arg);
bool hns3_is_reset_pending(struct hns3_adapter *hns);
bool hns3vf_is_reset_pending(struct hns3_adapter *hns);
+void hns3_update_link_status(struct hns3_hw *hw);
static inline bool
is_reset_pending(struct hns3_adapter *hns)
diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
index c1647af4b..26807bc4b 100644
--- a/drivers/net/hns3/hns3_mbx.c
+++ b/drivers/net/hns3/hns3_mbx.c
@@ -282,6 +282,40 @@ hns3_update_resp_position(struct hns3_hw *hw, uint32_t
resp_msg)
resp->tail = tail;
}
+static void
+hns3_link_fail_parse(struct hns3_hw *hw, uint8_t link_fail_code)
+{
+ switch (link_fail_code) {
+ case HNS3_MBX_LF_NORMAL:
+ break;
+ case HNS3_MBX_LF_REF_CLOCK_LOST:
+ hns3_warn(hw, "Reference clock lost!");
+ break;
+ case HNS3_MBX_LF_XSFP_TX_DISABLE:
+ hns3_warn(hw, "SFP tx is disabled!");
+ break;
+ case HNS3_MBX_LF_XSFP_ABSENT:
+ hns3_warn(hw, "SFP is absent!");
+ brea
[dpdk-dev] [PATCH v2 5/9] net/hns3: optimize RSS's default algorithm
From: Hao Chen This patch changed the default algorithm of RSS from simle_xor to toeplitz because toeplitz is used more frequently by upper applications such as ceph. Signed-off-by: Hao Chen Signed-off-by: Wei Hu (Xavier) --- drivers/net/hns3/hns3_rss.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/net/hns3/hns3_rss.c b/drivers/net/hns3/hns3_rss.c index b8c20e6d9..dfc42f840 100644 --- a/drivers/net/hns3/hns3_rss.c +++ b/drivers/net/hns3/hns3_rss.c @@ -211,7 +211,11 @@ hns3_set_rss_tuple_by_rss_hf(struct hns3_hw *hw, req->ipv6_fragment_en |= HNS3_IP_OTHER_BIT_MASK; break; default: - /* Other unsupported flow types won't change tuples */ + /* +* rss_hf doesn't include unsupported flow types +* because the API framework has checked it, and +* this branch will never go unless rss_hf is zero. +*/ break; } } @@ -251,8 +255,8 @@ hns3_dev_rss_hash_update(struct rte_eth_dev *dev, struct hns3_hw *hw = &hns->hw; struct hns3_rss_tuple_cfg *tuple = &hw->rss_info.rss_tuple_sets; struct hns3_rss_conf *rss_cfg = &hw->rss_info; - uint8_t algo = rss_cfg->conf.func; uint8_t key_len = rss_conf->rss_key_len; + uint8_t algo; uint64_t rss_hf = rss_conf->rss_hf; uint8_t *key = rss_conf->rss_key; int ret; @@ -285,6 +289,8 @@ hns3_dev_rss_hash_update(struct rte_eth_dev *dev, ret = -EINVAL; goto conf_err; } + algo = rss_cfg->conf.func == RTE_ETH_HASH_FUNCTION_SIMPLE_XOR ? + HNS3_RSS_HASH_ALGO_SIMPLE : HNS3_RSS_HASH_ALGO_TOEPLITZ; ret = hns3_set_rss_algo_key(hw, algo, key); if (ret) goto conf_err; @@ -500,7 +506,9 @@ hns3_set_default_rss_args(struct hns3_hw *hw) int i; /* Default hash algorithm */ - rss_cfg->conf.func = RTE_ETH_HASH_FUNCTION_SIMPLE_XOR; + rss_cfg->conf.func = RTE_ETH_HASH_FUNCTION_TOEPLITZ; + + /* Default RSS key */ memcpy(rss_cfg->key, hns3_hash_key, HNS3_RSS_KEY_SIZE); /* Initialize RSS indirection table */ -- 2.23.0
[dpdk-dev] [PATCH v2 4/9] net/hns3: modify custom macro
From: Huisong Li
This patch replaces custom macro named HNS3_MIN_FRAME_LEN for ethernet
minimum frame length with the macro named RTE_ETHER_MIN_LEN that defined
in dpdk framework.
Signed-off-by: Huisong Li
Signed-off-by: Wei Hu (Xavier)
---
drivers/net/hns3/hns3_ethdev.c | 2 +-
drivers/net/hns3/hns3_ethdev.h | 1 -
drivers/net/hns3/hns3_rxtx.c | 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 5795b3b34..981e05b61 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2148,7 +2148,7 @@ hns3_set_mac_mtu(struct hns3_hw *hw, uint16_t new_mps)
req = (struct hns3_config_max_frm_size_cmd *)desc.data;
req->max_frm_size = rte_cpu_to_le_16(new_mps);
- req->min_frm_size = HNS3_MIN_FRAME_LEN;
+ req->min_frm_size = RTE_ETHER_MIN_LEN;
return hns3_cmd_send(hw, &desc, 1);
}
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index 004cd75a9..7422706a8 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -33,7 +33,6 @@
#define HNS3_MAX_BD_SIZE 65535
#define HNS3_MAX_TX_BD_PER_PKT 8
#define HNS3_MAX_FRAME_LEN 9728
-#define HNS3_MIN_FRAME_LEN 64
#define HNS3_VLAN_TAG_SIZE 4
#define HNS3_DEFAULT_RX_BUF_LEN2048
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index e7f0c8fc9..0090cda31 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -1561,7 +1561,7 @@ hns3_prep_pkts(__rte_unused void *tx_queue, struct
rte_mbuf **tx_pkts,
m = tx_pkts[i];
/* check the size of packet */
- if (m->pkt_len < HNS3_MIN_FRAME_LEN) {
+ if (m->pkt_len < RTE_ETHER_MIN_LEN) {
rte_errno = EINVAL;
return i;
}
--
2.23.0
[dpdk-dev] [PATCH v2 8/9] net/hns3: remove the unnecessary assignment
From: "Wei Hu (Xavier)"
This patch removes the unncessary assignment in hns3_xmit_pkts function
to avoid performance loss.
Signed-off-by: Wei Hu (Xavier)
---
drivers/net/hns3/hns3_rxtx.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 0090cda31..18c07b85e 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -1612,7 +1612,6 @@ hns3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts)
struct rte_mbuf *m_seg;
struct rte_mbuf *temp;
uint32_t nb_hold = 0;
- uint16_t tx_next_clean;
uint16_t tx_next_use;
uint16_t tx_bd_ready;
uint16_t tx_pkt_num;
@@ -1627,11 +1626,8 @@ hns3_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts, uint16_t nb_pkts)
if (tx_bd_ready == 0)
return 0;
- tx_next_clean = txq->next_to_clean;
tx_next_use = txq->next_to_use;
tx_bd_max = txq->nb_tx_desc;
- tx_bak_pkt = &txq->sw_ring[tx_next_clean];
-
tx_pkt_num = (tx_bd_ready < nb_pkts) ? tx_bd_ready : nb_pkts;
/* send packets */
@@ -1707,7 +1703,6 @@ hns3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts)
if (likely(nb_tx)) {
hns3_queue_xmit(txq, nb_hold);
- txq->next_to_clean = tx_next_clean;
txq->tx_bd_ready = tx_bd_ready - nb_hold;
}
--
2.23.0
[dpdk-dev] [PATCH v2 1/9] net/hns3: support Rx interrupt
From: Hao Chen
This patch supports of receive packets through interrupt mode for hns3
PF/VF driver. The following ops functions should be implemented defined
in struct eth_dev_ops:
rx_queue_intr_enable
rx_queue_intr_disable
rx_queue_count
Signed-off-by: Hao Chen
Signed-off-by: Wei Hu (Xavier)
---
doc/guides/nics/features/hns3.ini| 1 +
doc/guides/nics/features/hns3_vf.ini | 1 +
drivers/net/hns3/hns3_cmd.h | 28 +
drivers/net/hns3/hns3_ethdev.c | 160 --
drivers/net/hns3/hns3_ethdev_vf.c| 166 ---
drivers/net/hns3/hns3_mbx.h | 13 +++
drivers/net/hns3/hns3_regs.h | 3 +
drivers/net/hns3/hns3_rxtx.c | 51
drivers/net/hns3/hns3_rxtx.h | 4 +
9 files changed, 405 insertions(+), 22 deletions(-)
diff --git a/doc/guides/nics/features/hns3.ini
b/doc/guides/nics/features/hns3.ini
index 6df789ed1..cd5c08a9d 100644
--- a/doc/guides/nics/features/hns3.ini
+++ b/doc/guides/nics/features/hns3.ini
@@ -5,6 +5,7 @@
;
[Features]
Link status = Y
+Rx interrupt = Y
MTU update = Y
Jumbo frame = Y
Promiscuous mode = Y
diff --git a/doc/guides/nics/features/hns3_vf.ini
b/doc/guides/nics/features/hns3_vf.ini
index 41497c4c2..fd00ac3e2 100644
--- a/doc/guides/nics/features/hns3_vf.ini
+++ b/doc/guides/nics/features/hns3_vf.ini
@@ -5,6 +5,7 @@
;
[Features]
Link status = Y
+Rx interrupt = Y
MTU update = Y
Jumbo frame = Y
Unicast MAC filter = Y
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index be0ecbe86..897dc1420 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -209,6 +209,10 @@ enum hns3_opcode_type {
/* SFP command */
HNS3_OPC_SFP_GET_SPEED = 0x7104,
+ /* Interrupts commands */
+ HNS3_OPC_ADD_RING_TO_VECTOR = 0x1503,
+ HNS3_OPC_DEL_RING_TO_VECTOR = 0x1504,
+
/* Error INT commands */
HNS3_QUERY_MSIX_INT_STS_BD_NUM = 0x1513,
HNS3_QUERY_CLEAR_ALL_MPF_MSIX_INT = 0x1514,
@@ -673,6 +677,30 @@ struct hns3_tqp_map_cmd {
uint8_t rsv[18];
};
+#define HNS3_RING_TYPE_B 0
+#define HNS3_RING_TYPE_TX 0
+#define HNS3_RING_TYPE_RX 1
+#define HNS3_RING_GL_IDX_S 0
+#define HNS3_RING_GL_IDX_M GENMASK(1, 0)
+#define HNS3_RING_GL_RX0
+#define HNS3_RING_GL_TX1
+
+#define HNS3_VECTOR_ELEMENTS_PER_CMD 10
+
+#define HNS3_INT_TYPE_S0
+#define HNS3_INT_TYPE_MGENMASK(1, 0)
+#define HNS3_TQP_ID_S 2
+#define HNS3_TQP_ID_M GENMASK(12, 2)
+#define HNS3_INT_GL_IDX_S 13
+#define HNS3_INT_GL_IDX_M GENMASK(14, 13)
+struct hns3_ctrl_vector_chain_cmd {
+ uint8_t int_vector_id;
+ uint8_t int_cause_num;
+ uint16_t tqp_type_and_id[HNS3_VECTOR_ELEMENTS_PER_CMD];
+ uint8_t vfid;
+ uint8_t rsv;
+};
+
struct hns3_config_max_frm_size_cmd {
uint16_t max_frm_size;
uint8_t min_frm_size;
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 72315718a..bf0ab458f 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2021,6 +2021,40 @@ hns3_check_dcb_cfg(struct rte_eth_dev *dev)
return hns3_check_mq_mode(dev);
}
+static int
+hns3_bind_ring_with_vector(struct rte_eth_dev *dev, uint8_t vector_id,
+ bool mmap, uint16_t queue_id)
+{
+ struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct hns3_cmd_desc desc;
+ struct hns3_ctrl_vector_chain_cmd *req =
+ (struct hns3_ctrl_vector_chain_cmd *)desc.data;
+ enum hns3_cmd_status status;
+ enum hns3_opcode_type op;
+ uint16_t tqp_type_and_id = 0;
+
+ op = mmap ? HNS3_OPC_ADD_RING_TO_VECTOR : HNS3_OPC_DEL_RING_TO_VECTOR;
+ hns3_cmd_setup_basic_desc(&desc, op, false);
+ req->int_vector_id = vector_id;
+
+ hns3_set_field(tqp_type_and_id, HNS3_INT_TYPE_M, HNS3_INT_TYPE_S,
+ HNS3_RING_TYPE_RX);
+ hns3_set_field(tqp_type_and_id, HNS3_TQP_ID_M, HNS3_TQP_ID_S, queue_id);
+ hns3_set_field(tqp_type_and_id, HNS3_INT_GL_IDX_M, HNS3_INT_GL_IDX_S,
+ HNS3_RING_GL_RX);
+ req->tqp_type_and_id[0] = rte_cpu_to_le_16(tqp_type_and_id);
+
+ req->int_cause_num = 1;
+ status = hns3_cmd_send(hw, &desc, 1);
+ if (status) {
+ hns3_err(hw, "Map TQP %d fail, vector_id is %d, status is %d.",
+queue_id, vector_id, status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int
hns3_dev_configure(struct rte_eth_dev *dev)
{
@@ -4020,15 +4054,83 @@ hns3_do_start(struct hns3_adapter *hns, bool
reset_queue)
}
static int
-hns3_dev_start(struct rte_eth_dev *eth_dev)
+hns3_map_rx_interrupt(struct rte_eth_dev *dev)
[dpdk-dev] [PATCH v2 2/9] net/hns3: get link state change through mailbox
From: Hongbo Zheng
Currently, firmware adds the function of sending message to PF driver
through mailbox when the link status is changed, hns3 PMD driver can
usually recognize link state change faster through the message.
And in some extreme cases, this way is not faster than existing method
regularly updating link status by issing the command every second in PF
driver, because of the parallel processing of mailbox and command messages
in firmware. So we reserve updating link status using timers in PF driver,
and add querying link status by issuing command to the firmware in
'.link_update' ops implementation function named hns3_dev_link_update to
solve the out of date link status.
Signed-off-by: Hongbo Zheng
Signed-off-by: Wei Hu (Xavier)
Signed-off-by: Huisong Li
---
v1 -> v2:
1.Add querying link status by issuing command to the firmware
in '.link_update' ops implementation function named
hns3_dev_link_update to solve the out of date link status.
---
drivers/net/hns3/hns3_ethdev.c | 14 +++--
drivers/net/hns3/hns3_ethdev.h | 1 +
drivers/net/hns3/hns3_mbx.c| 37 ++
drivers/net/hns3/hns3_mbx.h| 8
4 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index bf0ab458f..5795b3b34 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -77,6 +77,7 @@ static enum hns3_reset_level hns3_get_reset_level(struct
hns3_adapter *hns,
static int hns3_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static int hns3_vlan_pvid_configure(struct hns3_adapter *hns, uint16_t pvid,
int on);
+static int hns3_update_speed_duplex(struct rte_eth_dev *eth_dev);
static void
hns3_pf_disable_irq0(struct hns3_hw *hw)
@@ -218,6 +219,8 @@ hns3_interrupt_handler(void *param)
hns3_schedule_reset(hns);
} else if (event_cause == HNS3_VECTOR0_EVENT_RST)
hns3_schedule_reset(hns);
+ else if (event_cause == HNS3_VECTOR0_EVENT_MBX)
+ hns3_dev_handle_mbx_msg(hw);
else
hns3_err(hw, "Received unknown event");
@@ -2302,6 +2305,11 @@ hns3_dev_link_update(struct rte_eth_dev *eth_dev,
struct hns3_mac *mac = &hw->mac;
struct rte_eth_link new_link;
+ if (!hns3_is_reset_pending(hns)) {
+ hns3_update_speed_duplex(eth_dev);
+ hns3_update_link_status(hw);
+ }
+
memset(&new_link, 0, sizeof(new_link));
switch (mac->link_speed) {
case ETH_SPEED_NUM_10M:
@@ -3806,14 +3814,16 @@ hns3_get_mac_link_status(struct hns3_hw *hw)
return !!link_status;
}
-static void
+void
hns3_update_link_status(struct hns3_hw *hw)
{
int state;
state = hns3_get_mac_link_status(hw);
- if (state != hw->mac.link_status)
+ if (state != hw->mac.link_status) {
hw->mac.link_status = state;
+ hns3_warn(hw, "Link status change to %s!", state ? "up" :
"down");
+ }
}
static void
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index e9a3fe410..004cd75a9 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -631,6 +631,7 @@ int hns3_dev_filter_ctrl(struct rte_eth_dev *dev,
enum rte_filter_op filter_op, void *arg);
bool hns3_is_reset_pending(struct hns3_adapter *hns);
bool hns3vf_is_reset_pending(struct hns3_adapter *hns);
+void hns3_update_link_status(struct hns3_hw *hw);
static inline bool
is_reset_pending(struct hns3_adapter *hns)
diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
index c1647af4b..26807bc4b 100644
--- a/drivers/net/hns3/hns3_mbx.c
+++ b/drivers/net/hns3/hns3_mbx.c
@@ -282,6 +282,40 @@ hns3_update_resp_position(struct hns3_hw *hw, uint32_t
resp_msg)
resp->tail = tail;
}
+static void
+hns3_link_fail_parse(struct hns3_hw *hw, uint8_t link_fail_code)
+{
+ switch (link_fail_code) {
+ case HNS3_MBX_LF_NORMAL:
+ break;
+ case HNS3_MBX_LF_REF_CLOCK_LOST:
+ hns3_warn(hw, "Reference clock lost!");
+ break;
+ case HNS3_MBX_LF_XSFP_TX_DISABLE:
+ hns3_warn(hw, "SFP tx is disabled!");
+ break;
+ case HNS3_MBX_LF_XSFP_ABSENT:
+ hns3_warn(hw, "SFP is absent!");
+ break;
+ default:
+ hns3_warn(hw, "Unknown fail code:%u!", link_fail_code);
+ break;
+ }
+}
+
+static void
+hns3_handle_link_change_event(struct hns3_hw *hw,
+ struct hns3_mbx_pf_to_vf_cmd *req)
+{
+#define LINK_STATUS_OFFSET 1
+#define LINK_FAIL_CODE_OFFSET 2
+
+ if (!req->msg[LINK_STATUS_OFFSET])
+ hns3_link_fail_parse(hw, req->msg[LINK_FAIL_CODE_OFFSET]);
+
+ hns3_update_link_status(hw);
+}
+
void
hns3_dev_
[dpdk-dev] [PATCH v2 3/9] net/hns3: modify the return value of enable msix
From: "Wei Hu (Xavier)" This patch replaces the return value "-1" with "-ENXIO". Signed-off-by: Wei Hu (Xavier) --- drivers/net/hns3/hns3_ethdev_vf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/hns3/hns3_ethdev_vf.c b/drivers/net/hns3/hns3_ethdev_vf.c index 9b6bc83e4..781374c82 100644 --- a/drivers/net/hns3/hns3_ethdev_vf.c +++ b/drivers/net/hns3/hns3_ethdev_vf.c @@ -131,7 +131,7 @@ hns3vf_enable_msix(const struct rte_pci_device *device, bool op) (pos + PCI_MSIX_FLAGS)); return 0; } - return -1; + return -ENXIO; } static int -- 2.23.0
[dpdk-dev] [PATCH v2 7/9] net/hns3: remove the redundant variable initialization
From: "Wei Hu (Xavier)"
This patch removes the redundant initialization of the variable
named ret.
Signed-off-by: Hongbo Zheng
Signed-off-by: Hao Chen
Signed-off-by: Wei Hu (Xavier)
---
drivers/net/hns3/hns3_ethdev.c| 10 +-
drivers/net/hns3/hns3_ethdev_vf.c | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 981e05b61..a675c2064 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -3597,7 +3597,7 @@ hns3_dev_promiscuous_enable(struct rte_eth_dev *dev)
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = &hns->hw;
bool en_mc_pmc = (dev->data->all_multicast == 1) ? true : false;
- int ret = 0;
+ int ret;
rte_spinlock_lock(&hw->lock);
ret = hns3_set_promisc_mode(hw, true, en_mc_pmc);
@@ -3614,7 +3614,7 @@ hns3_dev_promiscuous_disable(struct rte_eth_dev *dev)
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = &hns->hw;
bool en_mc_pmc = (dev->data->all_multicast == 1) ? true : false;
- int ret = 0;
+ int ret;
/* If now in all_multicast mode, must remain in all_multicast mode. */
rte_spinlock_lock(&hw->lock);
@@ -3632,7 +3632,7 @@ hns3_dev_allmulticast_enable(struct rte_eth_dev *dev)
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = &hns->hw;
bool en_uc_pmc = (dev->data->promiscuous == 1) ? true : false;
- int ret = 0;
+ int ret;
rte_spinlock_lock(&hw->lock);
ret = hns3_set_promisc_mode(hw, en_uc_pmc, true);
@@ -3649,7 +3649,7 @@ hns3_dev_allmulticast_disable(struct rte_eth_dev *dev)
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = &hns->hw;
bool en_uc_pmc = (dev->data->promiscuous == 1) ? true : false;
- int ret = 0;
+ int ret;
/* If now in promiscuous mode, must remain in all_multicast mode. */
if (dev->data->promiscuous == 1)
@@ -4135,7 +4135,7 @@ hns3_dev_start(struct rte_eth_dev *dev)
{
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = &hns->hw;
- int ret = 0;
+ int ret;
PMD_INIT_FUNC_TRACE();
if (rte_atomic16_read(&hw->reset.resetting))
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c
b/drivers/net/hns3/hns3_ethdev_vf.c
index 46d3efad0..45e061d96 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -1465,7 +1465,7 @@ hns3vf_dev_start(struct rte_eth_dev *dev)
{
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = &hns->hw;
- int ret = 0;
+ int ret;
PMD_INIT_FUNC_TRACE();
if (rte_atomic16_read(&hw->reset.resetting))
--
2.23.0
[dpdk-dev] [PATCH v2 0/9] updates for hns3 PMD driver
This series are updates for hns3 ethernet PMD driver. v1 -> v2: There are changes in the No.02 patch, and the other patches are not updated. Hao Chen (4): net/hns3: support Rx interrupt net/hns3: optimize RSS's default algorithm net/hns3: remove the redundant function call net/hns3: remove the unused macros Hongbo Zheng (1): net/hns3: get link state change through mailbox Huisong Li (1): net/hns3: modify custom macro Wei Hu (Xavier) (3): net/hns3: modify the return value of enable msix net/hns3: remove the redundant variable initialization net/hns3: remove the unnecessary assignment doc/guides/nics/features/hns3.ini| 1 + doc/guides/nics/features/hns3_vf.ini | 1 + drivers/net/hns3/hns3_cmd.h | 28 + drivers/net/hns3/hns3_ethdev.c | 182 --- drivers/net/hns3/hns3_ethdev.h | 2 +- drivers/net/hns3/hns3_ethdev_vf.c| 167 +--- drivers/net/hns3/hns3_mbx.c | 37 ++ drivers/net/hns3/hns3_mbx.h | 21 drivers/net/hns3/hns3_regs.h | 3 + drivers/net/hns3/hns3_rss.c | 14 ++- drivers/net/hns3/hns3_rss.h | 10 -- drivers/net/hns3/hns3_rxtx.c | 58 - drivers/net/hns3/hns3_rxtx.h | 4 + 13 files changed, 479 insertions(+), 49 deletions(-) -- 2.23.0
[dpdk-dev] [PATCH v2 6/9] net/hns3: remove the redundant function call
From: Hao Chen This patch removes the redundant statement calling hns3_stats_reset() to clear statistical information explicitly in the initialization of VF device, because hardware has been reseted by FLR in the initialization and the initial hardware and software statistics values are 0. Signed-off-by: Hao Chen Signed-off-by: Wei Hu (Xavier) --- drivers/net/hns3/hns3_ethdev_vf.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/hns3/hns3_ethdev_vf.c b/drivers/net/hns3/hns3_ethdev_vf.c index 781374c82..46d3efad0 100644 --- a/drivers/net/hns3/hns3_ethdev_vf.c +++ b/drivers/net/hns3/hns3_ethdev_vf.c @@ -1167,7 +1167,6 @@ hns3vf_init_vf(struct rte_eth_dev *eth_dev) hns3_set_default_rss_args(hw); - (void)hns3_stats_reset(eth_dev); return 0; err_get_config: -- 2.23.0
[dpdk-dev] [PATCH v2 9/9] net/hns3: remove the unused macros
From: Hao Chen
This patch removed some unused macros defined in hns3_rss.h,
these macros are used to set tuples for abandoned RTE_ETH_FILTER_HASH
in hns3_dev_filter_ctrl().
Signed-off-by: Hao Chen
Signed-off-by: Wei Hu (Xavier)
---
drivers/net/hns3/hns3_rss.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/hns3/hns3_rss.h b/drivers/net/hns3/hns3_rss.h
index 7ffc15131..725970f89 100644
--- a/drivers/net/hns3/hns3_rss.h
+++ b/drivers/net/hns3/hns3_rss.h
@@ -27,7 +27,6 @@
#define HNS3_RSS_HASH_ALGO_TOEPLITZ0
#define HNS3_RSS_HASH_ALGO_SIMPLE 1
-#define HNS3_RSS_HASH_ALGO_SYMMETRIC 2
#define HNS3_RSS_HASH_ALGO_MASK0xf
#define HNS3_RSS_INPUT_TUPLE_OTHER GENMASK(3, 0)
@@ -56,15 +55,6 @@ struct hns3_rss_conf {
uint16_t queue[HNS3_RSS_QUEUES_BUFFER_NUM]; /* Queues indices to use */
};
-/* Bit 8 ~Bit 15 */
-#define HNS3_INSET_IPV4_SRC0x0100UL
-#define HNS3_INSET_IPV4_DST0x0200UL
-#define HNS3_INSET_IPV6_SRC0x0400UL
-#define HNS3_INSET_IPV6_DST0x0800UL
-#define HNS3_INSET_SRC_PORT0x1000UL
-#define HNS3_INSET_DST_PORT0x2000UL
-#define HNS3_INSET_SCTP_VT 0x4000UL
-
#ifndef ilog2
static inline int rss_ilog2(uint32_t x)
{
--
2.23.0
Re: [dpdk-dev] [PATCH] raw/ntb: fix write memory barrier issue
Hi Xiaoyun,
> -Original Message-
> From: dev On Behalf Of Xiaoyun Li
> Sent: Wednesday, December 4, 2019 11:19 PM
> To: jingjing...@intel.com
> Cc: dev@dpdk.org; Xiaoyun Li ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] raw/ntb: fix write memory barrier issue
>
> All buffers and ring info should be written before tail register update.
> This patch relocates the write memory barrier before updating tail register
> to avoid potential issues.
>
> Fixes: 11b5c7daf019 ("raw/ntb: add enqueue and dequeue functions")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiaoyun Li
> ---
> drivers/raw/ntb/ntb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/raw/ntb/ntb.c b/drivers/raw/ntb/ntb.c
> index ad7f6abfd..dd0b72f8c 100644
> --- a/drivers/raw/ntb/ntb.c
> +++ b/drivers/raw/ntb/ntb.c
> @@ -683,8 +683,8 @@ ntb_enqueue_bufs(struct rte_rawdev *dev,
> sizeof(struct ntb_used) * nb1);
> rte_memcpy(txq->tx_used_ring, tx_used + nb1,
> sizeof(struct ntb_used) * nb2);
> - *txq->used_cnt = txq->last_used;
> rte_wmb();
> + *txq->used_cnt = txq->last_used;
I am ok with the re-location of the barrier, but why not the rte_io_wmb instead
of rte_wmb?
Rte_io_wmb is sufficient to guarantee the preceding stores are visible to the
device, rte_wmb is overkill.
https://code.dpdk.org/dpdk/latest/source/lib/librte_eal/common/include/generic/rte_atomic.h#L92
>
> /* update queue stats */
> hw->ntb_xstats[NTB_TX_BYTES_ID + off] += bytes;
> @@ -789,8 +789,8 @@ ntb_dequeue_bufs(struct rte_rawdev *dev,
> sizeof(struct ntb_desc) * nb1);
> rte_memcpy(rxq->rx_desc_ring, rx_desc + nb1,
> sizeof(struct ntb_desc) * nb2);
> - *rxq->avail_cnt = rxq->last_avail;
> rte_wmb();
> + *rxq->avail_cnt = rxq->last_avail;
>
> /* update queue stats */
> off = NTB_XSTATS_NUM * ((size_t)context + 1);
> --
> 2.17.1
Re: [dpdk-dev] [PATCH 14/15] crypto/octeontx2: add inline tx path changes
Went through the patch, from the barrier usage perspective, Reviewed-by: Gavin Hu
Re: [dpdk-dev] [PATCH v1 2/6] raw/octeontx2_ep: add device configuration
Hi Mahipal,
> -Original Message-
> From: dev On Behalf Of Mahipal Challa
> Sent: Friday, December 6, 2019 2:39 PM
> To: dev@dpdk.org
> Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> venk...@marvell.com
> Subject: [dpdk-dev] [PATCH v1 2/6] raw/octeontx2_ep: add device
> configuration
>
> Register "dev_configure" API to configure/initialize the SDP
> VF PCIe devices.
>
> Signed-off-by: Mahipal Challa
> ---
> doc/guides/rawdevs/octeontx2_ep.rst| 29 ++
> drivers/common/octeontx2/hw/otx2_sdp.h | 184 +
> drivers/common/octeontx2/otx2_common.c | 9 +
> drivers/common/octeontx2/otx2_common.h | 4 +
> .../octeontx2/rte_common_octeontx2_version.map | 6 +
> drivers/raw/octeontx2_ep/Makefile | 3 +
> drivers/raw/octeontx2_ep/meson.build | 4 +-
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 294 ++
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 11 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 148 +++
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 434
> -
> drivers/raw/octeontx2_ep/otx2_ep_vf.c | 408 +++
> drivers/raw/octeontx2_ep/otx2_ep_vf.h | 10 +
> 13 files changed, 1542 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> b/doc/guides/rawdevs/octeontx2_ep.rst
> index 5f5ed01..2507fcf 100644
> --- a/doc/guides/rawdevs/octeontx2_ep.rst
> +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> @@ -39,3 +39,32 @@ entry `sriov_numvfs` for the corresponding PF driver.
>
> Once the required VFs are enabled, to be accessible from DPDK, VFs need to
> be
> bound to vfio-pci driver.
> +
> +Device Setup
> +
> +
> +The OCTEON TX2 SDP End Point VF devices will need to be bound to a
> +user-space IO driver for use. The script ``dpdk-devbind.py`` script
> +included with DPDK can be used to view the state of the devices and to bind
> +them to a suitable DPDK-supported kernel driver. When querying the status
> +of the devices, they will appear under the category of "Misc (rawdev)
> +devices", i.e. the command ``dpdk-devbind.py --status-dev misc`` can be
> +used to see the state of those devices alone.
> +
> +Device Configuration
> +
> +
> +Configuring SDP EP rawdev device is done using the
> ``rte_rawdev_configure()``
> +API, which takes the mempool as parameter. PMD uses this pool to
> send/receive
> +packets to/from the HW.
> +
> +The following code shows how the device is configured
> +
> +.. code-block:: c
> +
> + struct sdp_rawdev_info config = {0};
> + struct rte_rawdev_info rdev_info = {.dev_private = &config};
> + config.enqdeq_mpool = (void *)rte_mempool_create(...);
> +
> + rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
> +
> diff --git a/drivers/common/octeontx2/hw/otx2_sdp.h
> b/drivers/common/octeontx2/hw/otx2_sdp.h
> new file mode 100644
> index 000..7e03317
> --- /dev/null
> +++ b/drivers/common/octeontx2/hw/otx2_sdp.h
> @@ -0,0 +1,184 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2019 Marvell International Ltd.
> + */
> +
> +#ifndef __OTX2_SDP_HW_H_
> +#define __OTX2_SDP_HW_H_
> +
> +/* SDP VF IOQs */
> +#define SDP_MIN_RINGS_PER_VF(1)
> +#define SDP_MAX_RINGS_PER_VF(8)
> +
> +/* SDP VF IQ configuration */
> +#define SDP_VF_MAX_IQ_DESCRIPTORS (512)
> +#define SDP_VF_MIN_IQ_DESCRIPTORS (128)
> +
> +#define SDP_VF_DB_MIN (1)
> +#define SDP_VF_DB_TIMEOUT (1)
> +#define SDP_VF_INTR_THRESHOLD (0x)
> +
> +#define SDP_VF_64BYTE_INSTR (64)
> +#define SDP_VF_32BYTE_INSTR (32)
> +
> +/* SDP VF OQ configuration */
> +#define SDP_VF_MAX_OQ_DESCRIPTORS (512)
> +#define SDP_VF_MIN_OQ_DESCRIPTORS (128)
> +#define SDP_VF_OQ_BUF_SIZE (2048)
> +#define SDP_VF_OQ_REFIL_THRESHOLD (16)
> +
> +#define SDP_VF_OQ_INFOPTR_MODE (1)
> +#define SDP_VF_OQ_BUFPTR_MODE (0)
> +
> +#define SDP_VF_OQ_INTR_PKT (1)
> +#define SDP_VF_OQ_INTR_TIME (10)
> +#define SDP_VF_CFG_IO_QUEUESSDP_MAX_RINGS_PER_VF
> +
> +/* Wait time in milliseconds for FLR */
> +#define SDP_VF_PCI_FLR_WAIT (100)
> +#define SDP_VF_BUSY_LOOP_COUNT (1)
> +
> +#define SDP_VF_MAX_IO_QUEUESSDP_MAX_RINGS_PER_VF
> +#define SDP_VF_MIN_IO_QUEUESSDP_MIN_RINGS_PER_VF
> +
> +/* SDP VF IOQs per rawdev */
> +#define SDP_VF_MAX_IOQS_PER_RAWDEV SDP_VF_MAX_IO_QUEUES
> +#define SDP_VF_DEFAULT_IOQS_PER_RAWDEV SDP_VF_MIN_IO_QUEUES
> +
> +/* SDP VF Register definitions */
> +#define SDP_VF_RING_OFFSET(0x1ull << 17)
> +
> +/* SDP VF IQ Registers */
> +#define SDP_VF_R_IN_CONTROL_START (0x1)
> +#define SDP_VF_R_IN_ENABLE_START (0x10010)
> +#define SDP_VF_R_IN_INSTR_BADDR_START (0x10020)
> +#define SDP_VF_R_IN_INSTR_RSIZE_START (0x10030)
> +
Re: [dpdk-dev] What's possible reasons that may cause rx_total_missed_packets increase in ixgbe driver?
Hi, DPDK masters, I am debugging a `imissed` issue when we are using DPDK. We notice that imissed increase even when the traffic is slow. We are using x520 nic and ixgbe driver. Via check the code, imissed comes from rx_total_missed_packets in ixgbe. But what's the possible reason that make rx_total_missed_packets increase in ixgbe? Highly appreciated your reply if you have any clues on this. On Fri, Dec 13, 2019 at 12:32 AM Haosong Huang wrote: > Hi, DPDK masters, I am debugging a `imissed` issue when we are using DPDK. > > We notice that imissed increase even when the traffic is slow. We are > using x520 nic and ixgbe driver. > > Via check the code, imissed comes from rx_total_missed_packets in ixgbe. > But what's the possible reason that make rx_total_missed_packets increase > in ixgbe? > > Highly appreciated your reply if you have any clues on this. > -- *Haosong Huang* STO *Mobile* +65 8299 3624 *Address* 5 Science Park Drive, Shopee Building, Singapore 118265
Re: [dpdk-dev] [PATCH v1 5/6] raw/octeontx2_ep: add dequeue operation
Hi Mahipal,
> -Original Message-
> From: dev On Behalf Of Mahipal Challa
> Sent: Friday, December 6, 2019 2:39 PM
> To: dev@dpdk.org
> Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> venk...@marvell.com
> Subject: [dpdk-dev] [PATCH v1 5/6] raw/octeontx2_ep: add dequeue
> operation
>
> Add rawdev dequeue operation for SDP VF devices.
>
> Signed-off-by: Mahipal Challa
> ---
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 199
> ++
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 2 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 18 ++-
> 4 files changed, 219 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> index ebbacfb..451fcc0 100644
> --- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> +++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> @@ -260,6 +260,7 @@
> rte_mempool_get(sdpvf->enqdeq_mpool, &buf);
> if (buf == NULL) {
> otx2_err("OQ buffer alloc failed");
> + droq->stats.rx_alloc_failure++;
> /* sdp_droq_destroy_ring_buffers(droq);*/
> return -ENOMEM;
> }
> @@ -645,3 +646,201 @@
> return SDP_IQ_SEND_FAILED;
> }
>
> +static uint32_t
> +sdp_droq_refill(struct sdp_device *sdpvf, struct sdp_droq *droq)
> +{
> + struct sdp_droq_desc *desc_ring;
> + uint32_t desc_refilled = 0;
> + void *buf = NULL;
> +
> + desc_ring = droq->desc_ring;
> +
> + while (droq->refill_count && (desc_refilled < droq->nb_desc)) {
> + /* If a valid buffer exists (happens if there is no dispatch),
> + * reuse the buffer, else allocate.
> + */
> + if (droq->recv_buf_list[droq->refill_idx].buffer != NULL)
> + break;
> +
> + rte_mempool_get(sdpvf->enqdeq_mpool, &buf);
> + /* If a buffer could not be allocated, no point in
> + * continuing
> + */
> + if (buf == NULL) {
> + droq->stats.rx_alloc_failure++;
> + break;
> + }
> +
> + droq->recv_buf_list[droq->refill_idx].buffer = buf;
> + desc_ring[droq->refill_idx].buffer_ptr =
> rte_mem_virt2iova(buf);
> +
> + /* Reset any previous values in the length field. */
> + droq->info_list[droq->refill_idx].length = 0;
> +
> + droq->refill_idx = sdp_incr_index(droq->refill_idx, 1,
> + droq->nb_desc);
> +
> + desc_refilled++;
> + droq->refill_count--;
> +
> + }
> +
> + return desc_refilled;
> +}
> +
> +static int
> +sdp_droq_read_packet(struct sdp_device *sdpvf __rte_unused,
> + struct sdp_droq *droq,
> + struct sdp_droq_pkt *droq_pkt)
> +{
> + struct sdp_droq_info *info;
> + uint32_t total_len = 0;
> + uint32_t pkt_len = 0;
> +
> + info = &droq->info_list[droq->read_idx];
> + sdp_swap_8B_data((uint64_t *)&info->length, 1);
> + if (!info->length) {
> + otx2_err("OQ info_list->length[%ld]", (long)info->length);
> + goto oq_read_fail;
> + }
> +
> + /* Deduce the actual data size */
> + info->length -= SDP_RH_SIZE;
> + total_len += (uint32_t)info->length;
> +
> + otx2_sdp_dbg("OQ: pkt_len[%ld], buffer_size %d",
> + (long)info->length, droq->buffer_size);
> + if (info->length > droq->buffer_size) {
> + otx2_err("This mode is not supported: pkt_len > buffer_size");
> + goto oq_read_fail;
> + }
> +
> + if (info->length <= droq->buffer_size) {
> + pkt_len = (uint32_t)info->length;
> + droq_pkt->data = droq->recv_buf_list[droq->read_idx].buffer;
> + droq_pkt->len = pkt_len;
> +
> + droq->recv_buf_list[droq->read_idx].buffer = NULL;
> + droq->read_idx = sdp_incr_index(droq->read_idx, 1,/*
> count */
> + droq->nb_desc /* max rd idx
> */);
> + droq->refill_count++;
> +
> + }
> +
> + info->length = 0;
> +
> + return SDP_OQ_RECV_SUCCESS;
> +
> +oq_read_fail:
> + return SDP_OQ_RECV_FAILED;
> +}
> +
> +static inline uint32_t
> +sdp_check_droq_pkts(struct sdp_droq *droq, uint32_t burst_size)
> +{
> + uint32_t min_pkts = 0;
> + uint32_t new_pkts;
> + uint32_t pkt_count;
> +
> + /* Latest available OQ packets */
> + pkt_count = rte_read32(droq->pkts_sent_reg);
> +
> + /* Newly arrived packets */
> + new_pkts = pkt_count - droq->last_pkt_count;
> + otx2_sdp_dbg("Recvd [%d] new OQ pkts", new_pkts);
> +
> + min_pkts = (new_pkts > burst_size) ? burst_size : new_pkts;
> + if (min_pkts) {
> + rte_atomic64_add(&droq->pkts_pending, min_pkts);
Re: [dpdk-dev] [PATCH v1 4/6] raw/octeontx2_ep: add enqueue operation
Hi Mahipal,
> -Original Message-
> From: dev On Behalf Of Mahipal Challa
> Sent: Friday, December 6, 2019 2:39 PM
> To: dev@dpdk.org
> Cc: jer...@marvell.com; pathr...@marvell.com; sni...@marvell.com;
> venk...@marvell.com
> Subject: [dpdk-dev] [PATCH v1 4/6] raw/octeontx2_ep: add enqueue
> operation
>
> Add rawdev enqueue operation for SDP VF devices.
>
> Signed-off-by: Mahipal Challa
> ---
> doc/guides/rawdevs/octeontx2_ep.rst | 6 +
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c | 242
> ++
> drivers/raw/octeontx2_ep/otx2_ep_enqdeq.h | 39 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.c | 1 +
> drivers/raw/octeontx2_ep/otx2_ep_rawdev.h | 20 +++
> drivers/raw/octeontx2_ep/otx2_ep_vf.c | 24 +++
> 6 files changed, 332 insertions(+)
>
> diff --git a/doc/guides/rawdevs/octeontx2_ep.rst
> b/doc/guides/rawdevs/octeontx2_ep.rst
> index 2507fcf..39a7c29 100644
> --- a/doc/guides/rawdevs/octeontx2_ep.rst
> +++ b/doc/guides/rawdevs/octeontx2_ep.rst
> @@ -68,3 +68,9 @@ The following code shows how the device is configured
>
> rte_rawdev_configure(dev_id, (rte_rawdev_obj_t)&rdev_info);
>
> +Performing Data Transfer
> +
> +
> +To perform data transfer using SDP VF EP rawdev devices use standard
> +``rte_rawdev_enqueue_buffers()`` and ``rte_rawdev_dequeue_buffers()``
> APIs.
> +
> diff --git a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> index 584b818..ebbacfb 100644
> --- a/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> +++ b/drivers/raw/octeontx2_ep/otx2_ep_enqdeq.c
> @@ -403,3 +403,245 @@
> return -ENOMEM;
> }
>
> +static inline void
> +sdp_iqreq_delete(struct sdp_device *sdpvf,
> + struct sdp_instr_queue *iq, uint32_t idx)
> +{
> + uint32_t reqtype;
> + void *buf;
> +
> + buf = iq->req_list[idx].buf;
> + reqtype = iq->req_list[idx].reqtype;
> +
> + switch (reqtype) {
> + case SDP_REQTYPE_NORESP:
> + rte_mempool_put(sdpvf->enqdeq_mpool, buf);
> + otx2_sdp_dbg("IQ buffer freed at idx[%d]", idx);
> + break;
> +
> + case SDP_REQTYPE_NORESP_GATHER:
> + case SDP_REQTYPE_NONE:
> + default:
> + otx2_info("This iqreq mode is not supported:%d", reqtype);
> +
> + }
> +
> + /* Reset the request list at this index */
> + iq->req_list[idx].buf = NULL;
> + iq->req_list[idx].reqtype = 0;
> +}
> +
> +static inline void
> +sdp_iqreq_add(struct sdp_instr_queue *iq, void *buf,
> + uint32_t reqtype)
> +{
> + iq->req_list[iq->host_write_index].buf = buf;
> + iq->req_list[iq->host_write_index].reqtype = reqtype;
> +
> + otx2_sdp_dbg("IQ buffer added at idx[%d]", iq->host_write_index);
> +
> +}
> +
> +static void
> +sdp_flush_iq(struct sdp_device *sdpvf,
> + struct sdp_instr_queue *iq,
> + uint32_t pending_thresh __rte_unused)
> +{
> + uint32_t instr_processed = 0;
> +
> + rte_spinlock_lock(&iq->lock);
> +
> + iq->otx_read_index = sdpvf->fn_list.update_iq_read_idx(iq);
> + while (iq->flush_index != iq->otx_read_index) {
> + /* Free the IQ data buffer to the pool */
> + sdp_iqreq_delete(sdpvf, iq, iq->flush_index);
> + iq->flush_index =
> + sdp_incr_index(iq->flush_index, 1, iq->nb_desc);
> +
> + instr_processed++;
> + }
> +
> + iq->stats.instr_processed = instr_processed;
> + rte_atomic64_sub(&iq->instr_pending, instr_processed);
> +
> + rte_spinlock_unlock(&iq->lock);
> +}
> +
> +static inline void
> +sdp_ring_doorbell(struct sdp_device *sdpvf __rte_unused,
> + struct sdp_instr_queue *iq)
> +{
> + otx2_write64(iq->fill_cnt, iq->doorbell_reg);
> +
> + /* Make sure doorbell write goes through */
> + rte_wmb();
This is overkill, no need to wait for the completeness, is it ok to just ensure
the doorbell ring is seen by the device before the new fill_cnt is seen by
lcore? If yes, therefore rte_cio_wmb is sufficient.
> + iq->fill_cnt = 0;
> +
> +}
> +
> +static inline int
> +post_iqcmd(struct sdp_instr_queue *iq, uint8_t *iqcmd)
> +{
> + uint8_t *iqptr, cmdsize;
> +
> + /* This ensures that the read index does not wrap around to
> + * the same position if queue gets full before OCTEON TX2 could
> + * fetch any instr.
> + */
> + if (rte_atomic64_read(&iq->instr_pending) >=
> + (int32_t)(iq->nb_desc - 1)) {
> + otx2_err("IQ is full, pending:%ld",
> + (long)rte_atomic64_read(&iq->instr_pending));
> +
> + return SDP_IQ_SEND_FAILED;
> + }
> +
> + /* Copy cmd into iq */
> + cmdsize = ((iq->iqcmd_64B) ? 64 : 32);
> + iqptr = iq->base_addr + (cmdsize * iq->host_write_index);
> +
> + rte_memcpy(iqptr, iqcmd, cmdsize);
> +
> + otx2_sdp_dbg("IQ cmd posted @ index:%d", iq->host_write_index);
> +
> + /
Re: [dpdk-dev] [PATCH] ethdev: allow multiple security sessions to use one rte flow
Hi Konstantin, Please see inline. Thanks, Anoob > -Original Message- > From: Ananyev, Konstantin > Sent: Friday, December 13, 2019 5:25 PM > To: Anoob Joseph ; Akhil Goyal ; > Adrien Mazarguil ; Doherty, Declan > ; Yigit, Ferruh ; Jerin > Jacob > Kollanukkaran ; Thomas Monjalon > > Cc: Ankur Dwivedi ; Hemant Agrawal > ; Matan Azrad ; Nicolau, > Radu ; Shahaf Shuler ; > Narayana Prasad Raju Athreya ; dev@dpdk.org > Subject: [EXT] RE: [PATCH] ethdev: allow multiple security sessions to use one > rte flow > > External Email > > -- > > > > > > The rte_security API which enables inline protocol/crypto > > > > > > feature mandates that for every security session an rte_flow is > > > > > > created. > > > > > > This would internally translate to a rule in the hardware > > > > > > which would do packet classification. > > > > > > > > > > > > In rte_securty, one SA would be one security session. And if > > > > > > an rte_flow need to be created for every session, the number > > > > > > of SAs supported by an inline implementation would be limited > > > > > > by the number of rte_flows the PMD would be able to support. > > > > > > > > > > > > If the fields SPI & IP addresses are allowed to be a range, > > > > > > then this limitation can be overcome. Multiple flows will be > > > > > > able to use one rule for SECURITY processing. In this case, > > > > > > the security session provided as conf would be NULL. > > > > > > > > > > Wonder what will be the usage model for it? > > > > > AFAIK, RFC 4301 clearly states that either SPI value alone or > > > > > in conjunction with dst (and src) IP should clearly identify SA > > > > > for inbound SAD > > > lookup. > > > > > Am I missing something obvious here? > > > > > > > > [Anoob] Existing SECURITY action type requires application to > > > > create an 'rte_flow' per SA, which is not really required if h/w > > > > can use SPI to uniquely > > > identify the security session/SA. > > > > > > > > Existing rte_flow usage: IP (dst,src) + ESP + SPI -> security > > > > processing enabled on one security session (ie on SA) > > > > > > > > The above rule would uniquely identify packets for an SA. But with > > > > the above usage, we would quickly exhaust entries available in h/w > > > > lookup tables (which are limited on our hardware). But if h/w can > > > > use SPI field to index > > > into a table (for example), then the above requirement of one > > > rte_flow per SA is not required. > > > > > > > > Proposed rte_flow usage: IP (any) + ESP + SPI (any) -> security > > > > processing enabled on all ESP packets > > > > > > > > Now h/w could use SPI to index into a pre-populated table to get > > > > security session. Please do note that, SPI is not ignored during > > > > the actual > > > lookup. Just that it is not used while creating 'rte_flow'. > > > > > > And this table will be prepopulated by user and pointer to it will > > > be somehow passed via rte_flow API? > > > If yes, then what would be the mechanism? > > > > [Anoob] I'm not sure what exactly you meant by user. But may be I'll explain > how it's done in OCTEONTX2 PMD. > > > > The application would create security_session for every SA. SPI etc would be > available to PMD (in conf) when the session is created. > > Now the PMD would populate SA related params in a specific location > > that h/w would access. This memory is allocated during device configure and > h/w would have the pointer after the initialization is done. > > > > PMD uses SPI as index to write into specific locations(during session > > create) and h/w would use it when it sees an ESP packet eligible for > > SECURITY (in receive path, per packet). As long as session creation could > populate at memory locations that h/w would look at, this scheme would work. > > Thanks for explanation, few more questions: > Ok, so the table will be allocated at device init() somehow (nothing to do > with > rte_flow). [Anoob] Yes. > Then PMD will be able to write/update entries in that table and HW will be > able > to read (to get SPI, keys, etc), correct? [Anoob] Yes. > Now if upper layer (ipsec-secgw for example) would like to create new ESP > session on that device, what it would need to do? > Would it still need to use rte_flow API for that? > Or just call rte_security_session_create() and PMD will take update this HW/SW > table for it? [Anoob] rte_security_session_create() is enough. > > > > > > > > > > > > > > The usage of one 'rte_flow' for multiple SAs is not mandatory. It > > > > is only required when application requires large number of SAs. > > > > The proposed > > > change is to allow more efficient usage of h/w resources where it's > > > permitted by the PMD. > > > > > > > > > > > > > > > > > > > > > Application should do an rte_flow_validate() to make sure the > > > > > > flow is supported on the PMD. > > > > > > > > > > > > Signed-off-by: Anoob Joseph > > > > > > --- >
