Re: [PATCH for-next V2 0/9] Add completion timestamping support

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On Wed, 2015-06-10 at 11:45 +0300, Or Gerlitz wrote:
> On 6/10/2015 4:26 AM, Christoph Lameter wrote:
> >> >I have no problem with a bare metal interface exposing this.  But pretendin=
> >> >g that it's generic and that this is the one and only way that this could b=
> >> >e implemented doesn't make it so.
> > This is a way it was implemented and its usable. Shooting for pie in the
> > sky does not bring us anything. Nor ideas of requirements from a new
> > experimental API that does not support the basic features that we need
> > and seems to be on its way to mess up the latencies of access to RDMA operations.
> 
> Doug,
> 
> What's your maintainer say here?
> 
> The current proposal has:
> 
> 1. raw HCA clock completion generation time-stamp for CQEs
> 2. HCA clock frequency in KHZ
> 3. mask telling how many bits are relevant from the 64bit time-stamp
> 
> This is fairly simple, practical and very much usable to FSI 
> applications and users, and can be extended later if someone comes up 
> with better/other combination of the frequency/mask. Have a GO?

This is all related to the kernel <-> libibverbs interface.  In that
regard, I'm fine with what we have here.

To be more specific, the CQ creation flags and use of create_cq_ex and
the extension of the query_device struct and use of extended query
device are really the only user visible items here, and I'm OK with
those.  None of these items are hot path items and structure growth with
new fields is not the major item it is for the wc struct.

Now, the change to the wc struct and the change to ibv_poll_cq are more
important and still need some work to get to a final implementation IMO.
But that work is all limited to libibverbs and doesn't impact this
kernel patchset.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]