From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xing, Beilei" Subject: Re: [PATCH v5 07/17] net/i40e: add flow validate function Date: Thu, 5 Jan 2017 11:52:41 +0000 Message-ID: <94479800C636CB44BD422CB454846E013158E27D@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> <94479800C636CB44BD422CB454846E013158E038@SHSMSX101.ccr.corp.intel.com> <8d74dd50-2eba-37b6-996d-3d97dd043f2d@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Zhao1, Wei" To: "Yigit, Ferruh" , "Wu, Jingjing" , "Zhang, Helin" Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id D6125D4E0 for ; Thu, 5 Jan 2017 12:52:47 +0100 (CET) In-Reply-To: <8d74dd50-2eba-37b6-996d-3d97dd043f2d@intel.com> Content-Language: en-US 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: Yigit, Ferruh > Sent: Thursday, January 5, 2017 7:16 PM > To: Xing, Beilei ; Wu, Jingjing > ; Zhang, Helin > Cc: dev@dpdk.org; Zhao1, Wei > Subject: Re: [dpdk-dev] [PATCH v5 07/17] net/i40e: add flow validate > function >=20 > On 1/5/2017 6:08 AM, Xing, Beilei wrote: > > 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 > >> > >> 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 > >>> --- > >> > >> <...> > >> > >>> 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; > >> > >> Is this intentional (instead of using extern) ? > >> Because i40e_flow.c has a global variable definition with same name, > >> it looks like this is not causing a build error, but I think confusing= . > >> > > > > 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. > > > >> <...> > >> > >>> +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); > >> > >> 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. > > > >> > >> <...> > >> > >>> + > >>> +union i40e_filter_t cons_filter; > >> > >> Why this cons_filter is required. I can see this is saving some state > >> related rule during validate function. > >> If the plan is to use this during rule creation, is user has to call > >> validate 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 w= ill be > called in i40e_flow_create. >=20 > Ok then. >=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); > >> > >> It is your call, but I would suggest using a specific namespace for > >> all rte_flow related functions, something like "i40e_flow_". > >> In this context it is clear what this function is, but in whole > >> driver code, the function name is too generic to understand what it do= es. > > > > Make sense. I'll update the function names. > > > >> > >>> + if (ret) > >>> + return ret; > >>> + > >>> + return ret; > >>> +} > >>> + > >> > >> <...> > >> > >>> + > >>> +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) > >> > >> I think it is good idea to comment what pattern is recognized in to > >> function comment, instead of reading code every time to figure out. > > > > In fact, the array of i40e_supported_patterns has listed all supported > patterns for each filter type. > > i40e_supported_patterns is also defined in this patch. >=20 > i40e_supported_patterns only shows item->type values, I think it is good = to > documents expected/valid mask (.dst, .src, .type) and last values for thi= s > type. OK, I see, will add the comments in the function. >=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) { > >> > >> Why an eth_mask is required? > > Yes, since eth_type mask in eth_mask should be UINT16_MAX. > > > >> 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_type. Perfect match. >=20 > Thanks for clarification. >=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"); > >> > >> 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= only > specific eth_type for ethertype_filter. > > > >> > >>> + 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."); > >> > >> 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. > > > >> > >>> + 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."); > >> > >> 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_dev_eythertype_filter_set. > > After checing datasheet, "The ethertype programmed by this command > should not be one of the L2 tags ethertype (VLAN, E-tag, S-tag, etc.) and > should not be IP or IPv6" is descripted. > > But if QinQ is disabled, and inner vlan is ETHER_TYPE_VLAN, the filter = works. > 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 abov= e, and > return error if (filter->ether_type =3D=3D ETHER_TYPE_VLAN), because HW o= nly > recognizes ETH when QinQ is diabled. What do you think? >=20 > I think it is better. > And this can be fine tuned in the future to check QinQ and return accordi= ngly. I have tuned QinQ, and it will not work when ether_type is equal to the out= er vlan. So I will update. >=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) > >> > >> 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. > > > >> > >> <...> > >> > >>> + > >>> +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; > >>> + } > >> > >> 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 > > > >> > >> <...> > >> > >