Hi All,
we will run the following tests:
OS:
- RHEL5: up3, up4
- SLES10 SP2, SP3
- SLES11
- Kernel.org: 2.6.27, 2.6.28, 2.6.29, 2.6.30
Arch:
- ppc64 (build base and build all test)
HCA:
- eHCA
ULPs:
- IPoIB (netpipe, netperf)
This email was generated automatically, please do not reply
git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git
git_branch: ofed_kernel_1_5
Common build parameters:
Passed:
Passed on i686 with linux-2.6.19
Passed on i686 with linux-2.6.18
Passed on i686 with linux-2.6.21.1
Passed on
On Wed, Oct 21, 2009 at 03:30:29PM -0700, David J. Wilder wrote:
addr6_resolve_remote(). The second patch fixes the bugs in
addr_resolve_local(). The 3d patch I am posting now for discussion.
This patch, as Jason's suggested, moves the function of
addr_resolve_local() into
This patch, as Jason's suggested, moves the function of addr_resolve_local()
into addr4_resolve_remote()
and addr6_resolve_remote(). It eliminates the need for addr_resolve_local().
One quick comment, remove '_remote' from function names:
addr4_resolve_remote, addr6_resolve_remote, and
On Wed, Oct 21, 2009 at 04:17:01PM -0700, Sean Hefty wrote:
This doesn't end up doing the same thing as what resolve_local did. It only
matches up with the 'else if' portion below:
It does all the behaviors, it passes the input into a routing lookup
- though it is true the source needs to be
On Wed, Oct 21, 2009 at 05:36:39PM -0600, Jason Gunthorpe wrote:
- if (ipv4_is_zeronet(src_ip)) {
Looks like:
$ ip route get 10.0.0.11
local 10.0.0.11 dev lo src 10.0.0.11
cache local mtu 16436 advmss 16396 hoplimit 64
trips through the if == loopback and does
$ ip route get 10.0.0.11 from 192.168.122.1
local 10.0.0.11 from 192.168.122.1 dev lo
cache local mtu 16436 advmss 16396 hoplimit 64
(192.168.122.1 is bound to a different device on my system than
10.0.0.11)
The new case trips the if == loopback and does
rdma_translate_ip(10.0.0.11)
The
The local loopback case uses PRs?
Yes - the rdma cm makes no distinction when resolve route is called. It does a
PR query.
Even so, it still seems OK to me:
Path:
addr4_resolve_remote
$ ip route get 10.0.0.11 from 192.168.122.1
local 10.0.0.11 from 192.168.122.1 dev lo
srcIP =
On Wed, Oct 21, 2009 at 05:40:30PM -0700, Sean Hefty wrote:
Even so, it still seems OK to me:
Path:
addr4_resolve_remote
$ ip route get 10.0.0.11 from 192.168.122.1
local 10.0.0.11 from 192.168.122.1 dev lo
srcIP = 192.168.122.1
rdma_translate_ip(dst_ip = 10.0.0.11)
That is very difficult to fit into the semantics the IP routing
model uses :( And it looks like an API problem in DAPL :(
This depends on if your view is that the rdma cm is trying to match IP routing,
trying to use IP addresses as convenient names for RDMA ports, or something in
between that may
10 matches
Mail list logo
