Files
linux/include/uapi/linux
Martin KaFai Lau 8d21ec0e46 bpf: Add __sk_buff->delivery_time_type and bpf_skb_set_skb_delivery_time()
* __sk_buff->delivery_time_type:
This patch adds __sk_buff->delivery_time_type.  It tells if the
delivery_time is stored in __sk_buff->tstamp or not.

It will be most useful for ingress to tell if the __sk_buff->tstamp
has the (rcv) timestamp or delivery_time.  If delivery_time_type
is 0 (BPF_SKB_DELIVERY_TIME_NONE), it has the (rcv) timestamp.

Two non-zero types are defined for the delivery_time_type,
BPF_SKB_DELIVERY_TIME_MONO and BPF_SKB_DELIVERY_TIME_UNSPEC.  For UNSPEC,
it can only happen in egress because only mono delivery_time can be
forwarded to ingress now.  The clock of UNSPEC delivery_time
can be deduced from the skb->sk->sk_clockid which is how
the sch_etf doing it also.

* Provide forwarded delivery_time to tc-bpf@ingress:
With the help of the new delivery_time_type, the tc-bpf has a way
to tell if the __sk_buff->tstamp has the (rcv) timestamp or
the delivery_time.  During bpf load time, the verifier will learn if
the bpf prog has accessed the new __sk_buff->delivery_time_type.
If it does, it means the tc-bpf@ingress is expecting the
skb->tstamp could have the delivery_time.  The kernel will then
read the skb->tstamp as-is during bpf insn rewrite without
checking the skb->mono_delivery_time.  This is done by adding a
new prog->delivery_time_access bit.  The same goes for
writing skb->tstamp.

* bpf_skb_set_delivery_time():
The bpf_skb_set_delivery_time() helper is added to allow setting both
delivery_time and the delivery_time_type at the same time.  If the
tc-bpf does not need to change the delivery_time_type, it can directly
write to the __sk_buff->tstamp as the existing tc-bpf has already been
doing.  It will be most useful at ingress to change the
__sk_buff->tstamp from the (rcv) timestamp to
a mono delivery_time and then bpf_redirect_*().

bpf only has mono clock helper (bpf_ktime_get_ns), and
the current known use case is the mono EDT for fq, and
only mono delivery time can be kept during forward now,
so bpf_skb_set_delivery_time() only supports setting
BPF_SKB_DELIVERY_TIME_MONO.  It can be extended later when use cases
come up and the forwarding path also supports other clock bases.

Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-03-03 14:38:49 +00:00
..
2021-09-14 08:46:08 +02:00
2021-01-25 18:44:44 +01:00
2020-05-28 11:22:14 +02:00
2020-12-28 14:21:31 +00:00
2019-12-18 18:07:31 +01:00
2021-11-01 13:36:08 +00:00
2020-08-12 10:58:00 -07:00
2019-03-07 18:32:01 -08:00
2020-10-09 12:47:02 -06:00
2021-10-29 12:38:43 +02:00
2019-10-09 22:31:14 -04:00
2019-09-25 17:51:39 -07:00
2021-11-26 16:48:59 +01:00
2019-08-02 14:44:02 +10:00
2021-08-10 13:32:40 -04:00
2020-07-19 19:20:22 -07:00
2020-06-24 21:34:11 +02:00
2020-05-14 16:44:25 +02:00
2019-03-27 13:30:07 -07:00
2018-06-18 15:11:53 +10:00
2021-10-07 13:51:11 +02:00
2021-02-08 13:01:24 +01:00
2021-10-06 12:05:51 +00:00
2021-11-15 07:53:10 -08:00
2021-06-03 15:31:34 -07:00
2022-03-01 18:29:27 -08:00
2020-07-13 15:32:56 -07:00
2020-04-20 12:43:24 -07:00
2021-02-26 09:41:03 -08:00
2021-05-21 15:03:50 +02:00
2020-05-21 08:20:35 -06:00
2017-11-28 16:54:00 +01:00
2021-03-10 09:34:06 +01:00
2020-08-18 15:44:44 +02:00
2021-10-14 23:06:28 +02:00
2018-01-14 23:06:30 -05:00
2018-01-16 16:47:29 +01:00
2021-07-06 10:37:46 -05:00
2019-10-02 20:32:27 -06:00
2019-01-22 10:21:45 +01:00
2019-07-30 20:34:34 +02:00
2018-03-20 03:17:41 +02:00
2020-03-29 22:30:57 -07:00
2021-10-18 17:20:50 +02:00
2017-11-16 10:49:00 +09:00
2021-03-10 09:34:06 +01:00
2021-01-07 16:17:32 +01:00
2021-09-16 14:36:26 +01:00
2018-09-03 13:29:38 +02:00
2019-12-09 09:59:07 +01:00
2020-03-29 23:29:08 +02:00
2020-10-23 11:55:28 -04:00
2020-10-23 11:55:28 -04:00
2019-08-01 21:49:46 +02:00
2021-06-12 13:16:45 -07:00
2020-07-13 15:32:56 -07:00