All looks fine, I applied all three of your patches.
Thanks
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Various cleanups:
Change // to /* .. */
Place whitespace around binary operators.
Trim down a few long lines.
Some minor alignment formatting for better readability.
Remove some silly tabs.
Signed-off-by: Glenn Streiff <[EMAIL PROTECTED]>
---
Roland, this is
From: Eric Schneider <[EMAIL PROTECTED]>
This patch enables the iw_nes module for NetEffect RNICs to
support additional PHYs including SFP+ optical transceivers (referred
to as ARGUS in the code).
Signed-off-by: Eric Schneider <[EMAIL PROTECTED]>
Signed-off-by: Glenn Streiff <[EMAIL PROTECTED]>
-
anyway, I applied this at least.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
>
> We could do that or just copy only the flags that should be copied when
> creating a child device.
>
Or we could define a "clone" function that will have the wisdom of
which flags to copy.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.o
> I think they do but it would require using two fields for flags at the
> private data. priv->flags would
> save flags that relate to the state of the net device, and say,
> priv->cap_flags, to save stuff like LRO,
> checksum or any other stuff related to capabilities. What do you think?
We
On Tue, Apr 29, 2008 at 9:18 PM, Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> This changelog is a little too short for me to understand what this is
> fixing. It seems that child devices are left with a bogus MTU until
> they complete their multicast join, is that it?
The situation is even worse
thanks, makes sense, applied.
fast turnaround too ;)
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
> When the child joins the broadcast group reset the mtu to
> the real one.
This changelog is a little too short for me to understand what this is
fixing. It seems that child devices are left with a bogus MTU until
they complete their multicast join, is that it?
> +priv->dev->mtu = IPOIB
If a lot of QPs fall into Error state at once and the EQ of the respective
HCA is too small, it might overrun, causing the eHCA driver to stop
processing completion events and call application software's completion
handlers, effectively causing traffic to stop.
Fix this by limiting available QPs a
> > > Clean up the SFP+ patch.
> >
> > Why send a patch and then immediately a cleanup? Why not
> > just clean the
> > original patch?
> >
> > > -if ((nesadapter->OneG_Mode) &&
> > (nesadapter->phy_type[mac_index] != NES_PHY_TYPE_PUMA_1G)) {
> > > +if ((nesadapter->OneG_Mod
> My bad, on the array index idiom. I can redo.
Yes, please do resend without that.
> With regard to post patch clean-ups, I recall you telling me
> that is was preferred to either front-load or back-load the
> cleanups in a patch series.
Yes, that is true.
> I generally "cleaned-up"
> > Clean up the SFP+ patch.
>
> Why send a patch and then immediately a cleanup? Why not
> just clean the
> original patch?
>
> > - if ((nesadapter->OneG_Mode) &&
> (nesadapter->phy_type[mac_index] != NES_PHY_TYPE_PUMA_1G)) {
> > + if ((nesadapter->OneG_Mode) && (nesadapter->phy_type[
> Clean up the SFP+ patch.
Why send a patch and then immediately a cleanup? Why not just clean the
original patch?
> -if ((nesadapter->OneG_Mode) && (nesadapter->phy_type[mac_index] !=
> NES_PHY_TYPE_PUMA_1G)) {
> +if ((nesadapter->OneG_Mode) && (nesadapter->phy_type[ mac_index ] !=
>
> Signed-off-by: Stefan Roscher
Kind of an inadequate changelog ;)
Is this a fix or an enhancement or what?
> +if (atomic_read(&shca->num_cqs) >= ehca_max_cq) {
> +if (atomic_read(&shca->num_qps) >= ehca_max_qp) {
These are racy in the sense that multiple simultaneous calls to
> Olaf - I prefer that we wait a second for Roland to finish the review
> and merging of the mthca/mlx4 patches (maybe it would be splited to
> two patches) before merging them into 1.3.1 such that the instance in
> ofed would be the exact copy of the one in the kernel, agree?
I do prefer to s
Signed-off-by: Stefan Roscher
---
drivers/infiniband/hw/ehca/ehca_classes.h |5
drivers/infiniband/hw/ehca/ehca_cq.c | 10
drivers/infiniband/hw/ehca/ehca_main.c| 36 +++-
drivers/infiniband/hw/ehca/ehca_qp.c | 10
4 files c
On Tuesday 29 April 2008 13:36:36 Or Gerlitz wrote:
> Olaf - I prefer that we wait a second for Roland to finish the review
> and merging of the mthca/mlx4 patches (maybe it would be splited to two
> patches) before merging them into 1.3.1 such that the instance in ofed
> would be the exact copy
Roland Dreier wrote:
> Also it is very important for us that IPoIB 2 kernel panics will be fixed (
> https://bugs.openfabrics.org/show_bug.cgi?id=989,
> https://bugs.openfabrics.org/show_bug.cgi?id=985)
Both should not happen in upstream kernel:
989 - bug in a new optimization of OFED 1.
Eli Cohen wrote:
I don't intend to push this to upstream kernel but I think we should
keep it for ofed since for older kernels it provides better performance.
Again, the patch is very sensitive by nature, it did not pass a review
and numerous bugs were associated with it through the 1.3 cycle, I
appreciated.
Applied to ofed_1_3/linux-2.6.git and to ofed_1_3/rds-tools.git.
The following OFED build includes these patches:
http://www.openfabrics.org/builds/ofed-1.3.1/OFED-1.3.1-20080429-0110.tgz
Olaf - I prefer that we wait a second for Roland to finish the review
and merging of the mthca/mlx4
You can choose any enhancement products from our site. http://www.loauvcom.com/
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
>From 71e918e23f7f8815f3248c1089f69680ae6a203b Mon Sep 17 00:00:00 2001
From: Eli Cohen <[EMAIL PROTECTED]>
Date: Tue, 29 Apr 2008 11:48:09 +0300
Subject: [PATCH] IB/ipoib: set child MTU as the parent's
When the child joins the broadcast group reset the mtu to
the real one.
Signed-off-by: Eli Coh
On Mon, 2008-04-28 at 13:43 +0300, Or Gerlitz wrote:
> Eli Cohen wrote:
> >> 15 kernel_patches/fixes/ipoib_0190_unsig_udqp.patch
> > On older kernels this patch seems to improve throughput of small
> > messages so we should make the effort to include it. I would like to
> > verify this aga
24 matches
Mail list logo
