From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH for-next 09/10] IB/mlx4: Add timestamp_mask and hca_core_clock to query_device Date: Thu, 28 May 2015 14:47:49 -0600 Message-ID: <20150528204749.GA12780@obsidianresearch.com> References: <20150527222108.GA7855@obsidianresearch.com> <5566BDE4.50709@mellanox.com> <20150528162416.GA6515@obsidianresearch.com> <20150528175043.GA10966@obsidianresearch.com> <20150528195034.GA11182@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Lameter Cc: Or Gerlitz , Doug Ledford , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Amir Vadai , Tal Alon , Matan Barak , Yann Droneaud List-Id: linux-rdma@vger.kernel.org On Thu, May 28, 2015 at 03:34:00PM -0500, Christoph Lameter wrote: > On Thu, 28 May 2015, Jason Gunthorpe wrote: > > > Second: What about wrap around? Does it even make sense to expose less > > than 64 bits to userspace? Should the driver manage wrap around to > > create a flat 64 bit space? > > The wrap around is given by the mask. Cycle registers are often shorter > than 64 bits. I am aware of how cycle counters work. My point was exposing raw wrapping counters is a horrible UAPI. Shouldn't the driver software extend smaller counters to 64 bits? That would take a single or and an unlikely branch, so don't say 'performance' :) > through a complete cycle. But that is the nature of these counters. And > thats what you see when you look into the kernel timer subsystem for > example. Very little in the kernel is exposed to that wrapping, the timer subsystem takes care of it. Certainly, userspace never sees it. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html