Re: [ewg] status of ofed ipoib changes which are not upstream
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 again and if this is correct I will send for review. > I don't see why should performance gain only with old kernels justify > including such patch, Roland? 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. > >> 16 kernel_patches/fixes/ipoib_0210_draft_wr.patch > >> 17 kernel_patches/fixes/ipoib_0220_ud_post_list.patch > >> 18 kernel_patches/fixes/ipoib_0230_srq_post_n.patch > >> 19 kernel_patches/fixes/ipoib_0250_non_srq_param.patch > >> 20 kernel_patches/fixes/ipoib_0290_reduce_cm_tx.patch > >> 21 kernel_patches/fixes/ipoib_0310_def_ring_sizes.patch > >> 22 kernel_patches/fixes/ipoib_0320_small_skb_copy.patch > >> 23 kernel_patches/fixes/ipoib_0330_child_mtu.patch > >> 24 kernel_patches/fixes/ipoib_selector_updated.patch We have a few critical bugs in ofed which I will address first and in the background I'll push the fixes first and then the other patches. I hope to get more of them to 2.6.26 and the rest will wait for 2.6.27. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/ipoib: set child MTU as the parent's
>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 Cohen <[EMAIL PROTECTED]> --- drivers/infiniband/ulp/ipoib/ipoib_vlan.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c index 431fdea..872b670 100644 --- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c @@ -90,6 +90,9 @@ int ipoib_vlan_add(struct net_device *pdev, unsigned short pkey) } priv->max_ib_mtu = ppriv->max_ib_mtu; + /* MTU will be reset when mcast join happens */ + priv->dev->mtu = IPOIB_UD_MTU(priv->max_ib_mtu); + priv->mcast_mtu = priv->admin_mtu = priv->dev->mtu; set_bit(IPOIB_FLAG_SUBINTERFACE, &priv->flags); priv->pkey = pkey; -- 1.5.5 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Choose healthy and long lasting life.
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
[ewg] Re: [ofa-general] [PATCH 0/8] RDS patch set
Vladimir Sokolovsky wrote: Olaf Kirch wrote: mthca/mlx4: avoid recycling old FMR R_Keys too soon This is a re-run of a mthca patch I posted a while back; Jack Morgenstein requested that I should make the same change in the mlx4 driver. Here it is; review and feedback much 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 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? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] status of ofed ipoib changes which are not upstream
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 think isn't it should be enough to see that there is a problem here. If you see this differently, then send it for "review only for old kernels", state on which kernels you see improvement, what is this improvement and then we see. 16 kernel_patches/fixes/ipoib_0210_draft_wr.patch 17 kernel_patches/fixes/ipoib_0220_ud_post_list.patch 18 kernel_patches/fixes/ipoib_0230_srq_post_n.patch 19 kernel_patches/fixes/ipoib_0250_non_srq_param.patch 20 kernel_patches/fixes/ipoib_0290_reduce_cm_tx.patch 21 kernel_patches/fixes/ipoib_0310_def_ring_sizes.patch 22 kernel_patches/fixes/ipoib_0320_small_skb_copy.patch 23 kernel_patches/fixes/ipoib_0330_child_mtu.patch 24 kernel_patches/fixes/ipoib_selector_updated.patch We have a few critical bugs in ofed which I will address first and in the background I'll push the fixes first and then the other patches. I hope to get more of them to 2.6.26 and the rest will wait for 2.6.27. With "critical bugs in ofed (1.3)" are you referring to the IPoIB related cases 985,989,1004,etc or its something else? 2.6.26 feature window is going to be closed any day now, so the way to go is review and merge them into the for-2.6.27 branch, but lets do it now and not 3 months away. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED April 21 meeting summary
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.3 (see bug report for details) 985 - bug in backports only (Eli will update the bug and resolution) Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] [PATCH 0/8] RDS patch set
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 of the one in the kernel, agree? I don't have a very strong opinion on this either way. If Vlad wants to merge the patch the way I submitted it, I won't argue. If he replaces it with the patch that ends up in mainline, I'm just as happy. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
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 changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h
b/drivers/infiniband/hw/ehca/ehca_classes.h
index 3d6d946..00bab60 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -66,6 +66,7 @@ struct ehca_av;
#include "ehca_irq.h"
#define EHCA_EQE_CACHE_SIZE 20
+#define EHCA_MAX_NUM_QUEUES 0x
struct ehca_eqe_cache_entry {
struct ehca_eqe *eqe;
@@ -127,6 +128,8 @@ struct ehca_shca {
/* MR pgsize: bit 0-3 means 4K, 64K, 1M, 16M respectively */
u32 hca_cap_mr_pgsize;
int max_mtu;
+ atomic_t num_cqs;
+ atomic_t num_qps;
};
struct ehca_pd {
@@ -344,6 +347,8 @@ extern int ehca_use_hp_mr;
extern int ehca_scaling_code;
extern int ehca_lock_hcalls;
extern int ehca_nr_ports;
+extern int ehca_max_cq;
+extern int ehca_max_qp;
struct ipzu_queue_resp {
u32 qe_size; /* queue entry size */
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c
b/drivers/infiniband/hw/ehca/ehca_cq.c
index ec0cfcf..5b4f9a3 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -132,6 +132,14 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
if (cqe >= 0x - 64 - additional_cqe)
return ERR_PTR(-EINVAL);
+ if (atomic_read(&shca->num_cqs) >= ehca_max_cq) {
+ ehca_err(device, "Unable to create CQ, max number of %i "
+ "CQs reached.", ehca_max_cq);
+ ehca_err(device, "To increase the maximum number of CQs "
+ "use the number_of_cqs module parameter.\n");
+ return ERR_PTR(-ENOSPC);
+ }
+
my_cq = kmem_cache_zalloc(cq_cache, GFP_KERNEL);
if (!my_cq) {
ehca_err(device, "Out of memory for ehca_cq struct device=%p",
@@ -286,6 +294,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
}
}
+ atomic_inc(&shca->num_cqs);
return cq;
create_cq_exit4:
@@ -359,6 +368,7 @@ int ehca_destroy_cq(struct ib_cq *cq)
ipz_queue_dtor(NULL, &my_cq->ipz_queue);
kmem_cache_free(cq_cache, my_cq);
+ atomic_dec(&shca->num_cqs);
return 0;
}
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
index 6504897..401907f 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -68,6 +68,8 @@ int ehca_port_act_time = 30;
int ehca_static_rate = -1;
int ehca_scaling_code = 0;
int ehca_lock_hcalls = -1;
+int ehca_max_cq= -1;
+int ehca_max_qp= -1;
module_param_named(open_aqp1, ehca_open_aqp1, bool, S_IRUGO);
module_param_named(debug_level, ehca_debug_level, int, S_IRUGO);
@@ -79,6 +81,8 @@ module_param_named(poll_all_eqs, ehca_poll_all_eqs, bool,
S_IRUGO);
module_param_named(static_rate, ehca_static_rate, int, S_IRUGO);
module_param_named(scaling_code, ehca_scaling_code, bool, S_IRUGO);
module_param_named(lock_hcalls, ehca_lock_hcalls, bool, S_IRUGO);
+module_param_named(number_of_cqs, ehca_max_cq,int, S_IRUGO);
+module_param_named(number_of_qps, ehca_max_qp,int, S_IRUGO);
MODULE_PARM_DESC(open_aqp1,
"Open AQP1 on startup (default: no)");
@@ -104,6 +108,12 @@ MODULE_PARM_DESC(scaling_code,
MODULE_PARM_DESC(lock_hcalls,
"Serialize all hCalls made by the driver "
"(default: autodetect)");
+MODULE_PARM_DESC(number_of_cqs,
+ "Max number of CQs which can be allocated "
+ "(default: autodetect)");
+MODULE_PARM_DESC(number_of_qps,
+ "Max number of QPs which can be allocated "
+ "(default: autodetect)");
DEFINE_RWLOCK(ehca_qp_idr_lock);
DEFINE_RWLOCK(ehca_cq_idr_lock);
@@ -355,6 +365,25 @@ static int ehca_sense_attributes(struct ehca_shca *shca)
if (rblock->memory_page_size_supported & pgsize_map[i])
shca->hca_cap_mr_pgsize |= pgsize_map[i + 1];
+ /* Set maximum number of CQs and QPs to calculate EQ size */
+ if (ehca_max_qp == -1)
+ ehca_max_qp = min_t(int, rblock->max_qp, EHCA_MAX_NUM_QUEUES);
+ else if (ehca_max_qp < 1 || ehca_max_qp > rblock->max_qp) {
+ ehca_gen_err("Requested number of QPs is out of range (1 - %i) "
+ "specified by HW", rblock->max_qp);
+ ret = -EINVAL;
+ goto sense_attributes1;
+ }
+
+ if (ehca_max_cq == -1)
+ ehca_max_cq = min_t(int, rblock-
Re: [ewg] Re: [ofa-general] [PATCH 0/8] RDS patch set
> 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 split the patch in two (mthca/mlx4) I guess. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
>
> 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
create_cq/create_qp might end up exceeding the ehca_max_cq limit. Is
that an issue?
You could close the race by using atomic_add_unless() and testing the
return value (and being careful to do atomic_dec() on error paths after
you bump num_cqs/num_qps).
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ PATCH 3/3 ] RDMA/nes SFP+ cleanup
> 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 ] !=
> NES_PHY_TYPE_PUMA_1G)) {
This type of change isn't a cleanup... kernel style prefers
array[index]
to
array[ index ]
and it seems most of this patch is making the change to the less-good way?
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: [ PATCH 3/3 ] RDMA/nes SFP+ cleanup
> > 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 ] != NES_PHY_TYPE_PUMA_1G)) {
>
> This type of change isn't a cleanup... kernel style prefers
>
> array[index]
>
> to
>
> array[ index ]
>
> and it seems most of this patch is making the change to the
> less-good way?
>
> - R.
>
My bad, on the array index idiom. I can redo.
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.
I generally "cleaned-up" the entire functions rather than
just the patched portion. If I do both together, then you'll
get clean-up noise interspersed with functional deltas making
functional review somewhat annoying in my opinion.
Will be happy to redo as a single SFP patch
and drop 3rd patch if that works better for you. In fact that
is how I did it originally. :-)
Glenn
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ PATCH 3/3 ] RDMA/nes SFP+ cleanup
> 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" the entire functions rather than > just the patched portion. If I do both together, then you'll > get clean-up noise interspersed with functional deltas making > functional review somewhat annoying in my opinion. OK, got it. The changelog "Clean up the SFP+ patch." was misleading. - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] RE: [ PATCH 3/3 ] RDMA/nes SFP+ cleanup
> > > 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 ] != NES_PHY_TYPE_PUMA_1G)) {
> >
> > This type of change isn't a cleanup... kernel style prefers
> >
> > array[index]
> >
> > to
> >
> > array[ index ]
> >
> > and it seems most of this patch is making the change to the
> > less-good way?
> >
> > - R.
> >
>
> My bad, on the array index idiom. I can redo.
>
> 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.
>
> I generally "cleaned-up" the entire functions rather than
> just the patched portion. If I do both together, then you'll
> get clean-up noise interspersed with functional deltas making
> functional review somewhat annoying in my opinion.
>
Hmm...what I probably should of done was given a clean sfp-patch
and then add peripheral cleanups to the functions as a subsequent
patch. I'll go down that page.
Glenn
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [REPOST][PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
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 and CQs to a customizable max count,
and determining EQ size based on these counts and a worst-case assumption.
Signed-off-by: Stefan Roscher
---
Reposted based on Roland's comments:
- use atomic_add_unless instead of atomic_read
- inf% changelog increase ;)
drivers/infiniband/hw/ehca/ehca_classes.h |5
drivers/infiniband/hw/ehca/ehca_cq.c | 11 +
drivers/infiniband/hw/ehca/ehca_main.c| 36 +++-
drivers/infiniband/hw/ehca/ehca_qp.c | 26 +++-
4 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h
b/drivers/infiniband/hw/ehca/ehca_classes.h
index 3d6d946..00bab60 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -66,6 +66,7 @@ struct ehca_av;
#include "ehca_irq.h"
#define EHCA_EQE_CACHE_SIZE 20
+#define EHCA_MAX_NUM_QUEUES 0x
struct ehca_eqe_cache_entry {
struct ehca_eqe *eqe;
@@ -127,6 +128,8 @@ struct ehca_shca {
/* MR pgsize: bit 0-3 means 4K, 64K, 1M, 16M respectively */
u32 hca_cap_mr_pgsize;
int max_mtu;
+ atomic_t num_cqs;
+ atomic_t num_qps;
};
struct ehca_pd {
@@ -344,6 +347,8 @@ extern int ehca_use_hp_mr;
extern int ehca_scaling_code;
extern int ehca_lock_hcalls;
extern int ehca_nr_ports;
+extern int ehca_max_cq;
+extern int ehca_max_qp;
struct ipzu_queue_resp {
u32 qe_size; /* queue entry size */
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c
b/drivers/infiniband/hw/ehca/ehca_cq.c
index ec0cfcf..5540b27 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -132,10 +132,19 @@ struct ib_cq *ehca_create_cq(struct ib_device *device,
int cqe, int comp_vector,
if (cqe >= 0x - 64 - additional_cqe)
return ERR_PTR(-EINVAL);
+ if (!atomic_add_unless(&shca->num_cqs, 1, ehca_max_cq)) {
+ ehca_err(device, "Unable to create CQ, max number of %i "
+ "CQs reached.", ehca_max_cq);
+ ehca_err(device, "To increase the maximum number of CQs "
+ "use the number_of_cqs module parameter.\n");
+ return ERR_PTR(-ENOSPC);
+ }
+
my_cq = kmem_cache_zalloc(cq_cache, GFP_KERNEL);
if (!my_cq) {
ehca_err(device, "Out of memory for ehca_cq struct device=%p",
device);
+ atomic_dec(&shca->num_cqs);
return ERR_PTR(-ENOMEM);
}
@@ -305,6 +314,7 @@ create_cq_exit2:
create_cq_exit1:
kmem_cache_free(cq_cache, my_cq);
+ atomic_dec(&shca->num_cqs);
return cq;
}
@@ -359,6 +369,7 @@ int ehca_destroy_cq(struct ib_cq *cq)
ipz_queue_dtor(NULL, &my_cq->ipz_queue);
kmem_cache_free(cq_cache, my_cq);
+ atomic_dec(&shca->num_cqs);
return 0;
}
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
index 6504897..482103e 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -68,6 +68,8 @@ int ehca_port_act_time = 30;
int ehca_static_rate = -1;
int ehca_scaling_code = 0;
int ehca_lock_hcalls = -1;
+int ehca_max_cq= -1;
+int ehca_max_qp= -1;
module_param_named(open_aqp1, ehca_open_aqp1, bool, S_IRUGO);
module_param_named(debug_level, ehca_debug_level, int, S_IRUGO);
@@ -79,6 +81,8 @@ module_param_named(poll_all_eqs, ehca_poll_all_eqs, bool,
S_IRUGO);
module_param_named(static_rate, ehca_static_rate, int, S_IRUGO);
module_param_named(scaling_code, ehca_scaling_code, bool, S_IRUGO);
module_param_named(lock_hcalls, ehca_lock_hcalls, bool, S_IRUGO);
+module_param_named(number_of_cqs, ehca_max_cq,int, S_IRUGO);
+module_param_named(number_of_qps, ehca_max_qp,int, S_IRUGO);
MODULE_PARM_DESC(open_aqp1,
"Open AQP1 on startup (default: no)");
@@ -104,6 +108,12 @@ MODULE_PARM_DESC(scaling_code,
MODULE_PARM_DESC(lock_hcalls,
"Serialize all hCalls made by the driver "
"(default: autodetect)");
+MODULE_PARM_DESC(number_of_cqs,
+ "Max number of CQs which can be allocated "
+ "(default: autodetect)");
+MODULE_PARM_DESC(number_of_qps,
+ "Max number of QPs which can be allocated "
+ "(default: autodetect)");
DEFINE_RWLOCK(ehca_qp_idr_lock);
DEFINE_RWLOCK(ehca_cq_idr_lock);
@@ -355,6 +365,25 @@ static int ehca_sense_attributes(struct ehca_shca *shca)
if (rblock->memory_page_size_supported & pgsize
[ewg] Re: [PATCH] IB/ipoib: set child MTU as the parent's
> 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_UD_MTU(priv->max_ib_mtu); > +priv->mcast_mtu = priv->admin_mtu = priv->dev->mtu; Do child devices also need to copy over the checksum offload/LSO stuff from the parent? - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [REPOST][PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
thanks, makes sense, applied. fast turnaround too ;) ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] IB/ipoib: set child MTU as the parent's
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 since even when multicast join completes, the device's MTU will not be updated since the following statment dev->mtu = min(priv->mcast_mtu, priv->admin_mtu); at ipoib_mcast_join_task() yields zero since admin mtu is zero. > > Do child devices also need to copy over the checksum offload/LSO stuff > from the parent? > 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? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] IB/ipoib: set child MTU as the parent's
> 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 could do that or just copy only the flags that should be copied when creating a child device. - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] IB/ipoib: set child MTU as the parent's
> > 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.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] IB/ipoib: set child MTU as the parent's
anyway, I applied this at least. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [ PATCH 2/3 v2 ] RDMA/nes SFP+ enablement
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]>
---
Roland, here is the cleaned up sfp patch.
drivers/infiniband/hw/nes/nes.h |4 -
drivers/infiniband/hw/nes/nes_hw.c| 221 +
drivers/infiniband/hw/nes/nes_hw.h|6 +
drivers/infiniband/hw/nes/nes_nic.c | 72 +++
drivers/infiniband/hw/nes/nes_utils.c | 10 -
5 files changed, 249 insertions(+), 64 deletions(-)
diff --git a/drivers/infiniband/hw/nes/nes.h b/drivers/infiniband/hw/nes/nes.h
index 484b5e3..1f9f7bf 100644
--- a/drivers/infiniband/hw/nes/nes.h
+++ b/drivers/infiniband/hw/nes/nes.h
@@ -536,8 +536,8 @@ int nes_register_ofa_device(struct nes_i
int nes_read_eeprom_values(struct nes_device *, struct nes_adapter *);
void nes_write_1G_phy_reg(struct nes_device *, u8, u8, u16);
void nes_read_1G_phy_reg(struct nes_device *, u8, u8, u16 *);
-void nes_write_10G_phy_reg(struct nes_device *, u16, u8, u16);
-void nes_read_10G_phy_reg(struct nes_device *, u16, u8);
+void nes_write_10G_phy_reg(struct nes_device *, u16, u8, u16, u16);
+void nes_read_10G_phy_reg(struct nes_device *, u8, u8, u16);
struct nes_cqp_request *nes_get_cqp_request(struct nes_device *);
void nes_post_cqp_request(struct nes_device *, struct nes_cqp_request *, int);
int nes_arp_table(struct nes_device *, u32, u8 *, u32);
diff --git a/drivers/infiniband/hw/nes/nes_hw.c
b/drivers/infiniband/hw/nes/nes_hw.c
index 197eee9..0887ed5 100644
--- a/drivers/infiniband/hw/nes/nes_hw.c
+++ b/drivers/infiniband/hw/nes/nes_hw.c
@@ -1208,11 +1208,16 @@ int nes_init_phy(struct nes_device *nesd
{
struct nes_adapter *nesadapter = nesdev->nesadapter;
u32 counter = 0;
+ u32 sds_common_control0;
u32 mac_index = nesdev->mac_index;
- u32 tx_config;
+ u32 tx_config = 0;
u16 phy_data;
+ u32 temp_phy_data = 0;
+ u32 temp_phy_data2 = 0;
+ u32 i = 0;
- if (nesadapter->OneG_Mode) {
+ if ((nesadapter->OneG_Mode) &&
+ (nesadapter->phy_type[mac_index] != NES_PHY_TYPE_PUMA_1G)) {
nes_debug(NES_DBG_PHY, "1G PHY, mac_index = %d.\n", mac_index);
if (nesadapter->phy_type[mac_index] == NES_PHY_TYPE_1G) {
printk(PFX "%s: Programming mdc config for 1G\n",
__func__);
@@ -1278,12 +1283,116 @@ int nes_init_phy(struct nes_device *nesd
nes_read_1G_phy_reg(nesdev, 0,
nesadapter->phy_index[mac_index], &phy_data);
nes_write_1G_phy_reg(nesdev, 0,
nesadapter->phy_index[mac_index], phy_data | 0x0300);
} else {
- if (nesadapter->phy_type[mac_index] == NES_PHY_TYPE_IRIS) {
+ if ((nesadapter->phy_type[mac_index] == NES_PHY_TYPE_IRIS) ||
+ (nesadapter->phy_type[mac_index] == NES_PHY_TYPE_ARGUS)) {
/* setup 10G MDIO operation */
tx_config = nes_read_indexed(nesdev,
NES_IDX_MAC_TX_CONFIG);
tx_config |= 0x14;
nes_write_indexed(nesdev, NES_IDX_MAC_TX_CONFIG,
tx_config);
}
+ if ((nesadapter->phy_type[mac_index] == NES_PHY_TYPE_ARGUS)) {
+ nes_read_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x3, 0xd7ee);
+
+ temp_phy_data = (u16)nes_read_indexed(nesdev,
NES_IDX_MAC_MDIO_CONTROL);
+ mdelay(10);
+ nes_read_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x3, 0xd7ee);
+ temp_phy_data2 = (u16)nes_read_indexed(nesdev,
NES_IDX_MAC_MDIO_CONTROL);
+
+ /* if firmware is already running (like from a driver
un-load/load, don't do anything. */
+ if (temp_phy_data == temp_phy_data2) {
+ /* configure QT2505 AMCC PHY */
+ nes_write_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x1, 0x, 0x8000);
+ nes_write_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x1, 0xc300, 0x);
+ nes_write_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x1, 0xc302, 0x0044);
+ nes_write_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x1, 0xc318, 0x0052);
+ nes_write_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x1, 0xc319, 0x0008);
+ nes_write_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x1, 0xc31a, 0x0098);
+ nes_write_10G_phy_reg(nesdev,
nesadapter->phy_index[mac_index], 0x3, 0x0026, 0x0E00);
+ nes_write_10G_phy
[ewg] [ PATCH 3/3 v2 ] RDMA/nes Formatting cleanup
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 the replacement patch for "RDMA/nes SFP+ cleanup". I've fixed the whitespace issue with the array indices and swept through a bit more code. Feelings will not be hurt if I still don't have it right...can always punt on this patch if necessary. Glenn drivers/infiniband/hw/nes/nes_cm.c|8 +-- drivers/infiniband/hw/nes/nes_hw.c| 103 + drivers/infiniband/hw/nes/nes_hw.h|2 - drivers/infiniband/hw/nes/nes_nic.c | 96 --- drivers/infiniband/hw/nes/nes_verbs.c |2 - 5 files changed, 109 insertions(+), 102 deletions(-) diff --git a/drivers/infiniband/hw/nes/nes_cm.c b/drivers/infiniband/hw/nes/nes_cm.c index d940fc2..9a4b40f 100644 --- a/drivers/infiniband/hw/nes/nes_cm.c +++ b/drivers/infiniband/hw/nes/nes_cm.c @@ -594,7 +594,7 @@ static void nes_cm_timer_tick(unsigned l continue; } /* this seems like the correct place, but leave send entry unprotected */ - // spin_unlock_irqrestore(&cm_node->retrans_list_lock, flags); + /* spin_unlock_irqrestore(&cm_node->retrans_list_lock, flags); */ atomic_inc(&send_entry->skb->users); cm_packets_retrans++; nes_debug(NES_DBG_CM, "Retransmitting send_entry %p for node %p," @@ -1335,7 +1335,7 @@ static int process_packet(struct nes_cm_ cm_node->loc_addr, cm_node->loc_port, cm_node->rem_addr, cm_node->rem_port, cm_node->state, atomic_read(&cm_node->ref_count)); - // create event + /* create event */ cm_node->state = NES_CM_STATE_CLOSED; create_event(cm_node, NES_CM_EVENT_ABORTED); @@ -1669,7 +1669,7 @@ static struct nes_cm_node *mini_cm_conne if (!cm_node) return NULL; - // set our node side to client (active) side + /* set our node side to client (active) side */ cm_node->tcp_cntxt.client = 1; cm_node->tcp_cntxt.rcv_wscale = NES_CM_DEFAULT_RCV_WND_SCALE; @@ -1694,7 +1694,7 @@ static struct nes_cm_node *mini_cm_conne loopbackremotenode->mpa_frame_size = mpa_frame_size - sizeof(struct ietf_mpa_frame); - // we are done handling this state, set node to a TSA state + /* we are done handling this state, set node to a TSA state */ cm_node->state = NES_CM_STATE_TSA; cm_node->tcp_cntxt.rcv_nxt = loopbackremotenode->tcp_cntxt.loc_seq_num; loopbackremotenode->tcp_cntxt.rcv_nxt = cm_node->tcp_cntxt.loc_seq_num; diff --git a/drivers/infiniband/hw/nes/nes_hw.c b/drivers/infiniband/hw/nes/nes_hw.c index 0887ed5..1c02639 100644 --- a/drivers/infiniband/hw/nes/nes_hw.c +++ b/drivers/infiniband/hw/nes/nes_hw.c @@ -833,7 +833,7 @@ static void nes_init_csr_ne020(struct ne nes_write_indexed(nesdev, 0x0900, 0x2001); nes_write_indexed(nesdev, 0x60C0, 0x028e); nes_write_indexed(nesdev, 0x60C8, 0x0020); - // + nes_write_indexed(nesdev, 0x01EC, 0x7b2625a0); /* nes_write_indexed(nesdev, 0x01EC, 0x5f2625a0); */ @@ -1229,7 +1229,7 @@ int nes_init_phy(struct nes_device *nesd nes_read_1G_phy_reg(nesdev, 1, nesadapter->phy_index[mac_index], &phy_data); nes_debug(NES_DBG_PHY, "Phy data from register 1 phy address %u = 0x%X.\n", nesadapter->phy_index[mac_index], phy_data); - nes_write_1G_phy_reg(nesdev, 23, nesadapter->phy_index[mac_index], 0xb000); + nes_write_1G_phy_reg(nesdev, 23, nesadapter->phy_index[mac_index], 0xb000); /* Reset the PHY */ nes_write_1G_phy_reg(nesdev, 0, nesadapter->phy_index[mac_index], 0x8000); @@ -1363,7 +1363,7 @@ int nes_init_phy(struct nes_device *nesd * ensures it is stable after the amcc phy is stable */ - sds_common_control0 = nes_read_indexed(nesdev, NES_IDX_ETH_SERDES_COMMON_CONTROL0); + sds_common_control0 = nes_read_indexed
[ewg] Re: [ PATCH 3/3 v2 ] RDMA/nes Formatting cleanup
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
