Re: [dpdk-dev] [PATCH v16 2/8] ethdev: add mbuf RSS update as an offload

[Pavan Nikhilesh Bhagavatula]

>-Original Message-
>From: dev  On Behalf Of Ferruh Yigit
>Sent: Thursday, November 7, 2019 10:55 PM
>To: Pavan Nikhilesh Bhagavatula ;
>arybche...@solarflare.com; Jerin Jacob Kollanukkaran
>; tho...@monjalon.net; John McNamara
>; Marko Kovacevic
>
>Cc: dev@dpdk.org
>Subject: Re: [dpdk-dev] [PATCH v16 2/8] ethdev: add mbuf RSS update
>as an offload
>
>On 11/6/2019 7:17 PM, pbhagavat...@marvell.com wrote:
>> From: Pavan Nikhilesh 
>>
>> Add new Rx offload flag `DEV_RX_OFFLOAD_RSS_HASH` which can be
>used to
>> enable/disable PMDs write to `rte_mbuf::hash::rss`.
>> PMDs notify the validity of `rte_mbuf::hash:rss` to the applcation
>> by enabling `PKT_RX_RSS_HASH ` flag in `rte_mbuf::ol_flags`.
>>
>> Signed-off-by: Pavan Nikhilesh 
>> Reviewed-by: Andrew Rybchenko 
>
>testpmd support to enable the rx_offload seems missing, can you
>please check
>"port config 0 rx_offload ... " command, I think we should have
>following too:
>"port config 0 rx_offload rss_hash"

I will add this in the next version.

[dpdk-dev] [PATCH] net/mlx5: fix compiling without definition

[Bing Zhao]

When compiling the driver without macro for direct rules, the flow
table reference count should also be in the flow table resource
structure.

Fixes: c7455199284a ("net/mlx5: reorganize flow tables with hash list")

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 3296f10..feac5a3 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -587,9 +587,7 @@ struct mlx5_ibv_shared_port {
 /* Table structure. */
 struct mlx5_flow_tbl_resource {
void *obj; /**< Pointer to DR table object. */
-#ifdef HAVE_MLX5DV_DR
rte_atomic32_t refcnt; /**< Reference counter. */
-#endif
 };
 
 #define MLX5_MAX_TABLES UINT16_MAX
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v6] ethdev: add max LRO packet size

[Ananyev, Konstantin]

> 
> From: Dekel Peled 
> 
> 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.
> 
> Signed-off-by: Dekel Peled 
> Signed-off-by: Thomas Monjalon 
> ---
> 
> 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(-)
> 
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index d96696801a..1b2e120a9d 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -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:
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index b0b992dcb5..d4fcf9975b 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -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
> diff --git a/doc/guides/rel_notes/release_19_11.rst 
> b/doc/guides/rel_notes/release_19_11.rst
> index 795c7601c0..473af44374 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -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
> diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
> index 58a4f98c9f..95c60a3757 100644
> --- a/drivers/net/bnxt/bnxt_ethdev.c
> +++ b/drivers/net/bnxt/bnxt_ethdev.c
> @@ -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)
> diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c 
> b/drivers/net/hinic/hinic_pmd_ethdev.c
> index 9f37a404be..cbd2d032f9 100644
> --- a/drivers/net/hinic/hinic_pmd_ethdev.c
> +++ b/drivers/net/hinic/hinic_pmd_ethdev.c
> @@ -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;
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index dbce7a80e9..a01b8bbf10 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -3804,6 +3804,7 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
> rte_eth_

Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size

[Ananyev, Konstantin]

Hi Matan,

> > > > > > > >  On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > > > > > > > > @@ -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;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > 
> > > > > > > >  This check forces applications that enable LRO to
> > > > > > > >  provide
> > > > > > > > >> 'max_lro_pkt_size'
> > > > > > > >  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
> > > > > > > > >> 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.
> > > > > > > > >
> > > > > > > > >>>
> > > > > > > >  - 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.
> > > > > > > > >>>
> > > > > > > >  - 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.
> > > > > > > > >
> > > > > > > > >> 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.
> > > > > > > > >
> > > > > > > > >>>
> > > > > > > > >>> as same as max rx pkt len, no?
> > > > > > > > >>>
> > > > > > > >  - What do you think setting 'max_lro_pkt_size' config
> > > > > > > >  value to what PMD provided if application doesn't provid

Re: [dpdk-dev] [PATCH v5 1/3] ethdev: support API to set max LRO packet size

[Ananyev, Konstantin]

> 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/

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

> 
> Signed-off-by: Dekel Peled 
> Reviewed-by: Andrew Rybchenko 
> Acked-by: Thomas Monjalon 
> Acked-by: Matan Azrad 
> ---
>  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(-)
> 
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index 7a31cf7..2138ce3 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -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:
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index c10dc30..fdec33d 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -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
> diff --git a/doc/guides/rel_notes/release_19_11.rst 
> b/doc/guides/rel_notes/release_19_11.rst
> index 87b7bd0..a3fc023 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -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?

> +  PMD should use the new field in struct ``rte_eth_dev_info`` to report the
> +  supported port capability.
> +
> 
>  Shared Library Versions
>  ---
> diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
> index b9b055e..741b897 100644
> --- a/drivers/net/bnxt/bnxt_ethdev.c
> +++ b/drivers/net/bnxt/bnxt_ethdev.c
> @@ -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)
> diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c 
> b/drivers/net/hinic/h

Re: [dpdk-dev] [PATCH v5 3/3] app/testpmd: use API to set max LRO packet size

[Ananyev, Konstantin]

> 
> 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 
> Acked-by: Bernard Iremonger 
> Acked-by: Matan Azrad 
> ---
>  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(+)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 78c6899..2206a70 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -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 ",
> + .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,
>

Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size

[Ananyev, Konstantin]

> 
> From: Ferruh Yigit
> > On 11/8/2019 11:56 AM, Matan Azrad wrote:
> > >
> > >
> > > From: Ferruh Yigit
> > >> On 11/8/2019 10:10 AM, Matan Azrad wrote:
> > >>>
> > >>>
> > >>> From: Ferruh Yigit
> >  On 11/8/2019 6:54 AM, Matan Azrad wrote:
> > > Hi
> > >
> > > From: Ferruh Yigit
> > >> On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > >>> @@ -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;
> > >>> +   }
> > >>> +
> > >>
> > >> This check forces applications that enable LRO to provide
> >  'max_lro_pkt_size'
> > >> 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
> >  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.
> > >>>
> > >
> > >> - 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.
> > >
> > >> - 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.
> > >>>
> >  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.
> > >>>
> > >
> > > as same as max rx pkt len, no?
> > >
> > >> - 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.
> > >>>
> > >>
> > >> I think it

[dpdk-dev] [PATCH v3] net/ice: fix link status recovery

[Qiming Yang]

This patch fixes a kernel driver link status issue by recovering
link status when device stops.

Fixes: e6161345d8a9 ("net/ice: support link status change")
Cc: sta...@dpdk.org

Signed-off-by: Qiming Yang 
---
 drivers/net/ice/ice_ethdev.c | 28 +++-
 drivers/net/ice/ice_ethdev.h |  1 +
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index d746758..14ca5e6 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -2277,7 +2277,10 @@ ice_dev_stop(struct rte_eth_dev *dev)
/* Clear all queues and release mbufs */
ice_clear_queues(dev);
 
-   ice_dev_set_link_down(dev);
+   if (pf->init_link_status)
+   ice_dev_set_link_up(dev);
+   else
+   ice_dev_set_link_down(dev);
 
/* Clean datapath event and queue/vec mapping */
rte_intr_efd_disable(intr_handle);
@@ -2648,6 +2651,27 @@ ice_rxq_intr_setup(struct rte_eth_dev *dev)
return 0;
 }
 
+static void
+ice_get_init_link_status(struct rte_eth_dev *dev)
+{
+   struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+   bool enable_lse = dev->data->dev_conf.intr_conf.lsc ? true : false;
+   struct ice_link_status link_status;
+   int ret;
+
+   ret = ice_aq_get_link_info(hw->port_info, enable_lse,
+  &link_status, NULL);
+   if (ret != ICE_SUCCESS) {
+   PMD_DRV_LOG(ERR, "Failed to get link info");
+   pf->init_link_status = false;
+   return;
+   }
+
+   if (link_status.link_info & ICE_AQ_LINK_UP)
+   pf->init_link_status = true;
+}
+
 static int
 ice_dev_start(struct rte_eth_dev *dev)
 {
@@ -2717,6 +2741,8 @@ ice_dev_start(struct rte_eth_dev *dev)
if (ret != ICE_SUCCESS)
PMD_DRV_LOG(WARNING, "Fail to set phy mask");
 
+   ice_get_init_link_status(dev);
+
ice_dev_set_link_up(dev);
 
/* Call get_link_info aq commond to enable/disable LSE */
diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
index de67e59..27db4e7 100644
--- a/drivers/net/ice/ice_ethdev.h
+++ b/drivers/net/ice/ice_ethdev.h
@@ -369,6 +369,7 @@ struct ice_pf {
struct ice_parser_list rss_parser_list;
struct ice_parser_list perm_parser_list;
struct ice_parser_list dist_parser_list;
+   bool init_link_status;
 };
 
 #define ICE_MAX_QUEUE_NUM  2048
-- 
2.9.5

Re: [dpdk-dev] [EXT] Re: [PATCH v16 8/8] app/testpmd: add command to set supported ptype mask

[Pavan Nikhilesh Bhagavatula]

>On Fri, Nov 8, 2019 at 7:24 PM Ananyev, Konstantin
> wrote:
>>
>>
>>
>> > -Original Message-
>> > From: dev  On Behalf Of Ferruh Yigit
>> > Sent: Thursday, November 7, 2019 7:41 PM
>> > To: Jerin Jacob 
>> > Cc: Pavan Nikhilesh ; Andrew
>Rybchenko ; jer...@marvell.com;
>> > tho...@monjalon.net; Lu, Wenzhuo ;
>Wu, Jingjing ; Iremonger, Bernard
>> > ; Mcnamara, John
>; Kovacevic, Marko
>;
>> > dev@dpdk.org
>> > Subject: Re: [dpdk-dev] [PATCH v16 8/8] app/testpmd: add
>command to set supported ptype mask
>> >
>> > On 11/7/2019 6:55 PM, Jerin Jacob wrote:
>> > >
>> > >
>> > > On Fri, 8 Nov, 2019, 12:10 am Ferruh Yigit, > > > > wrote:
>> > >
>> > > On 11/6/2019 7:18 PM, pbhagavat...@marvell.com
>> > >  wrote:
>> > > > From: Pavan Nikhilesh > > > >
>> > > >
>> > > > Add command to set supported ptype mask.
>> > > > Usage:
>> > > >   set port  ptype_mask >  /* ***
>> > > >
>> > > >  /* list of instructions */
>> > > > @@ -19155,6 +19237,7 @@ cmdline_parse_ctx_t main_ctx[] =
>{
>> > > >   (cmdline_parse_inst_t *)&cmd_show_vf_stats,
>> > > >   (cmdline_parse_inst_t *)&cmd_clear_vf_stats,
>> > > >   (cmdline_parse_inst_t
>*)&cmd_show_port_supported_ptypes,
>> > > > + (cmdline_parse_inst_t *)&cmd_set_port_ptypes,
>> > > >   (cmdline_parse_inst_t *)&cmd_ptype_mapping_get,
>> > > >   (cmdline_parse_inst_t *)&cmd_ptype_mapping_replace,
>> > > >   (cmdline_parse_inst_t *)&cmd_ptype_mapping_reset,
>> > > > diff --git a/app/test-pmd/testpmd.c b/app/test-
>pmd/testpmd.c
>> > > > index 5ba974162..812aebf35 100644
>> > > > --- a/app/test-pmd/testpmd.c
>> > > > +++ b/app/test-pmd/testpmd.c
>> > > > @@ -2024,6 +2024,7 @@ start_port(portid_t pid)
>> > > >   queueid_t qi;
>> > > >   struct rte_port *port;
>> > > >   struct rte_ether_addr mac_addr;
>> > > > + static uint8_t clr_ptypes = 1;
>> > > >
>> > > >   if (port_id_is_invalid(pid, ENABLED_WARN))
>> > > >   return 0;
>> > > > @@ -2153,6 +2154,10 @@ start_port(portid_t pid)
>> > > >   }
>> > > >   }
>> > > >   configure_rxtx_dump_callbacks(verbose_level);
>> > > > + if (clr_ptypes) {
>> > > > + clr_ptypes = 0;
>> > > > + rte_eth_dev_set_ptypes(pi,
>RTE_PTYPE_UNKNOWN, NULL, 0);
>> > > > + }
>> > >
>> > > I am not sure about this command, we have now capability to
>set/disable ptypes
>> > > on demand, why disabling them by default?
>> > >
>> > >
>> > > As forward engines are not using the ptype offload. If a specific
>forwa
>> > > need the offload, it can be enabled.
>>
>> Well, at least now user can see ptype in pkt dump with 'set verbose >
>0'
>> It's definitely looks loke a a behavior change.
>> Wonder why it can't be done visa-versa?
>> Keep current behavior as default one (all ptypes are un-masked) and
>> have special command to disable/enable ptypes.
>> as I understand such command was added by these series. correct?
>
>IMO, we are following the principle that by default all offloads are
>disabled and enable it
>based on the need to have optimal performance across the DPDK. This
>change will be
>on the same theme.
>
>Regarding the verbose > 0 cases, I think, we can call
>rte_eth_dev_set_ptypes() to all PTYPES on
>the setting verbose callback.

Agree verbose > 0 case we can do set_ptypes with 
RTE_PTYPE_ALL_MASK. But what if the user wants to verify 
rte_eth_dev_set_ptypes() call itself in verbose mode?. 
Example:

set port 0 ptype_mask RTE_PTYPE_L3_MASK
set verbose 1

In this case user expects to see only L3 mask set. Wouldn’t it be confusing if
we set RTE_PTYPE_ALL_MASK under the hood when verbose level is increased?

Pavan.

[dpdk-dev] [Bug 361] device reset handling with igb_uio

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=361

Bug ID: 361
   Summary: device reset handling with igb_uio
   Product: DPDK
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: santosh.rasta...@broadcom.com
  Target Milestone: ---

Created attachment 73
  --> https://bugs.dpdk.org/attachment.cgi?id=73&action=edit
msi-x vector allocation for igb_uio after device reset

Hi,

I have a question on igb_uio.

>From the below function call traces, vfio-pci module frees/allocates msi-x
vector table as part of
interrupt disable/enable. Where as igb-uio module, only masks/unmasks the
msi-x interrupt.
Does this mean, when using igb_uio, device can't undergo reset which clears
MSI-X vector table?
How to handle device reset with igb_uio?

igb-uio:
rte_intr_disable->uio_intr_disable->igbuio_pci_irqcontrol->pci_msi_mask_irq
rte_intr_enable->uio_intr_enable->igbuio_pci_irqcontrol->pci_msi_unmask_irq

igbuio_pci_open->igbuio_pci_enable_interrupts->pci_alloc_irq_vectors/request_irq
igbuio_pci_release->igbuio_pci_disable_interrupts->free_irq->pci_free_irq_vectors

vfio-pci:
rte_intr_disable->vfio_disable_msix->vfio_pci_ioctl->vfio_msi_disable->pci_free_irq_vectors
rte_intr_enable->vfio_enable_msix->vfio_pci_ioctl->vfio_msi_enable->pci_alloc_irq_vectors/vfio_msi_set_vector_signal->request_irq

I am using the attached hack to overcome this. What is the correct way to
handle this? 
This is a hack as I am assigning "udev->info.irq = -1" when interrupt is
disabled to prevent uio_write from exiting.

kernel/linux/igb_uio/igb_uio.c: igbuio_pci_irqcontrol
igbuio_pci_disable_interrupts(udev);
udev->info.irq = -1; <-- Assigning to -1 and not 0.

Basically uio_write will not call igbuio_pci_enable_interrupts to enable the
interrupts back if irq is 0.

drivers/uio/uio.c: uio_write
if (!idev->info->irq) {
retval = -EIO;
goto out;
}
if (!idev->info->irqcontrol) {
retval = -ENOSYS;
goto out;
}
retval = idev->info->irqcontrol(idev->info, irq_on);


Regards
-Santosh

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [dpdk-dev] [EXT] Re: [PATCH v16 8/8] app/testpmd: add command to set supported ptype mask

[Jerin Jacob]

On Mon, Nov 11, 2019 at 10:26 AM Pavan Nikhilesh Bhagavatula
 wrote:
>
> >On Fri, Nov 8, 2019 at 7:24 PM Ananyev, Konstantin
> > wrote:
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: dev  On Behalf Of Ferruh Yigit
> >> > Sent: Thursday, November 7, 2019 7:41 PM
> >> > To: Jerin Jacob 
> >> > Cc: Pavan Nikhilesh ; Andrew
> >Rybchenko ; jer...@marvell.com;
> >> > tho...@monjalon.net; Lu, Wenzhuo ;
> >Wu, Jingjing ; Iremonger, Bernard
> >> > ; Mcnamara, John
> >; Kovacevic, Marko
> >;
> >> > dev@dpdk.org
> >> > Subject: Re: [dpdk-dev] [PATCH v16 8/8] app/testpmd: add
> >command to set supported ptype mask
> >> >
> >> > On 11/7/2019 6:55 PM, Jerin Jacob wrote:
> >> > >
> >> > >
> >> > > On Fri, 8 Nov, 2019, 12:10 am Ferruh Yigit,  >> > > > wrote:
> >> > >
> >> > > On 11/6/2019 7:18 PM, pbhagavat...@marvell.com
> >> > >  wrote:
> >> > > > From: Pavan Nikhilesh  >> > > >
> >> > > >
> >> > > > Add command to set supported ptype mask.
> >> > > > Usage:
> >> > > >   set port  ptype_mask >  /* ***
> >> > > >
> >> > > >  /* list of instructions */
> >> > > > @@ -19155,6 +19237,7 @@ cmdline_parse_ctx_t main_ctx[] =
> >{
> >> > > >   (cmdline_parse_inst_t *)&cmd_show_vf_stats,
> >> > > >   (cmdline_parse_inst_t *)&cmd_clear_vf_stats,
> >> > > >   (cmdline_parse_inst_t
> >*)&cmd_show_port_supported_ptypes,
> >> > > > + (cmdline_parse_inst_t *)&cmd_set_port_ptypes,
> >> > > >   (cmdline_parse_inst_t *)&cmd_ptype_mapping_get,
> >> > > >   (cmdline_parse_inst_t *)&cmd_ptype_mapping_replace,
> >> > > >   (cmdline_parse_inst_t *)&cmd_ptype_mapping_reset,
> >> > > > diff --git a/app/test-pmd/testpmd.c b/app/test-
> >pmd/testpmd.c
> >> > > > index 5ba974162..812aebf35 100644
> >> > > > --- a/app/test-pmd/testpmd.c
> >> > > > +++ b/app/test-pmd/testpmd.c
> >> > > > @@ -2024,6 +2024,7 @@ start_port(portid_t pid)
> >> > > >   queueid_t qi;
> >> > > >   struct rte_port *port;
> >> > > >   struct rte_ether_addr mac_addr;
> >> > > > + static uint8_t clr_ptypes = 1;
> >> > > >
> >> > > >   if (port_id_is_invalid(pid, ENABLED_WARN))
> >> > > >   return 0;
> >> > > > @@ -2153,6 +2154,10 @@ start_port(portid_t pid)
> >> > > >   }
> >> > > >   }
> >> > > >   configure_rxtx_dump_callbacks(verbose_level);
> >> > > > + if (clr_ptypes) {
> >> > > > + clr_ptypes = 0;
> >> > > > + rte_eth_dev_set_ptypes(pi,
> >RTE_PTYPE_UNKNOWN, NULL, 0);
> >> > > > + }
> >> > >
> >> > > I am not sure about this command, we have now capability to
> >set/disable ptypes
> >> > > on demand, why disabling them by default?
> >> > >
> >> > >
> >> > > As forward engines are not using the ptype offload. If a specific
> >forwa
> >> > > need the offload, it can be enabled.
> >>
> >> Well, at least now user can see ptype in pkt dump with 'set verbose >
> >0'
> >> It's definitely looks loke a a behavior change.
> >> Wonder why it can't be done visa-versa?
> >> Keep current behavior as default one (all ptypes are un-masked) and
> >> have special command to disable/enable ptypes.
> >> as I understand such command was added by these series. correct?
> >
> >IMO, we are following the principle that by default all offloads are
> >disabled and enable it
> >based on the need to have optimal performance across the DPDK. This
> >change will be
> >on the same theme.
> >
> >Regarding the verbose > 0 cases, I think, we can call
> >rte_eth_dev_set_ptypes() to all PTYPES on
> >the setting verbose callback.
>
> Agree verbose > 0 case we can do set_ptypes with
> RTE_PTYPE_ALL_MASK. But what if the user wants to verify
> rte_eth_dev_set_ptypes() call itself in verbose mode?.
> Example:
>
> set port 0 ptype_mask RTE_PTYPE_L3_MASK
> set verbose 1
>
> In this case user expects to see only L3 mask set. Wouldn’t it be confusing if
> we set RTE_PTYPE_ALL_MASK under the hood when verbose level is increased?

I thought of adding RTE_PTYPE_ALL_MASK in the callback to maintain the
existing behavior
if there is any concern in that area.

Either way is fine with me. (implicit RTE_PTYPE_ALL_MASK  in a
callback or explicit mask set in command line)

Re: [dpdk-dev] [PATCH v2 2/3] config: add arm neoverse N1 SDP configuration

[Gavin Hu (Arm Technology China)]

Hi Honnappa,

> -Original Message-
> From: Honnappa Nagarahalli 
> Sent: Tuesday, October 29, 2019 1:47 PM
> To: tho...@monjalon.net
> Cc: Jerin Jacob ; Ola Liljedahl
> ; Gavin Hu (Arm Technology China)
> ; dev@dpdk.org; pbhagavat...@marvell.com; nd
> ; jer...@marvell.com; hemant.agra...@nxp.com;
> bruce.richard...@intel.com; Honnappa Nagarahalli
> ; nd 
> Subject: RE: [dpdk-dev] [PATCH v2 2/3] config: add arm neoverse N1 SDP
> configuration
> 
> 
> 
> >
> > 28/10/2019 04:24, Honnappa Nagarahalli:
> > > > 23/10/2019 07:03, Jerin Jacob:
> > > > > On Wed, Oct 23, 2019 at 2:37 AM Honnappa Nagarahalli
> > > > >  wrote:
> > > > > > > > > On Thu, 2019-08-01 at 07:48 +0800, Gavin Hu wrote:
> > > > > > > > > > Arm N1 SDP is an infrastructure segment development
> > > > > > > > > > platform based on armv8.2-a Neoverse N1 CPU. For more
> > > > > > > > > > information, refer
> > > > to:
> > > > > > > > > > https://community.arm.com/developer/tools-software/oss-
> p
> > > > > > > > > > latf
> > > > > > > > > > orms/w
> > > > > > > > > > /
> > > > > > > > > > docs/440/neoverse-n1-sdp
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Gavin Hu 
> > > > > > > > > > Reviewed-by: Honnappa Nagarahalli
> > > > > > > > > > 
> > > > > > > > > > Reviewed-by: Steve Capper 
> > > > > > > > > > ---
> > > > > > > > > > +CONFIG_RTE_MACHINE="neoversen1"
> > > > > > > > > This should probably be "n1sdp" as this is the name of the
> > > > > > > > > platform that matches the below configuration.
> > > > > > > > A clear definition of RTE_MACHINE is required. Jerin?
> > > > > > >
> > > > > > > I think, In the existing scheme of things, RTE_MACHINE
> > > > > > > defines, where to take the MACHINE_CFLAGS
> > > > > > > mk/machine//rte.vars.mk
> > > > > > Ok, thank you
> > > > > >
> > > > > > >
> > > > > > > Considering the fact that there will be a lot of reusable
> > > > > > > IPs(for
> > > > > > > CPU) from ARM for  armv8, I think, it would make sense to
> > > > > > > introduce  RTE_MICRO_ARCH to avoid a lot of code duplications
> > > > > > > and
> > > > confusion.
> > > > > > >
> > > > > > > RTE_ARCH example: "x86" or "arm64"
> I see that there are already RTE_ARCH_X86, RTE_ARCH_ARM,
> RTE_ARCH_ARM64, RTE_ARCH_PPC_64 etc. I believe they should be
> sufficient.
> 
> > > > > > > RTE_MICRO_ARCH   example: "a72" or "thunderx3" -
> defines
> > > > > > > mcpu and armv8 verion arch etc
> Are you suggesting this just for Arm platforms?
> My understanding is your intention was to clean up the
> config/arm/meson.build file.
> 
> > > > > > > RTE_MACHINE   example: "bluefield" or 
> > > > > > > "thunderx3"
> > > > > > > - defines, number of cores, NUMA or not? etc
> > > > > > Looking at mk/machine/ directory, looks like RTE_MACHINE seems
> > > > > > to be
> > > > defining micro-architecture for Intel. For ex: hsw, nhm, wsm. I see
> > > > the same for Arm as well.
> > > > > > Are you suggesting that we use RTE_MICRO_ARCH to pick
> mk/micro-
> > > > arch//rte.vars.mk? and RTE_MACHINE would pick
> > > > mk/machine//rte.vars.mk, but contain NUMA, #of cores etc?
> > > > >
> > > > > Yes for Make build. I think, it is deprecated soon, so we need a
> > > > > similar solution for meson.
> > > >
> > > > Yes I would prefer we clean the mess in Meson, instead of talking
> > > > about the makefile system.
> > > > And honestly, N1 is not needed in the legacy makefile system.
> > > Unfortunately, most of the guys I talk to are still on makefile.
> >
> > You need to help them to switch.
> > Adding new targets in meson-only can be a good motivation :)
> >
> > > When is makefile system getting removed?
> >
> > It must be clearly decided and announced.
> > The previous techboard discussions were about making makefile hardly
> > usable during 2020, i.e. very soon.
> >
> > > > So focusing on config/arm/meson.build, I think RTE_MACHINE is
> > > > defined only for API compatibility with makefile.
> > > > However, I doubt this value is used by any application.
> > > > I think we can try to remove RTE_MACHINE from meson builds in
> DPDK
> > > > 19.11, or use RTE_MACHINE as micro-arch (my preference).
> > > 'MACHINE' means different things to different people, which is the root
> > cause of this discussion.
> > > 'MICRO-ARCH' has a very clear meaning. Do you see any problem going
> > with MICRO-ARCH instead?
> >
> > Some applications may use RTE_MACHINE for this purpose.
> > It is part of the API since the befinning of DPDK.
> > I don't see a real motivation to break this API now.
> The suggestions are not clear to me. The original suggestion was to
> introduce RTE_MICRO_ARCH and contain all the micro-architecture related
> compiler flags in that.
> Now, the suggestion is to use RTE_MACHINE to contain micro-architecture
> related compiler flags. Will it contain NUMA, number of cores as well (as
> suggested earlier)? If yes, I do not see it changing anything.
> 
> I am not a meson expert. Howev

Re: [dpdk-dev] [PATCH v13 2/5] eal: add the APIs to wait until equal

[Jerin Jacob]

On Sat, Nov 9, 2019 at 12:07 AM Ananyev, Konstantin
 wrote:
>
>
>
> > -Original Message-
> > From: Thomas Monjalon 
> > Sent: Friday, November 8, 2019 5:00 PM
> > To: Ananyev, Konstantin 
> > Cc: David Marchand ; dev@dpdk.org; n...@arm.com; 
> > Gavin Hu ; Mcnamara, John
> > ; Kovacevic, Marko ; 
> > Jerin Jacob ; Jan Viktorin
> > 
> > Subject: Re: [PATCH v13 2/5] eal: add the APIs to wait until equal
> >
> > 08/11/2019 17:38, Ananyev, Konstantin:
> > > > From: Gavin Hu 
> > > > +static __rte_always_inline void
> > > > +rte_wait_until_equal_64(volatile uint64_t *addr, uint64_t expected,
> > > > + int memorder)
> > > > +{
> > > > + uint64_t value;
> > > > +
> > > > + assert(memorder == __ATOMIC_ACQUIRE || memorder == __ATOMIC_RELAXED);
> > > > +
> > > > + /*
> > > > +  * Atomic exclusive load from addr, it returns the 64-bit content of
> > > > +  * *addr while making it 'monitored',when it is written by someone
> > > > +  * else, the 'monitored' state is cleared and a event is generated
> > > > +  * implicitly to exit WFE.
> > > > +  */
> > > > +#define __LOAD_EXC_64(src, dst, memorder) {  \
> > > > + if (memorder == __ATOMIC_RELAXED) {  \
> > > > + asm volatile("ldxr %x[tmp], [%x[addr]]"  \
> > > > + : [tmp] "=&r" (dst)  \
> > > > + : [addr] "r"(src)\
> > > > + : "memory"); \
> > > > + } else { \
> > > > + asm volatile("ldaxr %x[tmp], [%x[addr]]" \
> > > > + : [tmp] "=&r" (dst)  \
> > > > + : [addr] "r"(src)\
> > > > + : "memory"); \
> > > > + } }
> > > > +
> > > > + __LOAD_EXC_64(addr, value, memorder)
> > > > + if (value != expected) {
> > > > + __SEVL()
> > > > + do {
> > > > + __WFE()
> > > > + __LOAD_EXC_64(addr, value, memorder)
> > > > + } while (value != expected);
> > > > + }
> > > > +}
> > > > +#undef __LOAD_EXC_64
> > > > +
> > > > +#undef __SEVL
> > > > +#undef __WFE
> > >
> > > Personally I don't see how these define/undef are better then inline 
> > > functions...
> >
> > The benefit it to not pollute the API namespace
> > with some functions which are used only locally.
> > After using a macro, it disappears with #undef.
> >
> > > Again I suppose they might be re-used in future some other ARM specific 
> > > low-level primitvies.
> >
> > Do this low-level routines _LOAD_EXC_ need to be exposed in EAL for re-use?
>
> About load_exc don't know for sure...
> Though as I can see wfe/sevl are used here:
> http://patchwork.dpdk.org/patch/61779/
> Might be it is possible to reuse these functions/macros...
> But again, I am not arm expert, would be interested to know what arm guys 
> think.


Considering WFE has a requirement on using load_exec on ARM so IMO, it
makes sense to expose
load_exec in conjunction with wfe/sevl to use it properly.



>
> >
> > > My preference would be to keep them as inline function - much cleaner 
> > > code.
> > > But as I don't develop for/use, I wouldn't insist and let you and arm 
> > > guys to decide.
> >
> >
>

Re: [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd

[Ruifeng Wang (Arm Technology China)]

Hi David,

> -Original Message-
> From: David Marchand 
> Sent: Wednesday, November 6, 2019 22:04
> To: Ruifeng Wang (Arm Technology China) 
> Cc: Ananyev, Konstantin ; Honnappa
> Nagarahalli ; Kantecki, Tomasz
> ; dev@dpdk.org; Gavin Hu (Arm Technology
> China) ; nd 
> Subject: Re: [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd
> 
> Hello Ruifeng,
> 
> On Mon, Sep 16, 2019 at 4:30 AM Ruifeng Wang (Arm Technology China)
>  wrote:
> > > Not sure why it has to be  master core?
> > > Why interrupt thread wouldn't do?
> > > I think what we need to:
> > > 1. introduce reading routes from config file instead of having them
> > > hard- coded within the app.
> > > 2. add ability to update routes dynamically.
> > > Probably the easiest (and commonly used way) re-read conf file
> > > and update routes on the signal (SIGUSR1 or so).
> > > Konstantin
> > >
> > >
> > Sorry for delayed response. Just back from vacation.
> > Thanks for your suggestion.
> > I will try the config file based updating approach and get back with new
> version.
> 
> Any update on this series?

I heard different opinions on the approach. Currently no new version patch set 
available.
Will have more discussion before respin.
> 
> 
> --
> David Marchand

[dpdk-dev] [PATCH v3 3/3] config: add cortex-a76 configuration

[Gavin Hu]

To make the list complete and consistent, add cortex-a76 configuration.

Signed-off-by: Gavin Hu 
Reviewed-by: Honnappa Nagarahalli 
---
 config/arm/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index b56e442..b23dac1 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -90,6 +90,7 @@ machine_args_generic = [
['0xd08', ['-mcpu=cortex-a72']],
['0xd09', ['-mcpu=cortex-a73']],
['0xd0a', ['-mcpu=cortex-a75']],
+   ['0xd0b', ['-mcpu=cortex-a76']],
['0xd0c', ['-march=armv8.2-a+crc+crypto', '-mcpu=neoverse-n1'], 
flags_n1sdp_extra]]
 
 machine_args_cavium = [
-- 
2.7.4

[dpdk-dev] [PATCH v3 1/3] test/rcu: fix the compiling error for armv8.2

[Gavin Hu]

With "-march=armv8.2-a" specified, a compiling error generated:
app/test/test_rcu_qsbr.c:234:10: error: comparison of integer
expressions of different signedness: ‘unsigned int’ and ‘int’
[-Werror=sign-compare]

Fixes: b87089b0bb19 ("test/rcu: add API and functional tests")
Cc: sta...@dpdk.org

Signed-off-by: Gavin Hu 
Reviewed-by: Honnappa Nagarahalli 
Reviewed-by: Steve Capper 
---
 app/test/test_rcu_qsbr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test/test_rcu_qsbr.c b/app/test/test_rcu_qsbr.c
index 85d80e0..19229ac 100644
--- a/app/test/test_rcu_qsbr.c
+++ b/app/test/test_rcu_qsbr.c
@@ -230,7 +230,7 @@ test_rcu_qsbr_thread_unregister(void)
/* Update quiescent state counter */
for (i = 0; i < num_threads[j]; i++) {
/* Skip one update */
-   if (i == (RTE_MAX_LCORE - 10))
+   if (i == (unsigned int)(RTE_MAX_LCORE - 10))
continue;
rte_rcu_qsbr_quiescent(t[0],
(j == 2) ? (RTE_MAX_LCORE - 1) : i);
-- 
2.7.4

[dpdk-dev] [PATCH v3 2/3] config: add arm neoverse N1 SDP configuration

[Gavin Hu]

Arm N1 SDP is an infrastructure segment development platform
based on armv8.2-a Neoverse N1 CPU. For more information, refer to:
https://community.arm.com/developer/tools-software/oss-platforms/w/
docs/440/neoverse-n1-sdp

Signed-off-by: Gavin Hu 
Reviewed-by: Honnappa Nagarahalli 
Reviewed-by: Steve Capper 
---
V3
-change the configuration name from "neoversen1" to "n1sdp" to be platform
specific other than microarchitecture specific
-add the missing config/arm/arm64_n1sdp_linux-gcc file for meson build
---
 config/arm/arm64_n1sdp_linux_gcc  | 16 +++
 config/arm/meson.build|  9 +++-
 config/defconfig_arm64-n1sdp-linux-gcc|  1 +
 config/defconfig_arm64-n1sdp-linuxapp-gcc | 14 +
 mk/machine/n1sdp/rte.vars.mk  | 34 +++
 5 files changed, 73 insertions(+), 1 deletion(-)
 create mode 100644 config/arm/arm64_n1sdp_linux_gcc
 create mode 12 config/defconfig_arm64-n1sdp-linux-gcc
 create mode 100644 config/defconfig_arm64-n1sdp-linuxapp-gcc
 create mode 100644 mk/machine/n1sdp/rte.vars.mk

diff --git a/config/arm/arm64_n1sdp_linux_gcc b/config/arm/arm64_n1sdp_linux_gcc
new file mode 100644
index 000..83dad3d
--- /dev/null
+++ b/config/arm/arm64_n1sdp_linux_gcc
@@ -0,0 +1,16 @@
+[binaries]
+c = 'aarch64-linux-gnu-gcc'
+cpp = 'aarch64-linux-gnu-cpp'
+ar = 'aarch64-linux-gnu-gcc-ar'
+strip = 'aarch64-linux-gnu-strip'
+pcap-config = ''
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv8-a'
+endian = 'little'
+
+[properties]
+implementor_id = '0x41'
+implementor_pn = '0xd0c'
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 46dff3a..b56e442 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -57,6 +57,12 @@ flags_armada = [
['RTE_MAX_LCORE', 16]]
 
 flags_default_extra = []
+flags_n1sdp_extra = [
+   ['RTE_MACHINE', '"n1sdp"'],
+   ['RTE_MAX_NUMA_NODES', 1],
+   ['RTE_MAX_LCORE', 4],
+   ['RTE_EAL_NUMA_AWARE_HUGEPAGES', false],
+   ['RTE_LIBRTE_VHOST_NUMA', false]]
 flags_thunderx_extra = [
['RTE_MACHINE', '"thunderx"'],
['RTE_USE_C11_MEM_MODEL', false]]
@@ -83,7 +89,8 @@ machine_args_generic = [
['0xd07', ['-mcpu=cortex-a57']],
['0xd08', ['-mcpu=cortex-a72']],
['0xd09', ['-mcpu=cortex-a73']],
-   ['0xd0a', ['-mcpu=cortex-a75']]]
+   ['0xd0a', ['-mcpu=cortex-a75']],
+   ['0xd0c', ['-march=armv8.2-a+crc+crypto', '-mcpu=neoverse-n1'], 
flags_n1sdp_extra]]
 
 machine_args_cavium = [
['default', ['-march=armv8-a+crc+crypto','-mcpu=thunderx']],
diff --git a/config/defconfig_arm64-n1sdp-linux-gcc 
b/config/defconfig_arm64-n1sdp-linux-gcc
new file mode 12
index 000..103bbea
--- /dev/null
+++ b/config/defconfig_arm64-n1sdp-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm64-n1sdp-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm64-n1sdp-linuxapp-gcc 
b/config/defconfig_arm64-n1sdp-linuxapp-gcc
new file mode 100644
index 000..f913809
--- /dev/null
+++ b/config/defconfig_arm64-n1sdp-linuxapp-gcc
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Arm Ltd.
+#
+
+#include "defconfig_arm64-armv8a-linux-gcc"
+
+CONFIG_RTE_MACHINE="n1sdp"
+CONFIG_RTE_MAX_LCORE=4
+CONFIG_RTE_MAX_NUMA_NODES=1
+CONFIG_RTE_CACHE_LINE_SIZE=64
+
+# Doesn't support NUMA
+CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
+CONFIG_RTE_LIBRTE_VHOST_NUMA=n
diff --git a/mk/machine/n1sdp/rte.vars.mk b/mk/machine/n1sdp/rte.vars.mk
new file mode 100644
index 000..6d69de0
--- /dev/null
+++ b/mk/machine/n1sdp/rte.vars.mk
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Arm Ltd
+#
+
+#
+# machine:
+#
+#   - can define ARCH variable (overridden by cmdline value)
+#   - can define CROSS variable (overridden by cmdline value)
+#   - define MACHINE_CFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_LDFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_ASFLAGS variable (overridden by cmdline value)
+#   - can define CPU_CFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+#   - can define CPU_LDFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+#   - can define CPU_ASFLAGS variable (overridden by cmdline value) that
+# overrides the one defined in arch.
+#   - may override any previously defined variable
+#
+
+# ARCH =
+# CROSS =
+# MACHINE_CFLAGS =
+# MACHINE_LDFLAGS =
+# MACHINE_ASFLAGS =
+# CPU_CFLAGS =
+# CPU_LDFLAGS =
+# CPU_ASFLAGS =
+
+include $(RTE_SDK)/mk/rte.helper.mk
+
+MACHINE_CFLAGS += $(call rte_cc_has_argument, -march=armv8.2-a+crc+crypto)
+MACHINE_CFLAGS += $(call rte_cc_has_argument, -mcpu=neoverse-n1)
-- 
2.7.4

[dpdk-dev] [PATCH v3 0/3] add arm N1SDP and A76 configurations

[Gavin Hu]

Nerverse N1 is a new SoC based on armv8.2-a and with other advanced features.
N1 SDP is the infrastructure segment development platform with N1 SoC inside.
Here is more information about it:
https://community.arm.com/developer/tools-software/oss-platforms/w/docs/440/neoverse-n1-sdp

V3
-change the configuration name from "neoversen1" to "n1sdp" to be platform 
specific other than microarchitecture specific
-add the missing config/arm/arm64_n1sdp_linux-gcc file for meson build
V2:
-add the cover letter and the patch for cortex-a76 configuration

Gavin Hu (3):
  test/rcu: fix the compiling error for armv8.2
  config: add arm neoverse N1 SDP configuration
  config: add cortex-a76 configuration

 app/test/test_rcu_qsbr.c  |  2 +-
 config/arm/arm64_n1sdp_linux_gcc  | 16 +++
 config/arm/meson.build| 10 -
 config/defconfig_arm64-n1sdp-linux-gcc|  1 +
 config/defconfig_arm64-n1sdp-linuxapp-gcc | 14 +
 mk/machine/n1sdp/rte.vars.mk  | 34 +++
 6 files changed, 75 insertions(+), 2 deletions(-)
 create mode 100644 config/arm/arm64_n1sdp_linux_gcc
 create mode 12 config/defconfig_arm64-n1sdp-linux-gcc
 create mode 100644 config/defconfig_arm64-n1sdp-linuxapp-gcc
 create mode 100644 mk/machine/n1sdp/rte.vars.mk

-- 
2.7.4

[dpdk-dev] [PATCH] net/octeontx2: fix ptp configurations for VF

[Harman Kalra]

Issue has been observed if PTP is already enabled on PF and
later VFs are configured. Since PTP requires mbuf data off
to be shifted by 8 bytes, due to this l3fwd/l2fwd was not
working with VFs.
Also some extra garbage bytes were observed in packet data
when ptp was enabled.

Fixes: b5dc3140448e ("net/octeontx2: support base PTP")

Signed-off-by: Harman Kalra 
---
 drivers/common/octeontx2/otx2_mbox.h|  1 +
 drivers/net/octeontx2/otx2_ethdev.c | 13 -
 drivers/net/octeontx2/otx2_ethdev.h |  1 +
 drivers/net/octeontx2/otx2_ethdev_ops.c |  2 +
 drivers/net/octeontx2/otx2_ptp.c| 68 ++---
 drivers/net/octeontx2/otx2_rx.h |  2 +
 6 files changed, 79 insertions(+), 8 deletions(-)

diff --git a/drivers/common/octeontx2/otx2_mbox.h 
b/drivers/common/octeontx2/otx2_mbox.h
index c2a9e9fe6..e0e4e2f63 100644
--- a/drivers/common/octeontx2/otx2_mbox.h
+++ b/drivers/common/octeontx2/otx2_mbox.h
@@ -723,6 +723,7 @@ struct nix_lf_alloc_rsp {
uint8_t __otx2_io lf_tx_stats; /* NIX_AF_CONST1::LF_TX_STATS */
uint16_t __otx2_io cints; /* NIX_AF_CONST2::CINTS */
uint16_t __otx2_io qints; /* NIX_AF_CONST2::QINTS */
+   uint8_t __otx2_io hw_rx_tstamp_en; /*set if rx timestamping enabled */
 };
 
 struct nix_lf_free_req {
diff --git a/drivers/net/octeontx2/otx2_ethdev.c 
b/drivers/net/octeontx2/otx2_ethdev.c
index aab34dbcf..9274dbb96 100644
--- a/drivers/net/octeontx2/otx2_ethdev.c
+++ b/drivers/net/octeontx2/otx2_ethdev.c
@@ -86,6 +86,7 @@ nix_lf_alloc(struct otx2_eth_dev *dev, uint32_t nb_rxq, 
uint32_t nb_txq)
dev->cints = rsp->cints;
dev->qints = rsp->qints;
dev->npc_flow.channel = dev->rx_chan_base;
+   dev->ptp_en = rsp->hw_rx_tstamp_en;
 
return 0;
 }
@@ -1899,7 +1900,11 @@ otx2_nix_dev_start(struct rte_eth_dev *eth_dev)
struct otx2_eth_dev *dev = otx2_eth_pmd_priv(eth_dev);
int rc, i;
 
-   if (eth_dev->data->nb_rx_queues != 0) {
+   /* MTU recalculate should be avoided here if PTP is enabled by PF, as
+* otx2_nix_recalc_mtu would be invoked during otx2_nix_ptp_enable_vf
+* call below.
+*/
+   if (eth_dev->data->nb_rx_queues != 0 && !otx2_ethdev_is_ptp_en(dev)) {
rc = otx2_nix_recalc_mtu(eth_dev);
if (rc)
return rc;
@@ -1935,6 +1940,12 @@ otx2_nix_dev_start(struct rte_eth_dev *eth_dev)
else
otx2_nix_timesync_disable(eth_dev);
 
+   /* Update VF about data off shifted by 8 bytes if PTP already
+* enabled in PF owning this VF
+*/
+   if (otx2_ethdev_is_ptp_en(dev) && otx2_dev_is_vf(dev))
+   otx2_nix_ptp_enable_vf(eth_dev);
+
rc = npc_rx_enable(dev);
if (rc) {
otx2_err("Failed to enable NPC rx %d", rc);
diff --git a/drivers/net/octeontx2/otx2_ethdev.h 
b/drivers/net/octeontx2/otx2_ethdev.h
index b49e309fd..d369d4dc5 100644
--- a/drivers/net/octeontx2/otx2_ethdev.h
+++ b/drivers/net/octeontx2/otx2_ethdev.h
@@ -562,5 +562,6 @@ int otx2_nix_timesync_read_time(struct rte_eth_dev *eth_dev,
 int otx2_eth_dev_ptp_info_update(struct otx2_dev *dev, bool ptp_en);
 int otx2_nix_read_clock(struct rte_eth_dev *eth_dev, uint64_t *time);
 int otx2_nix_raw_clock_tsc_conv(struct otx2_eth_dev *dev);
+void otx2_nix_ptp_enable_vf(struct rte_eth_dev *eth_dev);
 
 #endif /* __OTX2_ETHDEV_H__ */
diff --git a/drivers/net/octeontx2/otx2_ethdev_ops.c 
b/drivers/net/octeontx2/otx2_ethdev_ops.c
index d1e77c324..45b5c5185 100644
--- a/drivers/net/octeontx2/otx2_ethdev_ops.c
+++ b/drivers/net/octeontx2/otx2_ethdev_ops.c
@@ -16,6 +16,8 @@ otx2_nix_mtu_set(struct rte_eth_dev *eth_dev, uint16_t mtu)
struct nix_frs_cfg *req;
int rc;
 
+   frame_size += NIX_TIMESYNC_RX_OFFSET * otx2_ethdev_is_ptp_en(dev);
+
/* Check if MTU is within the allowed range */
if (frame_size < NIX_MIN_FRS || frame_size > NIX_MAX_FRS)
return -EINVAL;
diff --git a/drivers/net/octeontx2/otx2_ptp.c b/drivers/net/octeontx2/otx2_ptp.c
index f13f0408a..f34b9339c 100644
--- a/drivers/net/octeontx2/otx2_ptp.c
+++ b/drivers/net/octeontx2/otx2_ptp.c
@@ -8,6 +8,38 @@
 
 #define PTP_FREQ_ADJUST (1 << 9)
 
+/* Function to enable ptp config for VFs */
+void
+otx2_nix_ptp_enable_vf(struct rte_eth_dev *eth_dev)
+{
+   struct otx2_eth_dev *dev = otx2_eth_pmd_priv(eth_dev);
+
+   if (otx2_nix_recalc_mtu(eth_dev))
+   otx2_err("Failed to set MTU size for ptp");
+
+   dev->scalar_ena = true;
+   dev->rx_offload_flags |= NIX_RX_OFFLOAD_TSTAMP_F;
+
+   /* Setting up the function pointers as per new offload flags */
+   otx2_eth_set_rx_function(eth_dev);
+   otx2_eth_set_tx_function(eth_dev);
+}
+
+static uint16_t
+nix_eth_ptp_vf_burst(void *queue, struct rte_mbuf **mbufs, uint16_t pkts)
+{
+   struct otx2_eth_rxq *rxq = queue;
+   struct rte_eth_dev *eth_dev;
+
+   RTE_SET_USED(mbufs);
+  

Re: [dpdk-dev] [PATCH v13 2/5] eal: add the APIs to wait until equal

[Gavin Hu (Arm Technology China)]

> -Original Message-
> From: Jerin Jacob 
> Sent: Monday, November 11, 2019 1:12 PM
> To: Ananyev, Konstantin 
> Cc: tho...@monjalon.net; David Marchand
> ; dev@dpdk.org; nd ; Gavin
> Hu (Arm Technology China) ; Mcnamara, John
> ; Kovacevic, Marko
> ; jer...@marvell.com; Jan Viktorin
> 
> Subject: Re: [dpdk-dev] [PATCH v13 2/5] eal: add the APIs to wait until
> equal
> 
> On Sat, Nov 9, 2019 at 12:07 AM Ananyev, Konstantin
>  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Thomas Monjalon 
> > > Sent: Friday, November 8, 2019 5:00 PM
> > > To: Ananyev, Konstantin 
> > > Cc: David Marchand ; dev@dpdk.org;
> n...@arm.com; Gavin Hu ; Mcnamara, John
> > > ; Kovacevic, Marko
> ; Jerin Jacob ; Jan
> Viktorin
> > > 
> > > Subject: Re: [PATCH v13 2/5] eal: add the APIs to wait until equal
> > >
> > > 08/11/2019 17:38, Ananyev, Konstantin:
> > > > > From: Gavin Hu 
> > > > > +static __rte_always_inline void
> > > > > +rte_wait_until_equal_64(volatile uint64_t *addr, uint64_t expected,
> > > > > + int memorder)
> > > > > +{
> > > > > + uint64_t value;
> > > > > +
> > > > > + assert(memorder == __ATOMIC_ACQUIRE || memorder ==
> __ATOMIC_RELAXED);
> > > > > +
> > > > > + /*
> > > > > +  * Atomic exclusive load from addr, it returns the 64-bit content of
> > > > > +  * *addr while making it 'monitored',when it is written by someone
> > > > > +  * else, the 'monitored' state is cleared and a event is generated
> > > > > +  * implicitly to exit WFE.
> > > > > +  */
> > > > > +#define __LOAD_EXC_64(src, dst, memorder) {  \
> > > > > + if (memorder == __ATOMIC_RELAXED) {  \
> > > > > + asm volatile("ldxr %x[tmp], [%x[addr]]"  \
> > > > > + : [tmp] "=&r" (dst)  \
> > > > > + : [addr] "r"(src)\
> > > > > + : "memory"); \
> > > > > + } else { \
> > > > > + asm volatile("ldaxr %x[tmp], [%x[addr]]" \
> > > > > + : [tmp] "=&r" (dst)  \
> > > > > + : [addr] "r"(src)\
> > > > > + : "memory"); \
> > > > > + } }
> > > > > +
> > > > > + __LOAD_EXC_64(addr, value, memorder)
> > > > > + if (value != expected) {
> > > > > + __SEVL()
> > > > > + do {
> > > > > + __WFE()
> > > > > + __LOAD_EXC_64(addr, value, memorder)
> > > > > + } while (value != expected);
> > > > > + }
> > > > > +}
> > > > > +#undef __LOAD_EXC_64
> > > > > +
> > > > > +#undef __SEVL
> > > > > +#undef __WFE
> > > >
> > > > Personally I don't see how these define/undef are better then inline
> functions...
> > >
> > > The benefit it to not pollute the API namespace
> > > with some functions which are used only locally.
> > > After using a macro, it disappears with #undef.
> > >
> > > > Again I suppose they might be re-used in future some other ARM
> specific low-level primitvies.
> > >
> > > Do this low-level routines _LOAD_EXC_ need to be exposed in EAL for re-
> use?
> >
> > About load_exc don't know for sure...
> > Though as I can see wfe/sevl are used here:
> > http://patchwork.dpdk.org/patch/61779/
> > Might be it is possible to reuse these functions/macros...
> > But again, I am not arm expert, would be interested to know what arm
> guys think.
> 
> 
> Considering WFE has a requirement on using load_exec on ARM so IMO, it
> makes sense to expose
> load_exec in conjunction with wfe/sevl to use it properly.
Agree, WFE should have more use cases can be developed, not limited to the 
WAIT_UNTIL_EQUAL_XX APIs. Marvel's patch is an example.
Sorry I don't have more use case so far, but Arm is evolving WFE, so I think 
more use cases are emerging. 
/Gavin
> 
> 
> >
> > >
> > > > My preference would be to keep them as inline function - much
> cleaner code.
> > > > But as I don't develop for/use, I wouldn't insist and let you and arm
> guys to decide.
> > >
> > >
> >

Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support API to set max LRO packet size

[Matan Azrad]

Hi

From: Ananyev, Konstantin
> Hi Matan,
> 
> > > > > > > > >  On 11/7/2019 12:35 PM, Dekel Peled wrote:
> > > > > > > > > > @@ -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;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > 
> > > > > > > > >  This check forces applications that enable LRO to
> > > > > > > > >  provide
> > > > > > > > > >> 'max_lro_pkt_size'
> > > > > > > > >  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
> > > > > > > > > >> 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.
> > > > > > > > > >
> > > > > > > > > >>>
> > > > > > > > >  - 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.
> > > > > > > > > >>>
> > > > > > > > >  - 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.
> > > > > > > > > >
> > > > > > > > > >> 2) Are we making this filed mandatory to provide for
> > > > > > > > > >> PMDs, it is easy to

Re: [dpdk-dev] [PATCH] net/mlx5: fix compiling without definition

[Slava Ovsiienko]

> -Original Message-
> From: Bing Zhao 
> Sent: Sunday, November 10, 2019 18:37
> To: Slava Ovsiienko ; Raslan Darawsheh
> 
> Cc: Ori Kam ; dev@dpdk.org
> Subject: [PATCH] net/mlx5: fix compiling without definition
> 
> When compiling the driver without macro for direct rules, the flow table
> reference count should also be in the flow table resource structure.
> 
> Fixes: c7455199284a ("net/mlx5: reorganize flow tables with hash list")
> 
> Signed-off-by: Bing Zhao 
Acked-by: Viacheslav Ovsiienko 

Re: [dpdk-dev] [PATCH] mk: add support for UBSAN

[Thomas Monjalon]

Hi,

Sorry for the very late review.
I hope someone else would try it.

I tried this:
devtools/test-build.sh -v x86_64-native-linux-clang+shared+UBSAN+SANITIZE_ALL
and it triggers some link errors:
/usr/bin/ld: rte_kvargs.c:(.text+0xc65): undefined reference to 
`__ubsan_handle_pointer_overflow'


19/08/2019 15:48, Harman Kalra:
> UndefinedBehaviorSanitizer (UBSan) is a fast undefined behavior
> detector. UBSan modifies the program at compile-time to catch
> various kinds of undefined behavior during program execution.
> 
> This patch implements support for UBSan to the DPDK.
> 
> See: doc/guides/prog_guide/ubsan.rst for more information.
> 
> Signed-off-by: Harman Kalra 
> ---
> +ifeq ($(CONFIG_RTE_UBSAN),y)
> +ifeq ($(UBSAN_ENABLE),y)

This can be replaced with an oneline:

ifeq ($(CONFIG_RTE_UBSAN)$(UBSAN_ENABLE),yy)

[dpdk-dev] [PATCH v2] ethdev: reserve space in main structs for extension

[Thomas Monjalon]

In order to allow smooth addition of features without breaking
ABI compatibility, some space is reserved in several core structs
of ethdev API.

The struct rte_eth_dev and rte_eth_dev_data are supposed
to be used internally only, but there is a chance that
increasing their size would break ABI for some applications.

Signed-off-by: Thomas Monjalon 
---
v2: padding more struct (config and get_info)

Note: previous acks are not kept in order to request an explicit
review of these new changes.
---
 lib/librte_ethdev/rte_ethdev.h  | 15 +++
 lib/librte_ethdev/rte_ethdev_core.h |  6 ++
 2 files changed, 21 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 44d77b332e..4ba01905c5 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -402,6 +402,9 @@ struct rte_eth_rxmode {
 * structure are allowed to be set.
 */
uint64_t offloads;
+
+   uint64_t reserved_64s[2]; /**< Reserved for future fields */
+   void *reserved_ptrs[2];   /**< Reserved for future fields */
 };
 
 /**
@@ -802,6 +805,9 @@ struct rte_eth_txmode {
/**< If set, reject sending out untagged pkts */
hw_vlan_insert_pvid : 1;
/**< If set, enable port based VLAN insertion */
+
+   uint64_t reserved_64s[2]; /**< Reserved for future fields */
+   void *reserved_ptrs[2];   /**< Reserved for future fields */
 };
 
 /**
@@ -818,6 +824,9 @@ struct rte_eth_rxconf {
 * fields on rte_eth_dev_info structure are allowed to be set.
 */
uint64_t offloads;
+
+   uint64_t reserved_64s[2]; /**< Reserved for future fields */
+   void *reserved_ptrs[2];   /**< Reserved for future fields */
 };
 
 /**
@@ -836,6 +845,9 @@ struct rte_eth_txconf {
 * fields on rte_eth_dev_info structure are allowed to be set.
 */
uint64_t offloads;
+
+   uint64_t reserved_64s[2]; /**< Reserved for future fields */
+   void *reserved_ptrs[2];   /**< Reserved for future fields */
 };
 
 /**
@@ -1260,6 +1272,9 @@ struct rte_eth_dev_info {
 * embedded managed interconnect/switch.
 */
struct rte_eth_switch_info switch_info;
+
+   uint64_t reserved_64s[2]; /**< Reserved for future fields */
+   void *reserved_ptrs[2];   /**< Reserved for future fields */
 };
 
 /**
diff --git a/lib/librte_ethdev/rte_ethdev_core.h 
b/lib/librte_ethdev/rte_ethdev_core.h
index f215af7c94..4d52be6121 100644
--- a/lib/librte_ethdev/rte_ethdev_core.h
+++ b/lib/librte_ethdev/rte_ethdev_core.h
@@ -785,6 +785,9 @@ struct rte_eth_dev {
struct rte_eth_rxtx_callback *pre_tx_burst_cbs[RTE_MAX_QUEUES_PER_PORT];
enum rte_eth_dev_state state; /**< Flag indicating the port state */
void *security_ctx; /**< Context for security ops */
+
+   uint64_t reserved_64s[4]; /**< Reserved for future fields */
+   void *reserved_ptrs[4];   /**< Reserved for future fields */
 } __rte_cache_aligned;
 
 struct rte_eth_dev_sriov;
@@ -851,6 +854,9 @@ struct rte_eth_dev_data {
/**< Switch-specific identifier.
 *   Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
 */
+
+   uint64_t reserved_64s[4]; /**< Reserved for future fields */
+   void *reserved_ptrs[4];   /**< Reserved for future fields */
 } __rte_cache_aligned;
 
 /**
-- 
2.23.0

Re: [dpdk-dev] [PATCH v5 3/3] app/testpmd: use API to set max LRO packet size

[Dekel Peled]

Thanks, PSB.

> -Original Message-
> From: Ananyev, Konstantin 
> Sent: Monday, November 11, 2019 1:11 AM
> To: Dekel Peled ; Mcnamara, John
> ; Kovacevic, Marko
> ; nhor...@tuxdriver.com;
> ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; Burakov,
> Anatoly ; xuanziya...@huawei.com;
> cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com; Lu, Wenzhuo
> ; Matan Azrad ; Shahaf
> Shuler ; Slava Ovsiienko
> ; rm...@marvell.com;
> shsha...@marvell.com; maxime.coque...@redhat.com; Bie, Tiwei
> ; Wang, Zhihong ;
> yongw...@vmware.com; Thomas Monjalon ; Yigit,
> Ferruh ; arybche...@solarflare.com; Wu, Jingjing
> ; Iremonger, Bernard
> 
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v5 3/3] app/testpmd: use API to set max LRO packet size
> 
> 
> >
> > 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 
> > Acked-by: Bernard Iremonger 
> > Acked-by: Matan Azrad 
> > ---
> >  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(+)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > 78c6899..2206a70 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -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 ",
> > +   .tokens = {
> > +   (void *)&cmd_config_max_lro_pkt

Re: [dpdk-dev] [PATCH v5 1/3] ethdev: support API to set max LRO packet size

[Dekel Peled]

Thnaks, PSB.

> -Original Message-
> From: Ananyev, Konstantin 
> Sent: Monday, November 11, 2019 1:08 AM
> To: Dekel Peled ; Mcnamara, John
> ; Kovacevic, Marko
> ; nhor...@tuxdriver.com;
> ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; Burakov,
> Anatoly ; xuanziya...@huawei.com;
> cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com; Lu, Wenzhuo
> ; Matan Azrad ; Shahaf
> Shuler ; Slava Ovsiienko
> ; rm...@marvell.com;
> shsha...@marvell.com; maxime.coque...@redhat.com; Bie, Tiwei
> ; Wang, Zhihong ;
> yongw...@vmware.com; Thomas Monjalon ; Yigit,
> Ferruh ; arybche...@solarflare.com; Wu, Jingjing
> ; Iremonger, Bernard
> 
> Cc: dev@dpdk.org
> Subject: RE: [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]
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> >
> es.dpdk.org%2Fpatch%2F58217%2F&data=02%7C01%7Cdekelp%40mell
> anox.co
> >
> m%7Cc12f78c6bd3d48bc223008d76632cd0f%7Ca652971c7d2e4d9ba6a4d1492
> 56f461
> >
> b%7C0%7C0%7C637090240692948792&sdata=pU6LJBYDmlzPFzHc%2FQlF
> UVXpGuv
> > ulTcl%2F29GsXdvBF8%3D&reserved=0
> > [2]
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> >
> es.dpdk.org%2Fpatch%2F57492%2F&data=02%7C01%7Cdekelp%40mell
> anox.co
> >
> m%7Cc12f78c6bd3d48bc223008d76632cd0f%7Ca652971c7d2e4d9ba6a4d1492
> 56f461
> >
> b%7C0%7C0%7C637090240692958790&sdata=VegV5HcYhkabDgcOF29u
> %2FFLq25I
> > %2BEDZTaEn20A2t2Wo%3D&reserved=0
> 
> 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.

> 
> Konstantin
> 
> >
> > Signed-off-by: Dekel Peled 
> > Reviewed-by: Andrew Rybchenko 
> > Acked-by: Thomas Monjalon 
> > Acked-by: Matan Azrad 
> > ---
> >  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(-)
> >
> > diff --git a/doc/guides/nics/features.rst
> > b/doc/guides/nics/features.rst index 7a31cf7..2138ce3 100644
> > --- a/doc/guides/nics/features.rst
> > +++ b/doc/guides/nics/features.rst
> > @@ -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:
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index c10dc30..fdec33d 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -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`

Re: [dpdk-dev] [PATCH 1/2] examples/l3fwd: increase number of routes

[Pavan Nikhilesh Bhagavatula]

>On Wed, Oct 30, 2019 at 6:23 AM  wrote:
>>
>> From: Pavan Nikhilesh 
>>
>> Increase the number of routes from 8 to 16 that are statically added
>for
>> lpm and em mode as most of the SoCs support more than 8
>interfaces.
>>
>> Signed-off-by: Pavan Nikhilesh 
>> ---
>>  examples/l3fwd/l3fwd_em.c  | 72
>++
>>  examples/l3fwd/l3fwd_lpm.c | 16 +
>>  2 files changed, 88 insertions(+)
>>
>> diff --git a/examples/l3fwd/l3fwd_em.c
>b/examples/l3fwd/l3fwd_em.c
>> index 74a7c8fa4..c07a5b937 100644
>> --- a/examples/l3fwd/l3fwd_em.c
>> +++ b/examples/l3fwd/l3fwd_em.c
>> @@ -103,6 +103,18 @@ static struct ipv4_l3fwd_em_route
>ipv4_l3fwd_em_route_array[] = {
>> {{RTE_IPV4(201, 0, 0, 0), RTE_IPV4(200, 20, 0, 1),  102, 12,
>IPPROTO_TCP}, 1},
>> {{RTE_IPV4(111, 0, 0, 0), RTE_IPV4(100, 30, 0, 1),  101, 11,
>IPPROTO_TCP}, 2},
>> {{RTE_IPV4(211, 0, 0, 0), RTE_IPV4(200, 40, 0, 1),  102, 12,
>IPPROTO_TCP}, 3},
>> +   {{RTE_IPV4(121, 0, 0, 0), RTE_IPV4(100, 10, 0, 1),  101, 11,
>IPPROTO_TCP}, 4},
>> +   {{RTE_IPV4(221, 0, 0, 0), RTE_IPV4(200, 20, 0, 1),  102, 12,
>IPPROTO_TCP}, 5},
>> +   {{RTE_IPV4(131, 0, 0, 0), RTE_IPV4(100, 30, 0, 1),  101, 11,
>IPPROTO_TCP}, 6},
>> +   {{RTE_IPV4(231, 0, 0, 0), RTE_IPV4(200, 40, 0, 1),  102, 12,
>IPPROTO_TCP}, 7},
>> +   {{RTE_IPV4(141, 0, 0, 0), RTE_IPV4(100, 30, 0, 1),  101, 11,
>IPPROTO_TCP}, 8},
>> +   {{RTE_IPV4(241, 0, 0, 0), RTE_IPV4(200, 40, 0, 1),  102, 12,
>IPPROTO_TCP}, 9},
>> +   {{RTE_IPV4(151, 0, 0, 0), RTE_IPV4(100, 30, 0, 1),  101, 11,
>IPPROTO_TCP}, 10},
>> +   {{RTE_IPV4(251, 0, 0, 0), RTE_IPV4(200, 40, 0, 1),  102, 12,
>IPPROTO_TCP}, 11},
>> +   {{RTE_IPV4(161, 0, 0, 0), RTE_IPV4(100, 30, 0, 1),  101, 11,
>IPPROTO_TCP}, 12},
>> +   {{RTE_IPV4(261, 0, 0, 0), RTE_IPV4(200, 40, 0, 1),  102, 12,
>IPPROTO_TCP}, 13},
>
>Am I reading this correctly ? 261.0.0.0 ?

My bad. Do you think it's better to change the address to198.18.0.0/15 
block as it
would be inline with RFC as well as LPM addresses? 

>
>
>--
>David Marchand

[dpdk-dev] [PATCH v2] net/ice: fix RSS rule destroy

[Simei Su]

This patch changes RSS rule destroy interface from ice_rem_vsi_rss_cfg()
to ice_rem_rss_cfg(). To coordinate with input set change, it should
destroy a specific flow rule but not all vsi cfg.

Fixes: 5ad3db8d4bdd ("net/ice: enable advanced RSS")

Signed-off-by: Simei Su 
---
 drivers/net/ice/ice_hash.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index 8dc3146..57e7d55 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -530,7 +530,8 @@ struct ice_hash_match_type ice_hash_type_list[] = {
(1 << VSIQF_HASH_CTL_HASH_SCHEME_S);
ICE_WRITE_REG(hw, VSIQF_HASH_CTL(vsi->vsi_id), reg);
} else {
-   ret = ice_rem_vsi_rss_cfg(hw, vsi->idx);
+   ret = ice_rem_rss_cfg(hw, vsi->idx,
+   filter_ptr->hashed_flds, filter_ptr->packet_hdr);
if (ret) {
rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
-- 
1.8.3.1