Re: [dpdk-dev] [PATCH v2 01/10] ethdev: reuse header definition in flow pattern item ETH
From: Ferruh Yigit <hidden>
Date: 2021-03-22 09:02:00
On 3/17/2021 6:40 AM, Andrew Rybchenko wrote:
On 3/16/21 8:38 PM, Ferruh Yigit wrote:quoted
On 3/12/2021 11:07 AM, Ivan Malov wrote:quoted
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? btw, thanks again for addressing this issue.
quoted
quoted
Signed-off-by: Ivan Malov <redacted> Reviewed-by: Andrew Rybchenko <redacted> Reviewed-by: Andy Moreton <redacted><...>