From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9CF0BA04B5; Tue, 22 Sep 2020 17:55:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 58B011D665; Tue, 22 Sep 2020 17:55:13 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id EEA691D5EB for ; Tue, 22 Sep 2020 17:55:10 +0200 (CEST) IronPort-SDR: oB9FxXSjuhVAoCM4IsaVdrSvII2tHmZv6Lmh6cevwzoVTZZay+B8S4yCLJTSUE5KpBNSjxI7v9 q8GT9j3ZxkHA== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="140111365" X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="140111365" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 08:55:09 -0700 IronPort-SDR: DPbpBFBQGAyOhWSSS7WJHuGO5shDJUN00d08L3IZ83P68vMapeujFJXB7wQIZYJmZfzqwUMAn/ cngklvSV89nA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="342067958" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga002.fm.intel.com with ESMTP; 22 Sep 2020 08:55:09 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 22 Sep 2020 08:55:08 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 22 Sep 2020 08:55:08 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.168) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 22 Sep 2020 08:55:05 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IHo60dzkDiC7G4sa4+XLpn1nF5uHdKzvAJWGhwVmH8THFuI/n/0wwHLjhwFtOMvPhjTdlJ8n6hngCDrooSlLG0rKtjMwNieHMdYegW8d/shuKwxMsLd8pnonTNxTFeVBetuwdJzLwndT+yb/8/Ze81DVQZAkLtxL2tZpRyTWisBidbb0ysyStoCOjKCHAZV6cuKL+bHd4/HXG80LlIQ+YjuA+EFd7HAdE+ngJcE7sR8wILwiB0nvUiailRgT8AaKrDqUDdJKSn73dIUKad8LCrwMb5Rc4z1C2JyUr/lOSOJeLcGYFhHVRbXDVY1Sl7Iu0gSqNN6UD+Q9Gcv5PlGpiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iG/RZRwtEMex7Hj61OV7ayHORQTQTUXduCJXtVh2P/k=; b=gXAOxJ/HyBsVJs27A5IhKyZUzrDr2HEDRt4xm8Ypz9GDL6PE6m2SiKqZspBsg2PkLCkALiBv9+FDuLCs+dloKdRMqda6d2cM7wcf3i2r2dDcug5BjpO/lC8IwpLifaq93JaklzcHR+H3uaUR8eBIQHoFUxCd5siG5rnPHeROkNTLftznv+fNJj/mDhlGXwhV3sf6VtSjw756rFBfZiQR/RZXTbzxtvDUBpSeJWFJ06482xzqd/drOFYikTfWO63YEEfYwXSKETDo8xEwp96tKdzNjrGbkVzaGnmUhk/MGMZHW2bMWujcItwZYA/B4aoZXKP1O4+/tPQdVW0eKStXWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iG/RZRwtEMex7Hj61OV7ayHORQTQTUXduCJXtVh2P/k=; b=E+ixszuyZV7946A7tvvRK8THO0xCMCw9Dpp5grBe2A+JfQOv0IK86NGJgChc3ydjd0bvMwWTGcbvvo9tbXcAlL7soSNuGSAl9VBmw4cGQx4Kyp+QWX3g/4mt211NuxtOO+LBMoY9FjWUBY6EaNK0qSiywdgbOHiCMmGBf9q8u00= Received: from SN6PR11MB3103.namprd11.prod.outlook.com (2603:10b6:805:d7::13) by SN6PR11MB3150.namprd11.prod.outlook.com (2603:10b6:805:d1::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.22; Tue, 22 Sep 2020 15:55:04 +0000 Received: from SN6PR11MB3103.namprd11.prod.outlook.com ([fe80::dd10:fbd6:99e9:52f4]) by SN6PR11MB3103.namprd11.prod.outlook.com ([fe80::dd10:fbd6:99e9:52f4%4]) with mapi id 15.20.3391.027; Tue, 22 Sep 2020 15:55:04 +0000 From: "McDaniel, Timothy" To: "dev@dpdk.org" Thread-Topic: dev Digest, Vol 318, Issue 122 Thread-Index: AQHWkPdycJRVdV6MjkqkrJB4Fligyql0z3yw Date: Tue, 22 Sep 2020 15:55:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: dpdk.org; dkim=none (message not signed) header.d=none;dpdk.org; dmarc=none action=none header.from=intel.com; x-originating-ip: [162.251.9.49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b49f84de-0da7-457f-f617-08d85f0fdf24 x-ms-traffictypediagnostic: SN6PR11MB3150: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1HhSROCOyar2fN03GDGSpy1nO3gttVViK9m5oT+lyuySfqH/p9FA/6Pxb1/gNKLN35dyAd3vvrhQTUqwd2jSIS8hno8pz+gNtRS8nt3g/rYJNK7oKeQS5X4cghIfMX/bnkDFA5BcjEazTfBlqXzhlhkU3OPvqkPsT5kJODN4XZJkJDFXGwGAaUHK2cPjbLomImOdJ6tyNJ4xg9dxZEj8d/gV/fDg9E5ajCCPEnmmoH7Dql86gB2P2uXhcWSK9AvkT9D1oPunQ1etYPajHTm1zBQHywyECmjMJZwx/+9OeMbvM1wl6WV13P/26os6lRIk72mii7/Y0OjZwKK/hEquwBxBbYqx5f0e9/l0VpmH5Rsm6Q+vggFf+1oLcoZFz+8IEC4E0v/ib9a+lmuGO+O8S3npYMsz7l8cLjvzX+3RX7DNbTrtKuVkexVan5/nnowJAHHOcZcRnS1LyVmP245yNkUMsnG7QyJ3ORzqG5qjziiwFiNmU6w6m3/bzmDB2a1P x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3103.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39850400004)(136003)(366004)(376002)(346002)(2906002)(55016002)(316002)(966005)(6916009)(8676002)(83380400001)(478600001)(8936002)(45080400002)(76116006)(71200400001)(66556008)(66446008)(33656002)(66476007)(64756008)(26005)(186003)(5660300002)(52536014)(53546011)(9686003)(86362001)(7696005)(30864003)(66946007)(6506007)(21314003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 6BrwAfL1fYZyjQs56rr1/lzp8gOBEMaF1IMXVO9L51gIdr3RCn8uhIO+e4JZMLJP5pBKil/Bg9JSCE35JBPMH9AYnRmAOiqyJ6pVntD6Lqa6ZRKRLLUAfgiXYf6LqQc02DbQuyTwmQz+ZT19zbDGHWQ/X3twGT2GZAt5Nj1h7qZlr1XwxK/j/8mfzIMqHXzbbslETSgi+JNSriSN6esFDiqccJnXUbWgVH6xuL3TgWSITiLJmoh4orFEXFnfOSNb/KRah/EQUb7Z6kH1UZ6N2JxStQWZsO+DATTIrmY/T77gBkeTjLGIhe0FgJv5Mh6JJrtM+0sNH1WxmeQiyadVSZFjax4FUxsxiaCS9KNQGJ7hl41tU5zMCyQc+AKvkNJfzc6CR2RefLXSC8+V1zU9G1btNNaozRZwwoak2I7N7bwunHk1oIisOs13M7T8XsrWHDYGw4F/yZ5knsZCybt8O3KVd7Yxc7kWCZkdqfGWucVasNrtnnieSCanR+q6tTE4AZZfJ+dQHpkub8vHH7dU6C4xLniwMuoivTaFnU+xBoqFR3qvDNI9C5zOlXSKuVWHySvaGNcLvmwK7B2UN/fRkRLPTR46v8SeJdVpeDtMANN0b9JUK7rns11NXF+9AOWrcbTVw3orch5iUQG5Du3gDA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3103.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b49f84de-0da7-457f-f617-08d85f0fdf24 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 15:55:04.4305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /XxRTx+/MxxoRj60bor95eTDpobTLKOHC+uMfGp2mVAZG2C2VKjNTVvkx6HPpj4lmfUXbnBJsBU9d+dxtee1DK/yXTFOgJ+Qph4OWGh/7D8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3150 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] dev Digest, Vol 318, Issue 122 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Thanks for the heads up Tim > -----Original Message----- > From: dev On Behalf Of dev-request@dpdk.org > Sent: Tuesday, September 22, 2020 10:45 AM > To: dev@dpdk.org > Subject: dev Digest, Vol 318, Issue 122 >=20 > Send dev mailing list submissions to > dev@dpdk.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://mails.dpdk.org/listinfo/dev > or, via email, send a message with subject or body 'help' to > dev-request@dpdk.org >=20 > You can reach the person managing the list at > dev-owner@dpdk.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dev digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: [PATCH v3 1/6] app/testpmd: fix missing verification of > port id (Ferruh Yigit) > 2. Re: [PATCH v3 3/6] app/testpmd: remove restriction on txpkts > set (Ferruh Yigit) > 3. Re: [PATCH v3 5/6] app/testpmd: fix valid desc id check > (Ferruh Yigit) > 4. Re: [RFC v2 1/1] app/testpmd: distinguish ICMP identifier > fields in packet (Ferruh Yigit) > 5. Re: [PATCH v3] app/testpmd: fix the default RSS key > configuration (Phil Yang) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 22 Sep 2020 15:49:36 +0100 > From: Ferruh Yigit > To: "Wei Hu (Xavier)" , dev@dpdk.org > Cc: xavier.huwei@huawei.com > Subject: Re: [dpdk-dev] [PATCH v3 1/6] app/testpmd: fix missing > verification of port id > Message-ID: <831d7d94-ce37-9ce4-16d1-e2de6f1162c3@intel.com> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > On 9/19/2020 11:47 AM, Wei Hu (Xavier) wrote: > > From: Chengchang Tang > > > > To set Tx vlan offloads, it is required to stop port firstly. But befor= e > > checking whether the port is stopped, the port id entered by the user > > is not checked for validity. When the port id is illegal, it would lead > > to a segmentation fault since it attempts to access a member of > > non-existent port. > > > > This patch adds verification of port id in tx vlan offloads and remove > > duplicated check. > > > > Fixes: 597f9fafe13b ("app/testpmd: convert to new Tx offloads API") > > Cc: stable@dpdk.org > > > > Signed-off-by: Chengchang Tang > > Signed-off-by: Wei Hu (Xavier) >=20 > Reviewed-by: Ferruh Yigit >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 22 Sep 2020 15:51:20 +0100 > From: Ferruh Yigit > To: "Wei Hu (Xavier)" , dev@dpdk.org > Cc: xavier.huwei@huawei.com > Subject: Re: [dpdk-dev] [PATCH v3 3/6] app/testpmd: remove restriction > on txpkts set > Message-ID: <72499939-f3c1-1caa-cded-b46b489c1863@intel.com> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > On 9/19/2020 11:47 AM, Wei Hu (Xavier) wrote: > > From: Chengchang Tang > > > > Currently, if nb_txd is not set, the txpkts is not allowed to be set > > because the nb_txd is used to avoid the numer of segments exceed the Tx > > ring size and the default value of nb_txd is 0. And there is a bug that > > nb_txd is the global configuration for Tx ring size and the ring size > > could be changed by some command per queue. So these valid check is > > unreliable and introduced unnecessary constraints. > > > > This patch adds a valid check function to use the real Tx ring size to > > check the validity of txpkts. > > > > Fixes: af75078fece3 ("first public release") > > Cc: stable@dpdk.org > > > > Signed-off-by: Chengchang Tang > > Signed-off-by: Wei Hu (Xavier) > > --- > > app/test-pmd/config.c | 42 ++++++++++++++++++++++++++++++++++++++--- > - > > 1 file changed, 38 insertions(+), 4 deletions(-) > > > > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c > > index 4e33208..882de2d 100644 > > --- a/app/test-pmd/config.c > > +++ b/app/test-pmd/config.c > > @@ -2984,17 +2984,51 @@ show_tx_pkt_segments(void) > > printf("Split packet: %s\n", split); > > } > > > > +static bool > > +nb_segs_is_invalid(unsigned int nb_segs) > > +{ > > + uint16_t port_id; > > + > > + RTE_ETH_FOREACH_DEV(port_id) { > > + struct rte_port *port =3D &ports[port_id]; > > + uint16_t ring_size; > > + uint16_t queue_id; > > + > > + /* > > + * When configure the txq by rte_eth_tx_queue_setup with > > + * nb_tx_desc being 0, it will use a default value provided by > > + * PMDs to setup this txq. If the default value is 0, it will > > + * use the RTE_ETH_DEV_FALLBACK_TX_RINGSIZE to setup this > txq. > > + */ > > + for (queue_id =3D 0; queue_id < nb_txq; queue_id++) { > > + if (port->nb_tx_desc[queue_id]) > > + ring_size =3D port->nb_tx_desc[queue_id]; > > + else if (port->dev_info.default_txportconf.ring_size) > > + ring_size =3D > > + port->dev_info.default_txportconf.ring_size; > > + else > > + ring_size =3D > RTE_ETH_DEV_FALLBACK_TX_RINGSIZE; > > + > > + if (ring_size < nb_segs) { > > + printf("nb segments per TX packets=3D%u >=3D TX " > > + "queue(%u) ring_size=3D%u - ignored\n", > > + nb_segs, queue_id, ring_size); > > + return true; > > + } > > + } >=20 > What do you think calling 'rte_eth_rx_queue_info_get()' & > 'rte_eth_tx_queue_info_get()' to get the 'nb_desc'? >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Tue, 22 Sep 2020 15:53:04 +0100 > From: Ferruh Yigit > To: "Wei Hu (Xavier)" , dev@dpdk.org > Cc: xavier.huwei@huawei.com > Subject: Re: [dpdk-dev] [PATCH v3 5/6] app/testpmd: fix valid desc id > check > Message-ID: <6e9c3318-1d89-3a50-9540-dbb80893ad8f@intel.com> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > On 9/19/2020 11:47 AM, Wei Hu (Xavier) wrote: > > From: Chengchang Tang > > > > The number of desc is a per queue configuration. But in the check funct= ion, > > nb_txd & nb_rxd are used to check whether the desc_id is valid. nb_txd = & > > nb_rxd are the global configuration of number of desc. If the queue > > configuration is changed by cmdline liks: "port config xx txq xx ring_s= ize > > xxx", the real value will be changed. > > > > This patch use the real value to check whether the desc_id is valid. An= d if > > these are not configured by user. It will use the default value to chec= k > > it, since the rte_eth_rx_queue_setup & rte_eth_tx_queue_setup will use = a > > default value to confiure the queue if nb_rx_desc or nb_tx_desc is zero= . > > > > Fixes: af75078fece3 ("first public release") > > Cc: stable@dpdk.org > > > > Signed-off-by: Chengchang Tang > > Signed-off-by: Wei Hu (Xavier) > > --- > > app/test-pmd/config.c | 53 > +++++++++++++++++++++++++++++++++++++++++---------- > > 1 file changed, 43 insertions(+), 10 deletions(-) > > > > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c > > index 882de2d..b7851c7 100644 > > --- a/app/test-pmd/config.c > > +++ b/app/test-pmd/config.c > > @@ -1891,22 +1891,55 @@ tx_queue_id_is_invalid(queueid_t txq_id) > > } > > > > static int > > -rx_desc_id_is_invalid(uint16_t rxdesc_id) > > +rx_desc_id_is_invalid(portid_t port_id, queueid_t rxq_id, uint16_t rxd= esc_id) > > { > > - if (rxdesc_id < nb_rxd) > > + struct rte_port *port =3D &ports[port_id]; > > + uint16_t ring_size; > > + > > + /* > > + * When configure the rxq by rte_eth_rx_queue_setup with nb_rx_desc > > + * being 0, it will use a default value provided by PMDs to setup thi= s > > + * rxq. If the default value is 0, it will use the > > + * RTE_ETH_DEV_FALLBACK_RX_RINGSIZE to setup this rxq. > > + */ > > + if (port->nb_rx_desc[rxq_id]) > > + ring_size =3D port->nb_rx_desc[rxq_id]; > > + else if (port->dev_info.default_rxportconf.ring_size) > > + ring_size =3D port->dev_info.default_rxportconf.ring_size; > > + else > > + ring_size =3D RTE_ETH_DEV_FALLBACK_RX_RINGSIZE; > > + > > + if (rxdesc_id < ring_size) > > return 0; > > - printf("Invalid RX descriptor %d (must be < nb_rxd=3D%d)\n", > > - rxdesc_id, nb_rxd); > > + printf("Invalid RX descriptor %d (must be < ring_size=3D%d)\n", > > + rxdesc_id, ring_size); > > return 1; >=20 > +1 to fix, but similar comment as previous patch, can > 'rte_eth_rx_queue_info_get()' be used to detect the 'ring_size'? >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Tue, 22 Sep 2020 16:38:13 +0100 > From: Ferruh Yigit > To: Li Zhang , dekelp@nvidia.com, orika@nvidia.com, > viacheslavo@nvidia.com, matan@nvidia.com > Cc: dev@dpdk.org, thomas@monjalon.net, rasland@nvidia.com > Subject: Re: [dpdk-dev] [RFC v2 1/1] app/testpmd: distinguish ICMP > identifier fields in packet > Message-ID: <3def4458-0cb1-835e-1006-463ce4878361@intel.com> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > On 9/9/2020 4:34 AM, Li Zhang wrote: > > From: lizh > > > > Ability to distinguish ICMP identifier fields in packets. > > Dstinguish ICMP sequence number field too. > > Already supports ICMP code and type fields in current version. > > Existing fields in ICMP header contain the required information. > > ICMP header already is supported and no code change in RTE FLOW. > > Extend testpmd CLI to include the fields of ident and sequence number. > > One example: > > flow create 0 ingress pattern eth / ipv4 / > > icmp code is 1 ident is 5 seq is 6 / > > end actions count / queue index 0 / end > > The ICMP packet with code 1, identifier 5 and > > sequence number 6 will be matched. > > It will implement action counter and forward to queue 0. > > >=20 > Overall looks good. @Ori, any objection? >=20 > @Li, is there any PMD implementation planned to use these icmp fields? >=20 > > Signed-off-by: Li Zhang > > --- > > app/test-pmd/cmdline_flow.c | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c > > index 6263d307ed..6e04d538ea 100644 > > --- a/app/test-pmd/cmdline_flow.c > > +++ b/app/test-pmd/cmdline_flow.c > > @@ -143,6 +143,8 @@ enum index { > > ITEM_ICMP, > > ITEM_ICMP_TYPE, > > ITEM_ICMP_CODE, > > + ITEM_ICMP_IDENT, > > + ITEM_ICMP_SEQ, > > ITEM_UDP, > > ITEM_UDP_SRC, > > ITEM_UDP_DST, > > @@ -893,6 +895,8 @@ static const enum index item_ipv6[] =3D { > > static const enum index item_icmp[] =3D { > > ITEM_ICMP_TYPE, > > ITEM_ICMP_CODE, > > + ITEM_ICMP_IDENT, > > + ITEM_ICMP_SEQ, > > ITEM_NEXT, > > ZERO, > > }; > > @@ -2193,6 +2197,20 @@ static const struct token token_list[] =3D { > > .args =3D ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_icmp, > > hdr.icmp_code)), > > }, > > + [ITEM_ICMP_IDENT] =3D { > > + .name =3D "ident", > > + .help =3D "ICMP packet identifier", > > + .next =3D NEXT(item_icmp, NEXT_ENTRY(UNSIGNED), > item_param), > > + .args =3D ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_icmp, > > + hdr.icmp_ident)), > > + }, > > + [ITEM_ICMP_SEQ] =3D { > > + .name =3D "seq", > > + .help =3D "ICMP packet sequence number", > > + .next =3D NEXT(item_icmp, NEXT_ENTRY(UNSIGNED), > item_param), > > + .args =3D ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_icmp, > > + hdr.icmp_seq_nb)), > > + }, > > [ITEM_UDP] =3D { > > .name =3D "udp", > > .help =3D "match UDP header", > > >=20 >=20 >=20 > ------------------------------ >=20 > Message: 5 > Date: Tue, 22 Sep 2020 15:44:29 +0000 > From: Phil Yang > To: oulijun , "wenzhuo.lu@intel.com" > , "beilei.xing@intel.com" > , "adrien.mazarguil@6wind.com" > , "ferruh.yigit@intel.com" > > Cc: "dev@dpdk.org" , "linuxarm@huawei.com" > , nd , nd > Subject: Re: [dpdk-dev] [PATCH v3] app/testpmd: fix the default RSS > key configuration > Message-ID: > urprd08.prod.outlook.com> >=20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > dev On Behalf Of Lijun Ou writes: >=20 >=20 > > >> Subject: [dpdk-dev] [PATCH v3] app/testpmd: fix the default RSS key > > >> configuration > > > > > > Hi Lijun, > > > > > > Please fix the coding style issues. > > > > > > "Must be a reply to the first patch (--in-reply-to)." > > > > > > > > >> > > >> When a user runs a flow create cmd to configure an RSS rule > > >> with specifying the empty rss actions in testpmd, this mean > > > = ^^^ means > > >> that the flow gets the default RSS functions from the valid > > >> NIC default RSS hash key. However, the testpmd is not set > > > = ^^^ is set xxx incorrectly > > >> the default RSS key incorrectly when RSS key is not specified > > >> in flow create cmd. > > > > > > Use the NIC valid default RSS key instead of the testpmd dummy RSS ke= y in > > the flow configuration when the RSS key is not specified in the flow ru= le. If > > the NIC RSS key is invalid, it will use testpmd dummy RSS key as the de= fault > > key. > > > > > > Is that good to put it in this way? Because I think it is not a bug, = your patch > > offers an approach to update the default testpmd RSS key. > > > > > Do you have any better advice? or don't use my approach? I think the >=20 >=20 > No, I think you misunderstood me. I agree with your proposal and your pat= ch > looks good to me. > My suggestion is to reword the commit message to highlight that you mare > making testpmd use the valid NIC RSS key as the default flow RSS key in t= his > patch. > In my perspective, if you don't specify any RSS key in your flow rule, it= should > allow any available RSS key work as the default key. > So use a dummy RSS key is correct as well. >=20 >=20 > > previous methods are easy to misunderstand.Can we use the NUL KEY > > solution and fix the problem that the length is 0 and the RSS key is no= t > > NULL ? > > > > Thanks > > Lijun Ou > > > I would also suggest making the commit message shorter and move the > > test result into the cover letter. > > > Because the checkepatch tool is not happy with the hex dumped below. > > > http://mails.dpdk.org/archives/test-report/2020-September/151395.html > > > > > > > > > Thanks, > > > Phil > > > > > >> the cmdline as flows: > > >> 1. first, startup testpmd: > > >> testpmd> show port 0 rss-hash key > > >> RSS functions: > > >> all ipv4-frag ipv4-other ipv6-frag ipv6-other ip > > >> RSS key: > > >> > > 6D5A56DA255B0EC24167253D43A38FB0D0CA2BCBAE7B30B477CB2DA38030F > > >> 20C6A42B73BBEAC01FA > > >> > > >> 2. create a rss rule > > >> testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end action= s rss \ > > >> types ipv4-udp end queues end / end > > >> > > >> 3. show rss-hash key > > >> testpmd> show port 0 rss-hash key > > >> RSS functions: > > >> all ipv4-udp udp > > >> RSS key: > > >> > > > 74657374706D6427732064656661756C74205253532068617368206B65792C20 > 6F > > >> 76657272696465 > > >> > > >> Now, it uses rte_eth_dev_rss_hash_conf_get to correctly the > > >> default rss key. the cmdline and result as flows: > > >> testpmd> show port 0 rss-hash key > > >> RSS functions: > > >> all ipv4-frag ipv4-other ipv6-frag ipv6-other ip > > >> RSS key: > > >> > > > 6D5A56DA255B0EC24167253D43A38FB0D0CA2BCBAE7B30B477CB2DA38030F2 > > >> 0C > > >> 6A42B73BBEAC01FA > > >> testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end action= s rss \ > > >> types ipv4-udp end queues end / end > > >> testpmd> show port 0 rss-hash key > > >> RSS functions: > > >> all ipv4-udp udp > > >> RSS key: > > >> > > 6D5A56DA255B0EC24167253D43A38FB0D0CA2BCBAE7B30B477CB2DA38030F > > >> 20C6A42B73BBEAC01FA > > >> > > >> Fixes: ac8d22de2394 ("ethdev: flatten RSS configuration in flow API"= ) > > >> Cc: stable@dpdk.org > > >> > > >> Signed-off-by: Lijun Ou > > >> --- > > >> V2->V3: > > >> -fix checkpatch warning. > > >> > > >> V1->V2: > > >> -fix the commit. > > >> --- > > >> app/test-pmd/cmdline_flow.c | 8 ++++++++ > > >> 1 file changed, 8 insertions(+) > > >> > > >> diff --git a/app/test-pmd/cmdline_flow.c b/app/test- > > pmd/cmdline_flow.c > > >> index 6263d30..e6648da 100644 > > >> --- a/app/test-pmd/cmdline_flow.c > > >> +++ b/app/test-pmd/cmdline_flow.c > > >> @@ -4312,6 +4312,7 @@ parse_vc_action_rss(struct context *ctx, const > > >> struct token *token, > > >> action_rss_data->queue[i] =3D i; > > >> if (!port_id_is_invalid(ctx->port, DISABLED_WARN) && > > >> ctx->port !=3D (portid_t)RTE_PORT_ALL) { > > >> + struct rte_eth_rss_conf rss_conf =3D {0}; > > >> struct rte_eth_dev_info info; > > >> int ret2; > > >> > > >> @@ -4322,6 +4323,13 @@ parse_vc_action_rss(struct context *ctx, cons= t > > >> struct token *token, > > >> action_rss_data->conf.key_len =3D > > >> RTE_MIN(sizeof(action_rss_data->key), > > >> info.hash_key_size); > > >> + > > >> + rss_conf.rss_key_len =3D sizeof(action_rss_data->key); > > >> + rss_conf.rss_key =3D action_rss_data->key; > > >> + ret2 =3D rte_eth_dev_rss_hash_conf_get(ctx->port, > > >> &rss_conf); > > >> + if (ret2 !=3D 0) > > >> + return ret2; > > >> + action_rss_data->conf.key =3D rss_conf.rss_key; > > >> } > > >> action->conf =3D &action_rss_data->conf; > > >> return ret; > > >> -- > > >> 2.7.4 > > > > > > . > > > >=20 >=20 > End of dev Digest, Vol 318, Issue 122 > *************************************