> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Tuesday, 31 January 2023 11:43
> Subject: Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header
> definition
>
> 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.
>
I also think we should just drop the rte_be32_t segments[0];
/**< Each hop IPv6 address. */
In any case application must allocate the correct size so maybe we can just
remove it.
Best,
Ori
>
>
>
