support API to set max LRO packet size
Subsystems (2)
cover support API to set max LRO packet size
This series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 5 ++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 ++++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 + drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 22 files changed, 170 insertions(+), 6 deletions(-)
Signature · 1 line
1.8.3.1
PATCH 1/3 ethdev: support API to set max LRO packet size
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
--- doc/guides/nics/features.rst | 2 ++ doc/guides/rel_notes/deprecation.rst | 4 --- doc/guides/rel_notes/release_19_11.rst | 8 ++++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++ drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 +++ 15 files changed, 70 insertions(+), 5 deletions(-)
doc/guides/nics/features.rst +2 -0
@@ -193,10 +193,12 @@ LRO Supports Large Receive Offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``. + ``dev_conf.rxmode.max_lro_pkt_size``. * **[implements] datapath**: ``LRO functionality``. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``. .. _nic_features_tso:
doc/guides/rel_notes/deprecation.rst +0 -4
@@ -87,10 +87,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
doc/guides/rel_notes/release_19_11.rst +8 -0
@@ -380,6 +380,14 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header. +* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in + struct ``rte_eth_dev_info`` for the port capability and in struct + ``rte_eth_rxmode`` for the port configuration. + Application should use the new field in struct ``rte_eth_rxmode`` to configure + the requested size. + PMD should use the new field in struct ``rte_eth_dev_info`` to report the + supported port capability. + Shared Library Versions -----------------------
drivers/net/bnxt/bnxt_ethdev.c +1 -0
@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pkt_size =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ;if (bp->flags &BNXT_FLAG_PTP_SUPPORTED )
drivers/net/hinic/hinic_pmd_ethdev.c +1 -0
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa) info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pkt_size =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;
drivers/net/ixgbe/ixgbe_ethdev.c +2 -0
@@ -3804,6 +3804,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, } dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */ dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =15872 ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ; dev_info->max_vfs = pci_dev->max_vfs;
@@ -3927,6 +3928,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, dev_info->max_tx_queues = (uint16_t )hw->mac.max_tx_queues; dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL reg */ dev_info->max_rx_pktlen =9728 ;/* includes CRC, cf MAXFRS reg */ + dev_info->max_lro_pkt_size =9728 ; dev_info->max_mtu = dev_info->max_rx_pktlen -IXGBE_ETH_OVERHEAD ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ;
drivers/net/ixgbe/ixgbe_vf_representor.c +1 -0
@@ -48,6 +48,7 @@ dev_info->min_rx_bufsize =1024 ;/**< Minimum size of RX buffer. */ dev_info->max_rx_pktlen =9728 ; + dev_info->max_lro_pkt_size =9728 ;/**< Maximum configurable length of RX pkt. */ dev_info->max_rx_queues =IXGBE_VF_MAX_RX_QUEUES ;/**< Maximum number of RX queues. */
drivers/net/mlx5/mlx5.h +3 -0
@@ -203,6 +203,9 @@ struct mlx5_hca_attr {#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */
drivers/net/mlx5/mlx5_ethdev.c +1 -0
@@ -606,6 +606,7 @@ struct ethtool_link_settings {/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pkt_size =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values.
drivers/net/mlx5/mlx5_rxq.c +0 -1
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))
drivers/net/qede/qede_ethdev.c +1 -0
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; + dev_info->max_lro_pkt_size = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;
drivers/net/virtio/virtio_ethdev.c +1 -0
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)RTE_MIN (hw->max_queue_pairs,VIRTIO_MAX_TX_QUEUES ); dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pkt_size =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features =VTPCI_OPS (hw)->get_features (hw);
drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -0
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev) dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;
lib/librte_ethdev/rte_ethdev.c +44 -0
62 lines not on this page · raw message
lib/librte_ethdev/rte_ethdev.h +4 -0
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {/** The multi-queue packet distribution mode to be used, e.g. RSS. */ enum rte_eth_rx_mq_mode mq_mode;uint32_t max_rx_pkt_len;/**< Only used if JUMBO_FRAME enabled. */ +/** Maximal allowed size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t split_hdr_size;/**< hdr buf size (header_split enabled).*/ /** * Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1223,6 +1225,8 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH 1/3] ethdev: support API to set max LRO packet size
Quoted 5 lines · Dekel Peled
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
Quoted 7 lines
Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/Signed-off-by Dekel Peled <[email protected]>
Few comments below, otherwise
[snip]
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1161
Quoted 11 lines
lib/librte_ethdev/rte_ethdev.c +3
-0@@ -1156,6 +1156,26 @@ struct rte_eth_dev *return name; } +static inline int +rte_eth_check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size)
As I understand Thomas prefers static functions without rte_eth_ prefix. I think it is reasonable.
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1170
Quoted 9 lines
lib/librte_ethdev/rte_ethdev.c +9
-0+{ +int ret =0 ; + +if (config_size > dev_info_size) { +RTE_ETHDEV_LOG (ERR ,"Ethdev port_id=%d max_lro_pkt_size %u > " +"max allowed value %u\n" , + port_id, config_size, dev_info_size); + ret = -EINVAL ; + }else if (config_size <RTE_ETHER_MIN_LEN ) {
Shouldn't config_size == 0 fallback to maximum?
(I don't know and I simply would like to get comments on it)
Quoted 14 lines
lib/librte_ethdev/rte_ethdev.c +8
-0+RTE_ETHDEV_LOG (ERR ,"Ethdev port_id=%d max_lro_pkt_size %u < " +"min allowed value %u\n" , port_id, config_size, + (unsigned int )RTE_ETHER_MIN_LEN ); + ret = -EINVAL ; + } +return ret; +} +int rte_eth_dev_configure (uint16_t port_id,uint16_t nb_rx_q,uint16_t nb_tx_q,const struct rte_eth_conf *dev_conf)@@ -1286,6 +1306,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN ; }
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1317
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +9
-0+/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret =rte_eth_check_lro_pkt_size ( + port_id, dev_conf->rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret)
if (ret != 0)
https://doc.dpdk.org/guides/contributing/coding_style.html#function-calls
and the style dominates in rte_ethdev.c
Quoted 9 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+ goto rollback; + } +/* Any requested offloading must be within its device capabilities */ if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) != dev_conf->rxmode.offloads) {@@ -1790,6 +1822,18 @@ struct rte_eth_dev *return -EINVAL ; }
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1833
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +9
-0+/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (local_conf.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { +int ret =rte_eth_check_lro_pkt_size (port_id, + dev->data->dev_conf.rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret)
if (ret != 0)
https://doc.dpdk.org/guides/contributing/coding_style.html#function-calls
and the style dominates in rte_ethdev.c
Quoted 7 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+return ret; + } + ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id, nb_rx_desc, socket_id, &local_conf, mp);if (!ret) {
[snip]
Re: [dpdk-dev] [PATCH 1/3] ethdev: support API to set max LRO packet size
05/11/2019 13:39, Andrew Rybchenko:
Quoted 9 lines · Dekel Peled
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1161
Quoted 5 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+static inline int +rte_eth_check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size)As I understand Thomas prefers static functions without
rte_eth_prefix. I think it is reasonable.
Indeed, rte_ prefix should be reserved for public API.
Re: [dpdk-dev] [PATCH 1/3] ethdev: support API to set max LRO packet size
In reply to Andrew RybchenkoThanks, PSB.
Quoted 70 lines
-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Tuesday, November 5, 2019 2:40 PM
To: Dekel Peled <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [PATCH 1/3] ethdev: support API to set max LRO packet sizeQuoted 10 lines · Dekel Peled
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1]
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
Quoted 1 line
es.dpdk.org%2Fpatch%2F58217%2F&data=02%7C01%7Cdekelp%40mell anox.co
Quoted 1 line
m%7C751aa0cb18b94b8a447c08d761ed4051%7Ca652971c7d2e4d9ba6a4d149 256f461
Quoted 1 line
b%7C0%7C1%7C637085543948425032&sdata=C2laHnaMCQZbDUneQD0 2Kpi5iAcr%
Quoted 3 lines
2FYDAS%2BMuO8IcV9s%3D&reserved=0
[2]https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
Quoted 1 line
es.dpdk.org%2Fpatch%2F57492%2F&data=02%7C01%7Cdekelp%40mell anox.co
Quoted 1 line
m%7C751aa0cb18b94b8a447c08d761ed4051%7Ca652971c7d2e4d9ba6a4d149 256f461
Quoted 1 line
b%7C0%7C1%7C637085543948435028&sdata=XnexdrRYNmFyLqT9IL6ZKa CLF2JKr
Quoted 3 lines
oKPDVML7gXKceE%3D&reserved=0
Signed-off-by Dekel Peled <[email protected]>Few comments below, otherwise
Reviewed-by Andrew Rybchenko <[email protected]>[snip]
Quoted 8 lines
(quoted diff) +0
-0
b/lib/librte_ethdev/rte_ethdev.cindex 85ab5f0..2f52090 100644lib/librte_ethdev/rte_ethdev.c +0
-0@@ -1156,6 +1156,26 @@ struct rte_eth_dev *return name; }
Quoted 6 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1161
Quoted 3 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+static inline int +rte_eth_check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size)As I understand Thomas prefers static functions without
rte_eth_prefix. I think it is reasonable.
Will remove prefix.
Quoted 7 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 6 lines
lib/librte_ethdev/rte_ethdev.c +5
-0+{ +int ret =0 ; + +if (config_size > dev_info_size) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u > "
Quoted 8 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1170
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.c +4
-0+"max allowed value %u\n" , + port_id, config_size, dev_info_size); + ret = -EINVAL ; + }else if (config_size <RTE_ETHER_MIN_LEN ) {Shouldn't
config_size== 0 fallback to maximum?
(I don't know and I simply would like to get comments on it)
This check is for value smaller than minimum, not just 0.
Quoted 30 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1171
Quoted 1 line
lib/librte_ethdev/rte_ethdev.c +1
-0+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u < "lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 9 lines
lib/librte_ethdev/rte_ethdev.c +7
-0+"min allowed value %u\n" , port_id, config_size, + (unsigned int)RTE_ETHER_MIN_LEN); + ret = -EINVAL ; + } +return ret; +} +int rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t
nb_tx_q,lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1181
Quoted 1 line
lib/librte_ethdev/rte_ethdev.c +0
-0const struct rte_eth_conf *dev_conf) @@ -1286,6+1306,18 @@
Quoted 2 lines
struct
rte_eth_dev*RTE_ETHER_MAX_LEN;lib/librte_ethdev/rte_ethdev.c
Quoted 12 lines
lib/librte_ethdev/rte_ethdev.c +7
-0} +/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret = rte_eth_check_lro_pkt_size( + port_id, dev_conf-rxmode.max_lro_pkt_size,
lib/librte_ethdev/rte_ethdev.c +2
-0+ dev_info.max_lro_pkt_size); +if (ret)
Quoted 9 lines
if (ret != 0)
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.d
pdk.org%2Fguides%2Fcontributing%2Fcoding_style.html%23function- calls&data=02%7C01%7Cdekelp%40mellanox.com%7C751aa0cb18b94b8 a447c08d761ed4051%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C 637085543948435028&sdata=wnlhZz70T2l%2B0UOe54XqRhJG53Pc6zMqI %2F%2FSu%2B5qDqc%3D&reserved=0
and the style dominates inrte_ethdev.c
Will change.
Quoted 21 lines
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+ goto rollback; + } +/* Any requested offloading must be within its device capabilities */ if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) != dev_conf->rxmode.offloads) {@@ -1790,6 +1822,18 @@ struct rte_eth_dev *return -EINVAL ; }lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1834
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +9
-0+/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (local_conf.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { +int ret =rte_eth_check_lro_pkt_size (port_id, + dev->data- dev_conf.rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret)
Quoted 9 lines
if (ret != 0)
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.d
pdk.org%2Fguides%2Fcontributing%2Fcoding_style.html%23function- calls&data=02%7C01%7Cdekelp%40mellanox.com%7C751aa0cb18b94b8 a447c08d761ed4051%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C 637085543948435028&sdata=wnlhZz70T2l%2B0UOe54XqRhJG53Pc6zMqI %2F%2FSu%2B5qDqc%3D&reserved=0
and the style dominates inrte_ethdev.c
Will change.
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+return ret; + } + ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id,
nb_rx_desc,Quoted 3 lines
lib/librte_ethdev/rte_ethdev.c +0
-0socket_id, &local_conf, mp);if (!ret) {
[snip]
Re: [dpdk-dev] [PATCH 1/3] ethdev: support API to set max LRO packet size
Quoted 61 lines · Dekel Peled
Thanks, PSB.
Quoted 59 lines
-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Tuesday, November 5, 2019 2:40 PM
To: Dekel Peled <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [PATCH 1/3] ethdev: support API to set max LRO packet sizeQuoted 10 lines · Dekel Peled
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1]
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
Quoted 1 line
es.dpdk.org%2Fpatch%2F58217%2F&data=02%7C01%7Cdekelp%40mell anox.co
Quoted 1 line
m%7C751aa0cb18b94b8a447c08d761ed4051%7Ca652971c7d2e4d9ba6a4d149 256f461
Quoted 1 line
b%7C0%7C1%7C637085543948425032&sdata=C2laHnaMCQZbDUneQD0 2Kpi5iAcr%
Quoted 3 lines
2FYDAS%2BMuO8IcV9s%3D&reserved=0
[2]https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
Quoted 1 line
es.dpdk.org%2Fpatch%2F57492%2F&data=02%7C01%7Cdekelp%40mell anox.co
Quoted 1 line
m%7C751aa0cb18b94b8a447c08d761ed4051%7Ca652971c7d2e4d9ba6a4d149 256f461
Quoted 1 line
b%7C0%7C1%7C637085543948435028&sdata=XnexdrRYNmFyLqT9IL6ZKa CLF2JKr
Quoted 3 lines
oKPDVML7gXKceE%3D&reserved=0
Signed-off-by Dekel Peled <[email protected]>Few comments below, otherwise
Reviewed-by Andrew Rybchenko <[email protected]>
[snip]
Quoted 33 lines
Quoted 8 lines
Quoted 8 lines
(quoted diff) +0
-0
b/lib/librte_ethdev/rte_ethdev.cindex 85ab5f0..2f52090 100644lib/librte_ethdev/rte_ethdev.c +0
-0@@ -1156,6 +1156,26 @@ struct rte_eth_dev *return name; }Quoted 6 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1161
Quoted 3 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+static inline int +rte_eth_check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size)As I understand Thomas prefers static functions without
rte_eth_prefix. I think it is reasonable.Will remove prefix.
Quoted 7 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 6 lines
lib/librte_ethdev/rte_ethdev.c +5
-0+{ +int ret =0 ; + +if (config_size > dev_info_size) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u > "Quoted 8 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1170
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.c +4
-0+"max allowed value %u\n" , + port_id, config_size, dev_info_size); + ret = -EINVAL ; + }else if (config_size <RTE_ETHER_MIN_LEN ) {Shouldn't
config_size== 0 fallback to maximum?
(I don't know and I simply would like to get comments on it)
Quoted 1 line
This check is for value smaller than minimum, not just 0.
Yes, I know, but the question still remains.
Quoted 13 lines
Quoted 13 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1171
Quoted 1 line
lib/librte_ethdev/rte_ethdev.c +1
-0+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u < "lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 9 lines
lib/librte_ethdev/rte_ethdev.c +7
-0+"min allowed value %u\n" , port_id, config_size, + (unsigned int)RTE_ETHER_MIN_LEN); + ret = -EINVAL ; + } +return ret; +} +int rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t
nb_tx_q,Quoted 1 line
lib/librte_ethdev/rte_ethdev.c +0
-0const struct rte_eth_conf *dev_conf) @@ -1286,6
[snip]
Re: [dpdk-dev] [PATCH 1/3] ethdev: support API to set max LRO packet size
Thanks, PSB.
Quoted 129 lines
-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Tuesday, November 5, 2019 4:27 PM
To: Dekel Peled <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [PATCH 1/3] ethdev: support API to set max LRO packet sizeQuoted 15 lines · Dekel Peled
Thanks, PSB.
Quoted 13 lines
-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Tuesday, November 5, 2019 2:40 PM
To: Dekel Peled <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected];Quoted 6 lines
Quoted 6 lines
Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [PATCH 1/3] ethdev: support API to set max LRO packet sizeQuoted 7 lines
Quoted 7 lines · Dekel Peled
Quoted 6 lines
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.Various PMDs using LRO offload are updated, the new data members
are
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
initialized to ensure they don't fail validation.
[1]
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
Quoted 3 lines
Quoted 3 lines
h
Quoted 1 line
es.dpdk.org%2Fpatch%2F58217%2F&data=02%7C01%7Cdekelp%40mell
Quoted 3 lines
Quoted 3 lines
anox.co
Quoted 1 line
m%7C751aa0cb18b94b8a447c08d761ed4051%7Ca652971c7d2e4d9ba6a4d149
Quoted 3 lines
Quoted 3 lines
256f461
Quoted 1 line
b%7C0%7C1%7C637085543948425032&sdata=C2laHnaMCQZbDUneQD0
Quoted 5 lines
Quoted 5 lines
2Kpi5iAcr%
Quoted 3 lines
2FYDAS%2BMuO8IcV9s%3D&reserved=0
[2]https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
Quoted 3 lines
Quoted 3 lines
h
Quoted 1 line
es.dpdk.org%2Fpatch%2F57492%2F&data=02%7C01%7Cdekelp%40mell
Quoted 3 lines
Quoted 3 lines
anox.co
Quoted 1 line
m%7C751aa0cb18b94b8a447c08d761ed4051%7Ca652971c7d2e4d9ba6a4d149
Quoted 3 lines
Quoted 3 lines
256f461
Quoted 1 line
b%7C0%7C1%7C637085543948435028&sdata=XnexdrRYNmFyLqT9IL6ZKa
Quoted 8 lines
Quoted 8 lines
CLF2JKr
Quoted 3 lines
oKPDVML7gXKceE%3D&reserved=0
Signed-off-by Dekel Peled <[email protected]>Few comments below, otherwise
Reviewed-by Andrew Rybchenko <[email protected]>[snip]
Quoted 33 lines
Quoted 8 lines
Quoted 8 lines
(quoted diff) +0
-0
b/lib/librte_ethdev/rte_ethdev.cindex 85ab5f0..2f52090 100644lib/librte_ethdev/rte_ethdev.c +0
-0@@ -1156,6 +1156,26 @@ struct rte_eth_dev *return name; }Quoted 6 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1161
Quoted 3 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+static inline int +rte_eth_check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size)As I understand Thomas prefers static functions without
rte_eth_prefix. I think it is reasonable.Will remove prefix.
Quoted 15 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 6 lines
lib/librte_ethdev/rte_ethdev.c +5
-0+{ +int ret =0 ; + +if (config_size > dev_info_size) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u > "lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1170
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.c +4
-0+"max allowed value %u\n" , + port_id, config_size, dev_info_size); + ret = -EINVAL ; + }else if (config_size <RTE_ETHER_MIN_LEN ) {Shouldn't
config_size== 0 fallback to maximum?
(I don't know and I simply would like to get comments on it)
Quoted 3 lines
Quoted 1 line
This check is for value smaller than minimum, not just 0.
Yes, I know, but the question still remains.
Application may set value 0 explicitly, don't think it should be modified.
Quoted 16 lines
Quoted 14 lines
Quoted 14 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1171
Quoted 2 lines
lib/librte_ethdev/rte_ethdev.c +1
-0+ RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u < "lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 9 lines
lib/librte_ethdev/rte_ethdev.c +7
-0+"min allowed value %u\n" , port_id, config_size, + (unsigned int)RTE_ETHER_MIN_LEN); + ret = -EINVAL ; + } +return ret; +} +int rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t
nb_tx_q,Quoted 1 line
lib/librte_ethdev/rte_ethdev.c +0
-0const struct rte_eth_conf *dev_conf) @@ -1286,6[snip]
PATCH 2/3 net/mlx5: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
Rx queue create is updated to use the relevant configuration. Documentation is updated accordingly.
--- doc/guides/nics/mlx5.rst | 2 ++ drivers/net/mlx5/mlx5_rxq.c | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-)
doc/guides/nics/mlx5.rst +2 -0
@@ -207,6 +207,8 @@ Limitations - KEEP_CRC offload cannot be supported with LRO. - The first mbuf length, without head-room, must be big enough to include the TCP header (122B). + - Rx queue with LRO offload enabled, receiving a non-LRO packet, can forward + it with size limited to max LRO size, not to max RX packet length. Statistics ----------
drivers/net/mlx5/mlx5_rxq.c +3 -1
@@ -1772,7 +1772,9 @@ struct mlx5_rxq_ctrl * dev->data->dev_conf.rxmode.offloads;unsigned int lro_on_queue = !!(offloads &DEV_RX_OFFLOAD_TCP_LRO );const int mprq_en =mlx5_check_mprq_support (dev) >0 ; -unsigned int max_rx_pkt_len = dev->data->dev_conf.rxmode.max_rx_pkt_len; +unsigned int max_rx_pkt_len = lro_on_queue ? + dev->data->dev_conf.rxmode.max_lro_pkt_size : + dev->data->dev_conf.rxmode.max_rx_pkt_len;unsigned int non_scatter_min_mbuf_size = max_rx_pkt_len +RTE_PKTMBUF_HEADROOM ;unsigned int max_lro_size =0 ;
Signature · 1 line
1.8.3.1
PATCH 3/3 app/testpmd: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.
--- app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 5 ++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 95 insertions(+)
app/test-pmd/cmdline.c +73 -0
@@ -2037,6 +2037,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ +struct cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) +{ +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + } + +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port->dev_conf.rxmode.max_lro_pkt_size) +return ; + + port->dev_conf.rxmode.max_lro_pkt_size = res->value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); +} + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + keyword,"config" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + all,"all" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + name,"max-lro-pkt-size" ); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + value,UINT32 ); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;
@@ -19024,6 +19096,7 @@ struct cmd_show_port_supported_ptypes_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss, (cmdline_parse_inst_t *)&cmd_config_rxtx_ring_size,
app/test-pmd/config.c +2 -0
@@ -629,6 +629,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data)printf ("Minimum size of RX buffer: %u\n" , dev_info.min_rx_bufsize);printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)
app/test-pmd/parameters.c +5 -0
@@ -592,6 +592,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 }, { "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },
@@ -888,6 +889,10 @@"Invalid max-pkt-len=%d - should be > %d\n" , n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt-size" )) { + n =atoi (optarg); + rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )) {if (!strcmp (optarg,"signature" )) fdir_conf.mode =
app/test-pmd/testpmd.c +1 -0
@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = {struct rte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN , };struct rte_eth_txmode tx_mode = {
doc/guides/testpmd_app_ug/run_app.rst +5 -0
@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The default value is 1518. +* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >= 64. + The default value is 1518. + * ``--eth-peers-configfile=name`` Use a configuration file containing the Ethernet addresses of the peer ports.
doc/guides/testpmd_app_ug/testpmd_funcs.rst +9 -0
@@ -2139,6 +2139,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~
Signature · 1 line
1.8.3.1
From: Dekel Peled
Quoted 8 lines
This series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
For all the series:
Quoted 27 lines
app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 5 ++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 ++++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 + drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 22 files changed, 170 insertions(+), 6 deletions(-)--
1.8.3.1
v2 cover support API to set max LRO packet size
In reply to Dekel PeledThis series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 5 ++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 ++++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 + drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 22 files changed, 170 insertions(+), 6 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v2 1/3 ethdev: support API to set max LRO packet size
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
--- doc/guides/nics/features.rst | 2 ++ doc/guides/rel_notes/deprecation.rst | 4 --- doc/guides/rel_notes/release_19_11.rst | 8 ++++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++ drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 +++ 15 files changed, 70 insertions(+), 5 deletions(-)
doc/guides/nics/features.rst +2 -0
@@ -193,10 +193,12 @@ LRO Supports Large Receive Offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``. + ``dev_conf.rxmode.max_lro_pkt_size``. * **[implements] datapath**: ``LRO functionality``. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``. .. _nic_features_tso:
doc/guides/rel_notes/deprecation.rst +0 -4
@@ -87,10 +87,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
doc/guides/rel_notes/release_19_11.rst +8 -0
@@ -380,6 +380,14 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header. +* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in + struct ``rte_eth_dev_info`` for the port capability and in struct + ``rte_eth_rxmode`` for the port configuration. + Application should use the new field in struct ``rte_eth_rxmode`` to configure + the requested size. + PMD should use the new field in struct ``rte_eth_dev_info`` to report the + supported port capability. + Shared Library Versions -----------------------
drivers/net/bnxt/bnxt_ethdev.c +1 -0
@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pkt_size =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ;if (bp->flags &BNXT_FLAG_PTP_SUPPORTED )
drivers/net/hinic/hinic_pmd_ethdev.c +1 -0
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa) info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pkt_size =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;
drivers/net/ixgbe/ixgbe_ethdev.c +2 -0
@@ -3804,6 +3804,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, } dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */ dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =15872 ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ; dev_info->max_vfs = pci_dev->max_vfs;
@@ -3927,6 +3928,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, dev_info->max_tx_queues = (uint16_t )hw->mac.max_tx_queues; dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL reg */ dev_info->max_rx_pktlen =9728 ;/* includes CRC, cf MAXFRS reg */ + dev_info->max_lro_pkt_size =9728 ; dev_info->max_mtu = dev_info->max_rx_pktlen -IXGBE_ETH_OVERHEAD ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ;
drivers/net/ixgbe/ixgbe_vf_representor.c +1 -0
@@ -48,6 +48,7 @@ dev_info->min_rx_bufsize =1024 ;/**< Minimum size of RX buffer. */ dev_info->max_rx_pktlen =9728 ; + dev_info->max_lro_pkt_size =9728 ;/**< Maximum configurable length of RX pkt. */ dev_info->max_rx_queues =IXGBE_VF_MAX_RX_QUEUES ;/**< Maximum number of RX queues. */
drivers/net/mlx5/mlx5.h +3 -0
@@ -203,6 +203,9 @@ struct mlx5_hca_attr {#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */
drivers/net/mlx5/mlx5_ethdev.c +1 -0
@@ -606,6 +606,7 @@ struct ethtool_link_settings {/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pkt_size =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values.
drivers/net/mlx5/mlx5_rxq.c +0 -1
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))
drivers/net/qede/qede_ethdev.c +1 -0
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; + dev_info->max_lro_pkt_size = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;
drivers/net/virtio/virtio_ethdev.c +1 -0
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)RTE_MIN (hw->max_queue_pairs,VIRTIO_MAX_TX_QUEUES ); dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pkt_size =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features =VTPCI_OPS (hw)->get_features (hw);
drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -0
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev) dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;
lib/librte_ethdev/rte_ethdev.c +44 -0
62 lines not on this page · raw message
lib/librte_ethdev/rte_ethdev.h +4 -0
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {/** The multi-queue packet distribution mode to be used, e.g. RSS. */ enum rte_eth_rx_mq_mode mq_mode;uint32_t max_rx_pkt_len;/**< Only used if JUMBO_FRAME enabled. */ +/** Maximal allowed size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t split_hdr_size;/**< hdr buf size (header_split enabled).*/ /** * Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1223,6 +1225,8 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 1/3] ethdev: support API to set max LRO packet size
06/11/2019 12:34, Dekel Peled:
Quoted 14 lines
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/Signed-off-by Dekel Peled <[email protected]>Reviewed-by Andrew Rybchenko <[email protected]>---
[...]
Quoted 5 lines
lib/librte_ethdev/rte_ethdev.c +0
-0@@ -1156,6 +1156,26 @@ struct rte_eth_dev *return name; }
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1167
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +9
-0+static inline int +check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size) +{ +int ret =0 ; + +if (config_size > dev_info_size) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u > " + "max allowed value %u\n",
Minor comment (can be fixed while merging):
it is better to keep fixed strings together so it can be grepped.
Here I would move " > " on the second line, so we can grep " > max allowed value ".
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1172
Quoted 5 lines
lib/librte_ethdev/rte_ethdev.c +5
-0+ port_id, config_size, dev_info_size); + ret = -EINVAL ; + }else if (config_size <RTE_ETHER_MIN_LEN ) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d max_lro_pkt_size %u < " + "min allowed value %u\n", port_id, config_size,
Same minor comment here.
Quoted 5 lines
lib/librte_ethdev/rte_ethdev.c +5
-0+ (unsigned int)RTE_ETHER_MIN_LEN); + ret = -EINVAL ; + } +return ret; +}
[...]
lib/librte_ethdev/rte_ethdev.h struct rte_eth_rxmode { · line 395
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.h +1
-0@@ -395,6 +395,8 @@ struct rte_eth_rxmode { +/** Maximal allowed size of LRO aggregated packet. */
Not sure, isn't it more correct to say "Maximum" in English?
lib/librte_ethdev/rte_ethdev.h struct rte_eth_dev_info { · line 1226
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.h +3
-0+uint32_t max_lro_pkt_size;@@ -1223,6 +1225,8 @@ struct rte_eth_dev_info { +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;
Except minor comments above,
Re: [dpdk-dev] [PATCH v2 1/3] ethdev: support API to set max LRO packet size
Thanks, PSB.
Quoted 73 lines
-----Original Message-----
From: Thomas Monjalon <[email protected]>
Sent: Wednesday, November 6, 2019 2:26 PM
To: Dekel Peled <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH v2 1/3] ethdev: support API to set max LRO packet size06/11/2019 12:34, Dekel Peled:
Quoted 10 lines
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1]
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
Quoted 1 line
es.dpdk.org%2Fpatch%2F58217%2F&data=02%7C01%7Cdekelp%40mell anox.co
Quoted 1 line
m%7C21fb831af76a46c0597208d762b490f1%7Ca652971c7d2e4d9ba6a4d14925 6f461
Quoted 1 line
b%7C0%7C1%7C637086399982280191&sdata=APp12mvk0RP92%2FzoNy Mj2%2BvV3
Quoted 3 lines
E4BAaTzo4M8xOIc1yc%3D&reserved=0
[2]https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
Quoted 1 line
es.dpdk.org%2Fpatch%2F57492%2F&data=02%7C01%7Cdekelp%40mell anox.co
Quoted 1 line
m%7C21fb831af76a46c0597208d762b490f1%7Ca652971c7d2e4d9ba6a4d14925 6f461
Quoted 1 line
b%7C0%7C1%7C637086399982280191&sdata=cBFoqYfJPNKMAv0AMVQ 9iO77ikiTi
Quoted 5 lines
pFwoFJx5pRQxCE%3D&reserved=0
Signed-off-by Dekel Peled <[email protected]>Reviewed-by Andrew Rybchenko <[email protected]>---
[...]
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.c +0
-0@@ -1156,6 +1156,26 @@ struct rte_eth_dev *return name;lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1166
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +8
-0} +static inline int +check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size) +{ +int ret =0 ; + +if (config_size > dev_info_size) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u > "
Quoted 7 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1167
Quoted 1 line
lib/librte_ethdev/rte_ethdev.c +1
-0+ "max allowed value %u\n",Minor comment (can be fixed while merging):
it is better to keep fixed strings together so it can be grepped. Here I would move " > " on the second line, so we can grep " > max allowed value ".
I'll edit it in v3.
Quoted 9 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.c +4
-0+ port_id, config_size, dev_info_size); + ret = -EINVAL ; + }else if (config_size <RTE_ETHER_MIN_LEN ) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u < "lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1172
Quoted 1 line
lib/librte_ethdev/rte_ethdev.c +1
-0+ "min allowed value %u\n", port_id, config_size,Same minor comment here.
I'll edit it in v3.
Quoted 6 lines
Quoted 5 lines
lib/librte_ethdev/rte_ethdev.c +5
-0+ (unsigned int)RTE_ETHER_MIN_LEN); + ret = -EINVAL ; + } +return ret; +}[...]
Quoted 7 lines
lib/librte_ethdev/rte_ethdev.h struct rte_eth_rxmode { · line 395
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.h +1
-0@@ -395,6 +395,8 @@ struct rte_eth_rxmode { +/** Maximal allowed size of LRO aggregated packet. */ Not sure, isn't it more correct to say "Maximum" in English?
I'll edit it in v3.
Quoted 8 lines
lib/librte_ethdev/rte_ethdev.h struct rte_eth_dev_info { · line 1226
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.h +3
-0+uint32_t max_lro_pkt_size;@@ -1223,6 +1225,8 @@ struct rte_eth_dev_info { +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;Except minor comments above,
Acked-by Thomas Monjalon <[email protected]>
PATCH v2 2/3 net/mlx5: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
Rx queue create is updated to use the relevant configuration. Documentation is updated accordingly.
--- doc/guides/nics/mlx5.rst | 2 ++ drivers/net/mlx5/mlx5_rxq.c | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-)
doc/guides/nics/mlx5.rst +2 -0
@@ -207,6 +207,8 @@ Limitations - KEEP_CRC offload cannot be supported with LRO. - The first mbuf length, without head-room, must be big enough to include the TCP header (122B). + - Rx queue with LRO offload enabled, receiving a non-LRO packet, can forward + it with size limited to max LRO size, not to max RX packet length. Statistics ----------
drivers/net/mlx5/mlx5_rxq.c +3 -1
@@ -1772,7 +1772,9 @@ struct mlx5_rxq_ctrl * dev->data->dev_conf.rxmode.offloads;unsigned int lro_on_queue = !!(offloads &DEV_RX_OFFLOAD_TCP_LRO );const int mprq_en =mlx5_check_mprq_support (dev) >0 ; -unsigned int max_rx_pkt_len = dev->data->dev_conf.rxmode.max_rx_pkt_len; +unsigned int max_rx_pkt_len = lro_on_queue ? + dev->data->dev_conf.rxmode.max_lro_pkt_size : + dev->data->dev_conf.rxmode.max_rx_pkt_len;unsigned int non_scatter_min_mbuf_size = max_rx_pkt_len +RTE_PKTMBUF_HEADROOM ;unsigned int max_lro_size =0 ;
Signature · 1 line
1.8.3.1
PATCH v2 3/3 app/testpmd: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.
--- app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 5 ++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 95 insertions(+)
app/test-pmd/cmdline.c +73 -0
@@ -2037,6 +2037,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ +struct cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) +{ +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + } + +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port->dev_conf.rxmode.max_lro_pkt_size) +return ; + + port->dev_conf.rxmode.max_lro_pkt_size = res->value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); +} + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + keyword,"config" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + all,"all" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + name,"max-lro-pkt-size" ); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + value,UINT32 ); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;
@@ -19024,6 +19096,7 @@ struct cmd_show_port_supported_ptypes_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss, (cmdline_parse_inst_t *)&cmd_config_rxtx_ring_size,
app/test-pmd/config.c +2 -0
@@ -629,6 +629,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data)printf ("Minimum size of RX buffer: %u\n" , dev_info.min_rx_bufsize);printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)
app/test-pmd/parameters.c +5 -0
@@ -592,6 +592,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 }, { "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },
@@ -888,6 +889,10 @@"Invalid max-pkt-len=%d - should be > %d\n" , n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt-size" )) { + n =atoi (optarg); + rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )) {if (!strcmp (optarg,"signature" )) fdir_conf.mode =
app/test-pmd/testpmd.c +1 -0
@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = {struct rte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN , };struct rte_eth_txmode tx_mode = {
doc/guides/testpmd_app_ug/run_app.rst +5 -0
@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The default value is 1518. +* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >= 64. + The default value is 1518. + * ``--eth-peers-configfile=name`` Use a configuration file containing the Ethernet addresses of the peer ports.
doc/guides/testpmd_app_ug/testpmd_funcs.rst +9 -0
@@ -2139,6 +2139,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v2 3/3] app/testpmd: use API to set max LRO packet size
Hi Dekel,
Quoted 64 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, November 6, 2019 11:35 AM
To: Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: [PATCH v2 3/3] app/testpmd: use API to set max LRO packet sizeThis patch implements use of the API for LRO aggregated packet max size. It adds command-line and runtime commands to configure this value, and adds option to show the supported value.
Documentation is updated accordingly.Signed-off-by Dekel Peled <[email protected]>--- app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 5 ++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 95 insertions(+)app/test-pmd/cmdline.c index renamed from app/test-pmd/cmdline.c +0
-04478069..edfa60f 100644
app/test-pmd/cmdline.c +20
-0@@ -2037,6 +2037,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ struct +cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) { +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + }
app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result { · line 2069
Quoted 10 lines
app/test-pmd/cmdline.c +9
-0+ +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port- >dev_conf.rxmode.max_lro_pkt_size) +return ; +
Should there be a check on the input value, max is RTE_ETHER_MAX_LEN ?
Quoted 79 lines
app/test-pmd/cmdline.c +16
-0+ port->dev_conf.rxmode.max_lro_pkt_size = res- >value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); } + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword = + TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c +3
-0+ keyword, "config"); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c +3
-0+ all, "all"); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c +3
-0+ name, "max-lro-pkt-size"); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c +17
-0+ value, UINT32); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;@@ -19024,6 +19096,7 @@ struct cmd_show_port_supported_ptypes_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss,(
cmdline_parse_inst_t*)&cmd_config_rxtx_ring_size, diff --gita/app/test-pmd/config.cb/app/test-pmd/config.cindex efe2812..50e6ac0 100644app/test-pmd/config.c +2
-0@@ -629,6 +629,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data) printf("Minimum size of RX buffer: %u\n", dev_info.min_rx_bufsize);printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)app/test-pmd/config.c +0
-0printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)app/test-pmd/parameters.c index renamed from app/test-pmd/parameters.c +0
-09ea87c1..3e371e2 100644
app/test-pmd/parameters.c line 595
Quoted 4 lines
app/test-pmd/parameters.c +1
-0@@ -592,6 +592,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 },
The max-lro-pkt-size option should be documented in the usage() function around line 110 in parameters.c
app/test-pmd/parameters.c line 895
Quoted 11 lines
app/test-pmd/parameters.c +2
-0{ "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },@@ -888,6 +889,10 @@ "Invalid max-pkt-len=%d - should be > %d\n", n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt- size")) { + n =atoi (optarg);
Should there be a check on the value input, max value is RTE_ETHER_MAX_LEN?
Quoted 28 lines
app/test-pmd/parameters.c +2
-0+ rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )){
app/test-pmd/parameters.c +0
-0if (!strcmp (optarg,"signature" )) fdir_conf.mode =app/test-pmd/testpmd.c index renamed from app/test-pmd/testpmd.c +0
-038acbc5..d4f67ec 100644
app/test-pmd/testpmd.c +1
-0@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = { structrte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN , };struct rte_eth_txmode tx_mode = {doc/guides/testpmd_app_ug/run_app.rst +0
-0@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The default valueis 1518.
doc/guides/testpmd_app_ug/run_app.rst The command line options are: · line 118
Quoted 4 lines
doc/guides/testpmd_app_ug/run_app.rst +4
-0+* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >= 64. + The default value is 1518.
Should a max value be specified ?
Quoted 27 lines
+
* ``--eth-peers-configfile=name``Use a configuration file containing the Ethernet addresses of the peer
ports.doc/guides/testpmd_app_ug/testpmd_funcs.rst +9
-1@@ -2139,6 +2139,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~ --
Quoted 1 line
1.8.3.1
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v2 3/3] app/testpmd: use API to set max LRO packet size
Thanks, PSB.
Quoted 97 lines
-----Original Message-----
From: Iremonger, Bernard <[email protected]>
Sent: Wednesday, November 6, 2019 2:36 PM
To: Dekel Peled <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v2 3/3] app/testpmd: use API to set max LRO packet sizeHi Dekel,
Quoted 8 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, November 6, 2019 11:35 AM
To: Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu,Wenzhuo
Quoted 3 lines
<[email protected]>; Ananyev, Konstantin <[email protected]>; [email protected]; [email protected]; [email protected];
Quoted 61 lines
[email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: [PATCH v2 3/3] app/testpmd: use API to set max LRO packet sizeThis patch implements use of the API for LRO aggregated packet max size. It adds command-line and runtime commands to configure this value, and adds option to show the supported value.
Documentation is updated accordingly.Signed-off-by Dekel Peled <[email protected]>--- app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 5 ++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 95 insertions(+)app/test-pmd/cmdline.c index renamed from app/test-pmd/cmdline.c +0
-04478069..edfa60f 100644
app/test-pmd/cmdline.c +27
-0@@ -2037,6 +2037,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ struct +cmd_config_max_lro_pkt_size_result { + cmdline_fixed_string_t port; + cmdline_fixed_string_t keyword; + cmdline_fixed_string_t all; + cmdline_fixed_string_t name; + uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed(void *parsed_result, + __attribute__((unused)) struct cmdline *cl, + __attribute__((unused)) void *data) { + struct cmd_config_max_lro_pkt_size_result *res = parsed_result; + portid_t pid; + + if (!all_ports_stopped()) { + printf("Please stop all ports first\n"); + return; + } + + RTE_ETH_FOREACH_DEV(pid) { + struct rte_port *port = &ports[pid]; + + if (!strcmp(res->name, "max-lro-pkt-size")) { + if (res->value == + port-
Quoted 6 lines
app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result { · line 2061
Quoted 3 lines
app/test-pmd/cmdline.c +2
-0>dev_conf.rxmode.max_lro_pkt_size) +return ; +Should there be a check on the input value, max is
RTE_ETHER_MAX_LEN?
Max is device specific, can't check it here.
Quoted 81 lines
Quoted 8 lines
app/test-pmd/cmdline.c +6
-0+ port->dev_conf.rxmode.max_lro_pkt_size = res- >value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + }app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result {
Quoted 10 lines
app/test-pmd/cmdline.c +9
-0+ +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); } + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword=
Quoted 47 lines
app/test-pmd/cmdline.c +1
-0+ TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c +3
-0+ keyword, "config"); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c +3
-0+ all, "all"); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c +3
-0+ name, "max-lro-pkt-size"); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c +17
-0+ value, UINT32); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;@@ -19024,6 +19096,7 @@ struct cmd_show_port_supported_ptypes_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss,(
cmdline_parse_inst_t*)&cmd_config_rxtx_ring_size, diff --gita/app/test-pmd/config.cb/app/test-pmd/config.cindex efe2812..50e6ac0 100644app/test-pmd/config.c static int bus_match_all(const struct rte_bus · line 630
Quoted 2 lines
app/test-pmd/config.c +0
-0@@ -629,6 +629,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data) printf("Minimum size of RX buffer: %u\n",dev_info.min_rx_bufsize);
Quoted 12 lines
app/test-pmd/config.c +2
-0printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);app/test-pmd/config.c +0
-0if (dev_info.max_vmdq_pools)app/test-pmd/parameters.c +0
-0index
9ea87c1..3e371e2 100644app/test-pmd/parameters.c +0
-0
Quoted 9 lines
app/test-pmd/parameters.c line 595
Quoted 5 lines
app/test-pmd/parameters.c +1
-0@@ -592,6 +592,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 },The max-lro-pkt-size option should be documented in the
usage()function around line 110 inparameters.c
I'll add in in v3.
Quoted 6 lines
Quoted 6 lines
app/test-pmd/parameters.c +0
-0{ "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },@@ -888,6 +889,10 @@ "Invalid max-pkt-len=%d - should be > %d\n",
Quoted 8 lines
app/test-pmd/parameters.c line 893
Quoted 5 lines
app/test-pmd/parameters.c +2
-0n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt- size")) { + n =atoi (optarg);Should there be a check on the value input, max value is
RTE_ETHER_MAX_LEN?
Max is device specific, can't check it here.
Quoted 29 lines
app/test-pmd/parameters.c
Quoted 4 lines
app/test-pmd/parameters.c +2
-0+ rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )){
Quoted 24 lines
app/test-pmd/parameters.c +0
-0if (!strcmp (optarg,"signature" )) fdir_conf.mode =app/test-pmd/testpmd.c index renamed from app/test-pmd/testpmd.c +0
-038acbc5..d4f67ec 100644
app/test-pmd/testpmd.c +1
-0@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = { structrte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN , };struct rte_eth_txmode tx_mode = {doc/guides/testpmd_app_ug/run_app.rst +0
-0@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. Thedefault value is 1518.
Quoted 7 lines
doc/guides/testpmd_app_ug/run_app.rst The command line options are:
Quoted 3 lines
doc/guides/testpmd_app_ug/run_app.rst +3
-0+* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >=64.
Quoted 1 line
+ The default value is 1518.
Should a max value be specified ?
Max is device specific, can't specify it here.
Quoted 33 lines
Quoted 28 lines
+
* ``--eth-peers-configfile=name``Use a configuration file containing the Ethernet addresses of the
peer ports.doc/guides/testpmd_app_ug/testpmd_funcs.rst +9
-1@@ -2139,6 +2139,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~ --Quoted 1 line
1.8.3.1
Regards,
Bernard.
v3 cover support API to set max LRO packet size
In reply to Dekel PeledThis series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
v3: Updated ethdev and testpmd patches per review comments.
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 ++++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 + drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 22 files changed, 172 insertions(+), 6 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v3 1/3 ethdev: support API to set max LRO packet size
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
--- doc/guides/nics/features.rst | 2 ++ doc/guides/rel_notes/deprecation.rst | 4 --- doc/guides/rel_notes/release_19_11.rst | 8 ++++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++ drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 +++ 15 files changed, 70 insertions(+), 5 deletions(-)
doc/guides/nics/features.rst +2 -0
@@ -193,10 +193,12 @@ LRO Supports Large Receive Offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``. + ``dev_conf.rxmode.max_lro_pkt_size``. * **[implements] datapath**: ``LRO functionality``. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``. .. _nic_features_tso:
doc/guides/rel_notes/deprecation.rst +0 -4
@@ -87,10 +87,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
doc/guides/rel_notes/release_19_11.rst +8 -0
@@ -380,6 +380,14 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header. +* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in + struct ``rte_eth_dev_info`` for the port capability and in struct + ``rte_eth_rxmode`` for the port configuration. + Application should use the new field in struct ``rte_eth_rxmode`` to configure + the requested size. + PMD should use the new field in struct ``rte_eth_dev_info`` to report the + supported port capability. + Shared Library Versions -----------------------
drivers/net/bnxt/bnxt_ethdev.c +1 -0
@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pkt_size =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ;if (bp->flags &BNXT_FLAG_PTP_SUPPORTED )
drivers/net/hinic/hinic_pmd_ethdev.c +1 -0
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa) info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pkt_size =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;
drivers/net/ixgbe/ixgbe_ethdev.c +2 -0
@@ -3804,6 +3804,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, } dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */ dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =15872 ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ; dev_info->max_vfs = pci_dev->max_vfs;
@@ -3927,6 +3928,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, dev_info->max_tx_queues = (uint16_t )hw->mac.max_tx_queues; dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL reg */ dev_info->max_rx_pktlen =9728 ;/* includes CRC, cf MAXFRS reg */ + dev_info->max_lro_pkt_size =9728 ; dev_info->max_mtu = dev_info->max_rx_pktlen -IXGBE_ETH_OVERHEAD ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ;
drivers/net/ixgbe/ixgbe_vf_representor.c +1 -0
@@ -48,6 +48,7 @@ dev_info->min_rx_bufsize =1024 ;/**< Minimum size of RX buffer. */ dev_info->max_rx_pktlen =9728 ; + dev_info->max_lro_pkt_size =9728 ;/**< Maximum configurable length of RX pkt. */ dev_info->max_rx_queues =IXGBE_VF_MAX_RX_QUEUES ;/**< Maximum number of RX queues. */
drivers/net/mlx5/mlx5.h +3 -0
@@ -203,6 +203,9 @@ struct mlx5_hca_attr {#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */
drivers/net/mlx5/mlx5_ethdev.c +1 -0
@@ -606,6 +606,7 @@ struct ethtool_link_settings {/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pkt_size =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values.
drivers/net/mlx5/mlx5_rxq.c +0 -1
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))
drivers/net/qede/qede_ethdev.c +1 -0
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; + dev_info->max_lro_pkt_size = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;
drivers/net/virtio/virtio_ethdev.c +1 -0
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)RTE_MIN (hw->max_queue_pairs,VIRTIO_MAX_TX_QUEUES ); dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pkt_size =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features =VTPCI_OPS (hw)->get_features (hw);
drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -0
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev) dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;
lib/librte_ethdev/rte_ethdev.c +44 -0
62 lines not on this page · raw message
lib/librte_ethdev/rte_ethdev.h +4 -0
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {/** The multi-queue packet distribution mode to be used, e.g. RSS. */ enum rte_eth_rx_mq_mode mq_mode;uint32_t max_rx_pkt_len;/**< Only used if JUMBO_FRAME enabled. */ +/** Maximum allowed size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t split_hdr_size;/**< hdr buf size (header_split enabled).*/ /** * Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1223,6 +1225,8 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [EXT] [PATCH v3 1/3] ethdev: support API to set max LRO packet size
Quoted 103 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, November 6, 2019 7:58 PM
To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Rasesh Mody <[email protected]>; Shahed Shaikh <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: [EXT] [PATCH v3 1/3] ethdev: support API to set max LRO packet sizeExternal Email
----------------------------------------------------------------------
This patch implements [1], to support API for configuration andvalidation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11
are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are
initialized to ensure they don't fail validation.
[1] https://urldefense.proofpoint.com/v2/url?u=http-
3A__patches.dpdk.org_patch_58217_&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtf Q&r=qeevDAWea4uZZbQhISypy6IVgD4EOfIP7D- cw6N6nsI&m=ghr6KiUvwMCjBQ7KRJJ8BfoTOHlY9gICprAIn4yao9A&s=ANfM9GH SB9nUhm8O8YaoqcXO0eTBO7TmGhVmekbNO6U&e=[2] https://urldefense.proofpoint.com/v2/url?u=http-
3A__patches.dpdk.org_patch_57492_&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtf Q&r=qeevDAWea4uZZbQhISypy6IVgD4EOfIP7D- cw6N6nsI&m=ghr6KiUvwMCjBQ7KRJJ8BfoTOHlY9gICprAIn4yao9A&s=ppYVWXe Jj3xhnvWCV2hIfNu6wy9N2r5lvJxgJnHKfSc&e=Signed-off-by Dekel Peled <[email protected]>Reviewed-by Andrew Rybchenko <[email protected]>Acked-by Thomas Monjalon <[email protected]>---
doc/guides/nics/features.rst | 2 ++doc/guides/rel_notes/deprecation.rst | 4 ---doc/guides/rel_notes/release_19_11.rst | 8 ++++++drivers/net/bnxt/bnxt_ethdev.c | 1 +drivers/net/hinic/hinic_pmd_ethdev.c | 1 +drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +drivers/net/mlx5/mlx5.h | 3 +++drivers/net/mlx5/mlx5_ethdev.c | 1 +drivers/net/mlx5/mlx5_rxq.c | 1 -drivers/net/qede/qede_ethdev.c | 1 +drivers/net/virtio/virtio_ethdev.c | 1 +drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +lib/librte_ethdev/rte_ethdev.c | 44++++++++++++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 4 +++15 files changed, 70 insertions(+), 5 deletions(-)(quoted diff) +0
-0@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t)QEDE_MIN_RX_BUFF_SIZE; dev_info->max_rx_pktlen =(uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
(quoted diff) +1
-0+ dev_info->max_lro_pkt_size =
Quoted 1 line
(uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN
Please use 0x7FFF instead of ETH_TX_MAX_NON_LSO_PKT_LEN.
We set the same limit in qede_ethdev.c: qede_update_sge_tpa_params()
sge_tpa_params->tpa_max_size = 0x7FFF;
Thanks,
Shahed
Quoted 6 lines
drivers/net/qede/qede_ethdev.c +0
-0dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;
Re: [dpdk-dev] [EXT] [PATCH v3 1/3] ethdev: support API to set max LRO packet size
Thanks, PSB.
Quoted 149 lines
-----Original Message-----
From: Shahed Shaikh <[email protected]>
Sent: Thursday, November 7, 2019 1:57 PM
To: Dekel Peled <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; Rasesh Mody <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: RE: [EXT] [PATCH v3 1/3] ethdev: support API to set max LRO packet sizeQuoted 5 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, November 6, 2019 7:58 PM
To: [email protected]; [email protected]; [email protected]; [email protected];Quoted 8 lines
[email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Rasesh Mody <[email protected]>; Shahed Shaikh <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected];
Quoted 21 lines
[email protected]; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: [EXT] [PATCH v3 1/3] ethdev: support API to set max LRO packet sizeExternal Email
----------------------------------------------------------------------
This patch implements [1], to support API for configuration andvalidation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11
are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are
Quoted 7 lines
initialized to ensure they don't fail validation.
[1]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-&data=02%7C01%7Cdekelp
Quoted 1 line
%40mellanox.com%7Cabfce6c19bcf4f42c75208d76379d781%7Ca652971c7d2e 4d9ba
Quoted 1 line
6a4d149256f461b%7C0%7C1%7C637087247277571736&sdata=gWGd5Ew ntdYj44F
Quoted 2 lines
PZXNTG0uMivl42B0bE2%2FZ2izxV%2Fo%3D&reserved=0
3A__patches.dpdk.org_patch_58217_&d=DwIBAg&c=nKjWec2b6R0mOyPaz 7xtf
Quoted 2 lines
Q&r=qeevDAWea4uZZbQhISypy6IVgD4EOfIP7D-
cw6N6nsI&m=ghr6KiUvwMCjBQ7KRJJ8BfoTOHlY9gICprAIn4yao9A&s=ANfM9 GH
Quoted 5 lines
SB9nUhm8O8YaoqcXO0eTBO7TmGhVmekbNO6U&e=
[2]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-&data=02%7C01%7Cdekelp
Quoted 1 line
%40mellanox.com%7Cabfce6c19bcf4f42c75208d76379d781%7Ca652971c7d2e 4d9ba
Quoted 1 line
6a4d149256f461b%7C0%7C1%7C637087247277571736&sdata=gWGd5Ew ntdYj44F
Quoted 2 lines
PZXNTG0uMivl42B0bE2%2FZ2izxV%2Fo%3D&reserved=0
3A__patches.dpdk.org_patch_57492_&d=DwIBAg&c=nKjWec2b6R0mOyPaz 7xtf
Quoted 2 lines
Q&r=qeevDAWea4uZZbQhISypy6IVgD4EOfIP7D-
cw6N6nsI&m=ghr6KiUvwMCjBQ7KRJJ8BfoTOHlY9gICprAIn4yao9A&s=ppYVW Xe
Quoted 52 lines
Jj3xhnvWCV2hIfNu6wy9N2r5lvJxgJnHKfSc&e=
Signed-off-by Dekel Peled <[email protected]>Reviewed-by Andrew Rybchenko <[email protected]>Acked-by Thomas Monjalon <[email protected]>---
doc/guides/nics/features.rst | 2 ++doc/guides/rel_notes/deprecation.rst | 4 ---doc/guides/rel_notes/release_19_11.rst | 8 ++++++drivers/net/bnxt/bnxt_ethdev.c | 1 +drivers/net/hinic/hinic_pmd_ethdev.c | 1 +drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +drivers/net/mlx5/mlx5.h | 3 +++drivers/net/mlx5/mlx5_ethdev.c | 1 +drivers/net/mlx5/mlx5_rxq.c | 1 -drivers/net/qede/qede_ethdev.c | 1 +drivers/net/virtio/virtio_ethdev.c | 1 +drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +lib/librte_ethdev/rte_ethdev.c | 44++++++++++++++++++++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 4 +++15 files changed, 70 insertions(+), 5 deletions(-)drivers/net/qede/qede_ethdev.c +0
-0@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ;
Quoted 8 lines
Quoted 5 lines
dev_info->max_rx_pktlen=
(uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;(quoted diff) +1
-0+ dev_info->max_lro_pkt_size =(uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN
Please use
0x7FFFinstead ofETH_TX_MAX_NON_LSO_PKT_LEN.
Sending v4 with this change.
Quoted 12 lines
We set the same limit in
qede_ethdev.c:qede_update_sge_tpa_params()
sge_tpa_params->tpa_max_size=0x7FFF;Thanks,
ShahedQuoted 6 lines
drivers/net/qede/qede_ethdev.c +0
-0dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;
Regards,
Dekel
PATCH v3 2/3 net/mlx5: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
Rx queue create is updated to use the relevant configuration. Documentation is updated accordingly.
--- doc/guides/nics/mlx5.rst | 2 ++ drivers/net/mlx5/mlx5_rxq.c | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-)
doc/guides/nics/mlx5.rst +2 -0
@@ -207,6 +207,8 @@ Limitations - KEEP_CRC offload cannot be supported with LRO. - The first mbuf length, without head-room, must be big enough to include the TCP header (122B). + - Rx queue with LRO offload enabled, receiving a non-LRO packet, can forward + it with size limited to max LRO size, not to max RX packet length. Statistics ----------
drivers/net/mlx5/mlx5_rxq.c +3 -1
@@ -1772,7 +1772,9 @@ struct mlx5_rxq_ctrl * dev->data->dev_conf.rxmode.offloads;unsigned int lro_on_queue = !!(offloads &DEV_RX_OFFLOAD_TCP_LRO );const int mprq_en =mlx5_check_mprq_support (dev) >0 ; -unsigned int max_rx_pkt_len = dev->data->dev_conf.rxmode.max_rx_pkt_len; +unsigned int max_rx_pkt_len = lro_on_queue ? + dev->data->dev_conf.rxmode.max_lro_pkt_size : + dev->data->dev_conf.rxmode.max_rx_pkt_len;unsigned int non_scatter_min_mbuf_size = max_rx_pkt_len +RTE_PKTMBUF_HEADROOM ;unsigned int max_lro_size =0 ;
Signature · 1 line
1.8.3.1
PATCH v3 3/3 app/testpmd: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.
--- app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 97 insertions(+)
app/test-pmd/cmdline.c +73 -0
@@ -2037,6 +2037,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ +struct cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) +{ +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + } + +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port->dev_conf.rxmode.max_lro_pkt_size) +return ; + + port->dev_conf.rxmode.max_lro_pkt_size = res->value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); +} + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + keyword,"config" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + all,"all" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + name,"max-lro-pkt-size" ); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + value,UINT32 ); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;
@@ -19024,6 +19096,7 @@ struct cmd_show_port_supported_ptypes_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss, (cmdline_parse_inst_t *)&cmd_config_rxtx_ring_size,
app/test-pmd/config.c +2 -0
@@ -629,6 +629,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data)printf ("Minimum size of RX buffer: %u\n" , dev_info.min_rx_bufsize);printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)
app/test-pmd/parameters.c +7 -0
@@ -107,6 +107,8 @@printf (" --total-num-mbufs=N: set the number of mbufs to be allocated " "in mbuf pools.\n" );printf (" --max-pkt-len=N: set the maximum size of packet to N bytes.\n" ); +printf (" --max-lro-pkt-size=N: set the maximum LRO aggregated packet " +"size to N bytes.\n" );#ifdef RTE_LIBRTE_CMDLINE printf (" --eth-peers-configfile=name: config file with ethernet addresses " "of peer ports.\n" );
@@ -592,6 +594,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 }, { "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },
@@ -888,6 +891,10 @@"Invalid max-pkt-len=%d - should be > %d\n" , n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt-size" )) { + n =atoi (optarg); + rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )) {if (!strcmp (optarg,"signature" )) fdir_conf.mode =
app/test-pmd/testpmd.c +1 -0
@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = {struct rte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN , };struct rte_eth_txmode tx_mode = {
doc/guides/testpmd_app_ug/run_app.rst +5 -0
@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The default value is 1518. +* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >= 64. + The default value is 1518. + * ``--eth-peers-configfile=name`` Use a configuration file containing the Ethernet addresses of the peer ports.
doc/guides/testpmd_app_ug/testpmd_funcs.rst +9 -0
@@ -2139,6 +2139,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~
Signature · 1 line
1.8.3.1
Hi Dekel,
Quoted 20 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, November 6, 2019 2:28 PM
To: Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: [PATCH v3 0/3] support API to set max LRO packet size
Quoted 5 lines
This series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
v3: Updated ethdev and testpmd patches per review comments.
My comments on the v2 testpmd patch have not been addressed in the v3 patch.
Quoted 31 lines
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet sizeapp/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 ++++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 + drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 22 files changed, 172 insertions(+), 6 deletions(-)
Quoted 2 lines
--
1.8.3.1
Regards,
Bernard.
Hi Bernard, PSB.
Quoted 45 lines
-----Original Message-----
From: Iremonger, Bernard <[email protected]>
Sent: Wednesday, November 6, 2019 6:41 PM
To: Dekel Peled <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v3 0/3] support API to set max LRO packet sizeHi Dekel,
Quoted 8 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Wednesday, November 6, 2019 2:28 PM
To: Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu,Wenzhuo
Quoted 3 lines
<[email protected]>; Ananyev, Konstantin <[email protected]>; [email protected]; [email protected]; [email protected];
Quoted 9 lines
[email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: [PATCH v3 0/3] support API to set max LRO packet size
Quoted 8 lines
Quoted 5 lines
This series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
v3: Updated ethdev and testpmd patches per review comments.My comments on the v2 testpmd patch have not been addressed in the v3 patch.
I accepted your comment about update of function usage(), and added it in v3. I replied your other comments in v2 reply email, and didn't see additional response.
Regards,
Dekel
Quoted 38 lines
Quoted 32 lines
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet sizeapp/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 ++++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 + drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 22 files changed, 172 insertions(+), 6 deletions(-)Quoted 2 lines
--
1.8.3.1Regards,
Bernard.
v4 cover support API to set max LRO packet size
In reply to Dekel PeledThis series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
v3: Updated ethdev and testpmd patches per review comments.
v4: Updated ethdev patch for QEDE PMD per review comments.
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 ++++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 + drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 22 files changed, 172 insertions(+), 6 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v4 1/3 ethdev: support API to set max LRO packet size
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
--- doc/guides/nics/features.rst | 2 ++ doc/guides/rel_notes/deprecation.rst | 4 --- doc/guides/rel_notes/release_19_11.rst | 8 ++++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++ drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 +++ 15 files changed, 70 insertions(+), 5 deletions(-)
doc/guides/nics/features.rst +2 -0
@@ -193,10 +193,12 @@ LRO Supports Large Receive Offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``. + ``dev_conf.rxmode.max_lro_pkt_size``. * **[implements] datapath**: ``LRO functionality``. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``. .. _nic_features_tso:
doc/guides/rel_notes/deprecation.rst +0 -4
@@ -87,10 +87,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
doc/guides/rel_notes/release_19_11.rst +8 -0
@@ -406,6 +406,14 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header. +* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in + struct ``rte_eth_dev_info`` for the port capability and in struct + ``rte_eth_rxmode`` for the port configuration. + Application should use the new field in struct ``rte_eth_rxmode`` to configure + the requested size. + PMD should use the new field in struct ``rte_eth_dev_info`` to report the + supported port capability. + Shared Library Versions -----------------------
drivers/net/bnxt/bnxt_ethdev.c +1 -0
@@ -519,6 +519,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pkt_size =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ;if (bp->flags &BNXT_FLAG_PTP_SUPPORTED )
drivers/net/hinic/hinic_pmd_ethdev.c +1 -0
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa) info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pkt_size =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;
drivers/net/ixgbe/ixgbe_ethdev.c +2 -0
@@ -3814,6 +3814,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, } dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */ dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =15872 ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ; dev_info->max_vfs = pci_dev->max_vfs;
@@ -3937,6 +3938,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, dev_info->max_tx_queues = (uint16_t )hw->mac.max_tx_queues; dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL reg */ dev_info->max_rx_pktlen =9728 ;/* includes CRC, cf MAXFRS reg */ + dev_info->max_lro_pkt_size =9728 ; dev_info->max_mtu = dev_info->max_rx_pktlen -IXGBE_ETH_OVERHEAD ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ;
drivers/net/ixgbe/ixgbe_vf_representor.c +1 -0
@@ -48,6 +48,7 @@ dev_info->min_rx_bufsize =1024 ;/**< Minimum size of RX buffer. */ dev_info->max_rx_pktlen =9728 ; + dev_info->max_lro_pkt_size =9728 ;/**< Maximum configurable length of RX pkt. */ dev_info->max_rx_queues =IXGBE_VF_MAX_RX_QUEUES ;/**< Maximum number of RX queues. */
drivers/net/mlx5/mlx5.h +3 -0
@@ -203,6 +203,9 @@ struct mlx5_hca_attr {#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */
drivers/net/mlx5/mlx5_ethdev.c +1 -0
@@ -606,6 +606,7 @@ struct ethtool_link_settings {/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pkt_size =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values.
drivers/net/mlx5/mlx5_rxq.c +0 -1
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))
drivers/net/qede/qede_ethdev.c +1 -0
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; + dev_info->max_lro_pkt_size = (uint32_t )0x7FFF ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;
drivers/net/virtio/virtio_ethdev.c +1 -0
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)RTE_MIN (hw->max_queue_pairs,VIRTIO_MAX_TX_QUEUES ); dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pkt_size =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features =VTPCI_OPS (hw)->get_features (hw);
drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -0
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev) dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;
lib/librte_ethdev/rte_ethdev.c +44 -0
62 lines not on this page · raw message
lib/librte_ethdev/rte_ethdev.h +4 -0
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {/** The multi-queue packet distribution mode to be used, e.g. RSS. */ enum rte_eth_rx_mq_mode mq_mode;uint32_t max_rx_pkt_len;/**< Only used if JUMBO_FRAME enabled. */ +/** Maximum allowed size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t split_hdr_size;/**< hdr buf size (header_split enabled).*/ /** * Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1218,6 +1220,8 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 6 lines · Dekel Peled
lib/librte_ethdev/rte_ethdev.c +2
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN ; } +/* +* If LRO is enabled, check that the maximum aggregated packet
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1300
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +10
-0+* size is supported by the configured device. +*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret =check_lro_pkt_size ( + port_id, dev_conf->rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) + goto rollback; + } +
This check forces applications that enable LRO to provide 'max_lro_pkt_size' config value.
- Why it is mandatory now, how it was working before if it is mandatory value?
- What happens if PMD doesn't provide 'max_lro_pkt_size', so it is '0'?
- What do you think setting 'max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Hi
From: Ferruh Yigit
Quoted 6 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Quoted 2 lines
(quoted diff) +0
-0}
Quoted 16 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1300
Quoted 13 lines
lib/librte_ethdev/rte_ethdev.c +12
-0+/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret =check_lro_pkt_size ( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) + goto rollback; + } +This check forces applications that enable LRO to provide '
max_lro_pkt_size' config value.
Yes.(we can break an API, we noticed it)
Quoted 2 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as max_rx_pkt_len which is mandatory for jumbo frame offload.
So now, when the user configures a LRO offload he must to set max lro pkt len.
We don't want to confuse the user here with the max rx pkt len configurations and behaviors, they should be with same logic.
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be the maximum size for LRO aggregated packets. Now, the user must say what is his intension, and the ethdev can limit it according to the device capability. By this way, also, the PMD can organize\optimize its data-path more.
Also, the application can create different mempools for LRO queues to allow bigger packet receiving for LRO traffic.
Quoted 1 line
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is '0'?
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?
Same answers as above.
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 26 lines · Matan Azrad
Hi
From: Ferruh Yigit
Quoted 6 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Quoted 2 lines
(quoted diff) +0
-0}Quoted 16 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1300
Quoted 13 lines
lib/librte_ethdev/rte_ethdev.c +12
-0+/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret =check_lro_pkt_size ( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) + goto rollback; + } +This check forces applications that enable LRO to provide '
max_lro_pkt_size' config value.
Quoted 1 line
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK.
With this check, if the application requested LRO offload but not provided 'max_lro_pkt_size' value, device configuration will fail.
Can there be a case application is good with whatever the PMD can support as max?
Quoted 14 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frame offload.
So now, when the user configures a LRO offload he must to set max lro pkt len.
We don't want to confuse the user here with the max rx pkt len configurations and behaviors, they should be with same logic.This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be the maximum size for LRO aggregated packets. Now, the user must say what is his intension, and the ethdev can limit it according to the device capability. By this way, also, the PMD can organize\optimize its data-path more.
Also, the application can create different mempools for LRO queues to allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 1 line
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is '0'?Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide 'max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really necessary?
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit 'max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
From: Ferruh Yigit
Quoted 25 lines · Matan Azrad
Quoted 24 lines
Hi
From: Ferruh Yigit
Quoted 21 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Quoted 5 lines
lib/librte_ethdev/rte_ethdev.c +3
-0} +/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1300
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +9
-0+*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret =check_lro_pkt_size ( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK.
With this check, if the application requested LRO offload but not provided 'max_lro_pkt_size' value, device configuration will fail.
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be consistent:
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max lro pkt len should be mandatory for LRO offload.
So your question is actually why both, non-lro packets and LRO packets max size are mandatory...
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 20 lines
Quoted 5 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 1 line
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 3 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 1 line
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 2 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is '0'?Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?
There is check.
If the capability is 0, any non-zero configuration will fail.
Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really necessary?
Yes, for consistence.
Quoted 11 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?
Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by the application.
Previous applications have no option to configure it, so they haven't configure it, (probably cover it somehow) I think it is our miss to supply this info.
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 97 lines · Matan Azrad
From: Ferruh Yigit
Quoted 25 lines · Matan Azrad
Quoted 24 lines
Hi
From: Ferruh Yigit
Quoted 21 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Quoted 5 lines
lib/librte_ethdev/rte_ethdev.c +3
-0} +/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1300
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +9
-0+*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret =check_lro_pkt_size ( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK.
With this check, if the application requested LRO offload but not provided 'max_lro_pkt_size' value, device configuration will fail.Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be consistent:
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max lro pkt len should be mandatory for LRO offload.So your question is actually why both, non-lro packets and LRO packets max size are mandatory...
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 20 lines
Quoted 5 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 1 line
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 3 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 1 line
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 2 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is '0'?Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really necessary?
Yes, for consistence.
Quoted 11 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?
Quoted 9 lines
Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by the application.
Previous applications have no option to configure it, so they haven't configure it, (probably cover it somehow) I think it is our miss to supply this info.
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of 'max_rx_pkt_len' does it.
Will it work, if:
- If application doesn't provide this value, use the PMD max
- If both application and PMD doesn't provide this value, fail on configure()?
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
From: Ferruh Yigit
Quoted 116 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 4 lines
lib/librte_ethdev/rte_ethdev.c +2
-0} +/* +* If LRO is enabled, check that the maximum aggregated packet
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 3 lines
lib/librte_ethdev/rte_ethdev.c +3
-0+* size is supported by the configured device. +*/ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 15 lines
Quoted 15 lines
Quoted 10 lines
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1300
Quoted 8 lines
lib/librte_ethdev/rte_ethdev.c +7
-0+ ret =check_lro_pkt_size ( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) + goto rollback; + } +This check forces applications that enable LRO to provide
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
Quoted 8 lines
Quoted 4 lines
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 1 line
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 2 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 53 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 24 lines
Quoted 5 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is '0'?Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really necessary?
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 7 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 2 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD max
May cause a problem if the mbuf size is not enough for the PMD maximum.
Quoted 1 line
- If both application and PMD doesn't provide this value, fail on
configure()?
It will work.
In my opinion - not ideal.
Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 126 lines · Matan Azrad
From: Ferruh Yigit
Quoted 116 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 15 lines
Quoted 15 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
Quoted 8 lines
Quoted 4 lines
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 1 line
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 2 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 53 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 24 lines
Quoted 5 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is '0'?Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really necessary?
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 7 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 2 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.
Quoted 6 lines
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD maximum.
OK, this is what I was missing, for this case I was thinking max_rx_pkt_len will be used but you already explained that application may want to use different mempools for LRO queues.
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ? This part seems missing and should be highlighted to other PMD maintainers.
Quoted 9 lines
Quoted 2 lines
- If both application and PMD doesn't provide this value, fail on
configure()?It will work.
In my opinion - not ideal.Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Thanks, PSB.
Quoted 162 lines
-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Friday, November 8, 2019 2:52 PM
To: Matan Azrad <[email protected]>; Dekel Peled <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet sizeQuoted 87 lines · Matan Azrad
From: Ferruh Yigit
Quoted 84 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 31 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 26 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 2 lines
Quoted 2 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 33 lines
Quoted 26 lines
Quoted 11 lines
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 8 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.Quoted 6 lines
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD maximum.
Quoted 9 lines
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMD maintainers.
All relevant PMDs were modified and maintainers are copied on this patch series.
Quoted 10 lines
Quoted 2 lines
Quoted 2 lines
- If both application and PMD doesn't provide this value, fail on
configure()?Quoted 7 lines
It will work.
In my opinion - not ideal.Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 168 lines · Dekel Peled
Thanks, PSB.
Quoted 166 lines
-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Friday, November 8, 2019 2:52 PM
To: Matan Azrad <[email protected]>; Dekel Peled <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet sizeQuoted 87 lines · Matan Azrad
From: Ferruh Yigit
Quoted 84 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 31 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 26 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 2 lines
Quoted 2 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 33 lines
Quoted 26 lines
Quoted 11 lines
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 8 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.Quoted 6 lines
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD maximum.
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.
Quoted 8 lines
Quoted 5 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMD maintainers.All relevant PMDs were modified and maintainers are copied on this patch series.
What modified is PMD announcing a 'dev_info->max_lro_pkt_size' value, which is good.
But PMDs are not using user provided 'rxmode.max_lro_pkt_size' value, I assume they are still using 'max_rx_pkt_len' to configure the device.
+1 to cc'ing maintainers, but everyone not able to follow all patches and not sure if every maintainer read the patch and recognized they should update their driver. I think better to highlight this things in cover letter / emails etc. I hope it is more clear now.
Not for this patch, but generally;
As a process, previously I proposed a keeping a todo list under documentation for PMDs for these kind of things, that each PMD maintainer can go there to figure out what kind of changes required because of others changes, but that didn't go in.
Other option is whoever updating library update all PMDs fully, but based on feature it can be very hard to update others PMDs.
Overall these gaps are causing inconsistencies between PMDs and we need a proper solution.
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
In reply to Ferruh YigitHi
From: Ferruh Yigit
Quoted 137 lines · Matan Azrad
Quoted 87 lines
From: Ferruh Yigit
Quoted 84 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 31 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 26 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 2 lines
Quoted 2 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 35 lines
Quoted 26 lines
Quoted 11 lines
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 8 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD maximum.
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.
So , are you agree with the idea?
Quoted 4 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMD maintainers.
Yes, you are right.
PMDs must limit the LRO aggregated packet according to the new field,
And it probably very hard for the patch introducer to understand how to do it for each PMD.
I think each new configuration requires other maintainers\developers to adjust their own PMD code to the new configuration and it should be done in limited time.
My suggestion here:
1. To reserve the info field and the configuration field for rc2.(if it is critical not to break ABI for rc3)
2. To merge the ethdev patch in the start of rc3.
3. Request each relevant PMD to adjust its PMD to the new configuration for the end of rc3.
Note: this should be small change and only for ~5 PMDs:
a. Introduce the info field according to the device ability.
b. For each LRO queue:
Use the LRO max size configuration instead of the current max rx pkt len configuration(looks like small condition).
What do you think?
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 165 lines
From: Ferruh Yigit
Quoted 137 lines · Matan Azrad
Quoted 87 lines
From: Ferruh Yigit
Quoted 84 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 31 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 26 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 2 lines
Quoted 2 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 35 lines
Quoted 26 lines
Quoted 11 lines
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 8 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD maximum.
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.So , are you agree with the idea?
Quoted 4 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMD maintainers.Yes, you are right.
PMDs must limit the LRO aggregated packet according to the new field,
And it probably very hard for the patch introducer to understand how to do it for each PMD.I think each new configuration requires other maintainers\developers to adjust their own PMD code to the new configuration and it should be done in limited time.
Quoted 8 lines
My suggestion here:
1. To reserve the info field and the configuration field for rc2.(if it is critical not to break ABI for rc3)
2. To merge the ethdev patch in the start of rc3.
3. Request each relevant PMD to adjust its PMD to the new configuration for the end of rc3.
Note: this should be small change and only for ~5 PMDs:
a. Introduce the info field according to the device ability.
b. For each LRO queue:
Use the LRO max size configuration instead of the current max rx pkt len configuration(looks like small condition).
That's definitely looks like a significant behavior change for existing apps and PMDs, and I wonder what for?
Why we can't keep max_rx_pkt_len semantics as it is right now,
and just add an optional ability to limit max size of LRO aggregations?
Quoted 5 lines
What do you think?
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
From: Ananyev, Konstantin
Quoted 179 lines
Quoted 62 lines
From: Ferruh Yigit
Quoted 60 lines · Matan Azrad
Quoted 59 lines
From: Ferruh Yigit
Quoted 56 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 3 lines
I think it should be important values for net applications
management.
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Also good for mbuf size managements.
Quoted 13 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
This parameter defines well the LRO behavior. Before this, each PMD took its own interpretation to what should be the
maximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 1 line
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 31 lines
Quoted 31 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 3 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Yes, for consistence.
Quoted 11 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 2 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 11 lines
Quoted 5 lines
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.So , are you agree with the idea?
Quoted 4 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMDmaintainers.
Quoted 5 lines
Yes, you are right.
PMDs must limit the LRO aggregated packet according to the new field, And it probably very hard for the patch introducer to understand how to doit for each PMD.
Quoted 3 lines
I think each new configuration requires other maintainers\developers to adjust their own PMD code to the new configuration and it should be
done in limited time.
Quoted 4 lines
My suggestion here:
1. To reserve the info field and the configuration field for rc2.(if it is critical not to break ABI for rc3) 2. To merge the ethdev patch in thestart of rc3.
Quoted 1 line
3. Request each relevant PMD to adjust its PMD to the new configuration
for the end of rc3.
Quoted 8 lines
Quoted 4 lines
Note: this should be small change and only for ~5 PMDs:
a. Introduce the info field according to the device ability. b. For each LRO queue:
Use the LRO max size configuration instead of thecurrent max rx pkt len configuration(looks like small condition).
That's definitely looks like a significant behavior change for existing apps and PMDs, and I wonder what for?
There was a miss in configuration:
It doesn't make sense to limit non-lro queues with the same packets length of lro queues:
Naturally, LRO packets are bigger significantly(because of the HW aggregation), hence,
the user may use bigger mbufs for the LRO packets, so potentially, it is better to separate mempool, one for the LRO queues with big mbufs and the second for the non-LRO queues with smaller mbufs (to optimize the memory usage). Since the user may want tail-room in the LRO mbuf it may limit the LRO packet size to smaller number than the mbuf (- HEADROOM) and for this reason as same as the usage of the regular field (max_rx_pkt_len) a new field should be set for LRO queues.
Quoted 2 lines
Why we can't keep
max_rx_pkt_lensemantics as it is right now, and just add an optional ability to limit max size of LRO aggregations?
What is the semantic of max_rx_pkt_len regards LRO packets? It is not clear from the documentation.
So this patch defines it well:
Non-LRO queues should be limited to max_rx_pkt_len. LRO queues should be limited to max_lro_pkt_len.
The consistence in the ways of the configuration for RX packet length should be the same. max_rx_pkt_len is mandatory for JUMBO offload => max_lro_pkt_len is mandatory for LRO offload.
Current applications uses LRO just need to configure the field same as current max_rx_pkt_len if they want to stay with the same behavior - really not a big change. If the application want to improve their memory usage as I said above, the new fields allow it as well.
Quoted 4 lines
Quoted 4 lines
What do you think?
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 216 lines
-----Original Message-----
From: Matan Azrad <[email protected]>
Sent: Monday, November 11, 2019 8:01 AM
To: Ananyev, Konstantin <[email protected]>; Yigit, Ferruh <[email protected]>; Dekel Peled <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet sizeFrom: Ananyev, Konstantin
Quoted 179 lines
Quoted 62 lines
From: Ferruh Yigit
Quoted 60 lines · Matan Azrad
Quoted 59 lines
From: Ferruh Yigit
Quoted 56 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 3 lines
I think it should be important values for net applications
management.
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Also good for mbuf size managements.
Quoted 13 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
This parameter defines well the LRO behavior. Before this, each PMD took its own interpretation to what should be the
maximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 1 line
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 31 lines
Quoted 31 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 3 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Yes, for consistence.
Quoted 11 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 2 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 11 lines
Quoted 5 lines
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.So , are you agree with the idea?
Quoted 4 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMDmaintainers.
Quoted 5 lines
Yes, you are right.
PMDs must limit the LRO aggregated packet according to the new field, And it probably very hard for the patch introducer to understand how to doit for each PMD.
Quoted 3 lines
I think each new configuration requires other maintainers\developers to adjust their own PMD code to the new configuration and it should be
done in limited time.
Quoted 4 lines
My suggestion here:
1. To reserve the info field and the configuration field for rc2.(if it is critical not to break ABI for rc3) 2. To merge the ethdev patch in thestart of rc3.
Quoted 1 line
3. Request each relevant PMD to adjust its PMD to the new configuration
for the end of rc3.
Quoted 8 lines
Quoted 4 lines
Note: this should be small change and only for ~5 PMDs:
a. Introduce the info field according to the device ability. b. For each LRO queue:
Use the LRO max size configuration instead of thecurrent max rx pkt len configuration(looks like small condition).
That's definitely looks like a significant behavior change for existing apps and PMDs, and I wonder what for?
There was a miss in configuration:
It doesn't make sense to limit non-lro queues with the same packets length of lro queues:
Naturally, LRO packets are bigger significantly(because of the HW aggregation), hence,
the user may use bigger mbufs for the LRO packets, so potentially, it is better to separate mempool, one for the LRO queues with
big mbufs and the second for the non-LRO queues with smaller mbufs (to optimize the memory usage).
Since the user may want tail-room in the LRO mbuf it may limit the LRO packet size to smaller number than the mbuf (-
HEADROOM) and for this reason as same as the usage of the regular field (max_rx_pkt_len) a new field should be set for LRO queues.
Quoted 4 lines
Quoted 2 lines
Why we can't keep
max_rx_pkt_lensemantics as it is right now, and just add an optional ability to limit max size of LRO aggregations?What is the semantic of
max_rx_pkt_lenregards LRO packets? It is not clear from the documentation.
That's probably where misunderstanding starts.
For me:max_rx_pkt_len is the maximum size of the ethernet packet the NIC will accept (doesn't matter LRO enabled or not).
Now if LRO is enabled NIC can accumulate multiple 'physical' packets into one big 'virtual' one.
So when LRO is enabled max_lro_size limits how big these accumulated 'virtual' packets can be.
While max_rx_pkt_len still limits max ethernet packet size NIC will accept.
In what you suggest it is not clear to me what will be max_lro_size semantics. Would it be maximum size of the ethernet packet the NIC will accept (equivalent of max_rx_pkt_len) or would it be accumulated 'virtual' packet size limit?
Or might be something else?
Quoted 14 lines
So this patch defines it well:
Non-LRO queues should be limited tomax_rx_pkt_len. LRO queues should be limited tomax_lro_pkt_len.The consistence in the ways of the configuration for RX packet length should be the same.
max_rx_pkt_lenis mandatory for JUMBO offload =>max_lro_pkt_lenis mandatory for LRO offload.Current applications uses LRO just need to configure the field same as current
max_rx_pkt_lenif they want to stay with the same behavior - really not a big change.
If the application want to improve their memory usage as I said above, the new fields allow it as well.Quoted 1 line
Quoted 1 line
What do you think?
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
In reply to Matan AzradQuoted 157 lines · Matan Azrad
Hi
From: Ferruh Yigit
Quoted 137 lines · Matan Azrad
Quoted 87 lines
From: Ferruh Yigit
Quoted 84 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 31 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 26 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 2 lines
Quoted 2 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 35 lines
Quoted 26 lines
Quoted 11 lines
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 8 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD maximum.
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.So , are you agree with the idea?
Quoted 4 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMD maintainers.
Quoted 5 lines
Yes, you are right.
PMDs must limit the LRO aggregated packet according to the new field,
And it probably very hard for the patch introducer to understand how to do it for each PMD.I think each new configuration requires other maintainers\developers to adjust their own PMD code to the new configuration and it should be done in limited time.
Agree.
But experience showed that this synchronization is not as easy as it sounds, whoever changing the interface/library says other PMDs should reflect the change but most of the times other PMD maintainers not aware of it or if they do they have other priorities for the release, so the changes should be in a way to give more time to PMDs to adapt it and during this time library change shouldn't break other PMDs.
Quoted 11 lines
My suggestion here:
1. To reserve the info field and the configuration field for rc2.(if it is critical not to break ABI for rc3)
2. To merge the ethdev patch in the start of rc3.
3. Request each relevant PMD to adjust its PMD to the new configuration for the end of rc3.
Note: this should be small change and only for ~5 PMDs:
a. Introduce the info field according to the device ability.
b. For each LRO queue:
Use the LRO max size configuration instead of the current max rx pkt len configuration(looks like small condition).What do you think?
There is already a v6 which only updates dev_info fields to have the 'max_lro_pktlen' field, the PMD updates there also looks safe, so I think we can go with it for rc2.
For the configuration part, I suggest deferring it next release, which gives more time for discussion and enough time for other PMDs to implement it.
And related configuration, right now devices already configured to limit the packet size to 'max_rx_pkt_len', it can be an optimization to increase it to 'max_lro_pkt_len' for the queues LRO is supported, why not make this configuration more explicitly with specific API as Konstantin suggested [1], this way it only affects the applications that are interested in and the PMDs that want to support this.
Current implementation is under 'rte_eth_dev_configure()' which is used by all DPDK applications and impact of changing it is much larger, also it makes mandatory for applications to provide this config option when LRO enabled, explicit API gives same result without making a mandatory config option.
[1]
int rte_eth_dev_set_max_lro(uint16_t port_id, uint32_t lro);
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
From: Ferruh Yigit
Quoted 173 lines · Matan Azrad
Quoted 86 lines
Hi
From: Ferruh Yigit
Quoted 83 lines · Matan Azrad
Quoted 82 lines
From: Ferruh Yigit
Quoted 79 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 26 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 21 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 1 line
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 30 lines
Quoted 30 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Yes, for consistence.
Quoted 11 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 2 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 11 lines
Quoted 5 lines
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.So , are you agree with the idea?
Quoted 4 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMDmaintainers.
Quoted 5 lines
Yes, you are right.
PMDs must limit the LRO aggregated packet according to the new field, And it probably very hard for the patch introducer to understand how to doit for each PMD.
Quoted 2 lines
I think each new configuration requires other maintainers\developers to
adjust their own PMD code to the new configuration and it should be done in limited time.
Quoted 8 lines
Agree.
But experience showed that this synchronization is not as easy as it sounds, whoever changing the interface/library says other PMDs should reflect the change but most of the times other PMD maintainers not aware of it or if they do they have other priorities for the release, so the changes should be in a way to give more time to PMDs to adapt it and during this time library change shouldn't break other PMDs.
Yes.
Quoted 10 lines
Quoted 3 lines
My suggestion here:
1. To reserve the info field and the configuration field for rc2.(if it is critical not to break ABI for rc3) 2. To merge the ethdev patch in thestart of rc3.
Quoted 1 line
3. Request each relevant PMD to adjust its PMD to the new configuration
for the end of rc3.
Quoted 4 lines
Note: this should be small change and only for ~5 PMDs:
a. Introduce the info field according to the device ability. b. For each LRO queue:
Use the LRO max size configuration instead of the
Quoted 8 lines
current max rx pkt len configuration(looks like small condition).
Quoted 2 lines
What do you think?
There is already a v6 which only updates
dev_infofields to have the 'max_lro_pktlen' field, the PMD updates there also looks safe, so I think we can go with it for rc2.
Doesn’t make sense to expose the info field without the configuration.
Quoted 15 lines
For the configuration part, I suggest deferring it next release, which gives more time for discussion and enough time for other PMDs to implement it.
And related configuration, right now devices already configured to limit the packet size to '
max_rx_pkt_len', it can be an optimization to increase it to 'max_lro_pkt_len' for the queues LRO is supported, why not make this configuration more explicitly with specific API as Konstantin suggested [1], this way it only affects the applications that are interested in and the PMDs that want to support this.
Current implementation is under 'rte_eth_dev_configure()' which is used by all DPDK applications and impact of changing it is much larger, also it makes mandatory for applications to provide this config option when LRO enabled, explicit API gives same result without making a mandatory config option.
Quoted 2 lines
[1]
intrte_eth_dev_set_max_lro(uint16_t port_id, uint32_t lro);
Please see my answers to Konstantin regarding this topic.
One more option:
In order to not break PMDs because of this feature:
0 in the capability field means, The PMD doesn't support LRO special limitation so if the application configuration is not the same like max_rx_pkt_len the validation will fail.
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 227 lines · Matan Azrad
From: Ferruh Yigit
Quoted 173 lines · Matan Azrad
Quoted 86 lines
Hi
From: Ferruh Yigit
Quoted 83 lines · Matan Azrad
Quoted 82 lines
From: Ferruh Yigit
Quoted 79 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 26 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 21 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 1 line
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 30 lines
Quoted 30 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Yes, for consistence.
Quoted 11 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 2 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 11 lines
Quoted 5 lines
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.So , are you agree with the idea?
Quoted 4 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled case) ?
This part seems missing and should be highlighted to other PMDmaintainers.
Quoted 5 lines
Yes, you are right.
PMDs must limit the LRO aggregated packet according to the new field, And it probably very hard for the patch introducer to understand how to doit for each PMD.
Quoted 2 lines
I think each new configuration requires other maintainers\developers to
adjust their own PMD code to the new configuration and it should be done in limited time.
Quoted 8 lines
Agree.
But experience showed that this synchronization is not as easy as it sounds, whoever changing the interface/library says other PMDs should reflect the change but most of the times other PMD maintainers not aware of it or if they do they have other priorities for the release, so the changes should be in a way to give more time to PMDs to adapt it and during this time library change shouldn't break other PMDs.Yes.
Quoted 10 lines
Quoted 3 lines
My suggestion here:
1. To reserve the info field and the configuration field for rc2.(if it is critical not to break ABI for rc3) 2. To merge the ethdev patch in thestart of rc3.
Quoted 1 line
3. Request each relevant PMD to adjust its PMD to the new configuration
for the end of rc3.
Quoted 4 lines
Note: this should be small change and only for ~5 PMDs:
a. Introduce the info field according to the device ability. b. For each LRO queue:
Use the LRO max size configuration instead of theQuoted 8 lines
current max rx pkt len configuration(looks like small condition).
Quoted 2 lines
What do you think?
There is already a v6 which only updates
dev_infofields to have the 'max_lro_pktlen' field, the PMD updates there also looks safe, so I think we can go with it for rc2.Doesn’t make sense to expose the info field without the configuration.
Quoted 15 lines
For the configuration part, I suggest deferring it next release, which gives more time for discussion and enough time for other PMDs to implement it.
And related configuration, right now devices already configured to limit the packet size to '
max_rx_pkt_len', it can be an optimization to increase it to 'max_lro_pkt_len' for the queues LRO is supported, why not make this configuration more explicitly with specific API as Konstantin suggested [1], this way it only affects the applications that are interested in and the PMDs that want to support this.
Current implementation is under 'rte_eth_dev_configure()' which is used by all DPDK applications and impact of changing it is much larger, also it makes mandatory for applications to provide this config option when LRO enabled, explicit API gives same result without making a mandatory config option.Quoted 2 lines
[1]
intrte_eth_dev_set_max_lro(uint16_t port_id, uint32_t lro);
Quoted 8 lines
Please see my answers to Konstantin regarding this topic.
One more option:
In order to not break PMDs because of this feature:
0 in the capability field means, The PMD doesn't support LRO special limitation so if the application configuration is not the same likemax_rx_pkt_lenthe validation will fail.
I don't see this is a mandatory field if the LRO is enabled, am I missing something? And current implementation does so by failing configure(), the affect to the applications is my first concern.
Second is when application supplied the proper values but PMD is not doing anything without letting application anything done.
That is why I think explicit API makes this clear and only required by application wants to use it.
Similar can be done with following, this also doesn't require both application and PMD changes, wdyt?
ethdev, configure():
if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_TCP_LRO) {
if (dev_conf->rxmode.max_lro_pktlen) {
if (dev_info.max_lro_pktlen) {
validate(rxmode.max_lro_pktlen, dev_info.max_lro_pktlen)
} else if (dev_info.max_rx_pktlen)
validate(rxmode.max_lro_pktlen, dev_info.max_rx_pktlen)
} }
}
in PMD:
if (LRO) {
queue.max_pktlen = rxmode.max_lro_pktlen ?
rxmode.max_lro_pktlen :
rxmode.max_tx_pktlen;
}Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
From: Ferruh Yigit
Quoted 247 lines · Matan Azrad
Quoted 19 lines
From: Ferruh Yigit
Quoted 16 lines · Matan Azrad
Quoted 15 lines
Hi
From: Ferruh Yigit
Quoted 12 lines · Matan Azrad
Quoted 11 lines
From: Ferruh Yigit
Quoted 8 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximumaggregated
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
packet
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration willfail.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 3 lines
I think it should be important values for net applications
management.
Quoted 139 lines
Quoted 114 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Also good for mbuf size managements.
Quoted 13 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
This parameter defines well the LRO behavior. Before this, each PMD took its own interpretation to what should be the
maximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 1 line
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 33 lines
Quoted 33 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 3 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 21 lines
Quoted 21 lines
Quoted 11 lines
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 8 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 1 line
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
It is mandatory only if LRO offload is configured.
Quoted 2 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 12 lines
Quoted 5 lines
OK, this is what I was missing, for this case I was thinking
max_rx_pkt_lenwill be used but you already explained that application may want to use different mempools for LRO queues.So , are you agree with the idea?
Quoted 5 lines
For this case shouldn't PMDs take the 'rxmode.max_lro_pkt_size' into account and program the device accordingly (of course in LRO enabled
case) ?
This part seems missing and should be highlighted to other PMDmaintainers.
Quoted 6 lines
Yes, you are right.
PMDs must limit the LRO aggregated packet according to the new field, And it probably very hard for the patch introducer to understand how to doit for each PMD.
Quoted 3 lines
I think each new configuration requires other maintainers\developers to
adjust their own PMD code to the new configuration and it should be done in limited time.
Quoted 8 lines
Agree.
But experience showed that this synchronization is not as easy as it sounds, whoever changing the interface/library says other PMDs should reflect the change but most of the times other PMD maintainers not aware of it or if they do they have other priorities for the release, so the changes should be in a way to give more time to PMDs to adapt it and during this time library change shouldn't break other PMDs.Yes.
Quoted 14 lines
Quoted 4 lines
My suggestion here:
1. To reserve the info field and the configuration field for rc2.(if it is critical not to break ABI for rc3) 2. To merge the ethdev patch in thestart of rc3.
Quoted 2 lines
3. Request each relevant PMD to adjust its PMD to the new configuration
for the end of rc3.
Quoted 4 lines
Note: this should be small change and only for ~5 PMDs:
a. Introduce the info field according to the device ability. b. For each LRO queue:
Use the LRO max size configuration instead of thecurrent max rx pkt len configuration(looks like small condition).
Quoted 1 line
Quoted 12 lines
Quoted 6 lines
Quoted 1 line
What do you think?
There is already a v6 which only updates
dev_infofields to have the 'max_lro_pktlen' field, the PMD updates there also looks safe, so I think we can go with it for rc2.Doesn’t make sense to expose the info field without the configuration.
Quoted 2 lines
For the configuration part, I suggest deferring it next release, which gives more time for discussion and enough time for other PMDs to
implement it.
Quoted 12 lines
Quoted 12 lines
And related configuration, right now devices already configured to limit the packet size to '
max_rx_pkt_len', it can be an optimization to increase it to 'max_lro_pkt_len' for the queues LRO is supported, why not make this configuration more explicitly with specific API as Konstantin suggested [1], this way it only affects the applications that are interested in and the PMDs that want to support this. Current implementation is under 'rte_eth_dev_configure()' which is used by all DPDK applications and impact of changing it is much larger, also it makes mandatory for applications to provide this config option when LRO enabled, explicit API gives same result withoutmaking a mandatory config option.
Quoted 11 lines
Quoted 3 lines
[1]
intrte_eth_dev_set_max_lro(uint16_t port_id, uint32_t lro);Please see my answers to Konstantin regarding this topic.
One more option:
In order to not break PMDs because of this feature:
0 in the capability field means, The PMD doesn't support LRO special
Quoted 6 lines
limitation so if the application configuration is not the same like
max_rx_pkt_lenthe validation will fail.Quoted 1 line
I don't see this is a mandatory field if the LRO is enabled, am I missing something?
From the application size, this is mandatory, you right exactly like max_rx_pkt_len.
Quoted 2 lines
And current implementation does so by failing
configure(), the affect to the applications is my first concern.
This is a small effect as any API change.
If an exists application wants to save its current LRO behavior, it just need to put max_lro_pkt_len=max_rx_pkt_len. Do you think this is a big change? Why?
Quoted 3 lines
Second is when application supplied the proper values but PMD is not doing anything without letting application anything done.
PMD which doesn't change its info to value != 0, as I said, means that it doesn't support LRO queues special limited size.
When the PMD maintainers have time to support the feature, they just need to change the info value to be !=0 and to take into account the max_lro_pkt_len in configuration.
Quoted 2 lines
That is why I think explicit API makes this clear and only required by application wants to use it.
I think that exposing a new function API is not good because it introduce a different way to limit the Rx packet size.
For regular packet - configure it in the configuration struct. For LRO packets - use a function to do it.
It is very confusing and not intuitive from the user side.
Why not to save convention and consistent, somax_rx_pkt_len is mandatory (for JUMBO offload) and in the config structure Also the new lro conf is mandatory (for LRO offload) and in the configuration structure.
So, all the configurations to limit the Rx packet size are in the same place and done by the same way.
Quoted 15 lines
Similar can be done with following, this also doesn't require both application and PMD changes, wdyt?
ethdev,
configure():
if (dev_conf->rxmode.offloads&DEV_RX_OFFLOAD_TCP_LRO) {if (dev_conf->rxmode.max_lro_pktlen) { if (dev_info.max_lro_pktlen) { validate(rxmode.max_lro_pktlen, dev_info.max_lro_pktlen) } else if (dev_info.max_rx_pktlen) validate(rxmode.max_lro_pktlen, dev_info.max_rx_pktlen) }}
}
Quoted 6 lines
in PMD:
if (LRO) { queue.max_pktlen = rxmode.max_lro_pktlen ? rxmode.max_lro_pktlen : rxmode.max_tx_pktlen; }
Again, my only concern here is the consistency of Rx packet size limitation mandatory for LRO and non-LRO.
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
In reply to Matan AzradQuoted 135 lines
-----Original Message-----
From: Matan Azrad <[email protected]>
Sent: Friday, November 8, 2019 11:56 AM
To: Yigit, Ferruh <[email protected]>; Dekel Peled <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet sizeFrom: Ferruh Yigit
Quoted 116 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 15 lines
Quoted 15 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
Quoted 8 lines
Quoted 4 lines
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 1 line
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 2 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 53 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 24 lines
Quoted 5 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is '0'?Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really necessary?
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 7 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 2 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
So max_rx_pkt_len will remain max size of one packet, while max_lro_len will be max accumulate size for each LRO session?
BTW, I think that for ixgbe max lro is RTE_IPV4_MAX_PKT_LEN. ixgbe_vf, as I remember, doesn’t support LRO at all.
Quoted 5 lines
Quoted 3 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD maximum.
Another question, what will happen if PMD will ignore that value and will generate packets bigger then requested?
Quoted 8 lines
Quoted 2 lines
- If both application and PMD doesn't provide this value, fail on
configure()?It will work.
In my opinion - not ideal.Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Thanks, PSB.
Quoted 178 lines
-----Original Message-----
From: Ananyev, Konstantin <[email protected]>
Sent: Friday, November 8, 2019 3:11 PM
To: Matan Azrad <[email protected]>; Yigit, Ferruh <[email protected]>; Dekel Peled <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet sizeQuoted 6 lines
-----Original Message-----
From: Matan Azrad <[email protected]>
Sent: Friday, November 8, 2019 11:56 AM
To: Yigit, Ferruh <[email protected]>; Dekel Peled <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>;Quoted 3 lines
[email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu,
Wenzhuo
Quoted 2 lines
<[email protected]>; Ananyev, Konstantin
<[email protected]>; Shahaf ShulerQuoted 12 lines
Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet sizeQuoted 85 lines
From: Ferruh Yigit
Quoted 84 lines · Matan Azrad
Quoted 7 lines
From: Ferruh Yigit
Quoted 4 lines · Matan Azrad
Quoted 3 lines
Hi
From: Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 31 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 26 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 2 lines
Quoted 2 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 30 lines
Quoted 30 lines
Quoted 11 lines
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 8 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 4 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
So
max_rx_pkt_lenwill remain max size of one packet, whilemax_lro_lenwill be max accumulate size for each LRO session?
Yes.
Quoted 1 line
BTW, I think that for ixgbe max lro is
RTE_IPV4_MAX_PKT_LEN.
Please see my change in drivers/net/ixgbe/ixgbe_ethdev.c. Change to RTE_IPV4_MAX_PKT_LEN?
Quoted 1 line
ixgbe_vf, as I remember, doesn’t support LRO at all.
Please see my change in drivers/net/ixgbe/ixgbe_vf_representor.c Remove it?
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD maximum.
Another question, what will happen if PMD will ignore that value and will generate packets bigger then requested?
PMD should use this value and not ignore it.
Quoted 10 lines
Quoted 3 lines
Quoted 3 lines
- If both application and PMD doesn't provide this value, fail on
configure()?Quoted 6 lines
It will work.
In my opinion - not ideal.Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 134 lines
Quoted 121 lines
Quoted 70 lines
Quoted 70 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximum aggregatedpacket
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 9 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration will fail.Quoted 5 lines
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 24 lines
I think it should be important values for net applications management. Also good for mbuf size managements.
Quoted 19 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 1 line
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior.
Before this, each PMD took its own interpretation to what should be themaximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
according to the device capability.
Quoted 3 lines
By this way, also, the PMD can organize\optimize its data-path more. Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 2 lines
Quoted 2 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0 value.
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 2 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 30 lines
Quoted 30 lines
Quoted 11 lines
Yes, for consistence.
Quoted 8 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
Quoted 8 lines
Quoted 3 lines
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 4 lines
Let's do it in same way as we do max rx pkt len (as this patch main idea). Later, we can change both to other meaning.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
So
max_rx_pkt_lenwill remain max size of one packet, whilemax_lro_lenwill be max accumulate size for each LRO session?Yes.
Quoted 1 line
BTW, I think that for ixgbe max lro is
RTE_IPV4_MAX_PKT_LEN.
Quoted 7 lines
Please see my change in
drivers/net/ixgbe/ixgbe_ethdev.c. Change toRTE_IPV4_MAX_PKT_LEN?Quoted 1 line
ixgbe_vf, as I remember, doesn’t support LRO at all.Please see my change in
drivers/net/ixgbe/ixgbe_vf_representor.cRemove it?
Yes, please for both.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Will it work, if:
- If application doesn't provide this value, use the PMD max
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
May cause a problem if the mbuf size is not enough for the PMD maximum.
Another question, what will happen if PMD will ignore that value and will generate packets bigger then requested?
PMD should use this value and not ignore it.
Hmm, ok but this patch updates mxl driver only...
I suppose you expect other PMD maintainers to do the job for their PMDs, right? If so, are they aware (and agree) for this new hard requirement and changes required? Again what PMD should do if it can't support exact value?
Let say user asked max_lro_size=20KB but PMD can do only 16KB or 24KB? Should it fail, or round to smallest, or ...?
Actually I wonder, should it really be a hard requirement or more like a guidance to PMD? Why app needs and *exact* value for LRO size?
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
Quoted 3 lines
- If both application and PMD doesn't provide this value, fail on
configure()?Quoted 6 lines
It will work.
In my opinion - not ideal.Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Thanks, PSB.
Quoted 167 lines
-----Original Message-----
From: Ananyev, Konstantin <[email protected]>
Sent: Friday, November 8, 2019 4:53 PM
To: Dekel Peled <[email protected]>; Matan Azrad <[email protected]>; Yigit, Ferruh <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet sizeQuoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximumaggregated
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
packet
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration willfail.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 3 lines
I think it should be important values for net applications
management.
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Also good for mbuf size managements.
Quoted 14 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 2 lines
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
This parameter defines well the LRO behavior. Before this, each PMD took its own interpretation to what should be the
maximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 1 line
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 31 lines
Quoted 31 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 3 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Yes, for consistence.
Quoted 11 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 2 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 19 lines
Quoted 11 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
So
max_rx_pkt_lenwill remain max size of one packet, whilemax_lro_lenwill be max accumulate size for each LRO session?Yes.
Quoted 1 line
BTW, I think that for ixgbe max lro is
RTE_IPV4_MAX_PKT_LEN.Please see my change in
drivers/net/ixgbe/ixgbe_ethdev.c. Change toRTE_IPV4_MAX_PKT_LEN?
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
ixgbe_vf, as I remember, doesn’t support LRO at all.Please see my change in
drivers/net/ixgbe/ixgbe_vf_representor.cRemove it?Yes, please for both.
Will change in v5.
Quoted 24 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 5 lines
Quoted 3 lines
Another question, what will happen if PMD will ignore that value and will generate packets bigger then requested?
PMD should use this value and not ignore it.
Hmm, ok but this patch updates mxl driver only...
I suppose you expect other PMD maintainers to do the job for their PMDs, right?
If so, are they aware (and agree) for this new hard requirement and changes required?
Again what PMD should do if it can't support exact value?
Let say user asked max_lro_size=20KB but PMD can do only 16KB or 24KB? Should it fail, or round to smallest, or ...?
Quoted 3 lines
Actually I wonder, should it really be a hard requirement or more like a guidance to PMD?
Why app needs and *exact* value for LRO size?
The exact value should be configured to HW as LRO session limit.
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 6 lines
Quoted 6 lines
- If both application and PMD doesn't provide this value, fail on
configure()?Quoted 6 lines
It will work.
In my opinion - not ideal.Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Quoted 181 lines
Quoted 148 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximumaggregated
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
packet
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to provide
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
'
max_lro_pkt_size'Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration willfail.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 3 lines
I think it should be important values for net applications
management.
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Also good for mbuf size managements.
Quoted 14 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 2 lines
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
This parameter defines well the LRO behavior. Before this, each PMD took its own interpretation to what should be the
maximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 1 line
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide '
max_lro_pkt_size', so it is'0'?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 31 lines
Quoted 31 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 3 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Yes, for consistence.
Quoted 11 lines
Quoted 7 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provide it?Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD instead of failing?Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 2 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 19 lines
Quoted 11 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
So
max_rx_pkt_lenwill remain max size of one packet, whilemax_lro_lenwill be max accumulate size for each LRO session?Yes.
Quoted 1 line
BTW, I think that for ixgbe max lro is
RTE_IPV4_MAX_PKT_LEN.Please see my change in
drivers/net/ixgbe/ixgbe_ethdev.c. Change toRTE_IPV4_MAX_PKT_LEN?Quoted 6 lines
Quoted 4 lines
Quoted 1 line
ixgbe_vf, as I remember, doesn’t support LRO at all.Please see my change in
drivers/net/ixgbe/ixgbe_vf_representor.cRemove it?Yes, please for both.
Will change in v5.
Quoted 24 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 5 lines
Quoted 3 lines
Another question, what will happen if PMD will ignore that value and will generate packets bigger then requested?
PMD should use this value and not ignore it.
Hmm, ok but this patch updates mxl driver only...
I suppose you expect other PMD maintainers to do the job for their PMDs, right?
If so, are they aware (and agree) for this new hard requirement and changes required?
Again what PMD should do if it can't support exact value?
Let say user asked max_lro_size=20KB but PMD can do only 16KB or 24KB? Should it fail, or round to smallest, or ...?
Quoted 5 lines
Quoted 3 lines
Actually I wonder, should it really be a hard requirement or more like a guidance to PMD?
Why app needs and *exact* value for LRO size?The exact value should be configured to HW as LRO session limit.
But if the HW can't support this exact value, see the example above? In fact, shouldn't we allow PMD to forbid user to configure max LRO size? Let say if in dev_info max_lro_size==0, then PMD doesn't support LRO size configuration at all.
That way PMDs who do support LRO, but don't want to (can't to) support configurable LRO size will stay untouched.
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 7 lines
Quoted 7 lines
- If both application and PMD doesn't provide this value, fail on
configure()?Quoted 6 lines
It will work.
In my opinion - not ideal.Matan
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Hi Konstantin
From: Ananyev, Konstantin
Quoted 212 lines
Sent: Friday, November 8, 2019 6:29 PM
To: Dekel Peled <[email protected]>; Matan Azrad <[email protected]>; Yigit, Ferruh <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet sizeQuoted 105 lines
Quoted 105 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines · Dekel Peled
Review struct rte_eth_dev * · line 1286
Quoted 2 lines
(quoted diff) +0
-0@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN;Review struct rte_eth_dev * · line 1290
Quoted 4 lines
(quoted diff) +2
-0} + /* + * If LRO is enabled, check that the maximumaggregated
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
packet
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Review struct rte_eth_dev * · line 1293
Quoted 3 lines
(quoted diff) +3
-0+ * size is supported by the configured device. + */ + if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Quoted 11 lines
Review struct rte_eth_dev * · line 1301
Quoted 8 lines
(quoted diff) +7
-0+ ret = check_lro_pkt_size( + port_id, dev_conf- rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); + if (ret != 0) + goto rollback; + } +This check forces applications that enable LRO to
provide'
max_lro_pkt_size'Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration willfail.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 3 lines
I think it should be important values for net applications
management.
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Also good for mbuf size managements.
Quoted 17 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 2 lines
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior. Before this, each PMD took its own interpretation to what should be the
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
maximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 2 lines
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 10 lines
Quoted 10 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide
'max_lro_pkt_size', so it is'0'?
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 13 lines
Quoted 13 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 3 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Yes, for consistence.
Quoted 5 lines
Quoted 5 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provideit?
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD insteadof failing?
Quoted 34 lines
Quoted 34 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 1 line
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 19 lines
Quoted 11 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
So
max_rx_pkt_lenwill remain max size of one packet, whilemax_lro_lenwill be max accumulate size for each LRO session?Yes.
Quoted 1 line
BTW, I think that for ixgbe max lro is
RTE_IPV4_MAX_PKT_LEN.Please see my change in
drivers/net/ixgbe/ixgbe_ethdev.c. Change toRTE_IPV4_MAX_PKT_LEN?Quoted 31 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
ixgbe_vf, as I remember, doesn’t support LRO at all.Please see my change in
drivers/net/ixgbe/ixgbe_vf_representor.cRemove it?Yes, please for both.
Will change in v5.
Quoted 22 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 5 lines
Quoted 3 lines
Another question, what will happen if PMD will ignore that value and will generate packets bigger then requested?
PMD should use this value and not ignore it.
Hmm, ok but this patch updates mxl driver only...
I suppose you expect other PMD maintainers to do the job for their PMDs, right?
If so, are they aware (and agree) for this new hard requirement and changes required?
Again what PMD should do if it can't support exact value? Let say user asked max_lro_size=20KB but PMD can do only 16KB or24KB?
Quoted 6 lines
Quoted 5 lines
Should it fail, or round to smallest, or ...?
Actually I wonder, should it really be a hard requirement or more like a guidance to PMD?
Why app needs and *exact* value for LRO size?
Quoted 8 lines
Quoted 1 line
The exact value should be configured to HW as LRO session limit.
But if the HW can't support this exact value, see the example above? In fact, shouldn't we allow PMD to forbid user to configure max LRO size? Let say if in
dev_infomax_lro_size==0, then PMD doesn't support LRO size configuration at all.
That way PMDs who do support LRO, but don't want to (can't to) support configurable LRO size will stay untouched.
Each HW should support packet size limitation no matter if it is LRO packet or not:
How does the PMD limit the packet size for max rx packet len conf?
How does the PMD limit the packet size for the mbuf size?
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Hi Matan,
Quoted 199 lines
Quoted 190 lines
Quoted 103 lines
Quoted 103 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
Quoted 2 lines
@@ -1266,6 +1286,18 @@ struct rte_eth_dev *
RTE_ETHER_MAX_LEN;Quoted 4 lines
}
+ /*
+ * If LRO is enabled, check that the maximumaggregated
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
packet
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
+ * size is supported by the configured device.
+ */
+ if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Quoted 11 lines
Quoted 8 lines
+ ret = check_lro_pkt_size(
+ port_id, dev_conf-
rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ goto rollback;
+ }
+This check forces applications that enable LRO to
provide'
max_lro_pkt_size'Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration willfail.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lro pkt len should be mandatory for LRO offload.
Quoted 3 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 3 lines
I think it should be important values for net applications
management.
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Also good for mbuf size managements.
Quoted 17 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working before if it is mandatory value?
It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameoffload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 2 lines
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same logic.
Quoted 4 lines
This parameter defines well the LRO behavior. Before this, each PMD took its own interpretation to what should be the
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
maximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 2 lines
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 10 lines
Quoted 10 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide
'max_lro_pkt_size', so it is'0'?
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for non-0
value.
Quoted 13 lines
Quoted 13 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 3 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Yes, for consistence.
Quoted 5 lines
Quoted 5 lines
as same as max rx pkt len, no?
Quoted 2 lines
- What do you think setting '
max_lro_pkt_size' config value to what PMD provided if application doesn't provideit?
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD insteadof failing?
Quoted 34 lines
Quoted 34 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 1 line
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 3 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 19 lines
Quoted 11 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of '
max_rx_pkt_len' does it.It is mandatory only if LRO offload is configured.
So
max_rx_pkt_lenwill remain max size of one packet, whilemax_lro_lenwill be max accumulate size for each LRO session?Yes.
Quoted 1 line
BTW, I think that for ixgbe max lro is
RTE_IPV4_MAX_PKT_LEN.Please see my change in
drivers/net/ixgbe/ixgbe_ethdev.c. Change toRTE_IPV4_MAX_PKT_LEN?Quoted 31 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
ixgbe_vf, as I remember, doesn’t support LRO at all.Please see my change in
drivers/net/ixgbe/ixgbe_vf_representor.cRemove it?Yes, please for both.
Will change in v5.
Quoted 22 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 5 lines
Quoted 3 lines
Another question, what will happen if PMD will ignore that value and will generate packets bigger then requested?
PMD should use this value and not ignore it.
Hmm, ok but this patch updates mxl driver only...
I suppose you expect other PMD maintainers to do the job for their PMDs, right?
If so, are they aware (and agree) for this new hard requirement and changes required?
Again what PMD should do if it can't support exact value? Let say user asked max_lro_size=20KB but PMD can do only 16KB or24KB?
Quoted 6 lines
Quoted 5 lines
Should it fail, or round to smallest, or ...?
Actually I wonder, should it really be a hard requirement or more like a guidance to PMD?
Why app needs and *exact* value for LRO size?Quoted 8 lines
Quoted 1 line
The exact value should be configured to HW as LRO session limit.
But if the HW can't support this exact value, see the example above? In fact, shouldn't we allow PMD to forbid user to configure max LRO size? Let say if in
dev_infomax_lro_size==0, then PMD doesn't support LRO size configuration at all.
That way PMDs who do support LRO, but don't want to (can't to) support configurable LRO size will stay untouched.
Quoted 3 lines
Each HW should support packet size limitation no matter if it is LRO packet or not:
How does the PMD limit the packet size for max rx packet len conf?
How does the PMD limit the packet size for the mbuf size?
Not sure I understand your statement and questions above...
For sure PMD has to support max_rx_pktlen., but how does it relate to max_lro? Konstantin
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size
Hi
From: Ananyev, Konstantin
Quoted 211 lines
Hi Matan,
Quoted 62 lines
Quoted 62 lines
Quoted 62 lines
Quoted 62 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Dekel Peled
@@ -1266,6 +1286,18 @@ struct rte_eth_dev *
RTE_ETHER_MAX_LEN;
}+ /*
+ * If LRO is enabled, check that the maximumaggregated
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
packet
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
+ * size is supported by the configured device.
+ */
+ if (dev_conf->rxmode.offloads &
DEV_RX_OFFLOAD_TCP_LRO) {Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Quoted 11 lines
+ ret = check_lro_pkt_size(
+ port_id, dev_conf-
rxmode.max_lro_pkt_size,
+ dev_info.max_lro_pkt_size);
+ if (ret != 0)
+ goto rollback;
+ }
+This check forces applications that enable LRO to
provide'
max_lro_pkt_size'Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
config value.
Yes.(we can break an API, we noticed it)
I am not talking about API/ABI breakage, that part is OK. With this check, if the application requested LRO offload but not provided '
max_lro_pkt_size' value, device configuration willfail.
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 1 line
Yes
Quoted 2 lines
Can there be a case application is good with whatever the PMD can support as max?
Yes can be - you know, we can do everything we want but it is better to be
consistent:
Quoted 2 lines
Due to the fact of Max rx pkt len field is mandatory for JUMBO offload, max
lro pkt len should be mandatory for LRO offload.
Quoted 1 line
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
So your question is actually why both, non-lro packets and LRO packets max
size are mandatory...
Quoted 4 lines
I think it should be important values for net applications
management.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Also good for mbuf size managements.
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
- Why it is mandatory now, how it was working
before if it is mandatory value?It is the same as
max_rx_pkt_lenwhich is mandatory for jumbo frameQuoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
offload.
Quoted 2 lines
So now, when the user configures a LRO offload he must to set max lro pkt
len.
Quoted 2 lines
We don't want to confuse the user here with the max rx pkt len
configurations and behaviors, they should be with same
logic.
Quoted 66 lines
Quoted 66 lines
Quoted 37 lines
Quoted 37 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
This parameter defines well the LRO behavior. Before this, each PMD took its own interpretation to what should be the
maximum size for LRO aggregated packets.
Quoted 2 lines
Now, the user must say what is his intension, and the ethdev can limit it
according to the device capability.
Quoted 2 lines
By this way, also, the PMD can organize\optimize its data-path
more.
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Also, the application can create different mempools for LRO queues to
allow bigger packet receiving for LRO traffic.
Quoted 3 lines
Quoted 3 lines
- What happens if PMD doesn't provide
'max_lro_pkt_size', so it is'0'?
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Yes, you can see the feature description Dekel added. This patch also updates all the PMDs support an LRO for
non-0value.
Quoted 14 lines
Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Of course I can see the updates Matan, my point is "What happens if PMD doesn't provide '
max_lro_pkt_size'",
1) There is no check for it right, so it is acceptable?Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
There is check.
If the capability is 0, any non-zero configuration will fail.Quoted 3 lines
2) Are we making this filed mandatory to provide for PMDs, it is easy to make new fields mandatory for PMDs but is this really
necessary?
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Yes, for consistence.
Quoted 6 lines
Quoted 6 lines
as same as max rx pkt len, no?
Quoted 3 lines
- What do you think setting 'max_lro_pkt_size'
config value to what PMD provided if application
doesn't provideit?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
Same answers as above.
If application doesn't care the value, as it has been till now, and not provided explicit '
max_lro_pkt_size', why not ethdev level use the value provided by PMD insteadof failing?
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 5 lines
Again, same question we can ask on max rx pkt len.
Looks like the packet size is very important value which should be set by
the application.
Quoted 3 lines
Previous applications have no option to configure it, so they haven't
configure it, (probably cover it somehow) I think it is our miss to supply this info.
Quoted 1 line
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Let's do it in same way as we do max rx pkt len (as this patch main
idea).
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Later, we can change both to other meaning.
I think it is not a good reason to introduce a new mandatory config option for application because of
'
max_rx_pkt_len' does it.Quoted 64 lines
Quoted 63 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 6 lines
Quoted 2 lines
It is mandatory only if LRO offload is configured.
So
max_rx_pkt_lenwill remain max size of one packet, whilemax_lro_lenwill be max accumulate size for each LRO session?Yes.
Quoted 1 line
BTW, I think that for ixgbe max lro is
RTE_IPV4_MAX_PKT_LEN.Please see my change in
drivers/net/ixgbe/ixgbe_ethdev.c. Change toRTE_IPV4_MAX_PKT_LEN?Quoted 1 line
ixgbe_vf, as I remember, doesn’t support LRO at all.Quoted 32 lines
Quoted 5 lines
Quoted 3 lines
Please see my change in
drivers/net/ixgbe/ixgbe_vf_representor.c
Remove it?Yes, please for both.
Will change in v5.
Quoted 24 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 7 lines
Will it work, if:
- If application doesn't provide this value, use the PMD maxMay cause a problem if the mbuf size is not enough for the PMD
maximum.
Quoted 5 lines
Quoted 3 lines
Another question, what will happen if PMD will ignore that value and will generate packets bigger then requested?
PMD should use this value and not ignore it.
Hmm, ok but this patch updates mxl driver only...
I suppose you expect other PMD maintainers to do the job for their PMDs, right?
If so, are they aware (and agree) for this new hard requirement and changes required?
Again what PMD should do if it can't support exact value? Let say user asked max_lro_size=20KB but PMD can do only 16KB or24KB?
Quoted 7 lines
Quoted 5 lines
Should it fail, or round to smallest, or ...?
Actually I wonder, should it really be a hard requirement or more like a guidance to PMD?
Why app needs and *exact* value for LRO size?The exact value should be configured to HW as LRO session limit.
But if the HW can't support this exact value, see the example above? In fact, shouldn't we allow PMD to forbid user to configure max LRO size? Let say if in
dev_infomax_lro_size==0, then PMD doesn't support LRO size configuration at all.
That way PMDs who do support LRO, but don't want to (can't to) support configurable LRO size will stay untouched.
Quoted 8 lines
Quoted 1 line
Each HW should support packet size limitation no matter if it is LRO packet
or not:
Quoted 2 lines
How does the PMD limit the packet size for max rx packet len conf? How does the PMD limit the packet size for the mbuf size?
Not sure I understand your statement and questions above... For sure PMD has to support
max_rx_pktlen., but how does it relate tomax_lro?
You said that HW may not support LRO max size configuration.
I answered that as same as the HW can limit packets to the configuration of max_rx_pkt_len, so it can limit LRO packets size here too. For simplifications:
Rx Queues which are not configured to do LRO offload should limit their packets to the max_rx_pkt_len field.
Rx Queues which are configured to do LRO offload should limit their packets to the max_lro_pkt_len new field.
In addition, both should limit the packets size to the mbuf size of the Rx mempool configured to the Rx queue( if scatter offload is not enabled).
PATCH v4 2/3 net/mlx5: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
Rx queue create is updated to use the relevant configuration. Documentation is updated accordingly.
--- doc/guides/nics/mlx5.rst | 2 ++ drivers/net/mlx5/mlx5_rxq.c | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-)
doc/guides/nics/mlx5.rst +2 -0
@@ -207,6 +207,8 @@ Limitations - KEEP_CRC offload cannot be supported with LRO. - The first mbuf length, without head-room, must be big enough to include the TCP header (122B). + - Rx queue with LRO offload enabled, receiving a non-LRO packet, can forward + it with size limited to max LRO size, not to max RX packet length. Statistics ----------
drivers/net/mlx5/mlx5_rxq.c +3 -1
@@ -1772,7 +1772,9 @@ struct mlx5_rxq_ctrl * dev->data->dev_conf.rxmode.offloads;unsigned int lro_on_queue = !!(offloads &DEV_RX_OFFLOAD_TCP_LRO );const int mprq_en =mlx5_check_mprq_support (dev) >0 ; -unsigned int max_rx_pkt_len = dev->data->dev_conf.rxmode.max_rx_pkt_len; +unsigned int max_rx_pkt_len = lro_on_queue ? + dev->data->dev_conf.rxmode.max_lro_pkt_size : + dev->data->dev_conf.rxmode.max_rx_pkt_len;unsigned int non_scatter_min_mbuf_size = max_rx_pkt_len +RTE_PKTMBUF_HEADROOM ;unsigned int max_lro_size =0 ;
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v4 2/3] net/mlx5: use API to set max LRO packet size
Quoted 19 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Thursday, November 7, 2019 14:35
To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: [PATCH v4 2/3] net/mlx5: use API to set max LRO packet size
Quoted 5 lines
This patch implements use of the API for LRO aggregated packet max size. Rx queue create is updated to use the relevant configuration. Documentation is updated accordingly.
Signed-off-by Dekel Peled <[email protected]>
Re: [dpdk-dev] [PATCH v4 2/3] net/mlx5: use API to set max LRO packet size
Quoted 19 lines · Slava Ovsiienko
Quoted 19 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Thursday, November 7, 2019 14:35
To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: [PATCH v4 2/3] net/mlx5: use API to set max LRO packet size
Quoted 7 lines
Quoted 5 lines
This patch implements use of the API for LRO aggregated packet max size. Rx queue create is updated to use the relevant configuration. Documentation is updated accordingly.
Signed-off-by Dekel Peled <[email protected]>
This is an ethdev level API change, that will affect multiple PMDs, shouldn't we get more input than single company?
PATCH v4 3/3 app/testpmd: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.
--- app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 97 insertions(+)
app/test-pmd/cmdline.c +73 -0
@@ -2037,6 +2037,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ +struct cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) +{ +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + } + +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port->dev_conf.rxmode.max_lro_pkt_size) +return ; + + port->dev_conf.rxmode.max_lro_pkt_size = res->value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); +} + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + keyword,"config" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + all,"all" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + name,"max-lro-pkt-size" ); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + value,UINT32 ); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;
@@ -19025,6 +19097,7 @@ struct cmd_show_port_supported_ptypes_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss, (cmdline_parse_inst_t *)&cmd_config_rxtx_ring_size,
app/test-pmd/config.c +2 -0
@@ -616,6 +616,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data)printf ("Minimum size of RX buffer: %u\n" , dev_info.min_rx_bufsize);printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)
app/test-pmd/parameters.c +7 -0
@@ -107,6 +107,8 @@printf (" --total-num-mbufs=N: set the number of mbufs to be allocated " "in mbuf pools.\n" );printf (" --max-pkt-len=N: set the maximum size of packet to N bytes.\n" ); +printf (" --max-lro-pkt-size=N: set the maximum LRO aggregated packet " +"size to N bytes.\n" );#ifdef RTE_LIBRTE_CMDLINE printf (" --eth-peers-configfile=name: config file with ethernet addresses " "of peer ports.\n" );
@@ -592,6 +594,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 }, { "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },
@@ -888,6 +891,10 @@"Invalid max-pkt-len=%d - should be > %d\n" , n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt-size" )) { + n =atoi (optarg); + rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )) {if (!strcmp (optarg,"signature" )) fdir_conf.mode =
app/test-pmd/testpmd.c +1 -0
@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = {struct rte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN , };struct rte_eth_txmode tx_mode = {
doc/guides/testpmd_app_ug/run_app.rst +5 -0
@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The default value is 1518. +* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >= 64. + The default value is 1518. + * ``--eth-peers-configfile=name`` Use a configuration file containing the Ethernet addresses of the peer ports.
doc/guides/testpmd_app_ug/testpmd_funcs.rst +9 -0
@@ -2139,6 +2139,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v4 3/3] app/testpmd: use API to set max LRO packet size
Quoted 22 lines
-----Original Message-----
From: Dekel Peled <[email protected]>
Sent: Thursday, November 7, 2019 12:35 PM
To: Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Ananyev, Konstantin <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: [PATCH v4 3/3] app/testpmd: use API to set max LRO packet size
Quoted 6 lines
This patch implements use of the API for LRO aggregated packet max size. It adds command-line and runtime commands to configure this value, and adds option to show the supported value.
Documentation is updated accordingly.Signed-off-by Dekel Peled <[email protected]>
Re: [dpdk-dev] [PATCH v4 3/3] app/testpmd: use API to set max LRO packet size
In reply to Dekel PeledQuoted 7 lines · Dekel Peled
This patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.Signed-off-by Dekel Peled <[email protected]>
<...>
app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result { · line 2101
Quoted 4 lines
app/test-pmd/cmdline.c +4
-0+cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" ,
Can you please update "cmd_help_long_parsed()" function to add this new command to the help output?
<...>
app/test-pmd/testpmd.c struct fwd_engine * fwd_engines[] = { · line 422
Quoted 5 lines
app/test-pmd/testpmd.c +1
-0@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = {struct rte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN ,
If PMD value used if application doesn't provide a default value, my comment on previous patch, we can remove this value. So 'max_lro_pkt_size' can be used only set explicitly, otherwise used PMD values.
Re: [dpdk-dev] [PATCH v4 3/3] app/testpmd: use API to set max LRO packet size
Hi
From: Ferruh Yigit
Quoted 21 lines · Dekel Peled
Quoted 7 lines
This patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value.
Documentation is updated accordingly.Signed-off-by Dekel Peled <[email protected]><...>
app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result { · line 2101
Quoted 4 lines
app/test-pmd/cmdline.c +4
-0+cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" ,Can you please update "
cmd_help_long_parsed()" function to add this new command to the help output?<...>
Quoted 10 lines
app/test-pmd/testpmd.c struct fwd_engine * fwd_engines[] = { struct · line 422
Quoted 5 lines
app/test-pmd/testpmd.c +1
-0@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = { structrte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN ,If PMD value used if application doesn't provide a default value, my comment on previous patch, we can remove this value. So '
max_lro_pkt_size' can be used only set explicitly, otherwise used PMD values.
Also here, should be the same behavior as for max_rx_pkt_len.
Re: [dpdk-dev] [PATCH v4 3/3] app/testpmd: use API to set max LRO packet size
In reply to Ferruh YigitThanks, PSB.
Quoted 29 lines
-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Thursday, November 7, 2019 10:26 PM
To: Dekel Peled <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Thomas Monjalon <[email protected]>; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: Re: [PATCH v4 3/3] app/testpmd: use API to set max LRO packet sizeQuoted 7 lines · Dekel Peled
This patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value.
Documentation is updated accordingly.Signed-off-by Dekel Peled <[email protected]><...>
Quoted 8 lines
app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result { · line 2101
Quoted 4 lines
app/test-pmd/cmdline.c +4
-0+cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" ,Can you please update "
cmd_help_long_parsed()" function to add this new command to the help output?
Will send v5 with update.
Quoted 12 lines
<...>
app/test-pmd/testpmd.c struct fwd_engine * fwd_engines[] = { struct · line 422
Quoted 5 lines
app/test-pmd/testpmd.c +1
-0@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = { structrte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN ,If PMD value used if application doesn't provide a default value, my comment on previous patch, we can remove this value. So '
max_lro_pkt_size' can be used only set explicitly, otherwise used PMD values.
From: Dekel Peled
Quoted 11 lines
This series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
v3: Updated ethdev and testpmd patches per review comments.
v4: Updated ethdev patch for QEDE PMD per review comments.Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
For all the series:
Quoted 27 lines
app/test-pmd/cmdline.c | 73 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 ++++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 2 + drivers/net/ixgbe/ixgbe_vf_representor.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 22 files changed, 172 insertions(+), 6 deletions(-)--
1.8.3.1
v5 cover support API to set max LRO packet size
In reply to Dekel PeledThis series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
v3: Updated ethdev and testpmd patches per review comments.
v4: Updated ethdev patch for QEDE PMD per review comments.
v5: Updated ethdev patch for IXGBE PMD, and testpmd patch, per review comments.
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
app/test-pmd/cmdline.c | 76 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 +++ doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 1 + drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 +++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 21 files changed, 173 insertions(+), 6 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v5 1/3 ethdev: support API to set max LRO packet size
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
--- doc/guides/nics/features.rst | 2 ++ doc/guides/rel_notes/deprecation.rst | 4 ---- doc/guides/rel_notes/release_19_11.rst | 8 +++++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++++ 14 files changed, 68 insertions(+), 5 deletions(-)
doc/guides/nics/features.rst +2 -0
@@ -193,10 +193,12 @@ LRO Supports Large Receive Offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``. + ``dev_conf.rxmode.max_lro_pkt_size``. * **[implements] datapath**: ``LRO functionality``. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``. .. _nic_features_tso:
doc/guides/rel_notes/deprecation.rst +0 -4
@@ -87,10 +87,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
doc/guides/rel_notes/release_19_11.rst +8 -0
@@ -418,6 +418,14 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header. +* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in + struct ``rte_eth_dev_info`` for the port capability and in struct + ``rte_eth_rxmode`` for the port configuration. + Application should use the new field in struct ``rte_eth_rxmode`` to configure + the requested size. + PMD should use the new field in struct ``rte_eth_dev_info`` to report the + supported port capability. + Shared Library Versions -----------------------
drivers/net/bnxt/bnxt_ethdev.c +1 -0
@@ -519,6 +519,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pkt_size =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ;if (bp->flags &BNXT_FLAG_PTP_SUPPORTED )
drivers/net/hinic/hinic_pmd_ethdev.c +1 -0
@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa) info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pkt_size =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;
drivers/net/ixgbe/ixgbe_ethdev.c +1 -0
@@ -3814,6 +3814,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, } dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */ dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =RTE_IPV4_MAX_PKT_LEN ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ; dev_info->max_vfs = pci_dev->max_vfs;
drivers/net/mlx5/mlx5.h +3 -0
@@ -206,6 +206,9 @@ struct mlx5_hca_attr {#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */
drivers/net/mlx5/mlx5_ethdev.c +1 -0
@@ -606,6 +606,7 @@ struct ethtool_link_settings {/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pkt_size =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values.
drivers/net/mlx5/mlx5_rxq.c +0 -1
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))
drivers/net/qede/qede_ethdev.c +1 -0
@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; + dev_info->max_lro_pkt_size = (uint32_t )0x7FFF ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;
drivers/net/virtio/virtio_ethdev.c +1 -0
@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)RTE_MIN (hw->max_queue_pairs,VIRTIO_MAX_TX_QUEUES ); dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pkt_size =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features =VTPCI_OPS (hw)->get_features (hw);
drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -0
@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev) dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;
lib/librte_ethdev/rte_ethdev.c +44 -0
62 lines not on this page · raw message
lib/librte_ethdev/rte_ethdev.h +4 -0
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {/** The multi-queue packet distribution mode to be used, e.g. RSS. */ enum rte_eth_rx_mq_mode mq_mode;uint32_t max_rx_pkt_len;/**< Only used if JUMBO_FRAME enabled. */ +/** Maximum allowed size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t split_hdr_size;/**< hdr buf size (header_split enabled).*/ /** * Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1218,6 +1220,8 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v5 1/3] ethdev: support API to set max LRO packet size
Quoted 7 lines
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
Quoted 5 lines
Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
Actually if the requirement is just to allow user to limit max lro size, then why not to add just new function for that:
int rte_eth_dev_set_max_lro(uint16_t port_id, uint32_t lro); ?
And make it optional for the drivers to support it. That way PMD/devices that allow LRO max size to be configurable, can support it others can fail.
Konstantin
Quoted 59 lines
Signed-off-by Dekel Peled <[email protected]>Reviewed-by Andrew Rybchenko <[email protected]>Acked-by Thomas Monjalon <[email protected]>Acked-by Matan Azrad <[email protected]>--- doc/guides/nics/features.rst | 2 ++ doc/guides/rel_notes/deprecation.rst | 4 ---- doc/guides/rel_notes/release_19_11.rst | 8 +++++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44 ++++++++++++++++++++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++++ 14 files changed, 68 insertions(+), 5 deletions(-)doc/guides/nics/features.rst +2
-0@@ -193,10 +193,12 @@ LRO Supports Large Receive Offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``. + ``dev_conf.rxmode.max_lro_pkt_size``. * **[implements] datapath**: ``LRO functionality``. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``. .. _nic_features_tso:doc/guides/rel_notes/deprecation.rst +0
-4@@ -87,10 +87,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equaldoc/guides/rel_notes/release_19_11.rst +0
-0
doc/guides/rel_notes/release_19_11.rst ABI Changes · line 425
Quoted 8 lines
doc/guides/rel_notes/release_19_11.rst +5
-0@@ -418,6 +418,14 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header. +* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in + struct ``rte_eth_dev_info`` for the port capability and in struct + ``rte_eth_rxmode`` for the port configuration. + Application should use the new field in struct ``rte_eth_rxmode`` to configure + the requested size.
That part I am not happy with: * application should use*. Many apps I suppose are ok with default LRO size selected by PMD/HW. Why to force changes in all of them?
Quoted 209 lines
doc/guides/rel_notes/release_19_11.rst +3
-0+ PMD should use the new field in struct ``rte_eth_dev_info`` to report the + supported port capability. + Shared Library Versions -----------------------drivers/net/bnxt/bnxt_ethdev.c +1
-0@@ -519,6 +519,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pkt_size =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ;if (bp->flags &BNXT_FLAG_PTP_SUPPORTED )drivers/net/hinic/hinic_pmd_ethdev.c +1
-0@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct rte_eth_dev *dev, uint32_t *speed_capa) info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pkt_size =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;drivers/net/ixgbe/ixgbe_ethdev.c +1
-0@@ -3814,6 +3814,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, } dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */ dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =RTE_IPV4_MAX_PKT_LEN ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ; dev_info->max_vfs = pci_dev->max_vfs;drivers/net/mlx5/mlx5.h +3
-0@@ -206,6 +206,9 @@ struct mlx5_hca_attr {#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */ drivers/net/mlx5/mlx5_ethdev.c +1
-0@@ -606,6 +606,7 @@ struct ethtool_link_settings {/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pkt_size =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values. drivers/net/mlx5/mlx5_rxq.c +0
-1@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))drivers/net/qede/qede_ethdev.c +1
-0@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; + dev_info->max_lro_pkt_size = (uint32_t )0x7FFF ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;drivers/net/virtio/virtio_ethdev.c +1
-0@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)RTE_MIN (hw->max_queue_pairs,VIRTIO_MAX_TX_QUEUES ); dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pkt_size =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features =VTPCI_OPS (hw)->get_features (hw);drivers/net/vmxnet3/vmxnet3_ethdev.c +1
-0@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev) dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pkt_size =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;lib/librte_ethdev/rte_ethdev.c +44
-0@@ -1136,6 +1136,26 @@ struct rte_eth_dev *return name; } +static inline int +check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size) +{ +int ret =0 ; + +if (config_size > dev_info_size) { +RTE_ETHDEV_LOG (ERR ,"Ethdev port_id=%d max_lro_pkt_size %u " +"> max allowed value %u\n" , port_id, config_size, + dev_info_size); + ret = -EINVAL ; + }else if (config_size <RTE_ETHER_MIN_LEN ) { +RTE_ETHDEV_LOG (ERR ,"Ethdev port_id=%d max_lro_pkt_size %u " +"< min allowed value %u\n" , port_id, config_size, + (unsigned int )RTE_ETHER_MIN_LEN ); + ret = -EINVAL ; + } +return ret; +} +int rte_eth_dev_configure (uint16_t port_id,uint16_t nb_rx_q,uint16_t nb_tx_q,const struct rte_eth_conf *dev_conf)@@ -1266,6 +1286,18 @@ struct rte_eth_dev *RTE_ETHER_MAX_LEN ; } +/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret =check_lro_pkt_size ( + port_id, dev_conf->rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) + goto rollback; + } +/* Any requested offloading must be within its device capabilities */ if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) != dev_conf->rxmode.offloads) {@@ -1770,6 +1802,18 @@ struct rte_eth_dev *return -EINVAL ; } +/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (local_conf.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { +int ret =check_lro_pkt_size (port_id, + dev->data->dev_conf.rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) +return ret; + } + ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id, nb_rx_desc, socket_id, &local_conf, mp);if (!ret) {lib/librte_ethdev/rte_ethdev.h +4
-1@@ -395,6 +395,8 @@ struct rte_eth_rxmode {/** The multi-queue packet distribution mode to be used, e.g. RSS. */ enum rte_eth_rx_mq_mode mq_mode;uint32_t max_rx_pkt_len;/**< Only used if JUMBO_FRAME enabled. */ +/** Maximum allowed size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t split_hdr_size;/**< hdr buf size (header_split enabled).*/ /** * Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags. @@ -1218,6 +1220,8 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */ --1.8.3.1
Re: [dpdk-dev] [PATCH v5 1/3] ethdev: support API to set max LRO packet size
Thnaks, PSB.
Quoted 58 lines
-----Original Message-----
From: Ananyev, Konstantin <[email protected]>
Sent: Monday, November 11, 2019 1:08 AM
To: Dekel Peled <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v5 1/3] ethdev: support API to set max LRO packet sizeQuoted 10 lines
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.Various PMDs using LRO offload are updated, the new data members are initialized to ensure they don't fail validation.
[1]
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
Quoted 1 line
es.dpdk.org%2Fpatch%2F58217%2F&data=02%7C01%7Cdekelp%40mell anox.co
Quoted 1 line
m%7Cc12f78c6bd3d48bc223008d76632cd0f%7Ca652971c7d2e4d9ba6a4d1492 56f461
Quoted 1 line
b%7C0%7C0%7C637090240692948792&sdata=pU6LJBYDmlzPFzHc%2FQlF UVXpGuv
Quoted 3 lines
ulTcl%2F29GsXdvBF8%3D&reserved=0
[2]https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
Quoted 1 line
es.dpdk.org%2Fpatch%2F57492%2F&data=02%7C01%7Cdekelp%40mell anox.co
Quoted 1 line
m%7Cc12f78c6bd3d48bc223008d76632cd0f%7Ca652971c7d2e4d9ba6a4d1492 56f461
Quoted 1 line
b%7C0%7C0%7C637090240692958790&sdata=VegV5HcYhkabDgcOF29u %2FFLq25I
Quoted 1 line
%2BEDZTaEn20A2t2Wo%3D&reserved=0
Quoted 8 lines
Actually if the requirement is just to allow user to limit max lro size, then why not to add just new function for that:
int
rte_eth_dev_set_max_lro(uint16_t port_id, uint32_t lro); ?And make it optional for the drivers to support it.
That way PMD/devices that allow LRO max size to be configurable, can support it others can fail.
Current implementation is consistent with the existing max_rx_pkt_len use, in case LRO is used. When using jumbo frames the packet len must be specified.
Using LRO the max session size should be specified.
Quoted 74 lines
Konstantin
Quoted 5 lines
Signed-off-by Dekel Peled <[email protected]>Reviewed-by Andrew Rybchenko <[email protected]>Acked-by Thomas Monjalon <[email protected]>Acked-by Matan Azrad <[email protected]>Quoted 14 lines
--- doc/guides/nics/features.rst | 2 ++ doc/guides/rel_notes/deprecation.rst | 4 ---- doc/guides/rel_notes/release_19_11.rst | 8 +++++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.c | 44++++++++++++++++++++++++++++++++++
doc/guides/nics/features.rst LRO · line 195
Quoted 11 lines
lib/librte_ethdev/rte_ethdev.h | 4 ++++ 14 files changed, 68 insertions(+), 5 deletions(-)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindex 7a31cf7..2138ce3 100644doc/guides/nics/features.rst +0
-0@@ -193,10 +193,12 @@ LRO Supports Large Receive Offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**:``offloads:DEV_RX_OFFLOAD_TCP_LRO``.
doc/guides/nics/features.rst LRO
Quoted 4 lines
doc/guides/nics/features.rst +1
-0+ ``dev_conf.rxmode.max_lro_pkt_size``. * **[implements] datapath**: ``LRO functionality``. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``,``mbuf.tso_segsz``.
doc/guides/nics/features.rst LRO · line 200
Quoted 1 line
doc/guides/nics/features.rst +0
-0* **[provides] rte_eth_dev_info**:``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``.
doc/guides/rel_notes/deprecation.rst Deprecation Notices · line 87
Quoted 11 lines
doc/guides/nics/features.rst +1
-0+* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``. .. _nic_features_tso:doc/guides/rel_notes/deprecation.rst +0
-0@@ -87,10 +87,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rxand
doc/guides/rel_notes/deprecation.rst Deprecation Notices
Quoted 9 lines
doc/guides/rel_notes/deprecation.rst +0
-1thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO sessionsize, in
doc/guides/rel_notes/deprecation.rst +0
-3- struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs``rte_crypto_auth_xform``,
Quoted 10 lines
``rte_crypto_aead_xform`` is set to zero. When IV length is greater
or equal diff --gita/doc/guides/rel_notes/release_19_11.rstb/doc/guides/rel_notes/release_19_11.rst
index 87b7bd0..a3fc023 100644doc/guides/rel_notes/release_19_11.rst +0
-0@@ -418,6 +418,14 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header.
Quoted 11 lines
doc/guides/rel_notes/release_19_11.rst ABI Changes · line 427
Quoted 7 lines
doc/guides/rel_notes/release_19_11.rst +7
-0+* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, +in + struct ``rte_eth_dev_info`` for the port capability and in struct + ``rte_eth_rxmode`` for the port configuration. + Application should use the new field in struct ``rte_eth_rxmode`` +to configure + the requested size.That part I am not happy with: * application should use*. Many apps I suppose are ok with default LRO size selected by PMD/HW. Why to force changes in all of them?
Again this is to keep consistent with max_rx_pkt_len use.
Quoted 242 lines
drivers/net/bnxt/bnxt_ethdev.c static int bnxt_dev_info_get_op(struct rte_eth_dev
Quoted 12 lines
doc/guides/rel_notes/release_19_11.rst +3
-0+ PMD should use the new field in struct ``rte_eth_dev_info`` to + report the supported port capability. + Shared Library Versions -----------------------(quoted diff) +0
-0
b/drivers/net/bnxt/bnxt_ethdev.cindex b9b055e..741b897 100644drivers/net/bnxt/bnxt_ethdev.c +0
-0@@ -519,6 +519,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev
*eth_dev,drivers/net/hinic/hinic_pmd_ethdev.c static void hinic_get_speed_capa(struct
Quoted 13 lines
drivers/net/bnxt/bnxt_ethdev.c +1
-0/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pkt_size =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ; if (bp->flags & BNXT_FLAG_PTP_SUPPORTED) diff --git
a/drivers/net/hinic/hinic_pmd_ethdev.cb/drivers/net/hinic/hinic_pmd_ethdev.c
index 9f37a40..b33b2cf 100644drivers/net/hinic/hinic_pmd_ethdev.c +0
-0@@ -727,6 +727,7 @@ static void hinic_get_speed_capa(struct
rte_eth_dev*dev,uint32_t*speed_capa)drivers/net/ixgbe/ixgbe_ethdev.c static int
Quoted 13 lines
drivers/net/hinic/hinic_pmd_ethdev.c +1
-0info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pkt_size =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;drivers/net/ixgbe/ixgbe_ethdev.c +0
-0@@ -3814,6 +3814,7 @@ static intixgbevf_dev_xstats_get_names(__rte_unused struct
rte_eth_dev*dev,drivers/net/ixgbe/ixgbe_ethdev.c static int · line 3815
Quoted 2 lines
drivers/net/ixgbe/ixgbe_ethdev.c +0
-0} dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */
drivers/net/ixgbe/ixgbe_ethdev.c static int · line 3816
Quoted 1 line
drivers/net/ixgbe/ixgbe_ethdev.c +0
-0dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register
Quoted 41 lines
drivers/net/ixgbe/ixgbe_ethdev.c +1
-0*/ + dev_info->max_lro_pkt_size =RTE_IPV4_MAX_PKT_LEN ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ;
dev_info->max_vfs=pci_dev->max_vfs; diff --gita/drivers/net/mlx5/mlx5.hb/drivers/net/mlx5/mlx5.hindex fab58c9..4783b5c 100644drivers/net/mlx5/mlx5.h +3
-0@@ -206,6 +206,9 @@ struct mlx5_hca_attr { #defineMLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ #define +MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {
uint32_tsupported:1; /* Whether LRO is supported. */ diff --gita/drivers/net/mlx5/mlx5_ethdev.cb/drivers/net/mlx5/mlx5_ethdev.cindex 2b7c867..3adc824 100644drivers/net/mlx5/mlx5_ethdev.c +1
-0@@ -606,6 +606,7 @@ struct ethtool_link_settings {/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pkt_size =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values. drivers/net/mlx5/mlx5_rxq.c +0
-1@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) #defineQuoted 1 line
MLX5_MAX_TCP_HDR_OFFSET((unsigned int)(sizeof(struct
rte_ether_hdr) + \drivers/net/qede/qede_ethdev.c static int qede_dev_configure(struct rte_eth_dev · line 1280
Quoted 11 lines
drivers/net/mlx5/mlx5_rxq.c +0
-0sizeof (struct rte_vlan_hdr ) *2 + \ sizeof(struct rte_ipv6_hdr)))(quoted diff) +0
-0
b/drivers/net/qede/qede_ethdev.cindex 575982f..ccbb8a4 100644drivers/net/qede/qede_ethdev.c +0
-0@@ -1277,6 +1277,7 @@ static int qede_dev_configure(struct rte_eth_dev *eth_dev) dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen =(uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
drivers/net/virtio/virtio_ethdev.c static void virtio_dev_free_mbufs(struct
Quoted 10 lines
drivers/net/qede/qede_ethdev.c +1
-0+ dev_info->max_lro_pkt_size = (uint32_t )0x7FFF ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;drivers/net/virtio/virtio_ethdev.c +0
-0@@ -2435,6 +2435,7 @@ static void virtio_dev_free_mbufs(struct
rte_eth_dev*dev)drivers/net/virtio/virtio_ethdev.c static void virtio_dev_free_mbufs(struct · line 2435
Quoted 1 line
drivers/net/virtio/virtio_ethdev.c +0
-0RTE_MIN(hw->max_queue_pairs,
VIRTIO_MAX_TX_QUEUES);drivers/net/vmxnet3/vmxnet3_ethdev.c static int eth_vmxnet3_pci_remove(struct
Quoted 12 lines
drivers/net/virtio/virtio_ethdev.c +1
-0dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pkt_size =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features = VTPCI_OPS(hw)->get_features(hw); diff --git
a/drivers/net/vmxnet3/vmxnet3_ethdev.cb/drivers/net/vmxnet3/vmxnet3_ethdev.c
index d1faeaa..d18e8bc 100644drivers/net/vmxnet3/vmxnet3_ethdev.c +0
-0@@ -1161,6 +1161,7 @@ static int eth_vmxnet3_pci_remove(struct
rte_pci_device*pci_dev)drivers/net/vmxnet3/vmxnet3_ethdev.c static int eth_vmxnet3_pci_remove(struct rte_pci_device *pci_dev)
Quoted 3 lines
drivers/net/vmxnet3/vmxnet3_ethdev.c +0
-0dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register
Quoted 11 lines
drivers/net/vmxnet3/vmxnet3_ethdev.c +1
-0*/ + dev_info->max_lro_pkt_size =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;(quoted diff) +0
-0
b/lib/librte_ethdev/rte_ethdev.cindex 652c369..c642ba5 100644lib/librte_ethdev/rte_ethdev.c +0
-0@@ -1136,6 +1136,26 @@ struct rte_eth_dev *return name;lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1146
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +8
-0} +static inline int +check_lro_pkt_size (uint16_t port_id,uint32_t config_size, +uint32_t dev_info_size) +{ +int ret =0 ; + +if (config_size > dev_info_size) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u "lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 5 lines
lib/librte_ethdev/rte_ethdev.c +5
-0+"> max allowed value %u\n" , port_id, config_size, + dev_info_size); + ret = -EINVAL ; + }else if (config_size <RTE_ETHER_MIN_LEN ) { + RTE_ETHDEV_LOG(ERR, "Ethdev port_id=%d
max_lro_pkt_size%u "lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev *
Quoted 9 lines
lib/librte_ethdev/rte_ethdev.c +7
-0+"< min allowed value %u\n" , port_id, config_size, + (unsigned int)RTE_ETHER_MIN_LEN); + ret = -EINVAL ; + } +return ret; +} +int rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t
nb_tx_q,lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1161
Quoted 1 line
lib/librte_ethdev/rte_ethdev.c +0
-0const struct rte_eth_conf *dev_conf) @@ -1266,6+1286,18 @@
Quoted 2 lines
struct
rte_eth_dev*RTE_ETHER_MAX_LEN;Quoted 26 lines
lib/librte_ethdev/rte_ethdev.c +7
-0} +/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ +if (dev_conf->rxmode.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { + ret = check_lro_pkt_size( + port_id, dev_conf-rxmode.max_lro_pkt_size,
lib/librte_ethdev/rte_ethdev.c +9
-0+ dev_info.max_lro_pkt_size); +if (ret !=0 ) + goto rollback; + } +/* Any requested offloading must be within its device capabilities */ if ((dev_conf->rxmode.offloads & dev_info.rx_offload_capa) != dev_conf->rxmode.offloads) {@@ -1770,6 +1802,18 @@ struct rte_eth_dev *return -EINVAL ; } +/* +* If LRO is enabled, check that the maximum aggregated packet +* size is supported by the configured device. +*/ lib/librte_ethdev/rte_ethdev.c struct rte_eth_dev * · line 1818
Quoted 10 lines
lib/librte_ethdev/rte_ethdev.c +8
-0+if (local_conf.offloads &DEV_RX_OFFLOAD_TCP_LRO ) { +int ret =check_lro_pkt_size (port_id, + dev->data- dev_conf.rxmode.max_lro_pkt_size, + dev_info.max_lro_pkt_size); +if (ret !=0 ) +return ret; + } + ret = (*dev->dev_ops->rx_queue_setup)(dev, rx_queue_id,
nb_rx_desc,lib/librte_ethdev/rte_ethdev.h struct rte_eth_rxmode { · line 395
Quoted 8 lines
lib/librte_ethdev/rte_ethdev.c +0
-0socket_id, &local_conf, mp);lib/librte_ethdev/rte_ethdev.c +0
-0if (!ret) {(quoted diff) +0
-0
b/lib/librte_ethdev/rte_ethdev.hindex 44d77b3..1b76df5 100644lib/librte_ethdev/rte_ethdev.h +0
-0@@ -395,6 +395,8 @@ struct rte_eth_rxmode {/** The multi-queue packet distribution mode to be used, e.g. RSS. */
lib/librte_ethdev/rte_ethdev.h struct rte_eth_rxmode { · line 397
Quoted 2 lines
lib/librte_ethdev/rte_ethdev.h +0
-0enum rte_eth_rx_mq_mode mq_mode;uint32_t max_rx_pkt_len;/**< Only used if JUMBO_FRAME enabled. */
lib/librte_ethdev/rte_ethdev.h struct rte_eth_dev_info { · line 1222
Quoted 9 lines
lib/librte_ethdev/rte_ethdev.h +2
-0+/** Maximum allowed size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t split_hdr_size;/**< hdr buf size (header_split enabled).*/ /** * Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags. @@ -1218,6 +1220,8 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt.
Quoted 6 lines
lib/librte_ethdev/rte_ethdev.h +2
-0*/ +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */
uint32_tmax_mac_addrs; /**< Maximum number of MACaddresses. */
Quoted 2 lines
--
1.8.3.1
PATCH v5 2/3 net/mlx5: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
Rx queue create is updated to use the relevant configuration. Documentation is updated accordingly.
--- doc/guides/nics/mlx5.rst | 2 ++ drivers/net/mlx5/mlx5_rxq.c | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-)
doc/guides/nics/mlx5.rst +2 -0
@@ -207,6 +207,8 @@ Limitations - KEEP_CRC offload cannot be supported with LRO. - The first mbuf length, without head-room, must be big enough to include the TCP header (122B). + - Rx queue with LRO offload enabled, receiving a non-LRO packet, can forward + it with size limited to max LRO size, not to max RX packet length. Statistics ----------
drivers/net/mlx5/mlx5_rxq.c +3 -1
@@ -1772,7 +1772,9 @@ struct mlx5_rxq_ctrl * dev->data->dev_conf.rxmode.offloads;unsigned int lro_on_queue = !!(offloads &DEV_RX_OFFLOAD_TCP_LRO );const int mprq_en =mlx5_check_mprq_support (dev) >0 ; -unsigned int max_rx_pkt_len = dev->data->dev_conf.rxmode.max_rx_pkt_len; +unsigned int max_rx_pkt_len = lro_on_queue ? + dev->data->dev_conf.rxmode.max_lro_pkt_size : + dev->data->dev_conf.rxmode.max_rx_pkt_len;unsigned int non_scatter_min_mbuf_size = max_rx_pkt_len +RTE_PKTMBUF_HEADROOM ;unsigned int max_lro_size =0 ;
Signature · 1 line
1.8.3.1
PATCH v5 3/3 app/testpmd: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.
--- app/test-pmd/cmdline.c | 76 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 100 insertions(+)
app/test-pmd/cmdline.c +76 -0
@@ -777,6 +777,9 @@ static void cmd_help_long_parsed(void *parsed_result,"port config all max-pkt-len (value)\n" " Set the max packet length.\n\n" +"port config all max-lro-pkt-size (value)\n" +" Set the max LRO aggregated packet size.\n\n" +"port config all drop-en (on|off)\n" " Enable or disable packet drop on all RX queues of all ports when no " "receive buffers available.\n\n"
@@ -2040,6 +2043,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ +struct cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) +{ +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + } + +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port->dev_conf.rxmode.max_lro_pkt_size) +return ; + + port->dev_conf.rxmode.max_lro_pkt_size = res->value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); +} + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + keyword,"config" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + all,"all" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + name,"max-lro-pkt-size" ); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + value,UINT32 ); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;
@@ -19124,6 +19199,7 @@ struct cmd_show_rx_tx_desc_status_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss, (cmdline_parse_inst_t *)&cmd_config_rxtx_ring_size,
app/test-pmd/config.c +2 -0
@@ -616,6 +616,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data)printf ("Minimum size of RX buffer: %u\n" , dev_info.min_rx_bufsize);printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)
app/test-pmd/parameters.c +7 -0
@@ -107,6 +107,8 @@printf (" --total-num-mbufs=N: set the number of mbufs to be allocated " "in mbuf pools.\n" );printf (" --max-pkt-len=N: set the maximum size of packet to N bytes.\n" ); +printf (" --max-lro-pkt-size=N: set the maximum LRO aggregated packet " +"size to N bytes.\n" );#ifdef RTE_LIBRTE_CMDLINE printf (" --eth-peers-configfile=name: config file with ethernet addresses " "of peer ports.\n" );
@@ -592,6 +594,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 }, { "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },
@@ -888,6 +891,10 @@"Invalid max-pkt-len=%d - should be > %d\n" , n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt-size" )) { + n =atoi (optarg); + rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )) {if (!strcmp (optarg,"signature" )) fdir_conf.mode =
app/test-pmd/testpmd.c +1 -0
@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = {struct rte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN , };struct rte_eth_txmode tx_mode = {
doc/guides/testpmd_app_ug/run_app.rst +5 -0
@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The default value is 1518. +* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >= 64. + The default value is 1518. + * ``--eth-peers-configfile=name`` Use a configuration file containing the Ethernet addresses of the peer ports.
doc/guides/testpmd_app_ug/testpmd_funcs.rst +9 -0
@@ -2147,6 +2147,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v5 3/3] app/testpmd: use API to set max LRO packet size
Quoted 171 lines
This patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.Signed-off-by Dekel Peled <[email protected]>Acked-by Matan Azrad <[email protected]>--- app/test-pmd/cmdline.c | 76 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 100 insertions(+)app/test-pmd/cmdline.c +76
-0@@ -777,6 +777,9 @@ static void cmd_help_long_parsed(void *parsed_result,"port config all max-pkt-len (value)\n" " Set the max packet length.\n\n" +"port config all max-lro-pkt-size (value)\n" +" Set the max LRO aggregated packet size.\n\n" +"port config all drop-en (on|off)\n" " Enable or disable packet drop on all RX queues of all ports when no " "receive buffers available.\n\n" @@ -2040,6 +2043,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ +struct cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) +{ +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + } + +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port->dev_conf.rxmode.max_lro_pkt_size) +return ; + + port->dev_conf.rxmode.max_lro_pkt_size = res->value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); +} + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + keyword,"config" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + all,"all" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + name,"max-lro-pkt-size" ); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + value,UINT32 ); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;@@ -19124,6 +19199,7 @@ struct cmd_show_rx_tx_desc_status_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss, (cmdline_parse_inst_t *)&cmd_config_rxtx_ring_size,app/test-pmd/config.c +2
-0@@ -616,6 +616,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data)printf ("Minimum size of RX buffer: %u\n" , dev_info.min_rx_bufsize);printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)app/test-pmd/parameters.c +7
-0@@ -107,6 +107,8 @@printf (" --total-num-mbufs=N: set the number of mbufs to be allocated " "in mbuf pools.\n" );printf (" --max-pkt-len=N: set the maximum size of packet to N bytes.\n" ); +printf (" --max-lro-pkt-size=N: set the maximum LRO aggregated packet " +"size to N bytes.\n" );#ifdef RTE_LIBRTE_CMDLINE printf (" --eth-peers-configfile=name: config file with ethernet addresses " "of peer ports.\n" );@@ -592,6 +594,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 }, { "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },@@ -888,6 +891,10 @@"Invalid max-pkt-len=%d - should be > %d\n" , n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt-size" )) { + n =atoi (optarg); + rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )) {if (!strcmp (optarg,"signature" )) fdir_conf.mode =app/test-pmd/testpmd.c +0
-0
app/test-pmd/testpmd.c struct fwd_engine * fwd_engines[] = { · line 422
Quoted 4 lines
app/test-pmd/testpmd.c +1
-0@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = {struct rte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN ,
That looks like a change in current testpmd behavior, correct? If so, is there real need for that?
Can't we have either some value for max_lro_pktlen, that would indicate PMD to use the default value it prefers?
Or probably better to let have a separate function to set max lro size. Then by default PMD will always use its preferred value,
and when needed user can change it via special function call.
Quoted 41 lines
app/test-pmd/testpmd.c +0
-0};struct rte_eth_txmode tx_mode = {doc/guides/testpmd_app_ug/run_app.rst +5
-0@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The default value is 1518. +* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >= 64. + The default value is 1518. + * ``--eth-peers-configfile=name`` Use a configuration file containing the Ethernet addresses of the peer ports.doc/guides/testpmd_app_ug/testpmd_funcs.rst +9
-1@@ -2147,6 +2147,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~ --1.8.3.1
Re: [dpdk-dev] [PATCH v5 3/3] app/testpmd: use API to set max LRO packet size
Thanks, PSB.
Quoted 215 lines
-----Original Message-----
From: Ananyev, Konstantin <[email protected]>
Sent: Monday, November 11, 2019 1:11 AM
To: Dekel Peled <[email protected]>; Mcnamara, John <[email protected]>; Kovacevic, Marko <[email protected]>; [email protected]; [email protected]; [email protected]; Burakov, Anatoly <[email protected]>; [email protected]; [email protected]; [email protected]; Lu, Wenzhuo <[email protected]>; Matan Azrad <[email protected]>; Shahaf Shuler <[email protected]>; Slava Ovsiienko <[email protected]>; [email protected]; [email protected]; [email protected]; Bie, Tiwei <[email protected]>; Wang, Zhihong <[email protected]>; [email protected]; Thomas Monjalon <[email protected]>; Yigit, Ferruh <[email protected]>; [email protected]; Wu, Jingjing <[email protected]>; Iremonger, Bernard <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH v5 3/3] app/testpmd: use API to set max LRO packet sizeQuoted 7 lines
This patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value.
Documentation is updated accordingly.Quoted 5 lines
Signed-off-by Dekel Peled <[email protected]>Acked-by Matan Azrad <[email protected]>--- app/test-pmd/cmdline.c | 76+++++++++++++++++++++++++++++
app/test-pmd/cmdline.c static void cmd_help_long_parsed(void
Quoted 12 lines
app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ app/test-pmd/testpmd.c | 1 + doc/guides/testpmd_app_ug/run_app.rst | 5 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 6 files changed, 100 insertions(+)app/test-pmd/cmdline.c index renamed from app/test-pmd/cmdline.c +0
-078c6899..2206a70 100644
app/test-pmd/cmdline.c +0
-0@@ -777,6 +777,9 @@ static void cmd_help_long_parsed(void
*parsed_result,app/test-pmd/cmdline.c static void cmd_help_long_parsed(void *parsed_result,
Quoted 8 lines
app/test-pmd/cmdline.c +3
-0"port config all max-pkt-len (value)\n" " Set the max packet length.\n\n" +"port config all max-lro-pkt-size (value)\n" +" Set the max LRO aggregated packet size.\n\n" +"port config all drop-en (on|off)\n" " Enable or disable packet drop on all RX queues ofall ports when no "
Quoted 39 lines
app/test-pmd/cmdline.c +32
-0"receive buffers available.\n\n" @@ -2040,6 +2043,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ struct +cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) { +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + } + +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port- dev_conf.rxmode.max_lro_pkt_size) +return ; + + port->dev_conf.rxmode.max_lro_pkt_size = res- value; + }else { +printf ("Unknown parameter\n" );app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result { · line 2089
Quoted 10 lines
app/test-pmd/cmdline.c +10
-0+return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); } + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result { · line 2091
Quoted 2 lines
app/test-pmd/cmdline.c +2
-0+ port, "port"); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword=
app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result { · line 2092
Quoted 1 line
app/test-pmd/cmdline.c +1
-0+ TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result {
Quoted 3 lines
app/test-pmd/cmdline.c +3
-0+ keyword, "config"); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result {
Quoted 3 lines
app/test-pmd/cmdline.c +3
-0+ all, "all"); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/cmdline.c struct cmd_config_max_pkt_len_result {
Quoted 3 lines
app/test-pmd/cmdline.c +3
-0+ name, "max-lro-pkt-size"); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct
cmd_config_max_lro_pkt_size_result,app/test-pmd/config.c static int bus_match_all(const struct rte_bus *bus,
Quoted 32 lines
app/test-pmd/cmdline.c +17
-0+ value, UINT32); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;@@ -19124,6 +19199,7 @@ struct cmd_show_rx_tx_desc_status_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss, (cmdline_parse_inst_t *)&cmd_config_rxtx_ring_size, diff --git
a/app/test-pmd/config.cb/app/test-pmd/config.cindex b603974..e1e5cf7 100644app/test-pmd/config.c +0
-0@@ -616,6 +616,8 @@ static int bus_match_all(const struct rte_bus *bus,const void *data)
app/test-pmd/config.c static int bus_match_all(const struct rte_bus *bus, · line 616
Quoted 1 line
app/test-pmd/config.c +0
-0printf("Minimum size of RX buffer: %u\n",dev_info.min_rx_bufsize);
app/test-pmd/parameters.c line 107
Quoted 13 lines
app/test-pmd/config.c +2
-0printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)app/test-pmd/parameters.c +0
-0@@ -107,6 +107,8 @@ printf(" --total-num-mbufs=N: set the number of mbufs to beallocated "
app/test-pmd/parameters.c line 111
Quoted 4 lines
app/test-pmd/parameters.c +1
-0"in mbuf pools.\n"); printf(" --max-pkt-len=N: set the maximum size of packet to N bytes.\n"); + printf(" --max-lro-pkt-size=N: set the maximum LRO aggregatedpacket "
app/test-pmd/parameters.c
Quoted 3 lines
app/test-pmd/parameters.c +1
-0+ "size to N bytes.\n");#ifdef RTE_LIBRTE_CMDLINE printf(" --eth-peers-configfile=name: config file with ethernetaddresses "
app/test-pmd/parameters.c line 891
Quoted 11 lines
app/test-pmd/parameters.c +1
-0"of peer ports.\n");@@ -592,6 +594,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 }, { "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },@@ -888,6 +891,10 @@ "Invalid max-pkt-len=%d -should be > %d\n",
app/test-pmd/parameters.c
Quoted 3 lines
app/test-pmd/parameters.c +1
-0n, RTE_ETHER_MIN_LEN); } + if (!strcmp(lgopts[opt_idx].name, "max-lro-pkt-size")) {
app/test-pmd/parameters.c
Quoted 4 lines
app/test-pmd/parameters.c +3
-0+ n =atoi (optarg); + rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )){
app/test-pmd/testpmd.c struct fwd_engine * fwd_engines[] = { struct · line 422
Quoted 11 lines
app/test-pmd/parameters.c +0
-0if (!strcmp (optarg,"signature" )) fdir_conf.mode =app/test-pmd/testpmd.c index renamed from app/test-pmd/testpmd.c +0
-05ba9741..3fe694f 100644
app/test-pmd/testpmd.c +1
-0@@ -419,6 +419,7 @@ struct fwd_engine * fwd_engines[] = { structrte_eth_rxmode rx_mode = { .max_rx_pkt_len =RTE_ETHER_MAX_LEN ,/**< Default maximum frame length. */ + .max_lro_pkt_size =RTE_ETHER_MAX_LEN ,
Quoted 8 lines
That looks like a change in current testpmd behavior, correct? If so, is there real need for that?
Can't we have either some value formax_lro_pktlen, that would indicate PMD to use the default value it prefers?
Or probably better to let have a separate function to set max lro size. Then by default PMD will always use its preferred value, and when needed user can change it via special function call.
This is to keep consistent with max_rx_pkt_len use.
Quoted 46 lines
doc/guides/testpmd_app_ug/run_app.rst The command line options are: · line 113
Quoted 11 lines
app/test-pmd/testpmd.c +0
-0};struct rte_eth_txmode tx_mode = {doc/guides/testpmd_app_ug/run_app.rst +0
-0@@ -112,6 +112,11 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The defaultvalue is 1518.
doc/guides/testpmd_app_ug/run_app.rst The command line options are:
Quoted 4 lines
doc/guides/testpmd_app_ug/run_app.rst +3
-0+* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >=64.
doc/guides/testpmd_app_ug/run_app.rst The command line options are:
Quoted 5 lines
doc/guides/testpmd_app_ug/run_app.rst +2
-0+ The default value is 1518. + * ``--eth-peers-configfile=name`` Use a configuration file containing the Ethernet addresses of the peerports.
Quoted 23 lines
doc/guides/testpmd_app_ug/testpmd_funcs.rst +9
-1@@ -2147,6 +2147,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~ --1.8.3.1
PATCH v6 1/1 ethdev: add max LRO packet size
In reply to Dekel PeledFrom: Dekel Peled <[email protected]>
The maximum supported aggregated packet size for LRO is advertised in rte_eth_dev_info.
For some devices, max_lro_pktlen may be different of the basic max_rx_pktlen property.
Various PMDs supporting LRO are updated.
---
v6: This is half of v5 1/3. Only the agreed part is here. Hope it represents the consensus, so we make a step forward. The field max_lro_pkt_size is renamed to max_lro_pktlen in order to look like max_rx_pktlen.
--- doc/guides/nics/features.rst | 1 + doc/guides/rel_notes/deprecation.rst | 4 ---- doc/guides/rel_notes/release_19_11.rst | 3 +++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.h | 1 + 13 files changed, 15 insertions(+), 5 deletions(-)
doc/guides/nics/features.rst +1 -0
@@ -197,6 +197,7 @@ Supports Large Receive Offload. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pktlen``. .. _nic_features_tso:
doc/guides/rel_notes/deprecation.rst +0 -4
@@ -88,10 +88,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
doc/guides/rel_notes/release_19_11.rst +3 -0
@@ -403,6 +403,9 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header. +* ethdev: Added 32-bit field for maximum LRO aggregated packet size, + as port capability in the struct ``rte_eth_dev_info``. + * security: The field ``replay_win_sz`` has been moved from ipsec library based ``rte_ipsec_sa_prm`` structure to security library based structure ``rte_security_ipsec_xform``, which specify the Anti replay window size
drivers/net/bnxt/bnxt_ethdev.c +1 -0
@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pktlen =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ;if (bp->flags &BNXT_FLAG_PTP_SUPPORTED )
drivers/net/hinic/hinic_pmd_ethdev.c +1 -0
@@ -727,6 +727,7 @@ hinic_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info) info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;
drivers/net/ixgbe/ixgbe_ethdev.c +1 -0
@@ -3804,6 +3804,7 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info) } dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */ dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pktlen =RTE_IPV4_MAX_PKT_LEN ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ; dev_info->max_vfs = pci_dev->max_vfs;
drivers/net/mlx5/mlx5.h +3 -0
@@ -198,6 +198,9 @@ TAILQ_HEAD(mlx5_flows, rte_flow);#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */
drivers/net/mlx5/mlx5_ethdev.c +1 -0
@@ -552,6 +552,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pktlen =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values.
drivers/net/mlx5/mlx5_rxq.c +0 -1
@@ -1524,7 +1524,6 @@ mlx5_mprq_alloc_mp(struct rte_eth_dev *dev)return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))
drivers/net/qede/qede_ethdev.c +1 -0
@@ -1273,6 +1273,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev, dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; + dev_info->max_lro_pktlen = (uint32_t )0x7FFF ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;
drivers/net/virtio/virtio_ethdev.c +1 -0
@@ -2435,6 +2435,7 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)RTE_MIN (hw->max_queue_pairs,VIRTIO_MAX_TX_QUEUES ); dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pktlen =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features =VTPCI_OPS (hw)->get_features (hw);
drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -0
@@ -1161,6 +1161,7 @@ vmxnet3_dev_info_get(struct rte_eth_dev *dev, dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pktlen =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;
lib/librte_ethdev/rte_ethdev.h +1 -0
@@ -1183,6 +1183,7 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +uint32_t max_lro_pktlen;/**< Maximum size of LRO aggregated packet. */ uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */
Signature · 1 line
2.23.0
Re: [dpdk-dev] [PATCH v6] ethdev: add max LRO packet size
Quoted 106 lines
From: Dekel Peled <[email protected]>
The maximum supported aggregated packet size for LRO is advertised in
rte_eth_dev_info.
For some devices,max_lro_pktlenmay be different of the basicmax_rx_pktlenproperty.Various PMDs supporting LRO are updated.
Signed-off-by Dekel Peled <[email protected]>Signed-off-by Thomas Monjalon <[email protected]>---
v6: This is half of v5 1/3. Only the agreed part is here. Hope it represents the consensus, so we make a step forward. The field
max_lro_pkt_sizeis renamed tomax_lro_pktlenin order to look likemax_rx_pktlen.--- doc/guides/nics/features.rst | 1 + doc/guides/rel_notes/deprecation.rst | 4 ---- doc/guides/rel_notes/release_19_11.rst | 3 +++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 1 + drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 1 - drivers/net/qede/qede_ethdev.c | 1 + drivers/net/virtio/virtio_ethdev.c | 1 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 + lib/librte_ethdev/rte_ethdev.h | 1 + 13 files changed, 15 insertions(+), 5 deletions(-)doc/guides/nics/features.rst +1
-0@@ -197,6 +197,7 @@ Supports Large Receive Offload. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pktlen``. .. _nic_features_tso:doc/guides/rel_notes/deprecation.rst +0
-4@@ -88,10 +88,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equaldoc/guides/rel_notes/release_19_11.rst +3
-0@@ -403,6 +403,9 @@ ABI Changes align the Ethernet header on receive and all known encapsulations preserve the alignment of the header. +* ethdev: Added 32-bit field for maximum LRO aggregated packet size, + as port capability in the struct ``rte_eth_dev_info``. + * security: The field ``replay_win_sz`` has been moved from ipsec library based ``rte_ipsec_sa_prm`` structure to security library based structure ``rte_security_ipsec_xform``, which specify the Anti replay window sizedrivers/net/bnxt/bnxt_ethdev.c +1
-0@@ -535,6 +535,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,/* Fast path specifics */ dev_info->min_rx_bufsize =1 ; dev_info->max_rx_pktlen =BNXT_MAX_PKT_LEN ; + dev_info->max_lro_pktlen =BNXT_MAX_PKT_LEN ; dev_info->rx_offload_capa =BNXT_DEV_RX_OFFLOAD_SUPPORT ;if (bp->flags &BNXT_FLAG_PTP_SUPPORTED )drivers/net/hinic/hinic_pmd_ethdev.c +1
-0@@ -727,6 +727,7 @@ hinic_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info) info->max_tx_queues = nic_dev->nic_cap.max_sqs; info->min_rx_bufsize =HINIC_MIN_RX_BUF_SIZE ; info->max_rx_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; + info->max_lro_pktlen =HINIC_MAX_JUMBO_FRAME_SIZE ; info->max_mac_addrs =HINIC_MAX_UC_MAC_ADDRS ; info->min_mtu =HINIC_MIN_MTU_SIZE ; info->max_mtu =HINIC_MAX_MTU_SIZE ;drivers/net/ixgbe/ixgbe_ethdev.c +0
-0
drivers/net/ixgbe/ixgbe_ethdev.c ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info) · line 3810
Quoted 7 lines
drivers/net/ixgbe/ixgbe_ethdev.c +1
-0@@ -3804,6 +3804,7 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info) } dev_info->min_rx_bufsize =1024 ;/* cf BSIZEPACKET in SRRCTL register */ dev_info->max_rx_pktlen =15872 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pktlen =RTE_IPV4_MAX_PKT_LEN ; dev_info->max_mac_addrs = hw->mac.num_rar_entries; dev_info->max_hash_mac_addrs =IXGBE_VMDQ_NUM_UC_MAC ; dev_info->max_vfs = pci_dev->max_vfs;
Actually after looking at ixgbe code once again -
as we set LRO capability conditionally, we probably better to set max_lro_pktlen conditionally too. Something like:
drivers/net/ixgbe/ixgbe_ethdev.c +3 -0
@@ -3820,6 +3820,9 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info) dev_info->tx_queue_offload_capa =ixgbe_get_tx_queue_offloads (dev); dev_info->tx_offload_capa =ixgbe_get_tx_port_offloads (dev); +if (dev_info->rx_offload_capa &DEV_RX_OFFLOAD_TCP_LRO ) + dev_info->max_lro_pktlen =RTE_IPV4_MAX_PKT_LEN ; + dev_info->default_rxconf = (struct rte_eth_rxconf ) { .rx_thresh = { .pthresh =IXGBE_DEFAULT_RX_PTHRESH ,
Sorry for missed that previously.
Apart from that: LGTM.
Quoted 88 lines
drivers/net/mlx5/mlx5.h +3
-0@@ -198,6 +198,9 @@ TAILQ_HEAD(mlx5_flows, rte_flow);#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */ drivers/net/mlx5/mlx5_ethdev.c +1
-0@@ -552,6 +552,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pktlen =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values. drivers/net/mlx5/mlx5_rxq.c +0
-1@@ -1524,7 +1524,6 @@ mlx5_mprq_alloc_mp(struct rte_eth_dev *dev)return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))drivers/net/qede/qede_ethdev.c +1
-0@@ -1273,6 +1273,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev, dev_info->min_rx_bufsize = (uint32_t )QEDE_MIN_RX_BUFF_SIZE ; dev_info->max_rx_pktlen = (uint32_t )ETH_TX_MAX_NON_LSO_PKT_LEN ; + dev_info->max_lro_pktlen = (uint32_t )0x7FFF ; dev_info->rx_desc_lim = qede_rx_desc_lim; dev_info->tx_desc_lim = qede_tx_desc_lim;drivers/net/virtio/virtio_ethdev.c +1
-0@@ -2435,6 +2435,7 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)RTE_MIN (hw->max_queue_pairs,VIRTIO_MAX_TX_QUEUES ); dev_info->min_rx_bufsize =VIRTIO_MIN_RX_BUFSIZE ; dev_info->max_rx_pktlen =VIRTIO_MAX_RX_PKTLEN ; + dev_info->max_lro_pktlen =VIRTIO_MAX_RX_PKTLEN ; dev_info->max_mac_addrs =VIRTIO_MAX_MAC_ADDRS ; host_features =VTPCI_OPS (hw)->get_features (hw);drivers/net/vmxnet3/vmxnet3_ethdev.c +1
-0@@ -1161,6 +1161,7 @@ vmxnet3_dev_info_get(struct rte_eth_dev *dev, dev_info->max_tx_queues =VMXNET3_MAX_TX_QUEUES ; dev_info->min_rx_bufsize =1518 +RTE_PKTMBUF_HEADROOM ; dev_info->max_rx_pktlen =16384 ;/* includes CRC, cf MAXFRS register */ + dev_info->max_lro_pktlen =16384 ; dev_info->speed_capa =ETH_LINK_SPEED_10G ; dev_info->max_mac_addrs =VMXNET3_MAX_MAC_ADDRS ;lib/librte_ethdev/rte_ethdev.h +1
-1@@ -1183,6 +1183,7 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +uint32_t max_lro_pktlen;/**< Maximum size of LRO aggregated packet. */ uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */ --2.23.0
v7 cover support API to set max LRO packet size
In reply to Thomas MonjalonThis series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
v3: Updated ethdev and testpmd patches per review comments.
v4: Updated ethdev patch for QEDE PMD per review comments.
v5: Updated ethdev patch for IXGBE PMD, and testpmd patch,
per review comments.
v6: This is half of v5 1/3. Only the agreed part is here.
v7: Remove other PMDs update, allow max_lro_pkt_len 0 in
application conf, and in device info.
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
app/test-pmd/cmdline.c | 76 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ doc/guides/nics/features.rst | 2 + doc/guides/nics/mlx5.rst | 2 + doc/guides/rel_notes/deprecation.rst | 4 -- doc/guides/rel_notes/release_19_11.rst | 8 +++ doc/guides/testpmd_app_ug/run_app.rst | 4 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ drivers/net/mlx5/mlx5.h | 3 ++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +- lib/librte_ethdev/rte_ethdev.c | 59 ++++++++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 ++ 14 files changed, 180 insertions(+), 6 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v7 1/3 ethdev: support API to set max LRO packet size
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/
--- doc/guides/nics/features.rst | 2 ++ doc/guides/rel_notes/deprecation.rst | 4 --- doc/guides/rel_notes/release_19_11.rst | 8 +++++ lib/librte_ethdev/rte_ethdev.c | 59 ++++++++++++++++++++++++++++++++++ lib/librte_ethdev/rte_ethdev.h | 4 +++ 5 files changed, 73 insertions(+), 4 deletions(-)
doc/guides/nics/features.rst +2 -0
@@ -193,10 +193,12 @@ LRO Supports Large Receive Offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_TCP_LRO``. + ``dev_conf.rxmode.max_lro_pkt_size``. * **[implements] datapath**: ``LRO functionality``. * **[implements] rte_eth_dev_data**: ``lro``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_LRO``, ``mbuf.tso_segsz``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_TCP_LRO``. +* **[provides] rte_eth_dev_info**: ``max_lro_pkt_size``. .. _nic_features_tso:
doc/guides/rel_notes/deprecation.rst +0 -4
@@ -83,10 +83,6 @@ Deprecation Notices This scheme will allow PMDs to avoid lookup to internal ptype table on Rx and thereby improve Rx performance if application wishes do so. -* ethdev: New 32-bit fields may be added for maximum LRO session size, in - struct ``rte_eth_dev_info`` for the port capability and in struct - ``rte_eth_rxmode`` for the port configuration. - * cryptodev: support for using IV with all sizes is added, J0 still can be used but only when IV length in following structs ``rte_crypto_auth_xform``, ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
doc/guides/rel_notes/release_19_11.rst +8 -0
@@ -444,6 +444,14 @@ ABI Changes * ipsec: The field ``replay_win_sz`` has been removed from the structure ``rte_ipsec_sa_prm`` as it has been added to the security library. +* ethdev: Added 32-bit fields for maximum LRO aggregated packet size, in + struct ``rte_eth_dev_info`` for the port capability and in struct + ``rte_eth_rxmode`` for the port configuration. + Application should use the new field in struct ``rte_eth_rxmode`` to configure + the requested size. + PMD should use the new field in struct ``rte_eth_dev_info`` to report the + supported port capability. + Shared Library Versions -----------------------
lib/librte_ethdev/rte_ethdev.c +59 -0
77 lines not on this page · raw message
lib/librte_ethdev/rte_ethdev.h +4 -0
@@ -395,6 +395,8 @@ struct rte_eth_rxmode {/** The multi-queue packet distribution mode to be used, e.g. RSS. */ enum rte_eth_rx_mq_mode mq_mode;uint32_t max_rx_pkt_len;/**< Only used if JUMBO_FRAME enabled. */ +/** Maximum allowed size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t split_hdr_size;/**< hdr buf size (header_split enabled).*/ /** * Per-port Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
@@ -1218,6 +1220,8 @@ struct rte_eth_dev_info {const uint32_t *dev_flags;/**< Device flags */ uint32_t min_rx_bufsize;/**< Minimum size of RX buffer. */ uint32_t max_rx_pktlen;/**< Maximum configurable length of RX pkt. */ +/** Maximum configurable size of LRO aggregated packet. */ +uint32_t max_lro_pkt_size;uint16_t max_rx_queues;/**< Maximum number of RX queues. */ uint16_t max_tx_queues;/**< Maximum number of TX queues. */ uint32_t max_mac_addrs;/**< Maximum number of MAC addresses. */
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v7 1/3] ethdev: support API to set max LRO packet size
Quoted 5 lines · Dekel Peled
This patch implements [1], to support API for configuration and validation of max size for LRO aggregated packet.
API change notice [2] is removed, and release notes for 19.11 are updated accordingly.
Quoted 7 lines
[1] http://patches.dpdk.org/patch/58217/
[2] http://patches.dpdk.org/patch/57492/Signed-off-by Dekel Peled <[email protected]>Reviewed-by Andrew Rybchenko <[email protected]>Acked-by Thomas Monjalon <[email protected]>Acked-by Matan Azrad <[email protected]>
PATCH v7 2/3 net/mlx5: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
Rx queue create is updated to use the relevant configuration. Documentation is updated accordingly.
--- doc/guides/nics/mlx5.rst | 2 ++ drivers/net/mlx5/mlx5.h | 3 +++ drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_rxq.c | 5 +++-- 4 files changed, 9 insertions(+), 2 deletions(-)
doc/guides/nics/mlx5.rst +2 -0
@@ -207,6 +207,8 @@ Limitations - KEEP_CRC offload cannot be supported with LRO. - The first mbuf length, without head-room, must be big enough to include the TCP header (122B). + - Rx queue with LRO offload enabled, receiving a non-LRO packet, can forward + it with size limited to max LRO size, not to max RX packet length. Statistics ----------
drivers/net/mlx5/mlx5.h +3 -0
@@ -218,6 +218,9 @@ struct mlx5_hca_attr {#define MLX5_LRO_SUPPORTED (dev) \ (((struct mlx5_priv *)((dev)->data->dev_private))->config.lro.supported) +/* Maximal size of aggregated LRO packet. */ +#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u) +/* LRO configurations structure. */ struct mlx5_lro_config {uint32_t supported:1 ;/* Whether LRO is supported. */
drivers/net/mlx5/mlx5_ethdev.c +1 -0
@@ -606,6 +606,7 @@ struct ethtool_link_settings {/* FIXME: we should ask the device for these values. */ info->min_rx_bufsize =32 ; info->max_rx_pktlen =65536 ; + info->max_lro_pkt_size =MLX5_MAX_LRO_SIZE ;/* * Since we need one CQ per QP, the limit is the minimum number * between the two values.
drivers/net/mlx5/mlx5_rxq.c +3 -2
@@ -1701,7 +1701,6 @@ struct mlx5_rxq_obj *return 0 ; } -#define MLX5_MAX_LRO_SIZE (UINT8_MAX * 256u)#define MLX5_MAX_TCP_HDR_OFFSET ((unsigned int)(sizeof(struct rte_ether_hdr) + \ sizeof(struct rte_vlan_hdr) * 2 + \ sizeof(struct rte_ipv6_hdr)))
@@ -1773,7 +1772,9 @@ struct mlx5_rxq_ctrl * dev->data->dev_conf.rxmode.offloads;unsigned int lro_on_queue = !!(offloads &DEV_RX_OFFLOAD_TCP_LRO );const int mprq_en =mlx5_check_mprq_support (dev) >0 ; -unsigned int max_rx_pkt_len = dev->data->dev_conf.rxmode.max_rx_pkt_len; +unsigned int max_rx_pkt_len = lro_on_queue ? + dev->data->dev_conf.rxmode.max_lro_pkt_size : + dev->data->dev_conf.rxmode.max_rx_pkt_len;unsigned int non_scatter_min_mbuf_size = max_rx_pkt_len +RTE_PKTMBUF_HEADROOM ;unsigned int max_lro_size =0 ;
Signature · 1 line
1.8.3.1
PATCH v7 3/3 app/testpmd: use API to set max LRO packet size
In reply to Dekel PeledThis patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.
--- app/test-pmd/cmdline.c | 76 +++++++++++++++++++++++++++++ app/test-pmd/config.c | 2 + app/test-pmd/parameters.c | 7 +++ doc/guides/testpmd_app_ug/run_app.rst | 4 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 ++++ 5 files changed, 98 insertions(+)
app/test-pmd/cmdline.c +76 -0
@@ -777,6 +777,9 @@ static void cmd_help_long_parsed(void *parsed_result,"port config all max-pkt-len (value)\n" " Set the max packet length.\n\n" +"port config all max-lro-pkt-size (value)\n" +" Set the max LRO aggregated packet size.\n\n" +"port config all drop-en (on|off)\n" " Enable or disable packet drop on all RX queues of all ports when no " "receive buffers available.\n\n"
@@ -2040,6 +2043,78 @@ struct cmd_config_max_pkt_len_result { }, }; +/* *** config max LRO aggregated packet size *** */ +struct cmd_config_max_lro_pkt_size_result { +cmdline_fixed_string_t port; +cmdline_fixed_string_t keyword; +cmdline_fixed_string_t all; +cmdline_fixed_string_t name; +uint32_t value; +}; + +static void +cmd_config_max_lro_pkt_size_parsed (void *parsed_result, + __attribute__((unused))struct cmdline *cl, + __attribute__((unused))void *data) +{ +struct cmd_config_max_lro_pkt_size_result *res = parsed_result; +portid_t pid; + +if (!all_ports_stopped ()) { +printf ("Please stop all ports first\n" ); +return ; + } + +RTE_ETH_FOREACH_DEV (pid) { +struct rte_port *port = &ports[pid]; + +if (!strcmp (res->name,"max-lro-pkt-size" )) { +if (res->value == + port->dev_conf.rxmode.max_lro_pkt_size) +return ; + + port->dev_conf.rxmode.max_lro_pkt_size = res->value; + }else { +printf ("Unknown parameter\n" ); +return ; + } + } + +init_port_config (); + +cmd_reconfig_device_queue (RTE_PORT_ALL ,1 ,1 ); +} + +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_port = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + port,"port" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_keyword = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + keyword,"config" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_all = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + all,"all" ); +cmdline_parse_token_string_t cmd_config_max_lro_pkt_size_name = + TOKEN_STRING_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + name,"max-lro-pkt-size" ); +cmdline_parse_token_num_t cmd_config_max_lro_pkt_size_value = + TOKEN_NUM_INITIALIZER(struct cmd_config_max_lro_pkt_size_result, + value,UINT32 ); + +cmdline_parse_inst_t cmd_config_max_lro_pkt_size = { + .f = cmd_config_max_lro_pkt_size_parsed, + .data =NULL , + .help_str ="port config all max-lro-pkt-size <value>" , + .tokens = { + (void *)&cmd_config_max_lro_pkt_size_port, + (void *)&cmd_config_max_lro_pkt_size_keyword, + (void *)&cmd_config_max_lro_pkt_size_all, + (void *)&cmd_config_max_lro_pkt_size_name, + (void *)&cmd_config_max_lro_pkt_size_value, +NULL , + }, +}; +/* *** configure port MTU *** */ struct cmd_config_mtu_result {cmdline_fixed_string_t port;
@@ -19124,6 +19199,7 @@ struct cmd_show_rx_tx_desc_status_result { (cmdline_parse_inst_t *)&cmd_config_rx_tx, (cmdline_parse_inst_t *)&cmd_config_mtu, (cmdline_parse_inst_t *)&cmd_config_max_pkt_len, + (cmdline_parse_inst_t *)&cmd_config_max_lro_pkt_size, (cmdline_parse_inst_t *)&cmd_config_rx_mode_flag, (cmdline_parse_inst_t *)&cmd_config_rss, (cmdline_parse_inst_t *)&cmd_config_rxtx_ring_size,
app/test-pmd/config.c +2 -0
@@ -624,6 +624,8 @@ static int bus_match_all(const struct rte_bus *bus, const void *data)printf ("Minimum size of RX buffer: %u\n" , dev_info.min_rx_bufsize);printf ("Maximum configurable length of RX packet: %u\n" , dev_info.max_rx_pktlen); +printf ("Maximum configurable size of LRO aggregated packet: %u\n" , + dev_info.max_lro_pkt_size);if (dev_info.max_vfs)printf ("Maximum number of VFs: %u\n" , dev_info.max_vfs);if (dev_info.max_vmdq_pools)
app/test-pmd/parameters.c +7 -0
@@ -107,6 +107,8 @@printf (" --total-num-mbufs=N: set the number of mbufs to be allocated " "in mbuf pools.\n" );printf (" --max-pkt-len=N: set the maximum size of packet to N bytes.\n" ); +printf (" --max-lro-pkt-size=N: set the maximum LRO aggregated packet " +"size to N bytes.\n" );#ifdef RTE_LIBRTE_CMDLINE printf (" --eth-peers-configfile=name: config file with ethernet addresses " "of peer ports.\n" );
@@ -594,6 +596,7 @@ { "mbuf-size", 1, 0, 0 }, { "total-num-mbufs", 1, 0, 0 }, { "max-pkt-len", 1, 0, 0 }, + { "max-lro-pkt-size", 1, 0, 0 }, { "pkt-filter-mode", 1, 0, 0 }, { "pkt-filter-report-hash", 1, 0, 0 }, { "pkt-filter-size", 1, 0, 0 },
@@ -891,6 +894,10 @@"Invalid max-pkt-len=%d - should be > %d\n" , n, RTE_ETHER_MIN_LEN); } +if (!strcmp (lgopts[opt_idx].name,"max-lro-pkt-size" )) { + n =atoi (optarg); + rx_mode.max_lro_pkt_size = (uint32_t ) n; + }if (!strcmp (lgopts[opt_idx].name,"pkt-filter-mode" )) {if (!strcmp (optarg,"signature" )) fdir_conf.mode =
doc/guides/testpmd_app_ug/run_app.rst +4 -0
@@ -112,6 +112,10 @@ The command line options are: Set the maximum packet size to N bytes, where N >= 64. The default value is 1518. +* ``--max-lro-pkt-size=N`` + + Set the maximum LRO aggregated packet size to N bytes, where N >= 64. + * ``--eth-peers-configfile=name`` Use a configuration file containing the Ethernet addresses of the peer ports.
doc/guides/testpmd_app_ug/testpmd_funcs.rst +9 -0
@@ -2147,6 +2147,15 @@ Set the maximum packet length:: This is equivalent to the ``--max-pkt-len`` command-line option. +port config - max-lro-pkt-size +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set the maximum LRO aggregated packet size:: + + testpmd> port config all max-lro-pkt-size (value) + +This is equivalent to the ``--max-lro-pkt-size`` command-line option. + port config - Drop Packets ~~~~~~~~~~~~~~~~~~~~~~~~~~
Signature · 1 line
1.8.3.1
Re: [dpdk-dev] [PATCH v7 3/3] app/testpmd: use API to set max LRO packet size
Quoted 9 lines · Dekel Peled
This patch implements use of the API for LRO aggregated packet max size.
It adds command-line and runtime commands to configure this value, and adds option to show the supported value. Documentation is updated accordingly.Signed-off-by Dekel Peled <[email protected]>Acked-by Matan Azrad <[email protected]>
Quoted 12 lines · Dekel Peled
This series implements support and use of API for configuration and validation of max size for LRO aggregated packet.
v2: Updated ethdev patch per review comments.
v3: Updated ethdev and testpmd patches per review comments.
v4: Updated ethdev patch for QEDE PMD per review comments.
v5: Updated ethdev patch for IXGBE PMD, and testpmd patch,
per review comments.
v6: This is half of v5 1/3. Only the agreed part is here.
v7: Remove other PMDs update, allowmax_lro_pkt_len0 in
application conf, and in device info.
Quoted 4 lines
Dekel Peled (3):
ethdev: support API to set max LRO packet size
net/mlx5: use API to set max LRO packet size
app/testpmd: use API to set max LRO packet size
Series applied to dpdk-next-net/master, thanks.