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
> We actually use the OFED 1.2 version. So, this feature is in use, but not
> this
> specific implementation.
Hmm... how much testing has the implementation being proposed for
merging actually had?
It might still be OK if the answer is that it hasn't been tested at
scale but that the basic c
>> With OFED 1.2 version of the code, right?
>>
>>
>Yes.
>But maybe they also used the new module - Sean?
We actually use the OFED 1.2 version. So, this feature is in use, but not this
specific implementation.
- Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
Michael S. Tsirkin wrote:
As far as I know Intel run with SA cache enabled on large clusters with
Intel MPI
With OFED 1.2 version of the code, right?
Yes.
But maybe they also used the new module - Sean?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
> Quoting Tziporet Koren <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: Further 2.6.23 merge plans...
>
> Michael S. Tsirkin wrote:
> >We have the patches applied in ofed 1.2.c with default module parameter set
> >to caching disabled (ofed 1.2 had a differe
Michael S. Tsirkin wrote:
We have the patches applied in ofed 1.2.c with default module parameter set to
caching disabled (ofed 1.2 had a different version of the patches, but caching
is disabled by default there, too). At least in this configuration
(caching disabled), all issues I've seen seem
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
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Further 2.6.23 merge plans...
>
> > - 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
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
> We are working on IPoIB to use multiple EQ for multiple
> links/connetions scalability. Does this mean this will wait for 2.6.24?
I think so -- I don't want to merge something that first appears in
the last few days of the merge window. The idea is to get your stuff
queued up *before
> Well, the only issue I recall is about the # of EQs we want to allocate.
> Was there something else?
Yes, some ideas about how applications should pick which EQ to use.
And how to handle CPU affinity. And whether we want to try to do
something NUMA-aware.
- R.
-
To unsubscribe from this lis
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Further 2.6.23 merge plans...
>
> > > I haven't done any work on it or seen anything from anyone else, so I
> > > expect this will have to wait for 2.6.24.
>
> > I'
> 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
> > I haven't done any work on it or seen anything from anyone else, so I
> > expect this will have to wait for 2.6.24.
> I'm surprised to hear this. How about this:
> http://lists.openfabrics.org/pipermail/general/2007-May/035757.html
Sure, I remember that. But I haven't seen anything to su
> Quoting Shirley Ma <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: Further 2.6.23 merge plans...
>
> Michael,
>
> I would like to try this patch for one adapter/2 ports scalability performance
> for IPoIB. Is this patch appliable to OFED-1.2?
Most likely yes
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
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Further 2.6.23 merge plans...
>
> > Any plans to do something with multiple EQ support in mthca?
>
> I haven't done any work on it or seen anything from anyone else, so I
> expect this will have to
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
Hello Roland,
> > Any plans to do something with multiple EQ support in mthca?
>
> I haven't done any work on it or seen anything from anyone else, so I
> expect this will have to wait for 2.6.24.
We are working on IPoIB to use multiple EQ for multiple
links/connetions scalability. Doe
> Any plans to do something with multiple EQ support in mthca?
I haven't done any work on it or seen anything from anyone else, so I
expect this will have to wait for 2.6.24.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
> Also, if there's something I didn't list and didn't already include in
> the tree I asked Linus to pull, please remind me. I probably dropped it.
Any plans to do something with multiple EQ support in mthca?
--
MST
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
- 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
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 (add an ioctl to enable P_Key mode without breaking old
30 matches
Mail list logo
