If the kernel is too old for timestamping, it should not be fatal. I
prefer to not accept SO_TIMESTAMP_OLD as the size of the timestamp is
arch-dependent.
Fix#1978
We don't need to use NativeEndian, we can just cast. The alignment is
ensured by CMSG_DATA macro, so it's safe even on archs not allowing
unaligned data access.
This way of doing things was one of the main reason Go took so much time
to get binary.NativeEndian.
This requires Linux 5.0+. Below, we would just get no timestamp. This is
more correct this way, even if most people would run that on 64-bit
Linux and already get 64-bit timestamp.
We also don't use the nanosecond part as it is "long long" and should be
virtually 64-bit on all archs, this is not totally correct.
This is useless as this also needs to be enabled with the SIOCSHWTSTAMP
ioctl. This requires CAP_NET_ADMIN and we would need to guess the
physical interface. Too much trouble.
This reverts commit 57e725108e. This is
mostly useless as it does not work inside an unprivileged container and
outside of it, people should just increase rmem_max on their system.
Less code is better.
With very large receive buffer, we may process many packets in burst
and not account for the real receive time. The kernel is able to
provide us with a timestamp, use it. We ask for hardware timestamps if
possible.
