On 5/9/19 10:51 AM, David Miller wrote: > From: David Ahern <dsah...@kernel.org> > Date: Thu, 9 May 2019 08:55:42 -0700 > >> From: David Ahern <dsah...@gmail.com> >> >> Add support for timestamping netlink messages. If a socket wants a >> timestamp, it is added when the skb clone is queued to the socket. >> >> Allow userspace to know the actual time an event happened. In a >> busy system there can be a long lag between when the event happened >> and when the message is read from the socket. Further, this allows >> separate netlink sockets for various RTNLGRP's where the timestamp >> can be used to sort the messages if needed. >> >> Signed-off-by: David Ahern <dsah...@gmail.com> >> --- >> one question I have is whether it would be better to add the timestamp >> when the skb is created so it is the same for all sockets as opposed to >> setting the time per socket. > > If the importance is that the timestamp is when the "event" occurs > then you should set it at skb creation time. >
The overhead of adding the timestamp is why I was thinking of setting it based on a socket request. If I defer setting the timestamp to do_one_broadcast only systems where a process / socket wanting a timestamp takes the overhead and all processes / sockets wanting the timestamp see the same the one. Seems like a good trade-off. It is a very small time gap between the skb allocation and do_one_broadcast. Worst case scenario is a notification storm such as a huge route dump into the kernel. Enabling the timestamp does have a measurable overhead (~15% for a notification storm of ~240,000/sec). Given all of the other improvements the end result is still a huge gain, but to defer the overhead only to users who want it seems like the right thing to do.
