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 230BDD4E0 for ; Thu, 5 Jan 2017 07:09:01 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 04 Jan 2017 22:09:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,319,1477983600"; d="scan'208";a="1079385668" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 04 Jan 2017 22:09:00 -0800 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 4 Jan 2017 22:09:00 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 4 Jan 2017 22:09:00 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.177]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.132]) with mapi id 14.03.0248.002; Thu, 5 Jan 2017 14:08:24 +0800 From: "Xing, Beilei" To: "Yigit, Ferruh" , "Wu, Jingjing" , "Zhang, Helin" CC: "dev@dpdk.org" , "Zhao1, Wei" Thread-Topic: [dpdk-dev] [PATCH v5 07/17] net/i40e: add flow validate function Thread-Index: AQHSZjo4ARYUEPiyRUW16g4d73eN06EoJimAgAEWNnA= Date: Thu, 5 Jan 2017 06:08:24 +0000 Message-ID: <94479800C636CB44BD422CB454846E013158E038@SHSMSX101.ccr.corp.intel.com> References: <1483068352-32272-1-git-send-email-beilei.xing@intel.com> <1483500187-124740-1-git-send-email-beilei.xing@intel.com> <1483500187-124740-8-git-send-email-beilei.xing@intel.com> <1bf8ab46-2ac1-a565-a965-38e68afe60cd@intel.com> In-Reply-To: <1bf8ab46-2ac1-a565-a965-38e68afe60cd@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 v5 07/17] net/i40e: add flow validate function 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: Thu, 05 Jan 2017 06:09:03 -0000 Hi Ferruh, > -----Original Message----- > From: Yigit, Ferruh > Sent: Thursday, January 5, 2017 2:57 AM > To: Xing, Beilei ; Wu, Jingjing > ; Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 07/17] net/i40e: add flow validate > function >=20 > On 1/4/2017 3:22 AM, Beilei Xing wrote: > > This patch adds i40e_flow_validation function to check if a flow is > > valid according to the flow pattern. > > i40e_parse_ethertype_filter is added first, it also gets the ethertype > > info. > > i40e_flow.c is added to handle all generic filter events. > > > > Signed-off-by: Beilei Xing > > --- >=20 > <...> >=20 > > diff --git a/drivers/net/i40e/i40e_ethdev.c > > b/drivers/net/i40e/i40e_ethdev.c index 153322a..edfd52b 100644 > > --- a/drivers/net/i40e/i40e_ethdev.c > > +++ b/drivers/net/i40e/i40e_ethdev.c > > @@ -8426,6 +8426,8 @@ i40e_ethertype_filter_handle(struct rte_eth_dev > *dev, > > return ret; > > } > > > > +const struct rte_flow_ops i40e_flow_ops; >=20 > Is this intentional (instead of using extern) ? > Because i40e_flow.c has a global variable definition with same name, it l= ooks > like this is not causing a build error, but I think confusing. >=20 Actually it's the global variable definition in i40e_flow.c. I thought gcc= would add extern automatically during compiling, as I checked the address = of the variable is the same in different files. To avoid confusion, I will add extern in next version. > <...> >=20 > > +static int i40e_parse_ethertype_act(struct rte_eth_dev *dev, > > + const struct rte_flow_action *actions, > > + struct rte_flow_error *error, > > + struct rte_eth_ethertype_filter *filter); >=20 > In API naming, I would prefer full "action" instead of shorten "act", but= it is > your call. I will change the API name in next version. Thanks. >=20 > <...> >=20 > > + > > +union i40e_filter_t cons_filter; >=20 > Why this cons_filter is required. I can see this is saving some state rel= ated > rule during validate function. > If the plan is to use this during rule creation, is user has to call vali= date before > each create? You are right, cons_filter will get filter info during validation, and it's= for flow_create function. User needn't to call the flow_validate function, as validate function will = be called in i40e_flow_create. >=20 > <...> >=20 > > + > > +static int > > +i40e_parse_ethertype_filter(struct rte_eth_dev *dev, > > + const struct rte_flow_attr *attr, > > + const struct rte_flow_item pattern[], > > + const struct rte_flow_action actions[], > > + struct rte_flow_error *error, > > + union i40e_filter_t *filter) > > +{ > > + struct rte_eth_ethertype_filter *ethertype_filter =3D > > + &filter->ethertype_filter; > > + int ret; > > + > > + ret =3D i40e_parse_ethertype_pattern(dev, pattern, error, > > + ethertype_filter); > > + if (ret) > > + return ret; > > + > > + ret =3D i40e_parse_ethertype_act(dev, actions, error, > > + ethertype_filter); > > + if (ret) > > + return ret; > > + > > + ret =3D i40e_parse_attr(attr, error); >=20 > It is your call, but I would suggest using a specific namespace for all r= te_flow > related functions, something like "i40e_flow_". > In this context it is clear what this function is, but in whole driver co= de, the > function name is too generic to understand what it does. Make sense. I'll update the function names. >=20 > > + if (ret) > > + return ret; > > + > > + return ret; > > +} > > + >=20 > <...> >=20 > > + > > +static int > > +i40e_parse_ethertype_pattern(__rte_unused struct rte_eth_dev *dev, > > + const struct rte_flow_item *pattern, > > + struct rte_flow_error *error, > > + struct rte_eth_ethertype_filter *filter) >=20 > I think it is good idea to comment what pattern is recognized in to funct= ion > comment, instead of reading code every time to figure out. In fact, the array of i40e_supported_patterns has listed all supported patt= erns for each filter type. i40e_supported_patterns is also defined in this patch. >=20 > > +{ > > + const struct rte_flow_item *item =3D pattern; > > + const struct rte_flow_item_eth *eth_spec; > > + const struct rte_flow_item_eth *eth_mask; > > + enum rte_flow_item_type item_type; > > + > > + for (; item->type !=3D RTE_FLOW_ITEM_TYPE_END; item++) { > > + if (item->last) { > > + rte_flow_error_set(error, EINVAL, > > + RTE_FLOW_ERROR_TYPE_ITEM, > > + item, > > + "Not support range"); > > + return -rte_errno; > > + } > > + item_type =3D item->type; > > + switch (item_type) { > > + case RTE_FLOW_ITEM_TYPE_ETH: > > + eth_spec =3D (const struct rte_flow_item_eth *)item- > >spec; > > + eth_mask =3D (const struct rte_flow_item_eth *)item- > >mask; > > + /* Get the MAC info. */ > > + if (!eth_spec || !eth_mask) { >=20 > Why an eth_mask is required? Yes, since eth_type mask in eth_mask should be UINT16_MAX.=20 > Can't driver support drop/queue packets from specific src to specific dst= with > specific eth_type? No, we support specific dst with specific eth_type, or only specific eth_t= ype. Perfect match. >=20 > > + rte_flow_error_set(error, EINVAL, > > + > RTE_FLOW_ERROR_TYPE_ITEM, > > + item, > > + "NULL ETH spec/mask"); > > + return -rte_errno; > > + } > > + > > + /* Mask bits of source MAC address must be full of 0. > > + * Mask bits of destination MAC address must be full > > + * of 1 or full of 0. > > + */ > > + if (!is_zero_ether_addr(ð_mask->src) || > > + (!is_zero_ether_addr(ð_mask->dst) && > > + !is_broadcast_ether_addr(ð_mask->dst))) { > > + rte_flow_error_set(error, EINVAL, > > + > RTE_FLOW_ERROR_TYPE_ITEM, > > + item, > > + "Invalid MAC_addr mask"); > > + return -rte_errno; > > + } > > + > > + if ((eth_mask->type & UINT16_MAX) !=3D > UINT16_MAX) { > > + rte_flow_error_set(error, EINVAL, > > + > RTE_FLOW_ERROR_TYPE_ITEM, > > + item, > > + "Invalid ethertype mask"); >=20 > Why returning error here? > Can't we say drop packets to specific MAC address, independent from the > ether_type? No. as I said above, we support specific dst with specific eth_type, or onl= y specific eth_type for ethertype_filter. >=20 > > + return -rte_errno; > > + } > > + > > + /* If mask bits of destination MAC address > > + * are full of 1, set RTE_ETHTYPE_FLAGS_MAC. > > + */ > > + if (is_broadcast_ether_addr(ð_mask->dst)) { > > + filter->mac_addr =3D eth_spec->dst; > > + filter->flags |=3D RTE_ETHTYPE_FLAGS_MAC; > > + } else { > > + filter->flags &=3D ~RTE_ETHTYPE_FLAGS_MAC; > > + } > > + filter->ether_type =3D rte_be_to_cpu_16(eth_spec- > >type); > > + > > + if (filter->ether_type =3D=3D ETHER_TYPE_IPv4 || > > + filter->ether_type =3D=3D ETHER_TYPE_IPv6) { > > + rte_flow_error_set(error, EINVAL, > > + > RTE_FLOW_ERROR_TYPE_ITEM, > > + item, > > + "Unsupported ether_type > in" > > + " control packet filter."); >=20 > Can't we create a drop rule based on dst MAC address if eth_type is ip ? No, we don't support drop MAC_addr + eth_type_IP for ethertype filter. >=20 > > + return -rte_errno; > > + } > > + if (filter->ether_type =3D=3D ETHER_TYPE_VLAN) > > + PMD_DRV_LOG(WARNING, "filter vlan > ether_type in" > > + " first tag is not supported."); >=20 > Who is the target of this message? > To the caller, this API is responding as this is supported. > The end user, the user of the application, can see this message, how this > message will help to end user? Actually I add this warning according to the original processing in i40e_de= v_eythertype_filter_set.=20 After checing datasheet, "The ethertype programmed by this command should n= ot be one of the L2 tags ethertype (VLAN, E-tag, S-tag, etc.) and should no= t be IP or IPv6" is descripted. But if QinQ is disabled, and inner vlan is ETHER_TYPE_VLAN, the filter work= s. So the message is "vlan ether_type in outer tag is not supported". I want to simplify it in next version, don't support the situation above, a= nd return error if (filter->ether_type =3D=3D ETHER_TYPE_VLAN), because HW = only recognizes ETH when QinQ is diabled. What do you think? >=20 > > + > > + break; > > + default: > > + break; > > + } > > + } > > + > > + return 0; > > +} > > + > > +static int > > +i40e_parse_ethertype_act(struct rte_eth_dev *dev, > > + const struct rte_flow_action *actions, > > + struct rte_flow_error *error, > > + struct rte_eth_ethertype_filter *filter) >=20 > I think it would be good to comment this functions to say only DROP and > QUEUE actions are supported. Yes, will update in next version. >=20 > <...> >=20 > > + > > +static int > > +i40e_flow_validate(struct rte_eth_dev *dev, > > + const struct rte_flow_attr *attr, > > + const struct rte_flow_item pattern[], > > + const struct rte_flow_action actions[], > > + struct rte_flow_error *error) > > +{ > > + struct rte_flow_item *items; /* internal pattern w/o VOID items */ > > + parse_filter_t parse_filter; > > + uint32_t item_num =3D 0; /* non-void item number of pattern*/ > > + uint32_t i =3D 0; > > + int ret; > > + > > + if (!pattern) { > > + rte_flow_error_set(error, EINVAL, > RTE_FLOW_ERROR_TYPE_ITEM_NUM, > > + NULL, "NULL pattern."); > > + return -rte_errno; > > + } > > + > > + if (!actions) { > > + rte_flow_error_set(error, EINVAL, > > + RTE_FLOW_ERROR_TYPE_ACTION_NUM, > > + NULL, "NULL action."); > > + return -rte_errno; > > + } >=20 > It may be good to validate attr too, if it is NULL or not. It is accessed= without > check in later stages of the call stack. Yes. Thanks for reminder. Best Regards, Beilei >=20 > <...> >=20