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 he
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
de
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 refere
>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 soluti
> > 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
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 fe
> 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 deployme
> - 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. An
> 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 bee
> 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 http://vge
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 "unsubscr
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 wi
- 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 abo
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
>disc
14 matches
Mail list logo
