You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When capturing packets, e.g., in the packetcapture service, the dataplane code has to take the timestamp of the packet. However, it seems that somewhere the Linux kernel handles the timestamp of the packet, given that there is a tstamp member in the sk_buff structure.
Describe the solution you'd like
It would be nice to be able to take the value possibly stored in sk_buff.tstamp instead of taking the timestamp in eBPF dataplane code.
Additional context
From some tests done on the packetcapture service, it seems that the value in sk_buff.tstamp is always zero (program running in TC, attached to both physical and virtual interfaces). However, the member is there and if we type man packet, which refers to AF_SOCKET, it says that the PACKET_TIMESTAMP is just for this purpose. So, it is not clear how to exploit this timestamping in eBPF code.
The text was updated successfully, but these errors were encountered:
The proposal in #320 is to provide a method to generate a Unix epoch timestamp by simply calling bpf_ktime_get_ns() and adding this value to a precomputed Epoch timestamp.
The problem we are facing with sk_buff.tstamp is that sometimes the field is empty or contains an unknown value.
Probably I am missing something, but right now it seems that we cannot fully trust this field, even because it does not exists in a XDP program
Problem statement
When capturing packets, e.g., in the packetcapture service, the dataplane code has to take the timestamp of the packet. However, it seems that somewhere the Linux kernel handles the timestamp of the packet, given that there is a
tstamp
member in thesk_buff
structure.Describe the solution you'd like
It would be nice to be able to take the value possibly stored in
sk_buff.tstamp
instead of taking the timestamp in eBPF dataplane code.Additional context
From some tests done on the packetcapture service, it seems that the value in
sk_buff.tstamp
is always zero (program running in TC, attached to both physical and virtual interfaces). However, the member is there and if we typeman packet
, which refers toAF_SOCKET
, it says that thePACKET_TIMESTAMP
is just for this purpose. So, it is not clear how to exploit this timestamping in eBPF code.The text was updated successfully, but these errors were encountered: