On 9/19/22 10:22 PM, Shmulik Ladkani wrote:
On Mon, 19 Sep 2022 19:58:20 -0700 Yonghong Song <yhs@xxxxxx> wrote:
+ /* set empty geneve options (of runtime length) using a dynptr */
+ __builtin_memset(opts, 0x0, sizeof(*opts));
+ if (*local_ip % 2)
+ bpf_dynptr_from_mem(opts, GENEVE_OPTS_LEN1, 0, &dptr);
+ else
+ bpf_dynptr_from_mem(opts, GENEVE_OPTS_LEN0, 0, &dptr);
+ ret = bpf_skb_set_tunnel_opt_dynptr(skb, &dptr);
I think the above example is not good. since it can write as
if (*local_ip % 2)
ret = bpf_skb_set_tunnel_opt(skb, opts, GENEVE_OPTS_LEN1);
else
ret = bpf_skb_set_tunnel_opt(skb, opts, GENEVE_OPTS_LEN0);
In the commit message of Patch 2, we have
===
For example, we have an ebpf program that gets geneve options on
incoming packets, stores them into a map (using a key representing
the incoming flow), and later needs to assign *same* options to
reply packets (belonging to same flow).
===
It would be great if you can create a test case for the above
use case.
Yes, but please note dynptr trim/advance API is still WIP:
https://lore.kernel.org/bpf/CAJnrk1a53F=LLaU+gdmXGcZBBeUR-anALT3iO6pyHKiZpD0cNw@xxxxxxxxxxxxxx/
However, once we settled on the API for setting variable length tunnel
options from a *dynptr* (and not from raw buffer+len), we can just
exercise 'bpf_skb_set_tunnel_opt_dynptr' regardless the original
usecase (i.e. we can assume dynptrs can be properly mangled).
In any case, I can later amend the test once all dynptr convenience
helpers are accepted.
Could you give more details how you could use these additional
dynptr trim/advance APIs in your use case? It would give an
overall picture whether bpf_skb_set_tunnel_opt_dynptr() is
useful or not.
W.r.t. your map use case, you could create a map and populate
needed info (geneve options, lens) in user space, and then
the bpf program tries to get such information from the map
and then call bpf_skb_set_tunnel_opt_dynptr(). Maybe this
could mimic your use case?
Best,
Shmulik
