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 has to be one of the most difficult words in the English =
> language to spell correctly, even with spell check) protocol could be imple=
> mented by the provider.  On the receive side, it may be of interest to repo=
> rt the start and ending time for larger transfers, primarily for debugging =
> purposes.

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 increase the latency.

> I have no idea how the time stamps are expected to be used, so why limit it=
> ?  An app could just as easily create their own time stamp when reading a w=
> ork completion, especially when the data is going into an anonymous receive=
>  buffer.  That would seem to work for your use case.

No it cannot as described earlier. The work can be completed much earlier
than when the polling thread gets around to check for it. We do that today
since there is nothing better but this means that there is a gap there.
On the send side you have no easy way to telling when the operation was
complete without the timestamp.

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


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to