Roland Dreier wrote:
> Since 2.6.31-rc8 has been out more than a week already, it's probably
> a good time to talk about 2.6.32 merge plans. All the pending things
> that I'm aware of are listed below.
Hi Roland, any update on the 2.6.33 merge plans?
Or.
--
To unsubscribe from this list: send th
Since 2.6.32 is already out, it's probably a good time (or at least I
shouldn't wait longer!) to talk about 2.6.33 merge plans.
Unfortunately I lost pretty much a week and a half after Thanksgiving
to the flu, so I'm pretty late and didn't get as much done as I hoped.
Anyway, all the pending things
Since 2.6.34 is here, it's probably a good time to talk about 2.6.35
merge plans. All the pending things that I'm aware of are listed below.
Boilerplate:
If something isn't already in my tree and it isn't listed below, I
probably missed it or dropped it unintentionally. Please remind me.
As us
Since 2.6.35 is here, it's probably a good time to talk about 2.6.36
merge plans. All the pending things that I'm aware of are listed below.
Boilerplate:
If something isn't already in my tree and it isn't listed below, I
probably missed it or dropped it unintentionally. Please remind me.
As us
On Mon, 2009-12-14 at 10:37 -0800, Roland Dreier wrote:
> - New QLogic qib driver. Needs at least one more iteration of
>cleanups; and I have not had time to look at the latest code in
>detail to see exactly what cleanups are needed. I am concerned
>that QLogic chose to abandon the
On Mon, Dec 14, 2009 at 10:37:40AM -0800, Roland Dreier wrote:
>
> Here are a few topics that are not ready in time for the 2.6.33 window
> and will need to wait for 2.6.34 at least:
>
>
> - IBoE. In principle I think this is starting to get there. Still
>want to see better ABI compatibil
Eli Cohen wrote:
- IBoE. In principle I think this is starting to get there. Still
want to see better ABI compatibility at least, and also make sure
the interface chosen works for both rdmacm and non-rdmacm applications.
Based on this, I am going to send a new patch set, a few days
On 12/14/2009 8:37 PM, Roland Dreier wrote:
- mlx4 SR-IOV support. Again, main problem was my lack of time. I
agree in principle with this stuff, just want to be careful that we
don't turn the mlx4 driver into an unmaintainable mess of "if
(sriov) something; else something_else"
> > - mlx4 SR-IOV support. Again, main problem was my lack of time. I
> > agree in principle with this stuff, just want to be careful that we
> > don't turn the mlx4 driver into an unmaintainable mess of "if
> > (sriov) something; else something_else" all over.
> Roland,
> Y
> I understand your frustration in having to deal with a large amount
> of code. If you included all the Mellanox firmware in the mlx4
> driver, it would be huge too. I'm limited in what I can do given
> the complexity of the IBTA spec.
Sure, I understand that your driver is going to be prett
>Here are a few topics that are not ready in time for the 2.6.35 window
>and will need to wait for 2.6.36 at least:
I just wanted to make sure that this didn't get dropped off the radar for 2.6.36
review. I have a set of patches to add support for AF_IB to the rdma_cm. At
this point, all receive
> I just wanted to make sure that this didn't get dropped off the radar for
> 2.6.36
> review. I have a set of patches to add support for AF_IB to the rdma_cm. At
> this point, all received feedback has been incorporated. I won't repost the
> entire patch set unless requested, but it's als
On Mon, May 17, 2010 at 12:58:59PM -0700, Sean Hefty wrote:
> which has been updated to 2.6.34-rc7. I tried to keep the patches small, to
> make review a little easier.
>
> Jason, you've been most involved in reviewing the patches so far.
> Any chance I can ask you to assist Roland with a more fo
On 05/17/2010 09:36 AM, Roland Dreier wrote:
Since 2.6.34 is here, it's probably a good time to talk about 2.6.35
merge plans. All the pending things that I'm aware of are listed below.
Boilerplate:
If something isn't already in my tree and it isn't listed below, I
probably missed it or droppe
> Please also pick up the 3-patch set "Least attached vector support"
> from Yevgeny on 2010-5-13? RDS changes depend on these.
It's now post -rc2, so these obviously wait for 2.6.36 at best.
However, I haven't replied to these patches in detail but in general I
don't like this approach of "pic
On 06/09/2010 11:08 AM, Roland Dreier wrote:
> Please also pick up the 3-patch set "Least attached vector support"
> from Yevgeny on 2010-5-13? RDS changes depend on these.
It's now post -rc2, so these obviously wait for 2.6.36 at best.
However, I haven't replied to these patches in detai
> > However, I haven't replied to these patches in detail but in general I
> > don't like this approach of "pick a random vector" since it is
> > non-deterministic and not likely to end up with an optimal result.
> What is the optimal way to do this, if it isn't to spread CQs evenly
> across
On 8/5/2010 2:33 AM, Roland Dreier wrote:
Hi Roland,
>
> Here are a few topics I'm tracking that are not ready in time for the
> 2.6.36 window and will need to wait for 2.6.37 at least:
>
> - XRC. While I think we made significant progress here, the fact is
>that this is not ready to merge
...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Roland Dreier
Sent: Thursday, August 05, 2010 1:34 AM
To: linux-ker...@vger.kernel.org; linux-rdma@vger.kernel.org
Subject: InfiniBand/RDMA merge plans for 2.6.36
Since 2.6.35 is here, it's probably a good time to talk
Walukiewicz, Miroslaw wrote:
Hello Roland, What about a series from Aleksey Senin [...] And my patch
RDMA/nes: IB_QPT_RAW_PACKET QP type support for nes driver
https://patchwork.kernel.org/patch/110252
Hi Mirek,
Reading your response @ http://marc.info/?l=linux-rdma&m=127954552519544
to the
, Miroslaw
Cc: Roland Dreier; linux-ker...@vger.kernel.org; linux-rdma@vger.kernel.org
Subject: Re: InfiniBand/RDMA merge plans for 2.6.36
Walukiewicz, Miroslaw wrote:
> Hello Roland, What about a series from Aleksey Senin [...] And my patch
> RDMA/nes: IB_QPT_RAW_PACKET QP type support for nes
> In general - none of our new features going to be included and I wish
> to understand the reason behind it (I hope it's not personal :-)
It's not personal -- it was a combination of when things were ready and
when I had time to work on things, and unfortunately it all lined up so
I wasn't able
Walukiewicz, Miroslaw wrote:
My patch was implemented using the most effective method available for current version of code and it is ready and working as a functionality.
[...] I will start a new discussion regarding an optimization of the post_send/post_recv path. Thank you for reminder.
Hi Mi
Roland Dreier wrote:
> What about RDMAoE?
> Patches were sent few weeks ago and it seems you ignore them.
Sorry, I should have mentioned that.
Yes, I have been ignoring the patches -- I want to get through XRC
first,
We can help with XRC if this will expedite the RDMAoE. Will it?
Tziporet
24 matches
Mail list logo
