On 10/12/2021 03:01, Jakub Kicinski wrote:
On Tue, 7 Dec 2021 23:56:33 +0100 Mathieu Jadin wrote:
Add a flag that, if set, triggers the call of eBPF program for each
packet holding an IPv6 extension header. Also add a sock_ops operator
that identifies such call.
This change uses skb_data and skb_data_end introduced for TCP options'
parsing but these pointer cover the IPv6 header and its extension
headers.
For instance, this change allows to read an eBPF sock_ops program to
read complex Segment Routing Headers carrying complex messages in TLV or
observing its intermediate segments as soon as they are received.
Can you share example use cases this opens up?
In the context of IPv6 Segment Routing, Host A could communicate to Host
B the Segment Routing Header (SRH) that it should use. For instance, a
server could alleviate the load on its load balancer by asking the other
host to route data away from the load balancer.
This can be more generic: Host A can have better information about the
paths to use than the Host B.
Host A could communicate that in two ways:
1) Host B could simply reverse the segment list of an SRH used by Host
A. This would make Host B follow the same path as Host A.
2) Host A could use a custom TLV in its own SRH to give an SRH to Host B.
For both options, Host B needs another patch to actually set the SRH in
the same eBPF program. I plan to submit that later.
As for the other IPv6 extension headers, this seemed like a good
opportunity to enable users to parse their received extension headers in
eBPF.
Mathieu
