Skip to contentSkip to conversation

net/fm10k: convert to new Rx/Tx offloads API

PATCH Superseded Wei Dai 5 participants 18 messages Mar 2, 2018 – Apr 4, 2018 Network drivers

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Wei Dai

author
#0 lore raw

PATCH 1/1 net/fm10k: convert to new Rx/Tx offloads API

Ethdev Rx offloads API has changed since:
commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") Ethdev Tx offloads API has changed since:
commit cba7f53b717d ("ethdev: introduce Tx queue offloads API") This commit support the new Rx and Tx offloads API.

---
 drivers/net/fm10k/fm10k.h          |  7 +++++++
 drivers/net/fm10k/fm10k_ethdev.c   | 33 ++++++++++++++++++++++++---------
 drivers/net/fm10k/fm10k_rxtx_vec.c |  6 +++---
 3 files changed, 34 insertions(+), 12 deletions(-)
drivers/net/fm10k/fm10k.h +7 -0
index 30dad3e..57bd533 100644
@@ -108,6 +108,11 @@
 
 #define FM10K_SIMPLE_TX_FLAG ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
 				ETH_TXQ_FLAGS_NOOFFLOADS)
+#define FM10K_SIMPLE_TX_OFFLOADS ((uint64_t)(DEV_TX_OFFLOAD_MULTI_SEGS  | \
+					     DEV_TX_OFFLOAD_VLAN_INSERT | \
+					     DEV_TX_OFFLOAD_SCTP_CKSUM  | \
+					     DEV_TX_OFFLOAD_UDP_CKSUM   | \
+					     DEV_TX_OFFLOAD_TCP_CKSUM))
 
 struct fm10k_macvlan_filter_info {
 	uint16_t vlan_num;       /* Total VLAN number */
@@ -180,6 +185,7 @@ struct fm10k_rx_queue {
 	uint8_t drop_en;
 	uint8_t rx_deferred_start; /* don't start this queue in dev start. */
 	uint16_t rx_ftag_en; /* indicates FTAG RX supported */
+	uint64_t offloads; /* offloads of DEV_RX_OFFLOAD_* */
 };
 
 /*
@@ -212,6 +218,7 @@ struct fm10k_tx_queue {
 	uint16_t next_dd; /* Next pos to check DD flag */
 	volatile uint32_t *tail_ptr;
 	uint32_t txq_flags; /* Holds flags for this TXq */
+	uint64_t offloads; /* Offloads of DEV_TX_OFFLOAD_* */
 	uint16_t nb_desc;
 	uint16_t port_id;
 	uint8_t tx_deferred_start; /** don't start this queue in dev start. */
drivers/net/fm10k/fm10k_ethdev.c +24 -9
index 9423761..5105874 100644
@@ -444,7 +444,7 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
 
 	PMD_INIT_FUNC_TRACE();
 
-	if (dev->data->dev_conf.rxmode.hw_strip_crc == 0)
+	if (dev->data->dev_conf.rxmode.offloads & DEV_RX_OFFLOAD_CRC_STRIP)
 		PMD_INIT_LOG(WARNING, "fm10k always strip CRC");
 	/* multipe queue mode checking */
 	ret  = fm10k_check_mq_mode(dev);
@@ -454,6 +454,8 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
 		return ret;
 	}
 
+	dev->data->scattered_rx = 0;
+
 	return 0;
 }
 
@@ -756,7 +758,7 @@ fm10k_dev_rx_init(struct rte_eth_dev *dev)
 		/* It adds dual VLAN length for supporting dual VLAN */
 		if ((dev->data->dev_conf.rxmode.max_rx_pkt_len +
 				2 * FM10K_VLAN_TAG_SIZE) > buf_size ||
-			dev->data->dev_conf.rxmode.enable_scatter) {
+			rxq->offloads & DEV_RX_OFFLOAD_SCATTER) {
 			uint32_t reg;
 			dev->data->scattered_rx = 1;
 			reg = FM10K_READ_REG(hw, FM10K_SRRCTL(i));
@@ -1389,11 +1391,17 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 	dev_info->vmdq_queue_base    = 0;
 	dev_info->max_vmdq_pools     = ETH_32_POOLS;
 	dev_info->vmdq_queue_num     = FM10K_MAX_QUEUES_PF;
+	dev_info->rx_queue_offload_capa = DEV_RX_OFFLOAD_SCATTER;
 	dev_info->rx_offload_capa =
-		DEV_RX_OFFLOAD_VLAN_STRIP |
-		DEV_RX_OFFLOAD_IPV4_CKSUM |
-		DEV_RX_OFFLOAD_UDP_CKSUM  |
-		DEV_RX_OFFLOAD_TCP_CKSUM;
+		DEV_RX_OFFLOAD_VLAN_STRIP  |
+		DEV_RX_OFFLOAD_VLAN_FILTER |
+		DEV_RX_OFFLOAD_IPV4_CKSUM  |
+		DEV_RX_OFFLOAD_UDP_CKSUM   |
+		DEV_RX_OFFLOAD_TCP_CKSUM   |
+		DEV_RX_OFFLOAD_JUMBO_FRAME |
+		DEV_RX_OFFLOAD_CRC_STRIP   |
+		DEV_RX_OFFLOAD_SCATTER;
+	dev_info->tx_queue_offload_capa = 0;
 	dev_info->tx_offload_capa =
 		DEV_TX_OFFLOAD_VLAN_INSERT |
 		DEV_TX_OFFLOAD_IPV4_CKSUM  |
@@ -1412,6 +1420,7 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 		},
 		.rx_free_thresh = FM10K_RX_FREE_THRESH_DEFAULT(0),
 		.rx_drop_en = 0,
+		.offloads = 0,
 	};
 
 	dev_info->default_txconf = (struct rte_eth_txconf) {
@@ -1423,6 +1432,7 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 		.tx_free_thresh = FM10K_TX_FREE_THRESH_DEFAULT(0),
 		.tx_rs_thresh = FM10K_TX_RS_THRESH_DEFAULT(0),
 		.txq_flags = FM10K_SIMPLE_TX_FLAG,
+		.offloads = 0,
 	};
 
 	dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
@@ -1571,19 +1581,22 @@ static int
 fm10k_vlan_offload_set(struct rte_eth_dev *dev, int mask)
 {
 	if (mask & ETH_VLAN_STRIP_MASK) {
-		if (!dev->data->dev_conf.rxmode.hw_vlan_strip)
+		if (!(dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_STRIP))
 			PMD_INIT_LOG(ERR, "VLAN stripping is "
 					"always on in fm10k");
 	}
 
 	if (mask & ETH_VLAN_EXTEND_MASK) {
-		if (dev->data->dev_conf.rxmode.hw_vlan_extend)
+		if (dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_EXTEND)
 			PMD_INIT_LOG(ERR, "VLAN QinQ is not "
 					"supported in fm10k");
 	}
 
 	if (mask & ETH_VLAN_FILTER_MASK) {
-		if (!dev->data->dev_conf.rxmode.hw_vlan_filter)
+		if (!(dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_FILTER))
 			PMD_INIT_LOG(ERR, "VLAN filter is always on in fm10k");
 	}
 
@@ -1879,6 +1892,7 @@ fm10k_rx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_id,
 		fm10k_rxq_vec_setup(q);
 
 	dev->data->rx_queues[queue_id] = q;
+	q->offloads = conf->offloads;
 	return 0;
 }
 
@@ -1995,6 +2009,7 @@ fm10k_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_id,
 	q->port_id = dev->data->port_id;
 	q->queue_id = queue_id;
 	q->txq_flags = conf->txq_flags;
+	q->offloads = conf->offloads;
 	q->ops = &def_txq_ops;
 	q->tail_ptr = (volatile uint32_t *)
 		&((uint32_t *)hw->hw_addr)[FM10K_TDT(queue_id)];
drivers/net/fm10k/fm10k_rxtx_vec.c +3 -3
index 498a178..e6dba04 100644
@@ -210,7 +210,7 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
 
 #ifndef RTE_FM10K_RX_OLFLAGS_ENABLE
 	/* whithout rx ol_flags, no VP flag report */
-	if (rxmode->hw_vlan_extend != 0)
+	if (rxmode->offloads & DEV_RX_OFFLOAD_VLAN_EXTEND)
 		return -1;
 #endif
 
@@ -219,7 +219,7 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
 		return -1;
 
 	/* no header split support */
-	if (rxmode->header_split == 1)
+	if (rxmode->offloads & DEV_RX_OFFLOAD_HEADER_SPLIT)
 		return -1;
 
 	return 0;
@@ -695,7 +695,7 @@ int __attribute__((cold))
 fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
 {
 	/* Vector TX can't offload any features yet */
-	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
+	if (txq->offloads & FM10K_SIMPLE_TX_OFFLOADS)
 		return -1;
 
 	if (txq->tx_ftag_en)
Signature · 1 line
2.9.4
#1 lore raw

Hi Daiwei:

Quoted 131 lines

-----Original Message-----
From: Dai, Wei
Sent: Friday, March 2, 2018 10:11 PM
To: Zhang, Qi Z <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]; Dai, Wei <[email protected]>
Subject: [PATCH] net/fm10k: convert to new Rx/Tx offloads API

Ethdev Rx offloads API has changed since:
commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") Ethdev Tx offloads API has changed since:
commit cba7f53b717d ("ethdev: introduce Tx queue offloads API") This commit support the new Rx and Tx offloads API.

---
 drivers/net/fm10k/fm10k.h          |  7 +++++++
 drivers/net/fm10k/fm10k_ethdev.c   | 33
++++++++++++++++++++++++---------
 drivers/net/fm10k/fm10k_rxtx_vec.c |  6 +++---
 3 files changed, 34 insertions(+), 12 deletions(-)
drivers/net/fm10k/fm10k.h index renamed from drivers/net/fm10k/fm10k.h +0 -0

30dad3e..57bd533 100644

drivers/net/fm10k/fm10k.h +5 -0
@@ -108,6 +108,11 @@
 
 #define FM10K_SIMPLE_TX_FLAG
 ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
 				ETH_TXQ_FLAGS_NOOFFLOADS)
+#define FM10K_SIMPLE_TX_OFFLOADS
 ((uint64_t)(DEV_TX_OFFLOAD_MULTI_SEGS  | \
+					     DEV_TX_OFFLOAD_VLAN_INSERT | \
+					     DEV_TX_OFFLOAD_SCTP_CKSUM  | \
+					     DEV_TX_OFFLOAD_UDP_CKSUM   | \
+					     DEV_TX_OFFLOAD_TCP_CKSUM))
 

struct fm10k_macvlan_filter_info {

drivers/net/fm10k/fm10k.h +2 -1
 	uint16_t vlan_num;       /* Total VLAN number */
@@ -180,6 +185,7 @@ struct fm10k_rx_queue {
 	uint8_t drop_en;
 	uint8_t rx_deferred_start; /* don't start this queue in dev start. */
 	uint16_t rx_ftag_en; /* indicates FTAG RX supported */
+	uint64_t offloads; /* offloads of DEV_RX_OFFLOAD_* */
 };
 
 /*
@@ -212,6 +218,7 @@ struct fm10k_tx_queue {
 	uint16_t next_dd; /* Next pos to check DD flag */
 	volatile uint32_t *tail_ptr;
 	uint32_t txq_flags; /* Holds flags for this TXq */
+	uint64_t offloads; /* Offloads of DEV_TX_OFFLOAD_* */
 	uint16_t nb_desc;
 	uint16_t port_id;
 	uint8_t tx_deferred_start; /** don't start this queue in dev start. */ diff
--git a/drivers/net/fm10k/fm10k_ethdev.c

b/drivers/net/fm10k/fm10k_ethdev.c
index 9423761..5105874 100644

drivers/net/fm10k/fm10k_ethdev.c +1 -1
@@ -444,7 +444,7 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
 
 	PMD_INIT_FUNC_TRACE();
 
-	if (dev->data->dev_conf.rxmode.hw_strip_crc == 0)
+	if (dev->data->dev_conf.rxmode.offloads &
 DEV_RX_OFFLOAD_CRC_STRIP)
 		PMD_INIT_LOG(WARNING, "fm10k always strip CRC");
 	/* multipe queue mode checking */
drivers/net/fm10k/fm10k_ethdev.c +17 -6
 	ret  = fm10k_check_mq_mode(dev);
@@ -454,6 +454,8 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
 		return ret;
 	}
 
+	dev->data->scattered_rx = 0;
+
 	return 0;
 }
 
@@ -756,7 +758,7 @@ fm10k_dev_rx_init(struct rte_eth_dev *dev)
 		/* It adds dual VLAN length for supporting dual VLAN */
 		if ((dev->data->dev_conf.rxmode.max_rx_pkt_len +
 				2 * FM10K_VLAN_TAG_SIZE) > buf_size ||
-			dev->data->dev_conf.rxmode.enable_scatter) {
+			rxq->offloads & DEV_RX_OFFLOAD_SCATTER) {
 			uint32_t reg;
 			dev->data->scattered_rx = 1;
 			reg = FM10K_READ_REG(hw, FM10K_SRRCTL(i)); @@
-1389,11 +1391,17 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 	dev_info->vmdq_queue_base    = 0;
 	dev_info->max_vmdq_pools     = ETH_32_POOLS;
 	dev_info->vmdq_queue_num     = FM10K_MAX_QUEUES_PF;
+	dev_info->rx_queue_offload_capa = DEV_RX_OFFLOAD_SCATTER;
 	dev_info->rx_offload_capa =
-		DEV_RX_OFFLOAD_VLAN_STRIP |
-		DEV_RX_OFFLOAD_IPV4_CKSUM |
-		DEV_RX_OFFLOAD_UDP_CKSUM  |
-		DEV_RX_OFFLOAD_TCP_CKSUM;
+		DEV_RX_OFFLOAD_VLAN_STRIP  |
+		DEV_RX_OFFLOAD_VLAN_FILTER |
+		DEV_RX_OFFLOAD_IPV4_CKSUM  |
+		DEV_RX_OFFLOAD_UDP_CKSUM   |
+		DEV_RX_OFFLOAD_TCP_CKSUM   |
+		DEV_RX_OFFLOAD_JUMBO_FRAME |
+		DEV_RX_OFFLOAD_CRC_STRIP   |
+		DEV_RX_OFFLOAD_SCATTER;
+	dev_info->tx_queue_offload_capa = 0;
 	dev_info->tx_offload_capa =
 		DEV_TX_OFFLOAD_VLAN_INSERT |
 		DEV_TX_OFFLOAD_IPV4_CKSUM  |
@@ -1412,6 +1420,7 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 		},
 		.rx_free_thresh = FM10K_RX_FREE_THRESH_DEFAULT(0),
 		.rx_drop_en = 0,
+		.offloads = 0,
 	};
 
 	dev_info->default_txconf = (struct rte_eth_txconf) { @@ -1423,6
+1432,7 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 		.tx_free_thresh = FM10K_TX_FREE_THRESH_DEFAULT(0),
 		.tx_rs_thresh = FM10K_TX_RS_THRESH_DEFAULT(0),
 		.txq_flags = FM10K_SIMPLE_TX_FLAG,
+		.offloads = 0,
 	};
 
 	dev_info->rx_desc_lim = (struct rte_eth_desc_lim) { @@ -1571,19
+1581,22 @@ static int  fm10k_vlan_offload_set(struct rte_eth_dev *dev,

int mask) {

drivers/net/fm10k/fm10k_ethdev.c +0 -1
 	if (mask & ETH_VLAN_STRIP_MASK) {
-		if (!dev->data->dev_conf.rxmode.hw_vlan_strip)

drivers/net/fm10k/fm10k_ethdev.c static int · line 1592

Quoted 10 lines
drivers/net/fm10k/fm10k_ethdev.c +4 -1
+		if (!(dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_STRIP))
 			PMD_INIT_LOG(ERR, "VLAN stripping is "
 					"always on in fm10k");
 	}
 
 	if (mask & ETH_VLAN_EXTEND_MASK) {
-		if (dev->data->dev_conf.rxmode.hw_vlan_extend)
+		if (dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_EXTEND)

Seems DEV_RX_OFFLOAD_VLAN_EXTEND is missed in fm10k_dev_infos_get?

Quoted 45 lines
drivers/net/fm10k/fm10k_ethdev.c +4 -1
 			PMD_INIT_LOG(ERR, "VLAN QinQ is not "
 					"supported in fm10k");
 	}
 
 	if (mask & ETH_VLAN_FILTER_MASK) {
-		if (!dev->data->dev_conf.rxmode.hw_vlan_filter)
+		if (!(dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_FILTER))
 			PMD_INIT_LOG(ERR, "VLAN filter is always on in fm10k");
 	}
@@ -1879,6 +1892,7 @@ fm10k_rx_queue_setup(struct rte_eth_dev *dev,
 uint16_t queue_id,
 		fm10k_rxq_vec_setup(q);
 
 	dev->data->rx_queues[queue_id] = q;
+	q->offloads = conf->offloads;
 	return 0;
 }
@@ -1995,6 +2009,7 @@ fm10k_tx_queue_setup(struct rte_eth_dev *dev,
 uint16_t queue_id,
 	q->port_id = dev->data->port_id;
 	q->queue_id = queue_id;
 	q->txq_flags = conf->txq_flags;
+	q->offloads = conf->offloads;
 	q->ops = &def_txq_ops;
 	q->tail_ptr = (volatile uint32_t *)
drivers/net/fm10k/fm10k_ethdev.c +0 -0
 		&((uint32_t *)hw->hw_addr)[FM10K_TDT(queue_id)];
drivers/net/fm10k/fm10k_rxtx_vec.c +1 -1
index 498a178..e6dba04 100644
@@ -210,7 +210,7 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev
 *dev)
 
 #ifndef RTE_FM10K_RX_OLFLAGS_ENABLE
 	/* whithout rx ol_flags, no VP flag report */
-	if (rxmode->hw_vlan_extend != 0)
+	if (rxmode->offloads & DEV_RX_OFFLOAD_VLAN_EXTEND)
 		return -1;
 #endif

drivers/net/fm10k/fm10k_rxtx_vec.c fm10k_rx_vec_condition_check(struct rte_eth_dev · line 223

Quoted 6 lines
drivers/net/fm10k/fm10k_rxtx_vec.c +1 -1
@@ -219,7 +219,7 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev
 *dev)
 		return -1;
 
 	/* no header split support */
-	if (rxmode->header_split == 1)
+	if (rxmode->offloads & DEV_RX_OFFLOAD_HEADER_SPLIT)

DEV_RX_OFFLOAD_HEADER_SPLIT also missed in fm10k_dev_infos_get?

drivers/net/fm10k/fm10k_rxtx_vec.c int __attribute__((cold)) · line 699

Quoted 10 lines
drivers/net/fm10k/fm10k_rxtx_vec.c +0 -0
 		return -1;
 
drivers/net/fm10k/fm10k_rxtx_vec.c +1 -1
 	return 0;
@@ -695,7 +695,7 @@ int __attribute__((cold))
 fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)  {
 	/* Vector TX can't offload any features yet */
-	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) !=
 FM10K_SIMPLE_TX_FLAG)
+	if (txq->offloads & FM10K_SIMPLE_TX_OFFLOADS)
 		return -1;

Is this correct? an offload not include in FM10K_SIMPLE_TX_OFFLOADS will also fail this branch and pass check, right? The logic can be implemented like below:

#define FM10K_VEC_TX_OFFLOAD_SUPPORT xxx | xxx ...

If (txq->offloads & FM10K_VEC_TX_OFFLOAD_SUPPORT != txq->offload)
return -1

Regards
Qi

Quoted 4 lines
drivers/net/fm10k/fm10k_rxtx_vec.c +0 -1
 	if (txq->tx_ftag_en)
--

2.9.4

author
#2 lore raw

Thank you, Zhang Qi for your feedback.

Quoted 148 lines

-----Original Message-----
From: Zhang, Qi Z
Sent: Monday, March 19, 2018 11:55 AM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH] net/fm10k: convert to new Rx/Tx offloads API

Hi Daiwei:

Quoted 139 lines

-----Original Message-----
From: Dai, Wei
Sent: Friday, March 2, 2018 10:11 PM
To: Zhang, Qi Z <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]; Dai, Wei <[email protected]>
Subject: [PATCH] net/fm10k: convert to new Rx/Tx offloads API

Ethdev Rx offloads API has changed since:
commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") Ethdev Tx offloads API has changed since:
commit cba7f53b717d ("ethdev: introduce Tx queue offloads API") This commit support the new Rx and Tx offloads API.

---
 drivers/net/fm10k/fm10k.h          |  7 +++++++
 drivers/net/fm10k/fm10k_ethdev.c   | 33
++++++++++++++++++++++++---------
 drivers/net/fm10k/fm10k_rxtx_vec.c |  6 +++---
 3 files changed, 34 insertions(+), 12 deletions(-)
drivers/net/fm10k/fm10k.h +0 -0

index
30dad3e..57bd533 100644

drivers/net/fm10k/fm10k.h +5 -0
@@ -108,6 +108,11 @@
 
 #define FM10K_SIMPLE_TX_FLAG
 ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
 				ETH_TXQ_FLAGS_NOOFFLOADS)
+#define FM10K_SIMPLE_TX_OFFLOADS
 ((uint64_t)(DEV_TX_OFFLOAD_MULTI_SEGS  | \
+					     DEV_TX_OFFLOAD_VLAN_INSERT | \
+					     DEV_TX_OFFLOAD_SCTP_CKSUM  | \
+					     DEV_TX_OFFLOAD_UDP_CKSUM   | \
+					     DEV_TX_OFFLOAD_TCP_CKSUM))
 

struct fm10k_macvlan_filter_info {

drivers/net/fm10k/fm10k.h +2 -0
 	uint16_t vlan_num;       /* Total VLAN number */
@@ -180,6 +185,7 @@ struct fm10k_rx_queue {
 	uint8_t drop_en;
 	uint8_t rx_deferred_start; /* don't start this queue in dev start. */
 	uint16_t rx_ftag_en; /* indicates FTAG RX supported */
+	uint64_t offloads; /* offloads of DEV_RX_OFFLOAD_* */
 };
 
 /*
@@ -212,6 +218,7 @@ struct fm10k_tx_queue {
 	uint16_t next_dd; /* Next pos to check DD flag */
 	volatile uint32_t *tail_ptr;
 	uint32_t txq_flags; /* Holds flags for this TXq */
+	uint64_t offloads; /* Offloads of DEV_TX_OFFLOAD_* */
 	uint16_t nb_desc;
 	uint16_t port_id;
 	uint8_t tx_deferred_start; /** don't start this queue in dev start.

*/ diff --git a/drivers/net/fm10k/fm10k_ethdev.c
b/drivers/net/fm10k/fm10k_ethdev.c
index 9423761..5105874 100644

drivers/net/fm10k/fm10k_ethdev.c +1 -1
@@ -444,7 +444,7 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
 
 	PMD_INIT_FUNC_TRACE();
 
-	if (dev->data->dev_conf.rxmode.hw_strip_crc == 0)
+	if (dev->data->dev_conf.rxmode.offloads &
 DEV_RX_OFFLOAD_CRC_STRIP)
 		PMD_INIT_LOG(WARNING, "fm10k always strip CRC");
 	/* multipe queue mode checking */
drivers/net/fm10k/fm10k_ethdev.c +18 -6
 	ret  = fm10k_check_mq_mode(dev);
@@ -454,6 +454,8 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
 		return ret;
 	}
 
+	dev->data->scattered_rx = 0;
+
 	return 0;
 }
 
@@ -756,7 +758,7 @@ fm10k_dev_rx_init(struct rte_eth_dev *dev)
 		/* It adds dual VLAN length for supporting dual VLAN */
 		if ((dev->data->dev_conf.rxmode.max_rx_pkt_len +
 				2 * FM10K_VLAN_TAG_SIZE) > buf_size ||
-			dev->data->dev_conf.rxmode.enable_scatter) {
+			rxq->offloads & DEV_RX_OFFLOAD_SCATTER) {
 			uint32_t reg;
 			dev->data->scattered_rx = 1;
 			reg = FM10K_READ_REG(hw, FM10K_SRRCTL(i)); @@
-1389,11 +1391,17 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 	dev_info->vmdq_queue_base    = 0;
 	dev_info->max_vmdq_pools     = ETH_32_POOLS;
 	dev_info->vmdq_queue_num     = FM10K_MAX_QUEUES_PF;
+	dev_info->rx_queue_offload_capa = DEV_RX_OFFLOAD_SCATTER;
 	dev_info->rx_offload_capa =
-		DEV_RX_OFFLOAD_VLAN_STRIP |
-		DEV_RX_OFFLOAD_IPV4_CKSUM |
-		DEV_RX_OFFLOAD_UDP_CKSUM  |
-		DEV_RX_OFFLOAD_TCP_CKSUM;
+		DEV_RX_OFFLOAD_VLAN_STRIP  |
+		DEV_RX_OFFLOAD_VLAN_FILTER |
+		DEV_RX_OFFLOAD_IPV4_CKSUM  |
+		DEV_RX_OFFLOAD_UDP_CKSUM   |
+		DEV_RX_OFFLOAD_TCP_CKSUM   |
+		DEV_RX_OFFLOAD_JUMBO_FRAME |
+		DEV_RX_OFFLOAD_CRC_STRIP   |
+		DEV_RX_OFFLOAD_SCATTER;
+	dev_info->tx_queue_offload_capa = 0;
 	dev_info->tx_offload_capa =
 		DEV_TX_OFFLOAD_VLAN_INSERT |
 		DEV_TX_OFFLOAD_IPV4_CKSUM  |
@@ -1412,6 +1420,7 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 		},
 		.rx_free_thresh = FM10K_RX_FREE_THRESH_DEFAULT(0),
 		.rx_drop_en = 0,
+		.offloads = 0,
 	};
 
 	dev_info->default_txconf = (struct rte_eth_txconf) { @@ -1423,6
+1432,7 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
 		.tx_free_thresh = FM10K_TX_FREE_THRESH_DEFAULT(0),
 		.tx_rs_thresh = FM10K_TX_RS_THRESH_DEFAULT(0),
 		.txq_flags = FM10K_SIMPLE_TX_FLAG,
+		.offloads = 0,
 	};
 
 	dev_info->rx_desc_lim = (struct rte_eth_desc_lim) { @@ -1571,19
+1581,22 @@ static int  fm10k_vlan_offload_set(struct rte_eth_dev
+*dev,

int mask) {

drivers/net/fm10k/fm10k_ethdev.c +2 -1
 	if (mask & ETH_VLAN_STRIP_MASK) {
-		if (!dev->data->dev_conf.rxmode.hw_vlan_strip)
+		if (!(dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_STRIP))
 			PMD_INIT_LOG(ERR, "VLAN stripping is "
 					"always on in fm10k");
 	}
Quoted 7 lines

drivers/net/fm10k/fm10k_ethdev.c static int · line 1592

Quoted 4 lines
drivers/net/fm10k/fm10k_ethdev.c +2 -1
 	if (mask & ETH_VLAN_EXTEND_MASK) {
-		if (dev->data->dev_conf.rxmode.hw_vlan_extend)
+		if (dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_EXTEND)

Seems DEV_RX_OFFLOAD_VLAN_EXTEND is missed in fm10k_dev_infos_get?

Yes, will add this offloading in my next version of patch.

Quoted 49 lines

drivers/net/fm10k/fm10k_ethdev.c fm10k_rx_queue_setup(struct rte_eth_dev

Quoted 12 lines
drivers/net/fm10k/fm10k_ethdev.c +2 -1
 			PMD_INIT_LOG(ERR, "VLAN QinQ is not "
 					"supported in fm10k");
 	}
 
 	if (mask & ETH_VLAN_FILTER_MASK) {
-		if (!dev->data->dev_conf.rxmode.hw_vlan_filter)
+		if (!(dev->data->dev_conf.rxmode.offloads &
+			DEV_RX_OFFLOAD_VLAN_FILTER))
 			PMD_INIT_LOG(ERR, "VLAN filter is always on in fm10k");
 	}
@@ -1879,6 +1892,7 @@ fm10k_rx_queue_setup(struct rte_eth_dev

*dev,

drivers/net/fm10k/fm10k_ethdev.c fm10k_tx_queue_setup(struct rte_eth_dev

Quoted 9 lines
drivers/net/fm10k/fm10k_ethdev.c +1 -0
 uint16_t queue_id,
 		fm10k_rxq_vec_setup(q);
 
 	dev->data->rx_queues[queue_id] = q;
+	q->offloads = conf->offloads;
 	return 0;
 }
@@ -1995,6 +2009,7 @@ fm10k_tx_queue_setup(struct rte_eth_dev

*dev,

drivers/net/fm10k/fm10k_rxtx_vec.c fm10k_rx_vec_condition_check(struct

Quoted 14 lines
drivers/net/fm10k/fm10k_ethdev.c +1 -0
 uint16_t queue_id,
 	q->port_id = dev->data->port_id;
 	q->queue_id = queue_id;
 	q->txq_flags = conf->txq_flags;
+	q->offloads = conf->offloads;
 	q->ops = &def_txq_ops;
 	q->tail_ptr = (volatile uint32_t *)
drivers/net/fm10k/fm10k_ethdev.c +0 -0
 		&((uint32_t *)hw->hw_addr)[FM10K_TDT(queue_id)];
drivers/net/fm10k/fm10k_rxtx_vec.c +0 -0
index 498a178..e6dba04 100644
@@ -210,7 +210,7 @@ fm10k_rx_vec_condition_check(struct

rte_eth_dev

drivers/net/fm10k/fm10k_rxtx_vec.c fm10k_rx_vec_condition_check(struct

Quoted 10 lines
drivers/net/fm10k/fm10k_rxtx_vec.c +1 -1
 *dev)
 
 #ifndef RTE_FM10K_RX_OLFLAGS_ENABLE
 	/* whithout rx ol_flags, no VP flag report */
-	if (rxmode->hw_vlan_extend != 0)
+	if (rxmode->offloads & DEV_RX_OFFLOAD_VLAN_EXTEND)
 		return -1;
 #endif
@@ -219,7 +219,7 @@ fm10k_rx_vec_condition_check(struct

rte_eth_dev

Quoted 8 lines

drivers/net/fm10k/fm10k_rxtx_vec.c fm10k_rx_vec_condition_check(struct rte_eth_dev *dev) · line 222

Quoted 6 lines
drivers/net/fm10k/fm10k_rxtx_vec.c +1 -1
 *dev)
 		return -1;
 
 	/* no header split support */
-	if (rxmode->header_split == 1)
+	if (rxmode->offloads & DEV_RX_OFFLOAD_HEADER_SPLIT)

DEV_RX_OFFLOAD_HEADER_SPLIT also missed in fm10k_dev_infos_get?

Yes, will add this offloading in my next version of patch.

Quoted 14 lines

drivers/net/fm10k/fm10k_rxtx_vec.c int __attribute__((cold)) · line 699

Quoted 10 lines
drivers/net/fm10k/fm10k_rxtx_vec.c +0 -0
 		return -1;
 
drivers/net/fm10k/fm10k_rxtx_vec.c +1 -1
 	return 0;
@@ -695,7 +695,7 @@ int __attribute__((cold))
 fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)  {
 	/* Vector TX can't offload any features yet */
-	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) !=
 FM10K_SIMPLE_TX_FLAG)
+	if (txq->offloads & FM10K_SIMPLE_TX_OFFLOADS)
 		return -1;

Is this correct? an offload not include in FM10K_SIMPLE_TX_OFFLOADS will also fail this branch and pass check, right?
The logic can be implemented like below:

Quoted 7 lines

#define FM10K_VEC_TX_OFFLOAD_SUPPORT xxx | xxx ...

If (txq->offloads & FM10K_VEC_TX_OFFLOAD_SUPPORT != txq->offload)
return -1

Regards
Qi

As there is a comment above show " Vector TX can't offload any features yet" I'd like to use if (txq->offloads != 0) in my next version of patch.

Quoted 4 lines
Quoted 4 lines
drivers/net/fm10k/fm10k_rxtx_vec.c +0 -1
 	if (txq->tx_ftag_en)
--

2.9.4

author
#3 lore raw

v2 cover net/fm10k: convert to new Rx/Tx offloads API

In reply to Wei Dai

This patch set support new offloads API in fm10k PF and VF.

---
v2:
Add Header_Split in per port Rx capability.
Add Rx/Tx offloading checking

Wei Dai (2):
net/fm10k: convert to new Rx offloads API
net/fm10k: convert to new Tx offloads API

 drivers/net/fm10k/fm10k.h          |   2 +
 drivers/net/fm10k/fm10k_ethdev.c   | 156 +++++++++++++++++++++++++++++++++----
 drivers/net/fm10k/fm10k_rxtx_vec.c |   6 +-
 3 files changed, 145 insertions(+), 19 deletions(-)
Signature · 1 line
2.9.5
author
#4 lore raw

PATCH v2 1/2 net/fm10k: convert to new Rx offloads API

Ethdev Rx offloads API has changed since:
commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") This commit support the new Rx offloads API.

---
 drivers/net/fm10k/fm10k.h          |  1 +
 drivers/net/fm10k/fm10k_ethdev.c   | 88 +++++++++++++++++++++++++++++++++-----
 drivers/net/fm10k/fm10k_rxtx_vec.c |  4 +-
 3 files changed, 81 insertions(+), 12 deletions(-)
drivers/net/fm10k/fm10k.h +1 -0
index 30dad3e..d3c80c2 100644
@@ -180,6 +180,7 @@ struct fm10k_rx_queue {
 	uint8_t drop_en;
 	uint8_t rx_deferred_start; /* don't start this queue in dev start. */
 	uint16_t rx_ftag_en; /* indicates FTAG RX supported */
+	uint64_t offloads; /* offloads of DEV_RX_OFFLOAD_* */
 };
 
 /*
drivers/net/fm10k/fm10k_ethdev.c +78 -10

162 lines not on this page · raw message

drivers/net/fm10k/fm10k_rxtx_vec.c +2 -2
index 498a178..b6967c0 100644
@@ -210,7 +210,7 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
 
 #ifndef RTE_FM10K_RX_OLFLAGS_ENABLE
 	/* whithout rx ol_flags, no VP flag report */
-	if (rxmode->hw_vlan_extend != 0)
+	if (rxmode->offloads & DEV_RX_OFFLOAD_VLAN_EXTEND)
 		return -1;
 #endif
 
@@ -219,7 +219,7 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
 		return -1;
 
 	/* no header split support */
-	if (rxmode->header_split == 1)
+	if (rxmode->offloads & DEV_RX_OFFLOAD_HEADER_SPLIT)
 		return -1;
 
 	return 0;
Signature · 1 line
2.9.5
#5 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Daiwei:

drivers/net/fm10k/fm10k_ethdev.c mempool_element_size_valid(struct rte_mempool *mp) · line 1807

Quoted 6 lines
drivers/net/fm10k/fm10k_ethdev.c +6 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Regards
Qi

#6 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 11 lines

-----Original Message-----
From: Zhang, Qi Z
Sent: Wednesday, March 28, 2018 6:08 PM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Daiwei:

Quoted 11 lines

drivers/net/fm10k/fm10k_ethdev.c mempool_element_size_valid(struct rte_mempool *mp) · line 1807

Quoted 6 lines
drivers/net/fm10k/fm10k_ethdev.c +6 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue offload.

Quoted 3 lines

Regards
Qi

#7 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 32 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Zhang, Qi Z
Sent: Thursday, March 29, 2018 7:09 AM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 9 lines

-----Original Message-----
From: Zhang, Qi Z
Sent: Wednesday, March 28, 2018 6:08 PM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Daiwei:

Quoted 11 lines

drivers/net/fm10k/fm10k_ethdev.c mempool_element_size_valid(struct rte_mempool *mp) · line 1807

Quoted 6 lines
drivers/net/fm10k/fm10k_ethdev.c +6 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Quoted 2 lines

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue offload.

Ok, but these days we have one RX function per device.
Looking at fm10k - it clearly has different RX function for scattered and non-scattered case. Yes, HW does support scatter/non-scatter selection per queue, but our SW - doesn't (same for ixgbe and i40e)
So how it could be per queue offload?
Konstantin

Quoted 3 lines
Quoted 3 lines

Regards
Qi

#8 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Konstantin:

Quoted 45 lines

-----Original Message-----
From: Ananyev, Konstantin
Sent: Thursday, March 29, 2018 5:29 PM
To: Zhang, Qi Z <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 34 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Zhang, Qi Z
Sent: Thursday, March 29, 2018 7:09 AM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 23 lines

-----Original Message-----
From: Zhang, Qi Z
Sent: Wednesday, March 28, 2018 6:08 PM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Daiwei:

drivers/net/fm10k/fm10k_ethdev.c mempool_element_size_valid(struct rte_mempool *mp) · line 1807

Quoted 7 lines
drivers/net/fm10k/fm10k_ethdev.c +7 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct
+rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Quoted 8 lines
Quoted 2 lines

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue offload.

Ok, but these days we have one RX function per device.
Looking at fm10k - it clearly has different RX function for scattered and non-scattered case.
Yes, HW does support scatter/non-scatter selection per queue, but our SW - doesn't (same for ixgbe and i40e) So how it could be per queue offload?

We saw the implementation of fm10k is a little bit different with i40e.
It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to turn on multi-seg feature when offload is required.

That means two queues can have different behavior when process a packet that exceed the buffer size base on the register setting, though we use the same rx scattered function, so we think this is per queue feature, is that make sense?

Regards
Qi

Quoted 7 lines

Konstantin

Quoted 3 lines
Quoted 3 lines

Regards
Qi

#9 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Qi,

Quoted 63 lines

-----Original Message-----
From: Zhang, Qi Z
Sent: Thursday, March 29, 2018 10:51 AM
To: Ananyev, Konstantin <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Konstantin:

Quoted 45 lines

-----Original Message-----
From: Ananyev, Konstantin
Sent: Thursday, March 29, 2018 5:29 PM
To: Zhang, Qi Z <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 34 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Zhang, Qi Z
Sent: Thursday, March 29, 2018 7:09 AM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 23 lines

-----Original Message-----
From: Zhang, Qi Z
Sent: Wednesday, March 28, 2018 6:08 PM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Daiwei:

drivers/net/fm10k/fm10k_ethdev.c mempool_element_size_valid(struct rte_mempool *mp) · line 1807

Quoted 7 lines
drivers/net/fm10k/fm10k_ethdev.c +7 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct
+rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Quoted 8 lines
Quoted 2 lines

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue offload.

Ok, but these days we have one RX function per device.
Looking at fm10k - it clearly has different RX function for scattered and non-scattered case.
Yes, HW does support scatter/non-scatter selection per queue, but our SW - doesn't (same for ixgbe and i40e) So how it could be per queue offload?

Quoted 5 lines

We saw the implementation of fm10k is a little bit different with i40e.
It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to turn on multi-seg feature when offload is required.

That means two queues can have different behavior when process a packet that exceed the buffer size base on the register setting, though we use the same rx scattered function, so we think this is per queue feature, is that make sense?

Ok, suppose we have 2 functions configured.
One with DEV_RX_OFFLOAD_SCATTER is on, second with DEV_RX_OFFLOAD_SCATTER is off. So scatter RX function will be selected, but for second queue HW support will not be enabled, so packets bigger then RX buffer will be silently dropped by HW, right? Konstantin

Quoted 12 lines

Regards
Qi

Quoted 7 lines

Konstantin

Quoted 3 lines
Quoted 3 lines

Regards
Qi

#10 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 89 lines

-----Original Message-----
From: Ananyev, Konstantin
Sent: Thursday, March 29, 2018 6:21 PM
To: Zhang, Qi Z <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Qi,

Quoted 9 lines

-----Original Message-----
From: Zhang, Qi Z
Sent: Thursday, March 29, 2018 10:51 AM
To: Ananyev, Konstantin <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 56 lines

Hi Konstantin:

Quoted 54 lines

-----Original Message-----
From: Ananyev, Konstantin
Sent: Thursday, March 29, 2018 5:29 PM
To: Zhang, Qi Z <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 35 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Zhang, Qi Z
Sent: Thursday, March 29, 2018 7:09 AM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 11 lines

-----Original Message-----
From: Zhang, Qi Z
Sent: Wednesday, March 28, 2018 6:08 PM
To: Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Daiwei:

Quoted 12 lines

drivers/net/fm10k/fm10k_ethdev.c mempool_element_size_valid(struct rte_mempool *mp) · line 1807

Quoted 7 lines
drivers/net/fm10k/fm10k_ethdev.c +7 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct
+rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Quoted 2 lines

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue offload.

Ok, but these days we have one RX function per device. Looking at fm10k - it clearly has different RX function for scattered and non-scattered case.
Yes, HW does support scatter/non-scatter selection per queue, but our SW - doesn't (same for ixgbe and i40e) So how it could be per queue

offload?

Quoted 3 lines

We saw the implementation of fm10k is a little bit different with i40e. It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to turn

on multi-seg feature when offload is required.

Quoted 3 lines

That means two queues can have different behavior when process a packet that exceed the buffer size base on the register setting, though we

use the same rx scattered function, so we think this is per queue feature, is that make sense?

Quoted 6 lines

Ok, suppose we have 2 functions configured.
One with DEV_RX_OFFLOAD_SCATTER is on, second with DEV_RX_OFFLOAD_SCATTER is off.
So scatter RX function will be selected, but for second queue HW support will not be enabled, so packets bigger then RX buffer will be silently dropped by HW, right?

Yes according to datasheet

Bit FM10K_SRRCTL_BUFFER_CHAINING_EN:

0b = Any packet longer than the data buffer size is terminated with a TOO_BIG error status in Rx descriptor write-back. The remainder of the frame is not posted to host, it is silently dropped.
1b = A packet can be spread over more than one single receive data buffer

Quoted 14 lines

Konstantin

Quoted 12 lines

Regards
Qi

Quoted 7 lines

Konstantin

Quoted 3 lines
Quoted 3 lines

Regards
Qi

#11 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Qi,

Quoted 42 lines
Quoted 35 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines

Hi Daiwei:

Review

Quoted 7 lines
(quoted diff) +7 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct
+rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Quoted 8 lines
Quoted 8 lines
Quoted 2 lines

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue offload.

Ok, but these days we have one RX function per device. Looking at fm10k - it clearly has different RX function for scattered and non-scattered case.
Yes, HW does support scatter/non-scatter selection per queue, but our SW - doesn't (same for ixgbe and i40e) So how it could be per queue

offload?

Quoted 3 lines

We saw the implementation of fm10k is a little bit different with i40e. It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to turn

on multi-seg feature when offload is required.

Quoted 3 lines

That means two queues can have different behavior when process a packet that exceed the buffer size base on the register setting, though we

use the same rx scattered function, so we think this is per queue feature, is that make sense?

Quoted 6 lines

Ok, suppose we have 2 functions configured.
One with DEV_RX_OFFLOAD_SCATTER is on, second with DEV_RX_OFFLOAD_SCATTER is off.
So scatter RX function will be selected, but for second queue HW support will not be enabled, so packets bigger then RX buffer will be silently dropped by HW, right?

Quoted 9 lines

Yes according to datasheet

Bit FM10K_SRRCTL_BUFFER_CHAINING_EN:

0b = Any packet longer than the data buffer size is terminated with a TOO_BIG error status in Rx descriptor write-back. The remainder of the frame is not posted to host, it is silently dropped.
1b = A packet can be spread over more than one single receive data buffer

Ok, that's a bit unusual approach but understandable. Thanks
Konstantin

author
#12 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Thanks, Konstantin and Zhang Qi for your feedback and support.
I have talked with Qi and know following:
To avoid packet dropping when FM10K_SRRCTL_BUFFER_CHAINING_EN is not set, the queue can work with a different mempool which has larger mem buffer size. For example, SCATTER is enabled on queue 0 with a small mem buffer size of mempool 0, And SCATTER is disabled on queue 1 with a large mem buffer size of mempool 1, Both queues can avoid packet dropping.
Indeed, current fm10k PMD also automatically set FM10K_SRRCTL_BUFFER_CHAINING_EN If max_rx_pkt_len + 2 * VLAN_TAG_SIZE > mem_buf_size no matter whether SCATTER is enabled on queue configuration or not.

Quoted 71 lines

-----Original Message-----
From: Ananyev, Konstantin
Sent: Sunday, April 1, 2018 8:09 PM
To: Zhang, Qi Z <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Qi,

Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines

Hi Daiwei:

Review

Quoted 7 lines
(quoted diff) +7 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct
+rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue

offload.

Quoted 29 lines
Quoted 20 lines
Quoted 7 lines
Quoted 7 lines

Ok, but these days we have one RX function per device. Looking at fm10k - it clearly has different RX function for scattered and non-scattered case.
Yes, HW does support scatter/non-scatter selection per queue, but our SW - doesn't (same for ixgbe and i40e) So how it could be per queue

offload?

Quoted 4 lines

We saw the implementation of fm10k is a little bit different with i40e. It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to turn

on multi-seg feature when offload is required.

Quoted 4 lines

That means two queues can have different behavior when process a packet that exceed the buffer size base on the register setting, though we

use the same rx scattered function, so we think this is per queue feature, is that make sense?

Quoted 6 lines

Ok, suppose we have 2 functions configured.
One with DEV_RX_OFFLOAD_SCATTER is on, second with DEV_RX_OFFLOAD_SCATTER is off.
So scatter RX function will be selected, but for second queue HW support will not be enabled, so packets bigger then RX buffer will be silently dropped by HW, right?

Yes according to datasheet

Quoted 8 lines

Bit FM10K_SRRCTL_BUFFER_CHAINING_EN:

0b = Any packet longer than the data buffer size is terminated with a TOO_BIG error status in Rx descriptor write-back. The remainder of the frame is not posted to host, it is silently dropped.
1b = A packet can be spread over more than one single receive data buffer

Ok, that's a bit unusual approach but understandable. Thanks
Konstantin

#13 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 9 lines

-----Original Message-----
From: Dai, Wei
Sent: Tuesday, April 3, 2018 8:11 AM
To: Ananyev, Konstantin <[email protected]>; Zhang, Qi Z <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 10 lines

Thanks, Konstantin and Zhang Qi for your feedback and support.
I have talked with Qi and know following:
To avoid packet dropping when FM10K_SRRCTL_BUFFER_CHAINING_EN is not set, the queue can work with a different mempool which has larger mem buffer size. For example, SCATTER is enabled on queue 0 with a small mem buffer size of mempool 0, And SCATTER is disabled on queue 1 with a large mem buffer size of mempool 1, Both queues can avoid packet dropping.
Indeed, current fm10k PMD also automatically set FM10K_SRRCTL_BUFFER_CHAINING_EN If max_rx_pkt_len + 2 * VLAN_TAG_SIZE > mem_buf_size no matter whether SCATTER is enabled on queue configuration or not.

You can make it just MULTISEG a port offload (not queue) and in that case none of the queues will drop the packets. But again - up to you guys, both approaches are possible, I think. Konstantin

Quoted 73 lines
Quoted 73 lines

-----Original Message-----
From: Ananyev, Konstantin
Sent: Sunday, April 1, 2018 8:09 PM
To: Zhang, Qi Z <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Qi,

Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines

Hi Daiwei:

Review

Quoted 7 lines
(quoted diff) +7 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct
+rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue

offload.

Quoted 29 lines
Quoted 20 lines
Quoted 7 lines
Quoted 7 lines

Ok, but these days we have one RX function per device. Looking at fm10k - it clearly has different RX function for scattered and non-scattered case.
Yes, HW does support scatter/non-scatter selection per queue, but our SW - doesn't (same for ixgbe and i40e) So how it could be per queue

offload?

Quoted 4 lines

We saw the implementation of fm10k is a little bit different with i40e. It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to turn

on multi-seg feature when offload is required.

Quoted 4 lines

That means two queues can have different behavior when process a packet that exceed the buffer size base on the register setting, though we

use the same rx scattered function, so we think this is per queue feature, is that make sense?

Quoted 6 lines

Ok, suppose we have 2 functions configured.
One with DEV_RX_OFFLOAD_SCATTER is on, second with DEV_RX_OFFLOAD_SCATTER is off.
So scatter RX function will be selected, but for second queue HW support will not be enabled, so packets bigger then RX buffer will be silently dropped by HW, right?

Yes according to datasheet

Quoted 8 lines

Bit FM10K_SRRCTL_BUFFER_CHAINING_EN:

0b = Any packet longer than the data buffer size is terminated with a TOO_BIG error status in Rx descriptor write-back. The remainder of the frame is not posted to host, it is silently dropped.
1b = A packet can be spread over more than one single receive data buffer

Ok, that's a bit unusual approach but understandable. Thanks
Konstantin

#14 lore raw

Re: [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 20 lines · Konstantin
Quoted 9 lines

-----Original Message-----
From: Dai, Wei
Sent: Tuesday, April 3, 2018 8:11 AM
To: Ananyev, Konstantin <[email protected]>; Zhang, Qi Z <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Quoted 10 lines

Thanks, Konstantin and Zhang Qi for your feedback and support.
I have talked with Qi and know following:
To avoid packet dropping when FM10K_SRRCTL_BUFFER_CHAINING_EN is not set, the queue can work with a different mempool which has larger mem buffer size. For example, SCATTER is enabled on queue 0 with a small mem buffer size of mempool 0, And SCATTER is disabled on queue 1 with a large mem buffer size of mempool 1, Both queues can avoid packet dropping.
Indeed, current fm10k PMD also automatically set FM10K_SRRCTL_BUFFER_CHAINING_EN If max_rx_pkt_len + 2 * VLAN_TAG_SIZE > mem_buf_size no matter whether SCATTER is enabled on queue configuration or not.

Quoted 2 lines

You can make it just MULTISEG a port offload (not queue) and in that case none of the queues will drop the packets.

I share the concern, having single Rx function for all queues but able to configure each queue separately for scattered rx seems confusing.

Also it seems PMD is already giving this decision independent from scatter offload flag.

I am ok to get patch as it is but I believe it worth thinking to change scatter offload to port level.

Quoted 76 lines

But again - up to you guys, both approaches are possible, I think. Konstantin

Quoted 73 lines
Quoted 73 lines

-----Original Message-----
From: Ananyev, Konstantin
Sent: Sunday, April 1, 2018 8:09 PM
To: Zhang, Qi Z <[email protected]>; Dai, Wei <[email protected]>; Wang, Xiao W <[email protected]>
Cc: '[email protected]' <[email protected]>
Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API

Hi Qi,

Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines

Hi Daiwei:

Review

Quoted 7 lines
(quoted diff) +7 -0
+static uint64_t fm10k_get_rx_queue_offloads_capa(struct
+rte_eth_dev
+*dev) {
+	RTE_SET_USED(dev);
+
+	return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
+}

why per queue rx scattered feature here?
My understanding is either we use scattered rx function that enable this feature for all queues or we use non-scattered rx function that disable this feature for all queues, right?

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Checked with Dai Wei offline, fm10k have per queue register that can be configured to support rx scattered, So it is per queue

offload.

Quoted 29 lines
Quoted 20 lines
Quoted 7 lines
Quoted 7 lines

Ok, but these days we have one RX function per device. Looking at fm10k - it clearly has different RX function for scattered and non-scattered case.
Yes, HW does support scatter/non-scatter selection per queue, but our SW - doesn't (same for ixgbe and i40e) So how it could be per queue

offload?

Quoted 4 lines

We saw the implementation of fm10k is a little bit different with i40e. It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to turn

on multi-seg feature when offload is required.

Quoted 4 lines

That means two queues can have different behavior when process a packet that exceed the buffer size base on the register setting, though we

use the same rx scattered function, so we think this is per queue feature, is that make sense?

Quoted 6 lines

Ok, suppose we have 2 functions configured.
One with DEV_RX_OFFLOAD_SCATTER is on, second with DEV_RX_OFFLOAD_SCATTER is off.
So scatter RX function will be selected, but for second queue HW support will not be enabled, so packets bigger then RX buffer will be silently dropped by HW, right?

Yes according to datasheet

Quoted 8 lines

Bit FM10K_SRRCTL_BUFFER_CHAINING_EN:

0b = Any packet longer than the data buffer size is terminated with a TOO_BIG error status in Rx descriptor write-back. The remainder of the frame is not posted to host, it is silently dropped.
1b = A packet can be spread over more than one single receive data buffer

Ok, that's a bit unusual approach but understandable. Thanks
Konstantin

author
#15 lore raw

PATCH v2 2/2 net/fm10k: convert to new Tx offloads API

In reply to Wei Dai

Ethdev Tx offloads API has changed since:
commit cba7f53b717d ("ethdev: introduce Tx queue offloads API") This commit support the new Rx and Tx offloads API.

---
 drivers/net/fm10k/fm10k.h          |  1 +
 drivers/net/fm10k/fm10k_ethdev.c   | 68 ++++++++++++++++++++++++++++++++++----
 drivers/net/fm10k/fm10k_rxtx_vec.c |  2 +-
 3 files changed, 64 insertions(+), 7 deletions(-)
drivers/net/fm10k/fm10k.h +1 -0
index d3c80c2..ce0f2c8 100644
@@ -213,6 +213,7 @@ struct fm10k_tx_queue {
 	uint16_t next_dd; /* Next pos to check DD flag */
 	volatile uint32_t *tail_ptr;
 	uint32_t txq_flags; /* Holds flags for this TXq */
+	uint64_t offloads; /* Offloads of DEV_TX_OFFLOAD_* */
 	uint16_t nb_desc;
 	uint16_t port_id;
 	uint8_t tx_deferred_start; /** don't start this queue in dev start. */
drivers/net/fm10k/fm10k_ethdev.c +62 -6

116 lines not on this page · raw message

drivers/net/fm10k/fm10k_rxtx_vec.c +1 -1
index b6967c0..005fda6 100644
@@ -695,7 +695,7 @@ int __attribute__((cold))
 fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
 {
 	/* Vector TX can't offload any features yet */
-	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
+	if (txq->offloads != 0)
 		return -1;
 
 	if (txq->tx_ftag_en)
Signature · 1 line
2.9.5
Acked-by on the v2 series
#16 lore raw
In reply to Wei Dai
Quoted 12 lines

-----Original Message-----
From: Dai, Wei
Sent: Wednesday, March 28, 2018 4:01 PM
To: Zhang, Qi Z <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]; Dai, Wei <[email protected]>
Subject: [PATCH v2 0/2] net/fm10k: convert to new Rx/Tx offloads API

This patch set support new offloads API in fm10k PF and VF.

Quoted 8 lines

---
v2:
Add Header_Split in per port Rx capability.
Add Rx/Tx offloading checking

Wei Dai (2):
net/fm10k: convert to new Rx offloads API
net/fm10k: convert to new Tx offloads API

Quoted 9 lines
 drivers/net/fm10k/fm10k.h          |   2 +
 drivers/net/fm10k/fm10k_ethdev.c   | 156
+++++++++++++++++++++++++++++++++----
 drivers/net/fm10k/fm10k_rxtx_vec.c |   6 +-
 3 files changed, 145 insertions(+), 19 deletions(-)

--
2.9.5

Applied
#17 lore raw
Quoted 25 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Zhang, Qi Z
Sent: Thursday, March 29, 2018 2:23 PM
To: Dai, Wei; Wang, Xiao W
Cc: [email protected]
Subject: Re: [dpdk-dev] [PATCH v2 0/2] net/fm10k: convert to new Rx/Tx offloads API

Quoted 15 lines

-----Original Message-----
From: Dai, Wei
Sent: Wednesday, March 28, 2018 4:01 PM
To: Zhang, Qi Z <[email protected]>; Wang, Xiao W <[email protected]>
Cc: [email protected]; Dai, Wei <[email protected]>
Subject: [PATCH v2 0/2] net/fm10k: convert to new Rx/Tx offloads API

This patch set support new offloads API in fm10k PF and VF.

---
v2:
Add Header_Split in per port Rx capability.
Add Rx/Tx offloading checking

Quoted 5 lines
Quoted 3 lines

Wei Dai (2):
net/fm10k: convert to new Rx offloads API
net/fm10k: convert to new Tx offloads API

Applied the series to dpdk-next-net-intel, thanks!

/Helin