On 11/6/24 7:31 PM, Jason Xing wrote:
/* ack: request ACK timestamp (tcp only)
* req_tskey: bpf prog can request to use a particular tskey.
* req_tskey should always be 0 for tcp.
* return: -ve for error. u32 for the tskey that the bpf prog should use.
* may be different from the req_tskey (e.g. the user space has
* already set one).
*/
__bpf_kfunc s64 bpf_skops_enable_tx_tstamp(struct bpf_sock_ops_kern *skops,
bool ack, u32 req_tskey);
For udp, I don't know whether it will be easier to set the tskey in the 'cork'
or 'sockcm_cookie' or 'skb'. I guess it depends where the bpf prog is called. If
skb, it seems the bpf prog may be called repetitively for doing the same thing
in the while loop in __ip[6]_append_data. If it is better to set the 'cork' or
'sockcm_cookie', the cork/sockcm_cookie pointer can be added to 'struct
bpf_sock_ops_kern'. The sizeof(struct bpf_sock_ops_kern) is at 64bytes. Adding
one pointer is not ideal.... probably it can be union with syn_skb but will need
some code audit (so please check).
3) extend SCM_TS_OPT_ID for the udp/bpf case.
I don't understand. What does it mean to extend SCM_TS_OPT_ID?
Oh, I thought you expect to pass the key from the bpf program through
using the interface of SCM_TS_OPT_ID feature which isn't supported by
bpf. Let me think more about it first.
I still don't understand the SCM_TS_OPT_ID part but no I don't mean that.
The bpf prog uses the kfunc to directly set the tskey (and tx_flags) in
skb/cork/sockcm_cookie. The name here for the tskey and tx_flags may be
different based on if it is skb/cork/sockcm_cookie..
