Hi Ilya,

Thank you for the clarification.

My understanding is:


   - set(nsh) / set_field for NSH fields is not currently unreliable in the
   kernel datapath in practice.
   - So any attempt in OVS to modify NSH fields such as nsh_si, nsh_spi,
   nsh_flags, or nsh_ttl may fail or be unsupported, regardless of whether I
   use MD-Type 1 or MD-Type 2.
   - For my setup, this means I should not rely on OVS to decrement SI or
   otherwise update NSH fields in the kernel datapath.
   - Instead, I need to inject packets into OVS with NSH headers already
   present, and perform SI decrement inside the Service Function itself rather
   than in OVS.

Please let me know if that understanding is correct.

Thanks again for the explanation.

Best regards,
Tariro Mukute

On Thu, Mar 26, 2026 at 11:30 AM Ilya Maximets <[email protected]> wrote:

> On 3/26/26 8:38 AM, tariro mukute wrote:
> > Hi OVS developers,
> >
> > I'm reporting a bug in OVS 3.3.4 where the kernel datapath rejects
> set_field
> > actions that modify nsh_si or nsh_spi on NSH MD-Type 2 packets, even
> though
> > these fields are in the base header and should be modifiable regardless
> of
> > MD type.
> > Environment
> >
> >    - OVS version: 3.3.4
> >    - Linux kernel: 6.x
> >    - Datapath: kernel
> >    - OpenFlow version: 1.3
> >    - Use case: Multi-VNF service function chaining with NSH MD-Type 2
>
> Hi, Tariro.  The implementation of the set(nsh) had a lot of issues up
> until v3.3.8.  So, you should definitely upgrade your setup if you want
> to use it.  The main commit is this one:
>
> https://github.com/openvswitch/ovs/commit/159475c1dd5cf744fa01533577efca6f6fe4fdbf
>
> However, this will not help much as support for setting NSH fields was
> also completely removed from the kernel recently, as it was broken and
> never actually worked:
>   https://lore.kernel.org/all/[email protected]/
>
> There is a plan to re-introduce it properly, so it will be available in
> one of the future 7.x kernels, but it wasn't done yet.  And I'm working
> on having a proper detection for the kernel support in userspace, so we
> can fall back on the processing in userspace without failing to install
> the flow first, but it's also not finished yet.
>
> Best regards, Ilya Maximets.
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to