Re: [PATCH RFC net-next] netlink: Add support for timestamping messages

[David Ahern <dsahern@gmail.com>]

On 5/9/19 10:51 AM, David Miller wrote:
> From: David Ahern <dsahern@kernel.org>
> Date: Thu,  9 May 2019 08:55:42 -0700
> 
>> From: David Ahern <dsahern@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 <dsahern@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.