From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 14586201 for ; Mon, 15 Oct 2018 05:30:48 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2018 20:30:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,383,1534834800"; d="scan'208";a="88356775" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 14 Oct 2018 20:30:46 -0700 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 14 Oct 2018 20:30:47 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx117.amr.corp.intel.com (10.18.116.17) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 14 Oct 2018 20:30:46 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.111]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.183]) with mapi id 14.03.0319.002; Mon, 15 Oct 2018 11:30:44 +0800 From: "Zhang, Qi Z" To: "Zhao1, Wei" , mocan CC: "dev@dpdk.org" , "Lu, Wenzhuo" Thread-Topic: Re:RE: [dpdk-dev] [PATCH] net/ixgbe: put 5tuple check in front to jump over ntuple filter case Thread-Index: AQHUVXKWfeVpWDyczk6TegBSJB81TaUCZkPwgBJAPACABDUgwIAAZx6AgAZ+XjA= Date: Mon, 15 Oct 2018 03:30:44 +0000 Message-ID: <039ED4275CED7440929022BC67E70611532C163F@SHSMSX103.ccr.corp.intel.com> References: <1537249732-7530-1-git-send-email-faicker.mo@ucloud.cn> <039ED4275CED7440929022BC67E70611532A1A27@SHSMSX103.ccr.corp.intel.com> <27452153.f1c7.16614f29e5f.Coremail.faicker.mo@ucloud.cn> <039ED4275CED7440929022BC67E70611532A6812@SHSMSX103.ccr.corp.intel.com> <039ED4275CED7440929022BC67E70611532BF9CE@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDkwNjQyYTctZjdlMi00ZTVjLWI1ZDUtNThlMDhlY2UxMzUwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNThSRDgrelNOR1NHUU1WbzhOXC9yOEdRZFVJb1hPeEs1VjBOZ2N4b2VCdEtZdFR6cjNoYncrZDFhNUgwZVpnUEYifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 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: put 5tuple check in front to jump over ntuple filter case 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: , X-List-Received-Date: Mon, 15 Oct 2018 03:30:49 -0000 Hi Wei: > -----Original Message----- > From: Zhao1, Wei > Sent: Thursday, October 11, 2018 1:10 AM > To: Zhang, Qi Z ; mocan > Cc: dev@dpdk.org; Lu, Wenzhuo > Subject: RE: Re:RE: [dpdk-dev] [PATCH] net/ixgbe: put 5tuple check in fro= nt > to jump over ntuple filter case >=20 > Hi, qi >=20 > > -----Original Message----- > > From: Zhang, Qi Z > > Sent: Thursday, October 11, 2018 2:36 AM > > To: Zhao1, Wei ; mocan > > Cc: dev@dpdk.org; Lu, Wenzhuo > > Subject: RE: Re:RE: [dpdk-dev] [PATCH] net/ixgbe: put 5tuple check in > > front to jump over ntuple filter case > > > > > > > > > -----Original Message----- > > > From: Zhao1, Wei > > > Sent: Monday, October 8, 2018 2:46 AM > > > To: Zhang, Qi Z ; mocan > > > Cc: dev@dpdk.org; Lu, Wenzhuo > > > Subject: RE: Re:RE: [dpdk-dev] [PATCH] net/ixgbe: put 5tuple check > > > in front to jump over ntuple filter case > > > > > > Hi, > > > > > > > > > > -----Original Message----- > > > > From: Zhang, Qi Z > > > > Sent: Wednesday, September 26, 2018 7:14 PM > > > > To: mocan ; Zhao1, Wei > > > > > Cc: dev@dpdk.org > > > > Subject: RE: Re:RE: [dpdk-dev] [PATCH] net/ixgbe: put 5tuple check > > > > in front to jump over ntuple filter case > > > > > > > > OK, got your point. We should not reject a possible valid fdir > > > > flow at n-tuple flow check stage. > > > > > > > > Review-by: Qi Zhang > > > > > > > > > I agree with the point of " We should not reject a possible valid > > > fdir flow at n-tuple flow check stage". > > > But, I think the fix patch should be more generic for all types > > > filter of this problem. > > > Maybe, we should delete all " goto out" in function > ixgbe_flow_create(). > > > Then, it will go to ntuple filter and ethertype filter, syn filter > > > and fdir filter ,l2_tn_filter one by one. > > > And aslo, we should code as > > > > > > { > > > > > > Ntuple: > > > .......... > > > if(ret) > > > Goto ethertype > > > .......... > > > > > > Ethertype: > > > > > > .......... > > > if(ret) > > > Goto fdir filter > > > ......... > > > > > > fdir filter: > > > > > > if(ret) > > > Goto l2_tn_filter > > > > > > l2_tn_filter: > > > > > > ............. > > > > > > } > > > > > > This fix patch only solve the problem of ntuple and fdir. > > > Qi, What do you think of this? > > > > I'm not the author of this part of code, so my understanding of > > current implementation is: > > It assume a flow will not be ambiguous which means if it match to some > > filter parser (ixgbe_parse_xxx_filter), it is not necessary to match > > on a different filter. > > But I'm not sure if the assumption is correct or not, (this depends on > > the knowledge of the device capability), So do you mean the assumption > > is not correct? If you think a generic fix is necessary, I have below > > comments >=20 > Yes, the assumption is may cause bug, this patch is an evidence, maybe th= is > user has encountered this problem. >=20 > > > > 1. it is better be done by Intel people with enough validation >=20 > I agree with you, I will commit a generic fix patch later. >=20 > >2. two options for patch submit. > > Submit a v2 with the generic fix, and it will be captured in this rele= ase. > > If it is not urgent, we can just accept current one first, then have > >a separate patch in next release. >=20 > Ok, If someone supply a v2 with the generic fix, I will ack. >=20 Just want to confirm with you , are you agree to merge this patch? Or you think v2 with generic fix is necessary? >>From my view, the patch can be accepted, since it just add more strict chec= k in cons_parse_ntuple_filter, it does not break anything, and it fix the s= pecific issue. Thanks Qi