From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 0F0AC5B32 for ; Wed, 17 Oct 2018 07:57:17 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2018 22:57:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,391,1534834800"; d="scan'208";a="241951192" Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105]) by orsmga004.jf.intel.com with ESMTP; 16 Oct 2018 22:57:15 -0700 Received: from pgsmsx103.gar.corp.intel.com ([169.254.2.13]) by PGSMSX107.gar.corp.intel.com ([169.254.7.83]) with mapi id 14.03.0319.002; Wed, 17 Oct 2018 13:57:14 +0800 From: "Zhao1, Wei" To: "Zhang, Qi Z" , 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: AQHUVXFXYMbcuuZBIkClVX2dndaqq6UB4x+AgBNEqPCAAzeIgIABZ5+wgAV2+wCAA9N1EA== Date: Wed, 17 Oct 2018 05:57:14 +0000 Message-ID: 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> <039ED4275CED7440929022BC67E70611532C163F@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <039ED4275CED7440929022BC67E70611532C163F@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [172.30.20.205] 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: Wed, 17 Oct 2018 05:57:18 -0000 > -----Original Message----- > From: Zhang, Qi Z > Sent: Monday, October 15, 2018 11:31 AM > To: Zhao1, Wei ; 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 Wei: >=20 > > -----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 > > front to jump over ntuple filter case > > > > Hi, qi > > > > > -----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 > > > > Yes, the assumption is may cause bug, this patch is an evidence, maybe > > this user has encountered this problem. > > > > > > > > 1. it is better be done by Intel people with enough validation > > > > I agree with you, I will commit a generic fix patch later. > > > > >2. two options for patch submit. > > > Submit a v2 with the generic fix, and it will be captured in this re= lease. > > > If it is not urgent, we can just accept current one first, then > > >have a separate patch in next release. > > > > 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 ch= eck > in cons_parse_ntuple_filter, it does not break anything, and it fix the s= pecific > issue. >=20 > Thanks > Qi >=20 >=20 Of course, it can be merge, but a more generic still need. Acked-by: Wei Zhao