Jason Gunthorpe wrote:
So why not have a more general, flexible approach? Isolating ACM from librdmacm
by using AF_IB is a good idea, it keeps them seperate and lets ACM and future
go where ever. I hope Sean can make it work with the rdma_getddrinfo idea, that
would completely seperate ACM
On Sun, Oct 25, 2009 at 01:25:21PM +0200, Or Gerlitz wrote:
well, you didn't address some of my comments (not the ice-cream
ones...), which come to say that this wouldn't be inter-operable if for
one side you convert INET/TCP to IB/IB and for the other side you don't
(e.g userA/userB
okay, I just wanted to make sure that the whole thing (ACM + modified
librdmacm + modifed rdma-cm) is applicable AND inter-operable for
AF_INET / PS_TCP applications.
I do not intend to have any changes that break anything.
Looking on kernel cma.c format_hdr code it first branches on the address
On Tue, Oct 20, 2009 at 11:08:58AM -0700, Sean Hefty wrote:
Looking on kernel cma.c format_hdr code it first branches on the address
family and next of the port space.
Going with your proposed flow, I understand that an app call to
rdma_resolve_addr will be broken down to rdma_bind_addr, ACM
rdma_bind_addr fills in the service id according RDMA IP CM service
annex.
Hm? If the sockaddr_ib contains the service ID why override it in the
kernel?
The AF_IB/PS_IB flow in the kernel side must just use straight service
IDs.
I agree. But we can still support AF_IB/PS_TCP by simply
I agree. But we can still support AF_IB/PS_TCP by simply assigning
the service ID correctly. rdma_bind_addr only needs to fill in a
service id if one is not given. This should enable
'one is not given' == 0 service ID?
yes
I'm guessing PS_IB would need to assign from the IB CM assigned
On Tue, Oct 20, 2009 at 01:05:15PM -0700, Sean Hefty wrote:
I agree. But we can still support AF_IB/PS_TCP by simply assigning
the service ID correctly. rdma_bind_addr only needs to fill in a
service id if one is not given. This should enable
'one is not given' == 0 service ID?
yes
Private data:
- AF_IB/PS_TCP - the kernel munges the private data to be compatible
with AF_INET/PS_TCP, but otherwise is the same.
- AF_IB/PS_IB - the kernel doesn't touch the private data.
I was thinking AF_IB/* - kernel doesn't touch the private data, as it lacks the
necessary information.
On Tue, Oct 20, 2009 at 01:48:34PM -0700, Sean Hefty wrote:
Private data:
- AF_IB/PS_TCP - the kernel munges the private data to be compatible
with AF_INET/PS_TCP, but otherwise is the same.
- AF_IB/PS_IB - the kernel doesn't touch the private data.
I was thinking AF_IB/* - kernel doesn't
Yep, not sure how you handle the listening side without port
conflicts?? But that doesn't seem to be a huge problem. TBH - since
ACM is kinda its own little world, it could just use a seperate
service ID space from RDMA CM?
I'm not sure how to handle the port space yet. The port space is
On Thu, Oct 8, 2009 at 1:42 AM, Sean Hefty sean.he...@intel.com wrote:
My intent, which differs from Jason's, was to fully support the existing
librdmacm interfaces as they are defined.
yes, I agree this is the way to go
Implementation wise, if the user of the librdmacm calls
Sean Hefty sean.he...@intel.com wrote:
When used over IB, the IP address is little more than a qualifier contained
within the IB CM REQ private data.
If we added support for AF_GID/AF_IB to the kernel, the rdma_cm could leave
all
of the private data carried in the IB CM REQ entirely up to the
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
If the listening side continues to use the IP mode to listen then I guess the
client can compute an appropriate service ID, but it seems a bit
strange for one side to use IP and the other side to use the ACM
method? I was imagining you'd
However, I don't manage to follow on your port space discussion with
Jason. Some apps may have client in user space and server in the
kernel or vise versa. I wouldn't tie PS_IB or a like with ACM. The ACM
ARP replacement protocol will reply only if the ip address specified
in the broadcast request
Sean Hefty wrote:
From user space, the call sequence does not change. The user calls
rdma_resolve_addr, rdma_resolve_route, rdma_connect, etc. It is up to the
librdmacm to perform the resolution. Today, the resolution request is simply
passed down to the kernel, which restricts how the
I understand that rdma_bind_address covers the local device and vlan
resolutions, but I we should also --keep-- supporting also
applications that use an explicit source address in rdma_resolve_addr
or that don't do bind, provide src=NULL to resolve_addr and rely on
the rdma-cm to use route lookup
Sean Hefty wrote:
Provide an option for user's to manually specify the socket address to DGID
mapping on InfiniBand. Currently, all mappings are done using ipoib, and
involve ARP. This will not work across IP subnets, and alternative mechanisms
of resolving the mapping are being explored.
If I understand correct your suggested changes are to optionally let an
application to - instead of the following sequence of calls
rdma_resolve_addr / addr resolved event
rdma_create_qp
rdma_resolve_route / route resolved event
rdma_connect / cm events
do
rdma_set_ib_path
rdma_create_qp
On Tue, Oct 06, 2009 at 12:05:02PM -0700, Sean Hefty wrote:
From user space, the call sequence does not change. The user calls
rdma_resolve_addr, rdma_resolve_route, rdma_connect, etc. It is up to the
librdmacm to perform the resolution. Today, the resolution request is simply
passed down
Actually, thinking about it some more, that would be very helpful. As
I said before, I have worked on apps using IB CM. The only reason is
to have complete control over the addressing. If I could use RDMA CM
API in some kind of AF_GID addressing and service ID space, it would
basically eliminate
On Tue, Oct 06, 2009 at 03:53:21PM -0700, Sean Hefty wrote:
Actually, thinking about it some more, that would be very helpful. As
I said before, I have worked on apps using IB CM. The only reason is
to have complete control over the addressing. If I could use RDMA CM
API in some kind of AF_GID
On Tue, Oct 06, 2009 at 06:20:05PM -0700, Sean Hefty wrote:
There are 3 interfaces of interest here. The librdmacm API, the rdma_ucm user
to kernel interface, and the rdma_cm interface. These patches are looking to
change the rdma_ucm interface. I want to avoid changing the API or behavior
22 matches
Mail list logo
