From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8D152A034F; Mon, 22 Mar 2021 11:10:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1F5864068A; Mon, 22 Mar 2021 11:10:43 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 474AB40040 for ; Mon, 22 Mar 2021 11:10:41 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id CF0B17F45C; Mon, 22 Mar 2021 13:10:40 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru CF0B17F45C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1616407840; bh=Wx0ShBckEbitqPVzbkDCK+WPHhh/g277jTgeWcMBq28=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=YmIZ1xeLnqKsB04BhBg5vZvrw/89vp45xP1Nj6oRum0eEm1kgxpZMhU/Cbos0SMHu pp1cwL18nhFswUzjpD+zdqkTvxDu71DhXjjHE2XBYiQgEg/Afh74m06zt0HTLnhsxt qjqdjFt+psjwvrmPEvPkIZeYhH8TbjWZv7D7Suls= To: Ferruh Yigit , Ivan Malov , dev@dpdk.org Cc: Andy Moreton , Ori Kam , Thomas Monjalon References: <20210312093143.28186-1-ivan.malov@oktetlabs.ru> <20210312110745.31721-1-ivan.malov@oktetlabs.ru> <0e5845a3-a06a-b335-959b-77cddee206ee@intel.com> <8b23c0d4-a5c8-8a18-c856-1719730181cc@oktetlabs.ru> <375db290-6bd1-a620-b74b-3590f5c81326@intel.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <41b811ae-ffa6-9abd-4ec7-a0f5c31c24a4@oktetlabs.ru> Date: Mon, 22 Mar 2021 13:10:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <375db290-6bd1-a620-b74b-3590f5c81326@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 01/10] ethdev: reuse header definition in flow pattern item ETH X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 3/22/21 12:01 PM, Ferruh Yigit wrote: > On 3/17/2021 6:40 AM, Andrew Rybchenko wrote: >> On 3/16/21 8:38 PM, Ferruh Yigit wrote: >>> On 3/12/2021 11:07 AM, Ivan Malov wrote: >>>> One ought to reuse existing header structs in flow items. >>>> This particular item contains non-header fields, so it's >>>> important to keep the header fields in a separate struct. >>>> >>> >>> Hi Ivan, Andrew, Thanks for following this up and updates. >>> >>> For record, existing deprecation note is: >>> https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v21.02#n99 >>> >>> >>> >>> Ori, Andrew, >>> >>> Is there any struct left not updated after this patch? >> >> As I understand the following flow items corresponding to >> network protocols, but still define own fields. Sometimes >> corresponding network protocols do not have definitions in >> DPDK, but it is not an excuse and definitions should be >> simply added: >> rte_flow_item_e_tag >> rte_flow_item_nvgre >> rte_flow_item_mpls >> rte_flow_item_gre >> rte_flow_item_gtp >> rte_flow_item_geneve >> rte_flow_item_vxlan_gpe >> rte_flow_item_arp_eth_ipv4 >> rte_flow_item_icmp6 >> rte_flow_item_icmp6_nd_ns >> rte_flow_item_icmp6_nd_na >> rte_flow_item_icmp6_nd_opt >> rte_flow_item_icmp6_nd_opt_sla_eth >> rte_flow_item_icmp6_nd_opt_tla_eth >> rte_flow_item_gtp_psc >> rte_flow_item_pppoe >> rte_flow_item_pppoe_proto_id >> rte_flow_item_l2tpv3oip >> rte_flow_item_nsh >> rte_flow_item_igmp >> rte_flow_item_ah >> rte_flow_item_pfcp >> rte_flow_item_geneve_opt >> >> The list is composed very quickly so may be I oversight >> something, but it definitely answers the question - yes, >> more flow items remain. >> > > Ahh, I was thinking the problematic ones, the ones adding extra fields > than the protocol header, 'rte_flow_item_eth', 'rte_flow_item_vlan' and > there was one more I guess, but you are right, all needs be updated. > > So there are more to be updated, are you planning to work on any more of > them in this release? No plans on it yet. > btw, thanks again for addressing this issue. > > >>> >>>> Signed-off-by: Ivan Malov >>>> Reviewed-by: Andrew Rybchenko >>>> Reviewed-by: Andy Moreton >>> >>> <...> >>