net/fm10k: convert to new Rx/Tx offloads API
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
@@ -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
@@ -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 Ð_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 Ð_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 Ð_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
@@ -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
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 APIEthdev Rx offloads API has changed since:
commitce17eddefc20("ethdev: introduce Rx queue offloads API") Ethdev Tx offloads API has changed since:
commitcba7f53b717d("ethdev: introduce Tx queue offloads API") This commit support the new Rx and Tx offloads API.Signed-off-by Wei Dai <[email protected]>--- 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
-030dad3e..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
-1uint16_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 100644drivers/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
-6ret =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
-1if (mask Ð_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 Ð_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
-1PMD_INIT_LOG (ERR ,"VLAN QinQ is not " "supported in fm10k" ); }if (mask Ð_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@@ -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
-0return -1 ;drivers/net/fm10k/fm10k_rxtx_vec.c +1
-1return 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
-1if (txq->tx_ftag_en) --2.9.4
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 APIHi 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 APIEthdev Rx offloads API has changed since:
commitce17eddefc20("ethdev: introduce Rx queue offloads API") Ethdev Tx offloads API has changed since:
commitcba7f53b717d("ethdev: introduce Tx queue offloads API") This commit support the new Rx and Tx offloads API.Signed-off-by Wei Dai <[email protected]>--- 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
-0index
30dad3e..57bd533 100644drivers/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
-0uint16_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.cb/drivers/net/fm10k/fm10k_ethdev.c
index 9423761..5105874 100644drivers/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
-6ret =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
-1if (mask Ð_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
-1if (mask Ð_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_EXTENDis missed infm10k_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
-1PMD_INIT_LOG (ERR ,"VLAN QinQ is not " "supported in fm10k" ); }if (mask Ð_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
-0uint16_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
-0uint16_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@@ -210,7 +210,7 @@ fm10k_rx_vec_condition_check(struct
rte_eth_devdrivers/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_SPLITalso missed infm10k_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
-0return -1 ;drivers/net/fm10k/fm10k_rxtx_vec.c +1
-1return 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_OFFLOADSwill also fail this branch and pass check, right?
The logic can be implemented like below:
Quoted 7 lines
#define
FM10K_VEC_TX_OFFLOAD_SUPPORTxxx | xxx ...If (
txq->offloads&FM10K_VEC_TX_OFFLOAD_SUPPORT!=txq->offload)
return -1Regards
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
-1if (txq->tx_ftag_en) --2.9.4
v2 cover net/fm10k: convert to new Rx/Tx offloads API
In reply to Wei DaiThis 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
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
@@ -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
@@ -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
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
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 APIHi 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
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 APIQuoted 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 APIHi 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
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 APIQuoted 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 APIQuoted 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 APIHi 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
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 APIHi 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 APIQuoted 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 APIQuoted 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 APIHi 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
QiQuoted 7 lines
Konstantin
Quoted 3 lines
Quoted 3 lines
Regards
Qi
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 APIHi 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 APIQuoted 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 APIQuoted 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 APIQuoted 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 APIHi 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 queueoffload?
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 turnon 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 withDEV_RX_OFFLOAD_SCATTERis on, second withDEV_RX_OFFLOAD_SCATTERis 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
QiQuoted 7 lines
Konstantin
Quoted 3 lines
Quoted 3 lines
Regards
Qi
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 queueoffload?
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 turnon 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 withDEV_RX_OFFLOAD_SCATTERis on, second withDEV_RX_OFFLOAD_SCATTERis 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_BIGerror 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
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 APIHi 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 queueoffload?
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 turnon 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 withDEV_RX_OFFLOAD_SCATTERis on, second withDEV_RX_OFFLOAD_SCATTERis 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_BIGerror 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 bufferOk, that's a bit unusual approach but understandable. Thanks
Konstantin
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 whenFM10K_SRRCTL_BUFFER_CHAINING_ENis 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 setFM10K_SRRCTL_BUFFER_CHAINING_ENIfmax_rx_pkt_len+ 2 *VLAN_TAG_SIZE>mem_buf_sizeno 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 APIHi 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 queueoffload?
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 turnon 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 withDEV_RX_OFFLOAD_SCATTERis on, second withDEV_RX_OFFLOAD_SCATTERis 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_BIGerror 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 bufferOk, that's a bit unusual approach but understandable. Thanks
Konstantin
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 APIQuoted 10 lines
Thanks, Konstantin and Zhang Qi for your feedback and support.
I have talked with Qi and know following:
To avoid packet dropping whenFM10K_SRRCTL_BUFFER_CHAINING_ENis 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 setFM10K_SRRCTL_BUFFER_CHAINING_ENIfmax_rx_pkt_len+ 2 *VLAN_TAG_SIZE>mem_buf_sizeno 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 APIHi 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 queueoffload?
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 turnon 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 withDEV_RX_OFFLOAD_SCATTERis on, second withDEV_RX_OFFLOAD_SCATTERis 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_BIGerror 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 bufferOk, that's a bit unusual approach but understandable. Thanks
Konstantin
PATCH v2 2/2 net/fm10k: convert to new Tx offloads API
In reply to Wei DaiEthdev 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
@@ -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
@@ -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
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 APIThis patch set support new offloads API in fm10k PF and VF.
Quoted 8 lines
---
v2:
AddHeader_Splitin per port Rx capability.
Add Rx/Tx offloading checkingWei 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
Zhang, Helin
AppliedQuoted 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 APIQuoted 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 APIThis patch set support new offloads API in fm10k PF and VF.
---
v2:
AddHeader_Splitin 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 APIAcked-by Qi Zhang <[email protected]>
Applied the series to dpdk-next-net-intel, thanks!
/Helin