On Mon, Oct 12, 2026 at 11:40:39PM +0200, Andrea Mayer wrote: > On Mon, 12 Oct 2026 17:28:06 +0800 > Hangbin Liu <[email protected]> wrote: > > > [snip] > > > > > > +/* look up the SRH to be processed by the RFC8986 flavors. As End does, a > > > + * routing header with SL = 0 is skipped (e.g. an SRH already consumed). > > > + * This function returns NULL when no valid SRH is found. > > > + */ > > > +static struct ipv6_sr_hdr *seg6_flv8986_get_srh(struct sk_buff *skb) > > > +{ > > > + struct ipv6_sr_hdr *srh; > > > + > > > + srh = seg6_get_srh(skb, IP6_FH_F_SKIP_RH); > > > + if (srh) > > > + return srh; > > > + > > > + /* we take the first routing header without skipping it. In this way, > > > + * seg6_get_srh_pktinfo() reports SL = 0 and not a missing SRH. > > > + */ > > > + return seg6_get_srh(skb, 0); > > > +} > > > + > > > /* process the packet on the basis of the RFC8986 flavors set for the > > > given > > > * SRv6 End behavior instance. > > > */ > > > @@ -837,7 +858,7 @@ static int end_flv8986_core(struct sk_buff *skb, > > > struct seg6_local_lwt *slwt) > > > __u32 flvmask; > > > int srhoff; > > > > > > - srh = seg6_get_srh(skb, 0); > > > + srh = seg6_flv8986_get_srh(skb); > > > > Hmm, here we always try skip the SL = 0 SRH when multi SRH exists. What if > > we want to add USP flavor support in future? Then we will not able to remove > > the first SRH which SL = 0, right? e.g. > > > > +------+----------------------+----------------------+---------+ > > | IPv6 | SRH, Segments Left 0 | SRH, Segments Left 2 | payload | > > +------+----------------------+----------------------+---------+ > > > > Thanks > > Hangbin > > > > Hi Hangbin, > thanks for the review and for testing the series. > > As it is now, seg6_flv8986_get_srh() skips that SRH, while with USP it > should be removed. USP is not supported today, and for PSP without USP, > skipping that SRH is correct. > > When USP is implemented, that SRH can still be removed, for example by > extending seg6_flv8986_get_srh() to take the flavors into account. Its > comment would then be updated as well. > > Does that sound reasonable to you?
Yes, this looks good to me. Thanks for the explanation. With this extendable interface: Reviewed-by: Hangbin Liu <[email protected]>
