> Intel is supporting multicast in hardware. Its just a bad implementation
> (broadcast and filtering MC groups in the HCA or what was that?) and there
> is no plan to fix the issues despite the problem being known for quite
> some time. Also does this mean that libfabric only to supports the
> fea
On Wed, 10 Jun 2015, Hefty, Sean wrote:
> > There are multiple problems with libfrabric related to the use cases in m=
> y
> > area. Most of all the lack of multicast support. Then there is the build
> > up of software bloat on top. The interest here is in low latency
> > operations. Redenzvous an
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 implement
> There are multiple problems with libfrabric related to the use cases in my
> area. Most of all the lack of multicast support. Then there is the build
> up of software bloat on top. The interest here is in low latency
> operations. Redenzvous and other new features are really not wanted if
> they
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
On Mon, 8 Jun 2015, Hefty, Sean wrote:
> You're assuming that the only start time of interest is when a send operati=
> on has been posted. Jason asked what I would do with libfabric. That inte=
> rface supports triggered operations. It has also been designed such that a=
> rendezvous (that ha
> > If I were adding timestamps, I would probably define a new completion
> > structure with 2 u64 time stamp fields (start and end times), and figure
> > out when start occurred, end occurred, and the timing metric later. :)
>
> Not sure why you would need the start. The app knows when it submit
On Sat, 6 Jun 2015, Doug Ledford wrote:
> The ppm rating is based upon the speed of the clock, not time. It's how
> many cycles of variance you are allowed from the target speed given in
> cycles / millions of cycles of the target clock frequency. If you have
> a 312.5MHz clock, and your accurac
On Sat, Jun 06, 2015 at 11:45:46AM -0400, Doug Ledford wrote:
> The ppm rating is based upon the speed of the clock, not time. It's how
> many cycles of variance you are allowed from the target speed given in
> cycles / millions of cycles of the target clock frequency.
Right, it is 'parts per mil
On Sat, Jun 6, 2015 at 6:45 PM, Doug Ledford wrote:
>>> So no, I disagree that rough is fine for anything.
>> I am sorry but the practical issues that we are dealing with in
>> timekeeping today shows just the opposite. For a true comparison of clocks
>> with nanosecond accuracy you would need t
On Sat, 2015-06-06 at 03:16 -0500, Christoph Lameter wrote:
> On Wed, 3 Jun 2015, Jason Gunthorpe wrote:
>
> > On Wed, Jun 03, 2015 at 07:55:58PM -0500, Christoph Lameter wrote:
> >
> > > I thknk the raw cycles and the rought oscillator speed are fine.
> >
> > Time keeping is designed to adjust fo
On Thu, 4 Jun 2015, Hefty, Sean wrote:
> If I were adding timestamps, I would probably define a new completion
> structure with 2 u64 time stamp fields (start and end times), and figure
> out when start occurred, end occurred, and the timing metric later. :)
Not sure why you would need the start
On Wed, 3 Jun 2015, Jason Gunthorpe wrote:
> On Wed, Jun 03, 2015 at 07:55:58PM -0500, Christoph Lameter wrote:
>
> > I thknk the raw cycles and the rought oscillator speed are fine.
>
> Time keeping is designed to adjust for 100's of ppm drift between
> clocks.
What time keeping? Ntp? pptp is su
On Thu, 2015-06-04 at 16:17 +, Hefty, Sean wrote:
> > No, if they followed (I didn't check yes) the extension scheme then the
> > poll call is
> >
> > struct ibv_wc_ex wcs[num_wcs]
> > ibv_poll_wc_ex(&wcs,num_wcs,sizeof(wcs[0]));
> >
> > And the drivers decide what to do based on the 3rd ar
> Can you share what the libfabric change would look like to add a
> timestamp field to the completion? That might be informative,
> libfabric is also consuming the kernel UAPI.
Libfabric uses a CQ format option. so this would just require a new format.
There is no type checking on CQ poll (read)
On Thu, Jun 04, 2015 at 04:17:35PM +, Hefty, Sean wrote:
> > No, if they followed (I didn't check yes) the extension scheme then the
> > poll call is
> >
> > struct ibv_wc_ex wcs[num_wcs]
> > ibv_poll_wc_ex(&wcs,num_wcs,sizeof(wcs[0]));
> >
> > And the drivers decide what to do based on the
> No, if they followed (I didn't check yes) the extension scheme then the
> poll call is
>
> struct ibv_wc_ex wcs[num_wcs]
> ibv_poll_wc_ex(&wcs,num_wcs,sizeof(wcs[0]));
>
> And the drivers decide what to do based on the 3rd argument, which is
> essentially the ABI version.
As a couple of opti
On Wed, Jun 03, 2015 at 07:55:58PM -0500, Christoph Lameter wrote:
> I thknk the raw cycles and the rought oscillator speed are fine.
Time keeping is designed to adjust for 100's of ppm drift between
clocks.
A communications clock source will be spec'd to be below 200ppm in
accuracy. IB clocks a
On Wed, 3 Jun 2015, Jason Gunthorpe wrote:
> MHz is fine *for mlx hardware* but someone elses hardware that uses,
> say 312.5 MHz (ie the ethernet symbol clock) is NOT OK because MHz
> looses too much precision.
Oscillator vary in frequency. In order to accurately convert to NS the
drift due to t
On Wed, Jun 03, 2015 at 10:48:28PM +0300, Or Gerlitz wrote:
> > - Should the frequency and mask be general, or driver private? If the
> >cycles->ns conversion is a function they should be driver private.
> >Even if they are general at libibverbs, they don't *have* to be in
> >the kern
On Tue, Jun 2, 2015 at 9:08 PM, Jason Gunthorpe
wrote:
> Or, the question in my mind based on looking at the UAPI patches is
> what things should be driver private and what should be general.
>
> Broadly my thoughts:
> - Should the frequency and mask be general, or driver private? If the
>cy
On Tue, 2015-06-02 at 13:04 -0600, Jason Gunthorpe wrote:
> On Tue, Jun 02, 2015 at 02:51:23PM -0400, Doug Ledford wrote:
> > On Tue, 2015-06-02 at 12:08 -0600, Jason Gunthorpe wrote:
> > > On Tue, Jun 02, 2015 at 10:35:24AM -0400, Doug Ledford wrote:
> > >
> > > > So, just so everyone is clear on
On Tue, Jun 02, 2015 at 02:51:23PM -0400, Doug Ledford wrote:
> On Tue, 2015-06-02 at 12:08 -0600, Jason Gunthorpe wrote:
> > On Tue, Jun 02, 2015 at 10:35:24AM -0400, Doug Ledford wrote:
> >
> > > So, just so everyone is clear on this point: the current user space
> > > implementation of this fea
On Tue, 2015-06-02 at 12:08 -0600, Jason Gunthorpe wrote:
> On Tue, Jun 02, 2015 at 10:35:24AM -0400, Doug Ledford wrote:
>
> > So, just so everyone is clear on this point: the current user space
> > implementation of this feature creates an unversioned, newly named
> > ibv_wc_ex struct that is ib
On Tue, Jun 02, 2015 at 10:35:24AM -0400, Doug Ledford wrote:
> So, just so everyone is clear on this point: the current user space
> implementation of this feature creates an unversioned, newly named
> ibv_wc_ex struct that is ibv_wc with a 64bit timestamp tacked on at the
> end (not 64bit aligne
On Tue, 2015-06-02 at 17:44 +0300, Or Gerlitz wrote:
> On 6/2/2015 5:35 PM, Doug Ledford wrote:
> > On Mon, 2015-06-01 at 10:43 -0600, Jason Gunthorpe wrote:
> >> On Mon, Jun 01, 2015 at 07:25:04AM -0400, Doug Ledford wrote:
> >>
> >>> attempted abstraction of ibverbs. Passing in the wc struct all
On 6/2/2015 5:35 PM, Doug Ledford wrote:
On Mon, 2015-06-01 at 10:43 -0600, Jason Gunthorpe wrote:
On Mon, Jun 01, 2015 at 07:25:04AM -0400, Doug Ledford wrote:
attempted abstraction of ibverbs. Passing in the wc struct allows the
driver to internally allocate a wc struct with extra private e
On Mon, 2015-06-01 at 10:43 -0600, Jason Gunthorpe wrote:
> On Mon, Jun 01, 2015 at 07:25:04AM -0400, Doug Ledford wrote:
>
> > attempted abstraction of ibverbs. Passing in the wc struct allows the
> > driver to internally allocate a wc struct with extra private elements
> > and pass that back to
On Mon, Jun 01, 2015 at 01:00:57PM -0400, Doug Ledford wrote:
> > case for this feature, generalizing too much may destroy the
> > performance that is valuable here.
> I'm not convinced of that. Steve has already spoke up about the
> timestamps available in cxgb4. Those are very different and y
On Mon, 2015-06-01 at 10:43 -0600, Jason Gunthorpe wrote:
> On Mon, Jun 01, 2015 at 07:25:04AM -0400, Doug Ledford wrote:
>
> > attempted abstraction of ibverbs. Passing in the wc struct allows the
> > driver to internally allocate a wc struct with extra private elements
> > and pass that back to
On Mon, Jun 01, 2015 at 07:25:04AM -0400, Doug Ledford wrote:
> attempted abstraction of ibverbs. Passing in the wc struct allows the
> driver to internally allocate a wc struct with extra private elements
> and pass that back to the user, when the user passes it back to
> ibv_get_timestamp the e
On Mon, 2015-06-01 at 08:58 -0500, Christoph Lameter wrote:
> On Mon, 1 Jun 2015, Doug Ledford wrote:
>
> > What's the point? If it's raw, it's raw. It's not coordinated between
> > adapters. Whether it's in ns or ps or flipflops doesn't matter, it's a
> > flat number that has no reference to a
On Mon, 1 Jun 2015, Doug Ledford wrote:
> What's the point? If it's raw, it's raw. It's not coordinated between
> adapters. Whether it's in ns or ps or flipflops doesn't matter, it's a
> flat number that has no reference to anything else, so the only thing
> that matters is < another version of
On Mon, 2015-06-01 at 12:30 +0300, Matan Barak wrote:
> On Sun, May 31, 2015 at 10:00 PM, Doug Ledford wrote:
> > On Sun, 2015-05-31 at 15:14 +0300, Or Gerlitz wrote:
> >> Hi Doug,
> >>
> >> This patchset adds completion timestamping supports for verbs consumers.
> >>
> >> Reviewing the weekend th
On Sun, May 31, 2015 at 10:00 PM, Doug Ledford wrote:
> On Sun, 2015-05-31 at 15:14 +0300, Or Gerlitz wrote:
>> Hi Doug,
>>
>> This patchset adds completion timestamping supports for verbs consumers.
>>
>> Reviewing the weekend threads, we've changed the flag time to reflect
>> that this is comple
On Sun, 2015-05-31 at 15:14 +0300, Or Gerlitz wrote:
> Hi Doug,
>
> This patchset adds completion timestamping supports for verbs consumers.
>
> Reviewing the weekend threads, we've changed the flag time to reflect
> that this is completion time-stamp and folded the mlx4 actual support
> into o
On 5/31/2015 3:14 PM, Or Gerlitz wrote:
We would to go for one helper
Would like to go for one helper
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
37 matches
Mail list logo
