Roland Dreier wrote:
> > Roland, I submitted an updated patch incorporating some of Sean's comments
> within
> > a day or two. Rest of comments pertained to restructuring the code and
> adding
> > some additional module parameters.
> >
> > This would require more discussions since some of
Can you give a link to your current final version of the patch?
Sean, what's your opinion of where we stand?
Let me look back over the last version that was sent and reply back
later today or tomorrow. Several of my initial comments were on code
structure.
Since module parameters create
> Roland, I submitted an updated patch incorporating some of Sean's comments
> within
> a day or two. Rest of comments pertained to restructuring the code and
> adding
> some additional module parameters.
>
> This would require more discussions since some of these had been already
>
Roland Dreier wrote:
> No mention about the iwarp port space issue?
I don't think we're at a stage where I'm prepared to merge something--
we all agree the latest patch has serious drawbacks, and it commits us
to a suboptimal interface that is userspace-visible.
Fair enough.
> I'm at a
Roland Dreier wrote:
No mention about the iwarp port space issue?
I don't think we're at a stage where I'm prepared to merge something--
we all agree the latest patch has serious drawbacks, and it commits us
to a suboptimal interface that is userspace-visible.
Fair enough.
I'm at a
Roland, I submitted an updated patch incorporating some of Sean's comments
within
a day or two. Rest of comments pertained to restructuring the code and
adding
some additional module parameters.
This would require more discussions since some of these had been already
discussed
Can you give a link to your current final version of the patch?
Sean, what's your opinion of where we stand?
Let me look back over the last version that was sent and reply back
later today or tomorrow. Several of my initial comments were on code
structure.
Since module parameters create
Roland Dreier wrote:
Roland, I submitted an updated patch incorporating some of Sean's comments
within
a day or two. Rest of comments pertained to restructuring the code and
adding
some additional module parameters.
This would require more discussions since some of these had
> No mention about the iwarp port space issue?
I don't think we're at a stage where I'm prepared to merge something--
we all agree the latest patch has serious drawbacks, and it commits us
to a suboptimal interface that is userspace-visible.
> I'm at a loss as to how to proceed.
Could we try
> > - XRC. Given the length of the backlog above and the fact that a
> > first draft of this code has not been posted yet, I don't see any
> > way that we could have something this major ready in time.
> >
> I posted the first draft patch set to the OpenFabrics list on September 18:
On Saturday 06 October 2007 01:18, Roland Dreier wrote:
> - XRC. Given the length of the backlog above and the fact that a
> first draft of this code has not been posted yet, I don't see any
> way that we could have something this major ready in time.
>
I posted the first draft patch set
On Saturday 06 October 2007 01:18, Roland Dreier wrote:
- XRC. Given the length of the backlog above and the fact that a
first draft of this code has not been posted yet, I don't see any
way that we could have something this major ready in time.
I posted the first draft patch set to
- XRC. Given the length of the backlog above and the fact that a
first draft of this code has not been posted yet, I don't see any
way that we could have something this major ready in time.
I posted the first draft patch set to the OpenFabrics list on September 18:
Sorry, I
No mention about the iwarp port space issue?
I don't think we're at a stage where I'm prepared to merge something--
we all agree the latest patch has serious drawbacks, and it commits us
to a suboptimal interface that is userspace-visible.
I'm at a loss as to how to proceed.
Could we try to
No mention about the iwarp port space issue?
Here is the status of the current proposed patch:
- needs another round of changes based on Sean's feedback
- Arkady raised issues about the pain this puts on admins
- it forces services like nfs-rdma, which already separates the nfs-rdma
server
No mention about the iwarp port space issue?
Here is the status of the current proposed patch:
- needs another round of changes based on Sean's feedback
- Arkady raised issues about the pain this puts on admins
- it forces services like nfs-rdma, which already separates the nfs-rdma
server
>
> ULPs:
>
> - Pradeep's IPoIB CM support for devices that don't have SRQs. Sean
>started reviewing but I didn't see any updated patches.
>
Roland, I submitted an updated patch incorporating some of Sean's comments
within
a day or two. Rest of comments pertained to restructuring the
ULPs:
- Pradeep's IPoIB CM support for devices that don't have SRQs. Sean
started reviewing but I didn't see any updated patches.
Roland, I submitted an updated patch incorporating some of Sean's comments
within
a day or two. Rest of comments pertained to restructuring the code and
Since 2.6.23 still isn't out, and I've managed to reduce my patch
review backlog a bit, it's probably a good idea to give another update
about what I have queued for 2.6.24 already and what I hope to get to
before the merge window opens.
Core:
- My user_mad P_Key index support patch. Merged
> 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
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.
Since 2.6.23 still isn't out, and I've managed to reduce my patch
review backlog a bit, it's probably a good idea to give another update
about what I have queued for 2.6.24 already and what I hope to get to
before the merge window opens.
Core:
- My user_mad P_Key index support patch. Merged
Roland Dreier <[EMAIL PROTECTED]> wrote on 09/17/2007 02:47:42 PM:
> > > IPoIB CM handles this properly by gathering together single pages
in
> > > skbs' fragment lists.
>
> > Then can we reuse IPoIB CM code here?
>
> Yes, if possible, refactoring things so that the rx skb allocation
> code
Roland Dreier [EMAIL PROTECTED] wrote on 09/17/2007 02:47:42 PM:
IPoIB CM handles this properly by gathering together single pages
in
skbs' fragment lists.
Then can we reuse IPoIB CM code here?
Yes, if possible, refactoring things so that the rx skb allocation
code becomes
>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
> >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
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
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: InfiniBand/RDMA merge plans for 2.6.24
>
> > Roland, could you merge the common TX CQ patch please?
> > It actually fixes a real problem.
>
> Yes, I will, but it collides with the net-2.6.24 NAPI r
> Roland, could you merge the common TX CQ patch please?
> It actually fixes a real problem.
Yes, I will, but it collides with the net-2.6.24 NAPI rework I think,
so it may not go in until a few days after the merge window.
Have you verified that the patch cures the interrupt overload issues?
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: InfiniBand/RDMA merge plans for 2.6.24
>
> 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.
Roland, could you merg
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
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.
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
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: InfiniBand/RDMA merge plans for 2.6.24
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.
Roland, could you merge the common TX CQ patch please
Roland, could you merge the common TX CQ patch please?
It actually fixes a real problem.
Yes, I will, but it collides with the net-2.6.24 NAPI rework I think,
so it may not go in until a few days after the merge window.
Have you verified that the patch cures the interrupt overload issues?
-
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: InfiniBand/RDMA merge plans for 2.6.24
Roland, could you merge the common TX CQ patch please?
It actually fixes a real problem.
Yes, I will, but it collides with the net-2.6.24 NAPI rework I think,
so it may not go in until a few
> 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
> > IPoIB CM handles this properly by gathering together single pages in
> > skbs' fragment lists.
> Then can we reuse IPoIB CM code here?
Yes, if possible, refactoring things so that the rx skb allocation
code becomes common between CM and non-CM would definitely make sense.
-
To unsubscribe
IPoIB CM handles this properly by gathering together single pages in
skbs' fragment lists.
Then can we reuse IPoIB CM code here?
Yes, if possible, refactoring things so that the rx skb allocation
code becomes common between CM and non-CM would definitely make sense.
-
To unsubscribe from
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:
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
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 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
> IPoIB CM handles this properly by gathering together single pages in
> skbs' fragment lists.
>
> - R.
Then can we reuse IPoIB CM code here?
Thanks
Shirley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
>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
> > 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
> >
> The patch is just needed to pick up broadcast MTU size instead of hard
> coding 2K right now. SKB allocation shouldn't be different with Ethernet
> Jambo Frame and IPoIB-CM which 64K MTU. I don't understand why it's
> different. Could you please explain this?
It's exactly the same problem
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
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
The patch is just needed to pick up broadcast MTU size instead of hard
coding 2K right now. SKB allocation shouldn't be different with Ethernet
Jambo Frame and IPoIB-CM which 64K MTU. I don't understand why it's
different. Could you please explain this?
It's exactly the same problem as
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
IPoIB CM handles this properly by gathering together single pages in
skbs' fragment lists.
- R.
Then can we reuse IPoIB CM code here?
Thanks
Shirley
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
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
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
> 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.
-
> 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
> > - 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.
> Since ehca can support 4K MTU, we would like to see a patch in
> IPoIB to allow link MTU to be up to 4K instead of current 2K for 2.6.24
> kernel. The idea is IPoIB link MTU will pick up a return value from SM's
> default broadcast MTU. This patch should be a small patch, I hope
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
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:
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
Hello Roland,
Since ehca can support 4K MTU, we would like to see a patch in
IPoIB to allow link MTU to be up to 4K instead of current 2K for 2.6.24
kernel. The idea is IPoIB link MTU will pick up a return value from SM's
default broadcast MTU. This patch should be a small patch, I
> - 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
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
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.
At the kernel summit, we discussed patch review (doing a web search
for "kernel summit" "reviewed-by:" should turn up lots of info on
this). Due to
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.
At the kernel summit, we discussed patch review (doing a web search
for kernel summit reviewed-by: should turn up lots of info on
this). Due to an
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.
Hello Roland,
Since ehca can support 4K MTU, we would like to see a patch in
IPoIB to allow link MTU to be up to 4K instead of current 2K for 2.6.24
kernel. The idea is IPoIB link MTU will pick up a return value from SM's
default broadcast MTU. This patch should be a small patch, I
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
Since ehca can support 4K MTU, we would like to see a patch in
IPoIB to allow link MTU to be up to 4K instead of current 2K for 2.6.24
kernel. The idea is IPoIB link MTU will pick up a return value from SM's
default broadcast MTU. This patch should be a small patch, I hope you
- 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
82 matches
Mail list logo
