netdev - Re: [PATCH net-next 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method

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: <1323748349.2583.38.camel@edumazet-laptop>
Date:	Tue, 13 Dec 2011 04:52:29 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	netdev@...r.kernel.org, e1000-devel@...ts.sourceforge.net,
	Jacob Keller <jacob.e.keller@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	John Ronciak <john.ronciak@...el.com>,
	John Stultz <john.stultz@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH net-next 2/2] igb: offer a PTP Hardware Clock instead of
 the timecompare method

Le mardi 13 décembre 2011 à 04:41 +0100, Richard Cochran a écrit :
> On Tue, Dec 13, 2011 at 04:28:52AM +0100, Eric Dumazet wrote:
> > 
> > Adding a (shared) spinlock on a multiqueue device is source of extra
> > delay (because of extra cache line trafic), I guess.
> > 
> > It seems current code doesnt need a spinlock, maybe it was a bug ?
> 
> (I didn't think about the old code. I only deleted it. ;)
> 
> The spinlock is needed because reading the 64 bit time value involves
> reading two 32 registers. The first read latches the value. Ditto for
> writing.
> 
> In addition, here we have to watch the most significant bit for
> one-to-zero transistion, in order to keep count of the overflow.
> 
> It is too bad that we have to take the spinlock for every time stamped
> packet, but it is the hardware's fault for not providing a 64 bit wide
> nanosecond time register.
> 

Yes, probably. Are you sure a workaround is not possible, using a
seqlock for synchronization of threads, and two hardware reads ?

Or maybe it doesnt matter at all :)



--
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