Re: [openib-general] [PATCH 1/2][RFC] Implement resize of CQ

2004-11-05 Thread Hal Rosenstock
On Thu, 2004-11-04 at 12:44, Krishna Kumar wrote: On Thu, 4 Nov 2004, Roland Dreier wrote: Not sure what the goal is here, but I should point out that current mthca code does not implement resizing either CQs or QPs. Yes, I agree on that. Infact the verbs layer will return ENOSYS for

Re: [openib-general] [PATCH 1/2][RFC] Implement resize of CQ

2004-11-05 Thread Roland Dreier
Hal Is this a driver or firmware issue ? Driver issue. I just haven't implemented CQ resize yet, and it's not a high priority for me. Hal Might this be useful for redirected QPs ? I don't think so, since the redirected QP will not be attached to the MAD layer's CQ. Hal Should the

Re: [openib-general] [PATCH 1/2][RFC] Implement resize of CQ

2004-11-05 Thread Sean Hefty
Hal Rosenstock wrote: However I'm not sure I understand why the MAD layer wants to resize these objects -- given that the number of QPs is known in advance and that the MAD layer can choose how many work requests to post per QP, I'm not sure what is gained by trying to resize things dynamically.

Re: [openib-general] [PATCH 1/2][RFC] Implement resize of CQ

2004-11-05 Thread Roland Dreier
Hal Does the driver do this (QP is sized larger than what was Hal requested) now ? Or is this a spec thing ? Unless my memory is playing tricks on me, I don't think mthca will create a QP larger than requested. - R. ___ openib-general mailing

RE: [openib-general] [PATCH 1/2][RFC] Implement resize of CQ

2004-11-05 Thread Fab Tillier
From: Sean Hefty [mailto:[EMAIL PROTECTED] Sent: Friday, November 05, 2004 11:21 AM Hal Rosenstock wrote: However I'm not sure I understand why the MAD layer wants to resize these objects -- given that the number of QPs is known in advance and that the MAD layer can choose how many work

Re: [openib-general] [PATCH 1/2][RFC] Implement resize of CQ

2004-11-05 Thread Krishna Kumar
Hi Hal, I think others have answered it, but my 2 cents : 1. Current driver doesn't do this, it is a spec thing, a potential driver could do this in future. It is useful in the sense that the CQ is always atleast the size of the QP's that are using it in case the driver implements it,

Re: [openib-general] [PATCH 1/2] [RFC] Implement resize of CQ

2004-11-04 Thread Roland Dreier
Michael If the max. number of QPs is very big, you may want the Michael actual CQ size to grow gradually with demand. sure but there are only 2 soecial qps per port. ___ openib-general mailing list [EMAIL PROTECTED]

Re: [openib-general] [PATCH 1/2] [RFC] Implement resize of CQ

2004-11-03 Thread Sean Hefty
Krishna Kumar wrote: qp_info-qp = ib_create_qp(port_priv-pd, qp_init_attr); - if (IS_ERR(qp_info-qp)) { - printk(KERN_ERR PFX Couldn't create ib_mad QP%d\n, - get_spl_qp_index(qp_type)); + if (!IS_ERR(qp_info-qp)) { + struct

Re: [openib-general] [PATCH 1/2] [RFC] Implement resize of CQ

2004-11-03 Thread Roland Dreier
Not sure what the goal is here, but I should point out that current mthca code does not implement resizing either CQs or QPs. However I'm not sure I understand why the MAD layer wants to resize these objects -- given that the number of QPs is known in advance and that the MAD layer can choose how