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 <[email protected]> GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
