31/01/2023 10:18, Rongwei Liu:
> From: Rongwei Liu
> > From: Stephen Hemminger <step...@networkplumber.org>
> > > Rongwei Liu <rongw...@nvidia.com> wrote:
> > >
> > > > +/**
> > > > + * @warning
> > > > + * @b EXPERIMENTAL: this structure may change without prior notice
> > > > + *
> > > > + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> > > > + *
> > > > + * Matches an IPv6 routing extension header.
> > > > + */
> > > > +struct rte_flow_item_ipv6_routing_ext {
> > > > + struct rte_ipv6_routing_ext hdr; };
> > >
> > > The problem with nesting a variable length structure inside another
> > > structure is not allowed.
> > >
> > > The issue is that the applicaiton would have to pass a variable length
> > > structure in for the flow definition. The flow item is variable length
> > > for this type? all the others are fixed length.
> > >
> > Yeah, segments_left is uint8 per definition. RFC doesn't set an upper
> > limitation.
> > It stands for intermediate routing nodes between src and dst nodes.
> > > One option would be to get rid of the wrapper structure.
> > Yeah, it works. @Andrew Rybchenko Can you share your preference here?
> I want to propose "moving flex array" out of the "struct rte_ipv6_routing_ext
> " and present in " struct rte_flow_item_ipv6_routing_ext"
> Sounds good?
For Geneve, we have defined a separate flow item: rte_flow_item_geneve_opt.
I'm OK to move the optional fields in the flow item.
This is what you did in v4.
