From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Miller <davem@davemloft.net>
Subject: Re: [PATCH] pktgen: document 32-bit timestamp overflow
Date: Wed, 08 Nov 2017 15:56:47 +0900 (KST)
Message-ID: <20171108.155647.75329617506195991.davem@davemloft.net>
References: <20171107103856.2830339-1-arnd@arndb.de>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: stephen@networkplumber.org, fan.du@windriver.com,
        edumazet@google.com, john.fastabend@gmail.com, oleg@redhat.com,
        ast@plumgrid.com, minipli@googlemail.com, tgraf@suug.ch,
        johannes.berg@intel.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
To: arnd@arndb.de
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20171107103856.2830339-1-arnd@arndb.de>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

From: Arnd Bergmann <arnd@arndb.de>
Date: Tue,  7 Nov 2017 11:38:32 +0100

> Timestamps in pktgen are currently retrieved using the deprecated
> do_gettimeofday() function that wraps its signed 32-bit seconds in 2038
> (on 32-bit architectures) and requires a division operation to calculate
> microseconds.
> 
> The pktgen header is also defined with the same limitations, hardcoding
> to a 32-bit seconds field that can be interpreted as unsigned to produce
> times that only wrap in 2106. Whatever code reads the timestamps should
> be aware of that problem in general, but probably doesn't care too
> much as we are mostly interested in the time passing between packets,
> and that is correctly represented.
> 
> Using 64-bit nanoseconds would be cheaper and good for 584 years. Using
> monotonic times would also make this unambiguous by avoiding the overflow,
> but would make it harder to correlate to the times with those on remote
> machines. Either approach would require adding a new runtime flag and
> implementing the same thing on the remote side, which we probably don't
> want to do unless someone sees it as a real problem. Also, this should
> be coordinated with other pktgen implementations and might need a new
> magic number.
> 
> For the moment, I'm documenting the overflow in the source code, and
> changing the implementation over to an open-coded ktime_get_real_ts64()
> plus division, so we don't have to look at it again while scanning for
> deprecated time interfaces.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied to net-next, thanks Arnd.