Since iWarp devices are not guaranteed to support loopback connections,
prevent rdma_bind_addr from associating the loopback address with
an iWarp device.
Signed-off-by: Sean Hefty
---
This includes feedback from Steve Wise based on the initial rfc patch.
Although this patch is needed to prevent
Tziporet Koren wrote:
On 2/5/2010 6:52 PM, Sean Hefty wrote:
BTW: Was this change an artifact of rebasing ofed-1.5.1 on a new
kernel
version?
apparently
Sorry to jump late on this thread
OFED 1.5.1 was not rebased on a new kernel - its still based on 2.6.30.
But many time we tak
>Can you identify the source of the regression? ie what was the change
>that broke things?
My understanding is that support for loopback addresses exposes an existing bug
in openmpi. It tries to bind to 127.0.0.1, which now succeeds. Openmpi passes
that address to a remote node for use in conne
Octavian Purdila wrote:
On Friday 05 February 2010 06:45:38 you wrote:
Again, using bitmap algorithm is not a problem and it's better, the
problem is sysctl interface, how would you plan to interact with users
via sysctl/proc if you use bitmap to handle this? I would like to hear
more details a
Tetsuo Handa wrote:
Cong Wang wrote:
Oh, IIUC, TOMOYO is something like SELinux?
Yes. It is a policy based mandatory access control implementation which is
applied to not only non root users but also root user. If MAC is enabled,
root user cannot freely modify via sysctl() or /proc/sys interfa
On 2/5/2010 6:52 PM, Sean Hefty wrote:
BTW: Was this change an artifact of rebasing ofed-1.5.1 on a new kernel
version?
apparently
Sorry to jump late on this thread
OFED 1.5.1 was not rebased on a new kernel - its still based on 2.6.30.
But many time we take patches that were acce
Roland Dreier wrote:
> My point, though, is that even with this patch in ofed-1.5.1, we still
> have an openmpi/IB/rdmacm regression. The only way to avoid this
> regression without changing openmpi is to disallow _all_ rdma binds to
> 127.0.0.1.
Can you identify the source of the regressio
> My point, though, is that even with this patch in ofed-1.5.1, we still
> have an openmpi/IB/rdmacm regression. The only way to avoid this
> regression without changing openmpi is to disallow _all_ rdma binds to
> 127.0.0.1.
Can you identify the source of the regression? ie what was the cha
Tziporet Koren wrote:
On 2/7/2010 3:22 AM, Steve Wise wrote:
Good catch, I'll update the patch and submit for 2.6.33 on Monday.
NOTE: This doesn't solve our IB/openmpi regression for ofed-1.5.1.
If this patch will be accepted to the kernel 2.6.33 we can take it too
If ofed-
Vladislav Bolkhovitin wrote:
> Or Gerlitz wrote:
> From where did you get those latency numbers?
read iostat(8), you'll see that await is "The average time (in milliseconds)
for I/O requests issued to the device to be served"
> what kind of test did you do?
I connected a Linux box through iser
On 2/7/2010 3:22 AM, Steve Wise wrote:
Good catch, I'll update the patch and submit for 2.6.33 on Monday.
NOTE: This doesn't solve our IB/openmpi regression for ofed-1.5.1.
If this patch will be accepted to the kernel 2.6.33 we can take it too
Tziporet
--
To unsubscribe fro
Hal Rosenstock wrote:
> On Fri, Feb 5, 2010 at 9:18 AM, Eli Dorfman wrote:
>> On Thu, Feb 4, 2010 at 10:52 PM, Hal Rosenstock
>> wrote:
>>> On Thu, Feb 4, 2010 at 12:43 PM, Eli Dorfman (Voltaire)
>>> wrote:
Subject: [PATCH] Wrong handling of MC create and delete traps
For these tr
12 matches
Mail list logo
