From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id C4F502B8B for ; Fri, 7 Dec 2018 06:09:50 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2018 21:09:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,324,1539673200"; d="scan'208";a="281653465" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 06 Dec 2018 21:09:49 -0800 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Dec 2018 21:09:49 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Dec 2018 21:09:48 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.59]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.46]) with mapi id 14.03.0415.000; Fri, 7 Dec 2018 13:09:46 +0800 From: "Zhang, Qi Z" To: "Kar, Subarna" , "Tu, Lijuan" , "dev@dpdk.org" CC: "Wu, Jingjing" , "Gasparakis, Joseph" Thread-Topic: [dpdk-dev] [PATCH] net-i40e-Match-on-outer-and-inner-headers-for-tunnel Thread-Index: AQHUjeimq4fx/HFbIkCXT8FUnqYD4aVyMQ4AgACIwWA= Date: Fri, 7 Dec 2018 05:09:46 +0000 Message-ID: <039ED4275CED7440929022BC67E70611532FADC7@SHSMSX103.ccr.corp.intel.com> References: <1544008393-72281-1-git-send-email-subarna.kar@intel.com> <039ED4275CED7440929022BC67E70611532FA86B@SHSMSX103.ccr.corp.intel.com> <8CE3E05A3F976642AAB0F4675D0AD20E0B9DD182@SHSMSX101.ccr.corp.intel.com> <73952280D14FA543AEF5AE7215A6722B5DFC15B7@ORSMSX101.amr.corp.intel.com> In-Reply-To: <73952280D14FA543AEF5AE7215A6722B5DFC15B7@ORSMSX101.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzQwNGQzMGItOGI5YS00MGMwLTgxMzItNTFjYzg3MjY3MWY3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUmVNbmFHNzZxdVBEYzFFZmtrOE8zRGJQYWNRbHhWeVlQK29ZSzZRakFna0VNTWlCQlpKamV6VzhCVWhtSDBaRCJ9 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-i40e-Match-on-outer-and-inner-headers-for-tunnel 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: Fri, 07 Dec 2018 05:09:51 -0000 The reason is below code prevent vPMD be used and I have comment as below. > > > + dev->data->dev_conf.fdir_conf.mode =3D RTE_FDIR_MODE_PERFECT; > > > > This is not correct, this will prevent vPMD be used for all cases, I > > know vPMD should not be used when the new flow be enabled, and below > > patch has some issue will break this, but we should fix on that patch a= nyway. > > https://patches.dpdk.org/patch/45697/ > -----Original Message----- > From: Kar, Subarna > Sent: Friday, December 7, 2018 12:58 PM > To: Tu, Lijuan ; Zhang, Qi Z ; > dev@dpdk.org > Cc: Wu, Jingjing ; Gasparakis, Joseph > > Subject: RE: [dpdk-dev] [PATCH] > net-i40e-Match-on-outer-and-inner-headers-for-tunnel >=20 > Can I ask what kind of packets you are sending? Because your packets > shouldn't hit my code. This is to accept flows for tunneled pkts on outer= and > inner headers. >=20 > -----Original Message----- > From: Tu, Lijuan > Sent: Thursday, December 6, 2018 8:52 PM > To: Zhang, Qi Z ; Kar, Subarna > ; dev@dpdk.org; Tu, Lijuan > Cc: Wu, Jingjing ; Gasparakis, Joseph > > Subject: RE: [dpdk-dev] [PATCH] > net-i40e-Match-on-outer-and-inner-headers-for-tunnel >=20 > Hi Subarna, >=20 > This patch cause a big performance drop , ~30% with single core performan= ce > test case. >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhang, Qi Z > > Sent: Thursday, December 6, 2018 7:45 PM > > To: Kar, Subarna ; dev@dpdk.org > > Cc: Wu, Jingjing ; Gasparakis, Joseph > > > > Subject: Re: [dpdk-dev] [PATCH] > > net-i40e-Match-on-outer-and-inner-headers-for-tunnel > > > > Hi Subarna: > > > > > -----Original Message----- > > > From: Kar, Subarna > > > Sent: Wednesday, December 5, 2018 7:13 PM > > > To: dev@dpdk.org > > > Cc: Zhang, Qi Z ; Wu, Jingjing > > > ; Kar, Subarna > > > Subject: [PATCH] > > > net-i40e-Match-on-outer-and-inner-headers-for-tunnel > > > > The title is not following DPDK style > > it could be > > net/i40e: match on outer and inner headers for tunnel. > > > > Also please add detail commit log for such a large patch. > > > > Btw, the patch is too large, it's better to separate it into small > > ones > > > > So far what I can suggestion is, at least you can separate into 2 > > patches One for new feature in fdir low level and one for bridge rte_fl= ow to > fdir. > > > > Below are some captures > > > > > > From: Subarna Kar > > > > > > --- > > > drivers/net/i40e/i40e_ethdev.c | 14 +- > > > drivers/net/i40e/i40e_ethdev.h | 109 +++++- > > > drivers/net/i40e/i40e_fdir.c | 392 +++++++++++++++++++-- > > > drivers/net/i40e/i40e_flow.c | 781 > > > ++++++++++++++++++++++++++++++++++++++++- > > > 4 files changed, 1250 insertions(+), 46 deletions(-) > > > > > > diff --git a/drivers/net/i40e/i40e_ethdev.c > > > b/drivers/net/i40e/i40e_ethdev.c index 7030eb1..0e9f22d 100644 > > > --- a/drivers/net/i40e/i40e_ethdev.c > > > +++ b/drivers/net/i40e/i40e_ethdev.c > > > @@ -1788,6 +1788,7 @@ i40e_dev_configure(struct rte_eth_dev *dev) > > > * legacy filter API is deprecated, the following codes should also= be > > > * removed. > > > */ > > > + dev->data->dev_conf.fdir_conf.mode =3D RTE_FDIR_MODE_PERFECT; > > > > This is not correct, this will prevent vPMD be used for all cases, I > > know vPMD should not be used when the new flow be enabled, and below > > patch has some issue will break this, but we should fix on that patch a= nyway. > > https://patches.dpdk.org/patch/45697/ > > > > > diff --git a/drivers/net/i40e/i40e_ethdev.h > > > b/drivers/net/i40e/i40e_ethdev.h index 11ecfc3..f7311ce 100644 > > > --- a/drivers/net/i40e/i40e_ethdev.h > > > +++ b/drivers/net/i40e/i40e_ethdev.h > > > @@ -466,6 +466,92 @@ struct i40e_vmdq_info { #define > > > I40E_FLEX_WORD_MASK(off) (0x80 >> (off)) > > > #define I40E_FDIR_IPv6_TC_OFFSET 20 > > > > > > static inline int > > > +i40e_flow_fdir_fill_outer_header(const struct i40e_fdir_input *fdir_= input, > > > + unsigned char *raw_pkt) > > > +{ > > > + struct ipv4_hdr *ip; > > > + struct ipv6_hdr *ip6; > > > + struct udp_hdr *udp; > > > + struct rte_flow_item_gre *gre; > > > + struct rte_flow_item_mpls *mpls; > > > + struct rte_flow_item_vxlan *vxlan; > > > + uint16_t *ether_type; > > > + uint8_t len =3D 2 * sizeof(struct ether_addr); > > > + raw_pkt +=3D 2 * sizeof(struct ether_addr); > > > + ether_type =3D (uint16_t *)raw_pkt; > > > + raw_pkt +=3D sizeof(uint16_t); > > > + len +=3D sizeof(uint16_t); > > > + > > > + > > > + //we don't need ETH, so direct skip to IP > > > > It's better to use /* xxx */ to follow coding style And same comment > > for all other places (except the case that you see nearby comment is > > already broken and you just follow it :)) > > > > > + vxlan =3D (struct rte_flow_item_vxlan *)raw_pkt; > > > + if (fdir_input->flow_ext.iip_type =3D=3D I40E_FDIR_IPTYPE_IPV4) { > > > + vxlan->vni[0] =3D > > > + fdir_input->flow.vxlanudp4_flow.vxlan.vni[0]; > > > + vxlan->vni[1] =3D > > > + fdir_input->flow.vxlanudp4_flow.vxlan.vni[1]; > > > + vxlan->vni[2] =3D > > > + fdir_input->flow.vxlanudp4_flow.vxlan.vni[2]; > > > + } else { > > > + vxlan->vni[0] =3D > > > + fdir_input->flow.vxlan6udp4_flow.vxlan.vni[0]; > > > + vxlan->vni[1] =3D > > > + fdir_input->flow.vxlan6udp4_flow.vxlan.vni[1]; > > > + vxlan->vni[2] =3D > > > + fdir_input->flow.vxlan6udp4_flow.vxlan.vni[2]; > > > + } > > > + vxlan->flags =3D VXLAN_DEFAULT_FLAG; > > > + len +=3D sizeof(struct rte_flow_item_vxlan); > > > + } else { > > > + //now put MPLS info for MPLSoUDP and MPLSoGRE > > > > The intend is not correct, replace spaces with tab > > > > > + > > > +static int > > > +i40e_flow_parse_fdir_tunnel_pattern(struct rte_eth_dev *dev, > > > + const struct rte_flow_item *pattern, > > > + struct rte_flow_error *error, > > > + struct i40e_fdir_filter_conf *filter) > > > > There is couple intend issue in this function, please double check. > > > > > > > > i =3D 0; > > > @@ -4621,9 +5382,17 @@ i40e_flow_validate(struct rte_eth_dev *dev, > > > rte_free(items); > > > return -rte_errno; > > > } > > > - if (parse_filter) > > > - ret =3D parse_filter(dev, attr, items, actions, > > > + if (parse_filter) { > > > + if (parse_filter !=3D TUNNEL_FDIR_FUNCTION && > > > + rss =3D=3D true) { > > > > s/rss =3D=3D true/rss > > > > > + ret =3D i40e_parse_rss_filter(dev, attr, pattern, > > > + actions, &cons_filter, error); > > > + return ret; > > > + } else { > > > + ret =3D parse_filter(dev, attr, items, actions, > > > error, &cons_filter); > > > + } > > > + } > > > flag =3D true; > > > } while ((ret < 0) && (i < RTE_DIM(i40e_supported_patterns))); > > > > > > -- > > > 2.7.4