I tested this by simulating a slow passive side responder, and it worked as
expected for those tests. Using an MRA does add another MAD to the CM
exchange,
which is why it is sent only after seeing a duplicate request.
Alternatively,
we can take the OFED module parameter patch.
OK -- just to make sure I'm understanding what you're saying: have you
confirmed that your proposed [CM MRA] patches actually fix the issue?
Not directly. I cannot easily test kernel patches on our larger, production
clusters. We've seen the issue with specific applications on 512 and
Umm... this is a difficult situation for me to merge the changes then.
We're changing the CM retry behavior blind here. How do we know that
the MRA changes don't make the scalability issue worse?
What's currently upstream doesn't work for Intel MPI on our larger clusters.
The connection requests
On Thursday 13 September 2007 20:57, Roland Dreier wrote:
HW specific:
- I already merged patches to enable MSI-X by default for mthca and
mlx4. I hope there aren't too many systems that get hosed if a
MSI-X interrupt is generated.
- Jack and Michael's mlx4 FMR support. Will
Hal Rosenstock wrote:
Has anyone tested these with QoS actually be used ? I suppose this
requires Connect-X.
You can test it with a switch without ConnectX.
If you want that the HCA will react to the QoS setting too then you
should have ConnectX
Tziporet
-
To unsubscribe from this
The IGMP enabling patch posted by me on September 2nd isn't on your list
http://lists.openfabrics.org/pipermail/general/2007-September/040250.html
can you add it?
Yes, I lost that somehow. I will add it to my list of things to take
a look at (no opinion yet).
- R.
-
To unsubscribe from
Roland Dreier wrote:
With 2.6.24 probably opening in the not-too-distant future, it's
probably a good time to review what my plans are for when the merge
window opens.
Core:
- Sean's QoS changes. These look fine at first glance, and I just
plan to understand the backwards compatibility
Roland Dreier wrote:
I was about to post v2 of my patch to avoid port space collisions with
the native stack. Can we get that 2.6.24? It is high priority
IMO. I've tried to solicit review on it, but I think folks are
reluctant... ;-)
I would like to get this in, but I'm still at
On Thu, Sep 13, 2007 at 01:59:21PM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
Well, if it involves /sharing/ port space with the native stack, i.e.
where port 1234 is IB but 1235 is Linux, pretty much all the networking
devs have NAK'd that approach AFAICS.
Jeff, I posted a fix that
I've been meaning to track down the bnx2 iscsi offload patch to look
and see if this issue is addressed, since the same problem seems to
exist: it seems an iscsi connection and a main stack tcp connection
might share the same 4-tuple unless something is done to avoid that
happening.
OK -- just to make sure I'm understanding what you're saying: have you
confirmed that your proposed patches actually fix the issue?
Not directly. I cannot easily test kernel patches on our larger, production
clusters. We've seen the issue with specific applications on 512 and 1024
cores, but
On Fri, 2007-09-14 at 09:18 -0700, Roland Dreier wrote:
However, do you have any plans to support iSCSI offload for targets?
Also, looking at the first CNIC patch, I can't help but notice that
you seem to have at least some support for iWARP there. How does the
CNIC look? Does it share the
Hey Roland,
I was about to post v2 of my patch to avoid port space collisions with
the native stack. Can we get that 2.6.24? It is high priority IMO.
I've tried to solicit review on it, but I think folks are reluctant... ;-)
Steve.
Roland Dreier wrote:
With 2.6.24 probably opening in
- My user_mad P_Key index support patch. I'll test the ioctl to
change to the new mode and merge this I guess, since Hal and Sean
have tested this out.
I can give this patch a reviewed-by: too, and I will also try to review a couple
of the pending ipoib patches.
- Sean's QoS changes.
Steve Wise wrote:
I was about to post v2 of my patch to avoid port space collisions with
the native stack. Can we get that 2.6.24? It is high priority IMO.
I've tried to solicit review on it, but I think folks are reluctant... ;-)
Well, if it involves /sharing/ port space with the native
Jeff Garzik wrote:
Steve Wise wrote:
I was about to post v2 of my patch to avoid port space collisions with
the native stack. Can we get that 2.6.24? It is high priority IMO.
I've tried to solicit review on it, but I think folks are reluctant...
;-)
Well, if it involves /sharing/ port
Steve Wise wrote:
Jeff Garzik wrote:
Steve Wise wrote:
I was about to post v2 of my patch to avoid port space collisions
with the native stack. Can we get that 2.6.24? It is high priority
IMO. I've tried to solicit review on it, but I think folks are
reluctant... ;-)
Well, if it involves
- My user_mad P_Key index support patch. I'll test the ioctl to
change to the new mode and merge this I guess, since Hal and Sean
have tested this out.
I can give this patch a reviewed-by: too, and I will also try to review a
couple
of the pending ipoib patches.
Thanks!
I was about to post v2 of my patch to avoid port space collisions with
the native stack. Can we get that 2.6.24? It is high priority
IMO. I've tried to solicit review on it, but I think folks are
reluctant... ;-)
I would like to get this in, but I'm still at least a little
reluctant,
Well, if it involves /sharing/ port space with the native stack,
i.e. where port 1234 is IB but 1235 is Linux, pretty much all the
networking devs have NAK'd that approach AFAICS.
Just to be clear, InfiniBand has no problem; the issue is port
collisions involving iWARP connections.
- R.
-
On Thu, 2007-09-13 at 14:11 -0700, Roland Dreier wrote:
I've been meaning to track down the bnx2 iscsi offload patch to look
and see if this issue is addressed, since the same problem seems to
exist: it seems an iscsi connection and a main stack tcp connection
might share the same 4-tuple
21 matches
Mail list logo
