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 B9F32A04AB; Mon, 31 Aug 2020 05:46:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0D316137D; Mon, 31 Aug 2020 05:46:31 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 30814255 for ; Mon, 31 Aug 2020 05:46:29 +0200 (CEST) IronPort-SDR: 5VjSYDUxFyhb0fMB4A5FNzf7VKfVIqT31mY2CqLwzxY6Z1jM7OPqfbVWFmKTnNzFjNpUXkoFAC YoALkVNmHONQ== X-IronPort-AV: E=McAfee;i="6000,8403,9729"; a="154313241" X-IronPort-AV: E=Sophos;i="5.76,374,1592895600"; d="scan'208";a="154313241" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2020 20:46:28 -0700 IronPort-SDR: TW5Y56oI2IhYOKRSavMKz6kE6BuxZoc3kPqfh9Hti3rjhk1PzXw1I2zBAlQr9OZ0dWmSTVvYdW v5A4upHSF1Eg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,374,1592895600"; d="scan'208";a="300914756" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga006.jf.intel.com with ESMTP; 30 Aug 2020 20:46:27 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sun, 30 Aug 2020 20:46:16 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Sun, 30 Aug 2020 20:46:16 -0700 Received: from shsmsx108.ccr.corp.intel.com (10.239.4.97) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 30 Aug 2020 20:46:16 -0700 Received: from shsmsx107.ccr.corp.intel.com ([169.254.9.141]) by SHSMSX108.ccr.corp.intel.com ([169.254.8.32]) with mapi id 14.03.0439.000; Mon, 31 Aug 2020 11:46:13 +0800 From: "Zhang, Qi Z" To: Pawel Wodkowski , "dev@dpdk.org" CC: "Zhao1, Wei" , "Guo, Jia" Thread-Topic: [PATCH] net/ixgbe: fix fdir flows with RTE_FLOW_ITEM_TYPE_RAW Thread-Index: AQHWb1VJx2SCFshroUu/PUq5Q8se86lRskUw Date: Mon, 31 Aug 2020 03:46:13 +0000 Message-ID: <039ED4275CED7440929022BC67E706115522E196@SHSMSX107.ccr.corp.intel.com> References: <20200810203108.28770-1-pawelwod@gmail.com> In-Reply-To: <20200810203108.28770-1-pawelwod@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.1.3 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix fdir flows with RTE_FLOW_ITEM_TYPE_RAW 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" > -----Original Message----- > From: Pawel Wodkowski > Sent: Tuesday, August 11, 2020 4:31 AM > To: dev@dpdk.org > Cc: Pawel Wodkowski ; Zhang, Qi Z > ; Zhao1, Wei ; Guo, Jia > > Subject: [PATCH] net/ixgbe: fix fdir flows with RTE_FLOW_ITEM_TYPE_RAW >=20 > Flows like IP4 / UDP / RAW are not working because after parsing > RTE_FLOW_ITEM_TYPE_RAW item pointer is not advanced. This make whole > parsing fail. >=20 > Fixes: f35fec63dde1 ("net/ixgbe: enable flex bytes for generic flow API") > Cc: qi.z.zhang@intel.com > Signed-off-by: Pawel Wodkowski > --- > drivers/net/ixgbe/ixgbe_flow.c | 2 ++ > 1 file changed, 2 insertions(+) >=20 > diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flo= w.c > index b2a2bfc02..a2cb599b1 100644 > --- a/drivers/net/ixgbe/ixgbe_flow.c > +++ b/drivers/net/ixgbe/ixgbe_flow.c > @@ -2251,6 +2251,8 @@ ixgbe_parse_fdir_filter_normal(struct rte_eth_dev > *dev, > (((uint16_t)raw_spec->pattern[1]) << 8) | > raw_spec->pattern[0]; > rule->flex_bytes_offset =3D raw_spec->offset; > + > + item =3D next_no_fuzzy_pattern(pattern, item); why we need to advance item pointer? The next branch will advance it and compare with RTe_FLOW_ITEM_TYPE_END. Can you double check if your pattern is IPv4/UDP/RAW/END ? > } >=20 > if (item->type !=3D RTE_FLOW_ITEM_TYPE_END) { > -- > 2.17.1