Sean wrote:
> >>It looks like this would work. If a client wanted to create multiple
> >>connections to the same remote service (for example, to separate control and
> >>data), then it seems more efficient to move the asynchronous at outside of
> >>the
> >>connect call.
> >>- Sean
>
> Thats a go
> -Original Message-
> From: Guy German [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 26, 2005 12:28 PM
> To: Caitlin Bestler; Sean Hefty; James Lentini
> Cc: openib-general@openib.org
> Subject: RE: [openib-general] RDMA connection and address
> translation A
>What do you think about this flow ?
>1. resolve device and port from ip address - synchronous operation
> (like at.c resolve_ip)
>2. rdma_create_qp (device+port) - modifies qp to init with default pkey index
>3. ib_post_recvs(...);
>4. cma_connect - asynchronous at, modify qp with correct pkey i
>What do you think about this flow ?
>1. resolve device and port from ip address - synchronous operation
> (like at.c resolve_ip)
>2. rdma_create_qp (device+port) - modifies qp to init with default pkey index
>3. ib_post_recvs(...);
>4. cma_connect - asynchronous at, modify qp with correct pkey i
> What do you think about this flow ?
> 1. resolve device and port from ip address - synchronous operation
>(like at.c resolve_ip)
> 2. rdma_create_qp (device+port) - modifies qp to init with
> default pkey index
> 3. ib_post_recvs(...);
> 4. cma_connect - asynchronous at, modify qp with
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Guy German
> Sent: Friday, August 26, 2005 1:27 AM
> To: Sean Hefty; James Lentini
> Cc: openib-general@openib.org
> Subject: RE: [openib-general] RDMA connection and addre
On Thu, 25 Aug 2005, Sean Hefty wrote:
> >> Any way providing src/dst IPs in the CM Private data is simple,
> >> and we can come with IBTA extension blessing that data structure
> >> as a general way to map IP oriented protocols over IB (a 1-2 page
> >> draft at the most) This way it can also
>> We need to insert in here:
>>
>> ib_modify_qp(...); /* somehow uses address resolution... */
>> ib_post_recvs(...);
>>
>
>or add a new call to create the qp and modify it to init (an analog to
>the socket(2) function).
Sean> This approach seems reasonable to me. Maybe something like:
Sean> rd
On Thu, Aug 25, 2005 at 01:18:06PM -0400, Talpey, Thomas wrote:
> At 12:56 PM 8/25/2005, Caitlin Bestler wrote:
> >Generic code MUST support both IPv4 and IPv6 addresses.
> >I've even seen code that actually does this.
>
> Let me jump ahead to the root question. How will the NFS layer know
> what
> -Original Message-
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 25, 2005 2:37 PM
> To: 'James Lentini'; Yaron Haviv
> Cc: openib-general@openib.org
> Subject: RE: [openib-general] RDMA connection and address translation
API
>
>
>> Any way providing src/dst IPs in the CM Private data is simple, and we
>> can come with IBTA extension blessing that data structure as a general
>> way to map IP oriented protocols over IB (a 1-2 page draft at the most)
>> This way it can also address Caitlin concerns regarding NFS & IETF
>> (si
>Sean> Another possibility could be to add a list of receives to
>Sean> rdma_connect().
>
>Guy> I added this to both connect and accept calls
>
>I don't think this is a good idea. Let's try to streamline the
>connect call, not add every single possible feature to it.
I don't think tha
>> We need to insert in here:
>>
>> ib_modify_qp(...); /* somehow uses address resolution... */
>> ib_post_recvs(...);
>>
>
>or add a new call to create the qp and modify it to init (an analog to
>the socket(2) function).
This approach seems reasonable to me. Maybe something like:
rdma_create_q
On Tue, 23 Aug 2005, Roland Dreier wrote:
> The listen side is even simpler:
>
> rdma_listen():
> inputs: local service, event callback, consumer context
>
> Wait for connection requests and pass events to the consumer's
> callback. I'm not sure if/home we want to
ways planned to be one
>option for GIDs).
>
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of James Lentini
>> Sent: Thursday, August 25, 2005 9:48 AM
>> To: Tom Tucker
>> Cc: openib-general@open
On Wed, 24 Aug 2005, Sean Hefty wrote:
> >With this in mind, I believe that the connection API needs to be
> >something more like the following:
> >
> >rdma_resolve_address():
> >inputs: dest IP address, qos, npaths,
> >done callback, opaque context
> > done callback
On Wed, 24 Aug 2005, Fab Tillier wrote:
> Performing a forward lookup via ARP is going to be a lot faster than
> ATS if the ARP entry already exists.
ATS responses could also be cached.
___
openib-general mailing list
openib-general@openib.org
http:/
> -Original Message-
> From: James Lentini [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 25, 2005 12:21 PM
> To: Yaron Haviv
> Cc: Fab Tillier; Roland Dreier; openib-general@openib.org
> Subject: RE: [openib-general] RDMA connection and address translation
API
>
> Cc: openib-general@openib.org
> Subject: RE: [openib-general] RDMA connection and address
> translation API
>
>
>
> On Wed, 24 Aug 2005, Tom Tucker wrote:
>
> > >
> > > - It's not just preventing connections to the wrong
> local address.
> >
At 12:34 PM 8/25/2005, Roland Dreier wrote:
>All implementation of NFS/RDMA on top of IB had better interoperate,
>right? Which means that someone has to specify which address
>translation mechanism is the choice for NFS/RDMA.
Correct. At the moment the existing NFS/RDMA implementations
use ATS (
On Wed, 24 Aug 2005, Tom Tucker wrote:
> >
> > - It's not just preventing connections to the wrong local address.
> >NFS-RDMA wants the remote source address (ie getpeername()) so that
> >it can look it up in the exports list.
>
> Agreed. But you could also get rid of ATS by allowing
Roland> No, I think we just need to realize that a perfectly
Roland> transport neutral protocol implementation is not
Roland> achievable.
James> It is achievable. Although the IB and iWARP protocols are
James> different, they can provide the same services to NFS-RDMA.
Not real
On Wed, 24 Aug 2005, Roland Dreier wrote:
> James> I agree with Caitlin. The eventual solution cannot force
> James> protocol modifications in ULPs.
>
> Does this mean we're stuck with the current use of ATS in NFS-RDMA?
NFS-RDMA requires that the lower layer provide IP addressing. ATS
On Wed, 24 Aug 2005, Yaron Haviv wrote:
> Any way providing src/dst IPs in the CM Private data is simple, and we
> can come with IBTA extension blessing that data structure as a general
> way to map IP oriented protocols over IB (a 1-2 page draft at the most)
> This way it can also address Caitl
On Thu, 2005-08-25 at 08:58 -0700, Roland Dreier wrote:
> Sean> Another possibility could be to add a list of receives to
> Sean> rdma_connect().
>
> Guy> I added this to both connect and accept calls
>
> I don't think this is a good idea. Let's try to streamline the
> connect call,
On Wed, 24 Aug 2005, Caitlin Bestler wrote:
> NFS over RDMA does not do that.
>
> Shouldn't that be the end of discussion on abusing CM private data
> unless you are talking *solely* about IB private data. And if that is
> the discussion, should not such a strategy be proposed to IETF
> and/or
On Wed, 24 Aug 2005, Roland Dreier wrote:
> James> You need to consider what makes sense for *both* ib and
> James> iwarp. Keep in mind that the correct API will allow a
> James> consumer to use ib and iwarp devices transparently. In
> James> other words their will be one code pa
Sean> Another possibility could be to add a list of receives to
Sean> rdma_connect().
Guy> I added this to both connect and accept calls
I don't think this is a good idea. Let's try to streamline the
connect call, not add every single possible feature to it.
- R.
__
age-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of James Lentini
> Sent: Thursday, August 25, 2005 7:54 AM
> To: Roland Dreier
> Cc: openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and address
> translation API
>
>
>
>
On Wed, 24 Aug 2005, Roland Dreier wrote:
> Sean> Is the idea that the user calls connect() and then receives
> Sean> a single callback indicating that the connection has been
> Sean> established? If so, then the user may need to modify the QP
> Sean> to the INIT state, which wo
ssing.
-Original Message-
From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 1:52 AM
To: Caitlin Bestler
Cc: Christoph Hellwig; openib-general@openib.org
Subject: Re: [openib-general] RDMA connection and address translation API
On Wed, Aug 24, 2005 at 02:22
On Wed, 2005-08-24 at 18:28 -0700, Sean Hefty wrote:
> Another possibility could be to add a list of receives to rdma_connect().
I added this to both connect and accept calls
Guy
___
openib-general mailing list
openib-general@openib.org
http://openib.
On Wed, Aug 24, 2005 at 02:22:31PM -0700, Caitlin Bestler wrote:
> Not if the host connects two disjoint networks and does not route
> between them. Such a host should/may be configured to reject any
> packet that arrives with a destination address that does not match
> the expected destination add
On Wed, Aug 24, 2005 at 02:15:09PM -0700, Roland Dreier wrote:
> Roland> Well, that's not what I would expect. Suppose I have a
> Roland> device configured with local addresses 192.168.11.12 and
> Roland> 192.168.98.99 and I
>
> Christoph> You never configure a device with local a
>With this in mind, I believe that the connection API needs to be
>something more like the following:
>
>rdma_resolve_address():
>inputs: dest IP address, qos, npaths,
>done callback, opaque context
> done callback params: status, local RDMA device,
>RDMA t
> -Original Message-
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 7:29 PM
> To: Yaron Haviv
> Cc: James Lentini; Roland Dreier; openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and address translation
API
> From: James Lentini [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 1:58 PM
>
> On Wed, 24 Aug 2005, Fab Tillier wrote:
>
> > > From: Roland Dreier [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, August 24, 2005 11:03 AM
> > >
> > > Fab> Why can't the IPV field be ignored? If
Yaron> The current implementation may not use the private data
Yaron> field (since its not critical/mandatory) but the intention
Yaron> is to add it to address multi homed hosts, we would like to
Yaron> push such a definition into IBTA so every IP oriented ULP
Yaron> can use it,
> -Original Message-
> From: James Lentini [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 5:51 PM
> To: Yaron Haviv
> Cc: Roland Dreier; openib-general@openib.org
> Subject: RE: [openib-general] RDMA connection and address translation
API
>
>
>
> -Original Message-
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 4:03 PM
> To: Tom Tucker
> Cc: Sean Hefty; Roland Dreier; openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and address
> translation
Roland> No, I think we just need to realize that a perfectly
Roland> transport neutral protocol implementation is not
Roland> achievable. It's unfortunate that kDAPL fooled people by
Roland> hiding the details of the wire protocol under a supposedly
Roland> "neutral API," but t
James> NFS/RDMA is not specific to iWARP or InfiniBand. My
James> understanding is that this could not be easily accommodated
James> in the current standards for that reason.
Yes, it seems that there will need to be some additional NFS/RDMA
drafts describing the iWARP and IB wire proto
riginal Message-
From: Roland Dreier [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 24, 2005 2:45 PM
To: Caitlin Bestler
Cc: Roland Dreier; James Lentini; openib-general@openib.org
Subject: Re: [openib-general] RDMA connection and address translation API
Caitlin> So with this wealth of opt
On Wed, 24 Aug 2005, Yaron Haviv wrote:
> > On Tue, 23 Aug 2005, Roland Dreier wrote:
> >
> > > It would be possible to have another function like
> > > rdma_getpeername() that takes the transport address and returns
> > > a source IP address. In the IB case this would do an ATS
> > > reverse l
Caitlin> So with this wealth of options available, do you agree
Caitlin> that there is no reason to elevate any of these issues to
Caitlin> being visisble to a transport neutral application?
No -- the fact that there are a wealth of options actually means that
picking one is an arbitra
Subject: Re: [openib-general] RDMA connection and address translation API
Roland> No, I think we just need to realize that a perfectly
Roland> transport neutral protocol implementation is not
Roland> achievable. It's unfortunate that kDAPL fooled people by
Roland
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier
Sent: Wednesday, August 24, 2005 2:03 PM
To: Tom Tucker
Cc: openib-general@openib.org
Subject: Re: [openib-general] RDMA connection and address translation API
By the way, as far as I can
James> You need to consider what makes sense for *both* ib and
James> iwarp. Keep in mind that the correct API will allow a
James> consumer to use ib and iwarp devices transparently. In
James> other words their will be one code path that support both.
James> If we were to adopt
-general@openib.org
Subject: Re: [openib-general] RDMA connection and address translation API
On Wed, Aug 24, 2005 at 11:14:08AM -0700, Caitlin Bestler wrote:
> The concensus when this issue was debated in the DAT Collaborative was
> that there was no transport neutral way to specify a
Roland> Well, that's not what I would expect. Suppose I have a
Roland> device configured with local addresses 192.168.11.12 and
Roland> 192.168.98.99 and I
Christoph> You never configure a device with local addresses. IP
Christoph> addresses are always a per-host attribute in
Tom> The issue is that this connection will be established when
Tom> the server may only want to accept requests that are
Tom> targetted to the 10.10.1.1 address. I don't get why this is
Tom> such a big deal. You can preclude this behavior by simply
Tom> keeping a one to one ma
On Wed, Aug 24, 2005 at 11:14:08AM -0700, Caitlin Bestler wrote:
> The concensus when this issue was debated in the DAT Collaborative was
> that there was no transport neutral way to specify a set of addresses to
> listen
> on other than "all addresses supported by this device".
That doesn't make
On Wed, Aug 24, 2005 at 09:26:42AM -0700, Roland Dreier wrote:
> Tom> I think I understand, but the purpose of specifying the IP
> Tom> address in the listen is not to filter incoming connect
> Tom> requests, but rather to determine which devices I listen
> Tom> on. I think this wor
On Wed, 24 Aug 2005, Fab Tillier wrote:
> > From: Roland Dreier [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 24, 2005 11:03 AM
> >
> > Fab> Why can't the IPV field be ignored? If a listen wants only
> > Fab> IPV4 addresses, it would specify a 16-byte compare buffer
> > Fab
ilto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 2:12 PM
> To: Tom Tucker; Roland Dreier
> Cc: openib-general@openib.org
> Subject: RE: [openib-general] RDMA connection and address
> translation API
>
> >Because it would be better to configure your network "prop
Tom> Isn't this inevitable regardless of whether or not we have a
Tom> tranport independent connection API. I thought ATS was
Tom> required by NFS for authentication/authorization. Sorry in
Tom> advance if I'm confused --- again.
Current NFS-RDMA code uses and relies on ATS. Howev
EMAIL PROTECTED] On Behalf Of Roland Dreier
> Sent: Wednesday, August 24, 2005 3:27 PM
> To: James Lentini
> Cc: Caitlin Bestler; openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and address
> translation API
>
> James> I agree with Caitlin. The
James> I agree with Caitlin. The eventual solution cannot force
James> protocol modifications in ULPs.
Does this mean we're stuck with the current use of ATS in NFS-RDMA?
Surely there's still time to fix the protocol.
- R.
___
openib-general ma
On Wed, 24 Aug 2005, Caitlin Bestler wrote:
> On 8/24/05, Fab Tillier <[EMAIL PROTECTED]> wrote:
> >
> > I think if all ULPs provide their source and destination IP in the
> > private data, you can eliminate the reverse lookup altogether. A
> > simple forward lookup is all that's needed to v
Sean> Is the idea that the user calls connect() and then receives
Sean> a single callback indicating that the connection has been
Sean> established? If so, then the user may need to modify the QP
Sean> to the INIT state, which would require some knowledge
Sean> already of the p
>If the connect call succeeds in establishing a connection, the ULP's
>QP should be ready for posting work requests. This simplifies the ULP
>considerably.
>
>The API should not create the QP. That would create race conditions
>for certain protocols. For example, consider a protocol in which the
>f
On Wed, 24 Aug 2005, Sean Hefty wrote:
> I guess that I'd like to clarify what the operation of a connect
> call would do. Would it be responsible for modifying the QP? If
> so, could such a call also allocate the QP? Note that I'm not
> advocating either of these, just trying to determine
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:openib-general-
> [EMAIL PROTECTED] On Behalf Of Fab Tillier
> Sent: Wednesday, August 24, 2005 3:00 PM
> To: 'Roland Dreier'
> Cc: openib-general@openib.org
> Subject: RE: [openib-general] RDMA connect
>Because it would be better to configure your network "properly". Putting
>IP addresses in private data is fundamentally insecure since any user
>mode client can spoof the IP address.
A simple forward lookup could detect this.
- Sean
___
openib-general
> -Original Message-
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 1:17 PM
> To: Tom Tucker
> Cc: openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and address
> translation API
>
> Tom>
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 11:18 AM
>
> For IB, using private data to listen on a specific IP address seems the
> easiest thing to do. (Maybe we could do it by mapping different IP
> addresses to different service IDs, requiring registration an
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 11:03 AM
>
> Fab> Why can't the IPV field be ignored? If a listen wants only
> Fab> IPV4 addresses, it would specify a 16-byte compare buffer
> Fab> with the first 12 bytes zero, the next 4 filled with
> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 11:14 AM
>
> On 8/24/05, Fab Tillier <[EMAIL PROTECTED]> wrote:
> > > From: Roland Dreier [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, August 24, 2005 10:16 AM
> > >
> > > Fab> Knowledge of actual IP addre
NFS over RDMA does not do that.
Shouldn't that be the end of discussion on abusing CM private data
unless you are talking *solely* about IB private data. And if that is
the discussion, should not such a strategy be proposed to IETF
and/or IBTA for an NFSoRDMA for IB official mapping?
The other en
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 10:16 AM
>
> Fab> Knowledge of actual IP addresses would be up to the consumer.
> Fab> However, the IB CM can facilitate checks by allowing the user
> Fab> to specify an offset and length in the private
>> I think if all ULPs provide their source and destination IP in the private
>data,
>> you can eliminate the reverse lookup altogether. A simple forward lookup is
>all
>> that's needed to validate that the source GID in the REQ matches the reported
>> source IP in the private data. The forward l
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:openib-general-
> [EMAIL PROTECTED] On Behalf Of Caitlin Bestler
> Sent: Wednesday, August 24, 2005 2:14 PM
> To: Fab Tillier
> Cc: openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and ad
>Fab> Why can't the IPV field be ignored? If a listen wants only
>Fab> IPV4 addresses, it would specify a 16-byte compare buffer
>Fab> with the first 12 bytes zero, the next 4 filled with the IPV4
>Fab> address, and would set the offset to that of the hello
>Fab> message's dest
Tom> Good point, although for iWARP it will work that way that you
Tom> expect. For IB, admitedly it's more complex and would
Tom> require ATS. There seems to be significant reluctance around
Tom> ATS and I don't understand the issues. Can you provide a
Tom> quick synopsis?
My
On 8/24/05, Fab Tillier <[EMAIL PROTECTED]> wrote:
> > From: Roland Dreier [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 24, 2005 10:16 AM
> >
> > Fab> Knowledge of actual IP addresses would be up to the consumer.
> > Fab> However, the IB CM can facilitate checks by allowing the use
> -Original Message-
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 11:27 AM
> To: Tom Tucker
> Cc: Roland Dreier; openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and address
> translation API
&g
Fab> Why can't the IPV field be ignored? If a listen wants only
Fab> IPV4 addresses, it would specify a 16-byte compare buffer
Fab> with the first 12 bytes zero, the next 4 filled with the IPV4
Fab> address, and would set the offset to that of the hello
Fab> message's destinati
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:openib-general-
> [EMAIL PROTECTED] On Behalf Of James Lentini
> Sent: Wednesday, August 24, 2005 1:43 PM
> To: Roland Dreier
> Cc: openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and ad
On Tue, 23 Aug 2005, Roland Dreier wrote:
> It would be possible to have another function like
> rdma_getpeername() that takes the transport address and
> returns a source IP address. In the IB case this would do an
> ATS reverse lookup. However, I hate this ide
Fab> I think the IB CM needs to be able to do two things. It
Fab> needs to allow a listen to be bound to a specific port -
Fab> using the port GUID or the LID or something along those
Fab> lines.
Yes, this is probably a good idea.
Fab> Knowledge of actual IP addresses would b
> > However, there's another problem with trying to lump address
> > translation and connection into a single "connect" call, and this
> > problem looks fundamental and fatal to me. The connect call takes a
> > QP pointer, but to create a QP the consumer needs to know which local
> > device to u
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 9:27 AM
>
> Tom> I think I understand, but the purpose of specifying the IP
> Tom> address in the listen is not to filter incoming connect
> Tom> requests, but rather to determine which devices I listen
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier
> Sent: Wednesday, August 24, 2005 11:27 AM
> To: Tom Tucker
> Cc: openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and address
> tran
Tom> I think I understand, but the purpose of specifying the IP
Tom> address in the listen is not to filter incoming connect
Tom> requests, but rather to determine which devices I listen
Tom> on. I think this works for the IB case as well. So the
Tom> utility of the IP address s
> -Original Message-
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 11:04 AM
> To: Tom Tucker
> Cc: Roland Dreier; openib-general@openib.org
> Subject: Re: [openib-general] RDMA connection and address
> translation API
>
&g
Tom> The listen side, however, I think needs a little tweaking. It
Tom> would be beneficial if the client can specify either an IP
Tom> address and port to listen on (effectively selecting a
Tom> particular device), or a wild card (all RDMA devices). An NFS
Tom> server is an exa
Roland, this looks good! A few comments below...
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier
> Sent: Wednesday, August 24, 2005 12:07 AM
> To: openib-general@openib.org
> Subject: [openib-general] RDMA connection and address tr
Roland:
Steve and I came to the same conclusion on the airplane ride back to
Austin. Whereas plain old TCP/IP selects a device at the bottom of the
stack, RDMA transports must select the device at the top because
pre-connect resources must be allocated and these resouces are
associated with a part
Hi,
- Here is a header file for cm abstraction API proposition.
- This is just a preliminary suggestion, for review.
- All comments are welcome.
- Please read the notes in the header remarks
- I am attaching the file and will send it later in a different message,
to the list.
- I think that the ib
>However, there's another problem with trying to lump address
>translation and connection into a single "connect" call, and this
>problem looks fundamental and fatal to me. The connect call takes a
>QP pointer, but to create a QP the consumer needs to know which local
>device to use. However, the
90 matches
Mail list logo
