From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F3D3C282CE for ; Tue, 4 Jun 2019 17:06:33 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 0F0A8207E0 for ; Tue, 4 Jun 2019 17:06:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F0A8207E0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 02EEF1B9E0; Tue, 4 Jun 2019 19:06:32 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 8D6971B9D2 for ; Tue, 4 Jun 2019 19:06:30 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9D42181E10; Tue, 4 Jun 2019 17:06:21 +0000 (UTC) Received: from [10.36.112.59] (ovpn-112-59.ams2.redhat.com [10.36.112.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 59D9E12C73; Tue, 4 Jun 2019 17:06:19 +0000 (UTC) To: Leyi Rong , qi.z.zhang@intel.com Cc: dev@dpdk.org, Chinh T Cao , Paul M Stillwell Jr References: <20190604054248.68510-1-leyi.rong@intel.com> <20190604054248.68510-3-leyi.rong@intel.com> From: Maxime Coquelin Message-ID: Date: Tue, 4 Jun 2019 19:06:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190604054248.68510-3-leyi.rong@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 04 Jun 2019 17:06:26 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 02/49] net/ice/base: update standard extr seq to include DIR flag 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 6/4/19 7:42 AM, Leyi Rong wrote: > Once upon a time, the ice_flow_create_xtrct_seq() function in ice_flow.c > extracted only protocol fields explicitly specified by the caller of the > ice_flow_add_prof() function via its struct ice_flow_seg_info instances. > However, to support different ingress and egress flow profiles with the > same matching criteria, it would be necessary to also match on the packet > Direction metadata. The primary reason was because there could not be more > than one HW profile with the same CDID, PTG, and VSIG. The Direction > metadata was not a parameter used to select HW profile IDs. > > Thus, for ACL, the direction flag would need to be added to the extraction > sequence. This information will be use later as one criteria for ACL > scenario entry matching. > > Signed-off-by: Chinh T Cao > Signed-off-by: Paul M Stillwell Jr > Signed-off-by: Leyi Rong > --- > drivers/net/ice/base/ice_flow.c | 43 +++++++++++++++++++++++++++++++++ > 1 file changed, 43 insertions(+) > > diff --git a/drivers/net/ice/base/ice_flow.c b/drivers/net/ice/base/ice_flow.c > index be819e0e9..f1bf5b5e7 100644 > --- a/drivers/net/ice/base/ice_flow.c > +++ b/drivers/net/ice/base/ice_flow.c > @@ -495,6 +495,42 @@ ice_flow_proc_seg_hdrs(struct ice_flow_prof_params *params) > return ICE_SUCCESS; > } > > +/** > + * ice_flow_xtract_pkt_flags - Create an extr sequence entry for packet flags > + * @hw: pointer to the HW struct > + * @params: information about the flow to be processed > + * @flags: The value of pkt_flags[x:x] in RX/TX MDID metadata. > + * > + * This function will allocate an extraction sequence entries for a DWORD size > + * chunk of the packet flags. > + */ > +static enum ice_status > +ice_flow_xtract_pkt_flags(struct ice_hw *hw, > + struct ice_flow_prof_params *params, > + enum ice_flex_mdid_pkt_flags flags) > +{ > + u8 fv_words = hw->blk[params->blk].es.fvw; > + u8 idx; > + > + /* Make sure the number of extraction sequence entries required does not > + * exceed the block's capacity. > + */ > + if (params->es_cnt >= fv_words) > + return ICE_ERR_MAX_LIMIT; > + > + /* some blocks require a reversed field vector layout */ > + if (hw->blk[params->blk].es.reverse) > + idx = fv_words - params->es_cnt - 1; > + else > + idx = params->es_cnt; > + > + params->es[idx].prot_id = ICE_PROT_META_ID; > + params->es[idx].off = flags; > + params->es_cnt++; > + > + return ICE_SUCCESS; > +} > + > /** > * ice_flow_xtract_fld - Create an extraction sequence entry for the given field > * @hw: pointer to the HW struct > @@ -744,6 +780,13 @@ ice_flow_create_xtrct_seq(struct ice_hw *hw, > enum ice_status status = ICE_SUCCESS; > u8 i; > > + /* For ACL, we also need to extract the direction bit (Rx,Tx) data from > + * packet flags > + */ > + if (params->blk == ICE_BLK_ACL) > + ice_flow_xtract_pkt_flags(hw, params, > + ICE_RX_MDID_PKT_FLAGS_15_0); Shouldn't you propagate the error (ICE_ERR_MAX_LIMIT)? > + > for (i = 0; i < params->prof->segs_cnt; i++) { > u64 match = params->prof->segs[i].match; > u16 j; >