On Sun, Jul 29, 2007 at 05:04:31PM +0300, Michael S. Tsirkin wrote:
Hello!
Here is an API proposal for support of the SRC
(scalable reliable connected) protocol extension in libibverbs.
This adds APIs to:
- manage SRC domains
- share SRC domains between processes,
by means of creating
On Mon, Jul 30, 2007 at 11:52:21AM +0300, Michael S. Tsirkin wrote:
On Sun, Jul 29, 2007 at 05:04:31PM +0300, Michael S. Tsirkin wrote:
Hello!
Here is an API proposal for support of the SRC
(scalable reliable connected) protocol extension in libibverbs.
This adds APIs to:
-
On Mon, Jul 30, 2007 at 12:01:40PM +0300, Michael S. Tsirkin wrote:
Some code examples:
/* create a domain and share it: */
struct ibv_src_domain * d = ibv_get_new_src_domain(ctx);
int fd = open(path, O_CREAT | O_RDWR, mode);
ibv_share_src_domain(d, fd);
/*
On Mon, Jul 30, 2007 at 12:16:39PM +0300, Michael S. Tsirkin wrote:
More code examples:
Create an SRC QP, part of SRC domain:
attr.qp_type = IBV_QPT_SRC;
attr.src_domain = d;
qp = ibv_create_qp(pd, attr);
Given remote SRQ number, send data to this SRQ over an SRC QP:
On Mon, Jul 30, 2007 at 03:10:57PM +0300, Michael S. Tsirkin wrote:
It seems what you are missing is what SRC is, not how to use the API.
So tell us.
This calls for a separate document. From feedback from Sonoma I really assumed
people have it figured out.
Let's open a separate
On Mon, Jul 30, 2007 at 03:50:54PM +0300, Michael S. Tsirkin wrote:
With SRC:
O(N ^ 2 * J)
This is achived by using a single send queue (per job, out of O(N * J)
jobs)
to send data to all J jobs running on a specific node (out of O(N)
nodes).
Hardware
On Tue, Jan 15, 2008 at 01:02:12PM -0800, Sean Hefty wrote:
I would rather see OFED pull code from upstream with patches added
on only for backports and fixes.
This is very important point actually. Is there any guaranty that XRC
API will be pushed to the kernel as is? What if kernel
On Wed, Jan 16, 2008 at 09:35:39PM -0800, Roland Dreier wrote:
Roland, you said that XRC API is ugly, are you going to push it upstream
in its present form?
That's a good question. Since there is no 'present form' for XRC as
far as I can tell, it's hard to make a definitive answer.
On Tue, Jan 22, 2008 at 03:04:39PM -0800, Roland Dreier wrote:
I guess you mean just implement XRC without allowing multiple
processes to share an XRC domain? That actually seems like a sensible
thing to implement as well...
This is part of the current XRC implementation --
On Thu, Jan 31, 2008 at 01:30:23PM -0500, Doug Ledford wrote:
And I'm really not trying to come across harsh here, but if the distros are
willing to pull the OFED code, why should OFA bother trying to merge
anything
upstream?
I pull *some* OFED code. I don't pull it all. There are
10 matches
Mail list logo
