netdev - Re: [RFC][PATCH 1/1] net: support for hardware timestamping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200807292110.45320.opurdila@ixiacom.com>
Date:	Tue, 29 Jul 2008 21:10:44 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	Ingo Oeser <netdev@...eo.de>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	Patrick Ohly <patrick.ohly@...el.com>, netdev@...r.kernel.org
Subject: Re: [RFC][PATCH 1/1] net: support for hardware timestamping

On Tuesday 29 July 2008, Ingo Oeser wrote:
> Hi Octavian,
>

Hi Ingo,

> Just convert your hardware specific cookie you have into the nanoseconds
> resolution timstamp in skb->tstamp just before calling netif_rx()
> or net_receive_skb().
>
> These functions will not touch it, as long as they never see a ZERO
> value there. A ZERO value in tstamp.tv64 means, we have no timestamp.
>
> The difference to CPU clock doesn't matter.
> That compensation can be done by your driver or application at will.
> For mainline, compensation in driver might be preferred.
>
> As long as it is montonic increasing and related to time in any way,
> you could put anything there, I think :-)
>

In here:

net/netfilter/xt_time.c

it seems that the skb->tstamp needs to be CPU time. 

Frankly I don't care about that, but the tstamp is also used in other places 
like the IP and TCP code paths and I can't say that I barely understand that 
part :) 

But if it is ok to use any kind of monotonic increasing timestamp, that will 
solve my problem, indeed.

Thanks,
tavi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html