Based on discussions so far, maybe the best path forward from here is to
delay until 2.6.24. This will let us add this version to OFED 1.3 for
more widespread testing, plus give us the time that we need to come up
with a plan to integrate QoS with the local SA.
I spoke with Matt on this, and
We will have a better idea of the issues and possible solutions once the QoS
spec is released, and we can hold discussions on it. I will be working more
details on QoS enhancements starting in the next couple of weeks.
Based on discussions so far, maybe the best path forward from here is to
Roland Dreier wrote:
> I would like to see these features moved upstream. DOE funded this
> work as part of the items we see needing on our large scale IB
> deployment (both present and future). So from at least one big customer
> perspective we see this as useful.
Does your
Roland Dreier wrote:
I would like to see these features moved upstream. DOE funded this
work as part of the items we see needing on our large scale IB
deployment (both present and future). So from at least one big customer
perspective we see this as useful.
Does your reference
We will have a better idea of the issues and possible solutions once the QoS
spec is released, and we can hold discussions on it. I will be working more
details on QoS enhancements starting in the next couple of weeks.
Based on discussions so far, maybe the best path forward from here is to
Based on discussions so far, maybe the best path forward from here is to
delay until 2.6.24. This will let us add this version to OFED 1.3 for
more widespread testing, plus give us the time that we need to come up
with a plan to integrate QoS with the local SA.
I spoke with Matt on this, and
>I think this is an important question. If we merge the local SA
>stuff, then are we creating a problem for dealing with QoS?
Yes - I do believe that merging PR caching and QoS together will be difficult.
I don't think the problems are insurmountable, but I can't say that I have a
definite
> > But to be fair, it will be difficult to enable both QoS and local PR
> > caching. To me, this would be the strongest reason against using it.
> > However, QoS places additional burden on the SA, which will make scaling
> > even more challenging.
>
> my understanding is that the local
On Tue, 2007-07-17 at 11:07 -0700, Roland Dreier wrote:
> > - Take a look at Sean's local SA caching patches. I merged
> >everything else from Sean's tree, but I'm still undecided about
> >these. I haven't read them carefully yet, but even aside from that
> >I don't have a good
> I would like to see these features moved upstream. DOE funded this
> work as part of the items we see needing on our large scale IB
> deployment (both present and future). So from at least one big customer
> perspective we see this as useful.
Does your reference to "present
> - Take a look at Sean's local SA caching patches. I merged
>everything else from Sean's tree, but I'm still undecided about
>these. I haven't read them carefully yet, but even aside from that
>I don't have a good feeling about whether there's consensus about
>this yet.
- Take a look at Sean's local SA caching patches. I merged
everything else from Sean's tree, but I'm still undecided about
these. I haven't read them carefully yet, but even aside from that
I don't have a good feeling about whether there's consensus about
this yet. Any
I would like to see these features moved upstream. DOE funded this
work as part of the items we see needing on our large scale IB
deployment (both present and future). So from at least one big customer
perspective we see this as useful.
Does your reference to present deployment
On Tue, 2007-07-17 at 11:07 -0700, Roland Dreier wrote:
- Take a look at Sean's local SA caching patches. I merged
everything else from Sean's tree, but I'm still undecided about
these. I haven't read them carefully yet, but even aside from that
I don't have a good feeling
But to be fair, it will be difficult to enable both QoS and local PR
caching. To me, this would be the strongest reason against using it.
However, QoS places additional burden on the SA, which will make scaling
even more challenging.
my understanding is that the local sa does a
I think this is an important question. If we merge the local SA
stuff, then are we creating a problem for dealing with QoS?
Yes - I do believe that merging PR caching and QoS together will be difficult.
I don't think the problems are insurmountable, but I can't say that I have a
definite
> FYI, we are working on several IPoIB performance improvement
> patches which are not on the list. Some of the patches are under test,
> some of the patches are going to be submitted soon. They are:
There is less than a week left in the merge window, and none of these
changes has
> Till when can we insert mlx4 with FMRs?
2.6.22 came out on July 8, so I would expect 2.6.23-rc1 (the end of
the merge window) to be July 22.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Till when can we insert mlx4 with FMRs?
2.6.22 came out on July 8, so I would expect 2.6.23-rc1 (the end of
the merge window) to be July 22.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
FYI, we are working on several IPoIB performance improvement
patches which are not on the list. Some of the patches are under test,
some of the patches are going to be submitted soon. They are:
There is less than a week left in the merge window, and none of these
changes has been
Roland Dreier wrote:
As you can see, I just sent my first 2.6.23 pull request for Linus.
There are still a few more things I plan to do in before the merge
window closes (in ~10 days):
Till when can we insert mlx4 with FMRs?
Tziporet
-
To unsubscribe from this list: send the line
Roland Dreier wrote:
As you can see, I just sent my first 2.6.23 pull request for Linus.
There are still a few more things I plan to do in before the merge
window closes (in ~10 days):
Till when can we insert mlx4 with FMRs?
Tziporet
-
To unsubscribe from this list: send the line
Hello Roland,
FYI, we are working on several IPoIB performance improvement
patches which are not on the list. Some of the patches are under test,
some of the patches are going to be submitted soon. They are:
1. skb aggregations for both dev xmit(networking layer) and IPoIB send
(it
Hello Roland,
FYI, we are working on several IPoIB performance improvement
patches which are not on the list. Some of the patches are under test,
some of the patches are going to be submitted soon. They are:
1. skb aggregations for both dev xmit(networking layer) and IPoIB send
(it
- Take a look at Sean's local SA caching patches. I merged
everything else from Sean's tree, but I'm still undecided about
these. I haven't read them carefully yet, but even aside from that
I don't have a good feeling about whether there's consensus about
this yet. Any opinions
On Thu, 2007-07-12 at 19:15, Roland Dreier wrote:
> As you can see, I just sent my first 2.6.23 pull request for Linus.
> There are still a few more things I plan to do in before the merge
> window closes (in ~10 days):
>
> - Write a patch to add P_Key handling to user_mad in the way we
>
On Thu, 2007-07-12 at 19:15, Roland Dreier wrote:
As you can see, I just sent my first 2.6.23 pull request for Linus.
There are still a few more things I plan to do in before the merge
window closes (in ~10 days):
- Write a patch to add P_Key handling to user_mad in the way we
discussed
- Take a look at Sean's local SA caching patches. I merged
everything else from Sean's tree, but I'm still undecided about
these. I haven't read them carefully yet, but even aside from that
I don't have a good feeling about whether there's consensus about
this yet. Any opinions
28 matches
Mail list logo
