Re: [PATCH net-next 2/5] seg6: handle a consumed SRH in SRv6 End with the PSP flavor

On Mon, Oct 12, 2026 at 11:40:39PM +0200, Andrea Mayer wrote:

On Mon, 12 Oct 2026 17:28:06 +0800
Hangbin Liu [off-list ref] wrote:

quoted

[snip]

quoted

 
+/* 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 <redacted>