Remove unused variable from ipoib_mutlicast.c
Index: ipoib_multicast.c
===
--- ipoib_multicast.c (revision 1167)
+++ ipoib_multicast.c (working copy)
@@ -259,7 +259,6 @@
{
struct ipoib_mcast *mcast = mcast_ptr;
st
On Sat, 2004-11-06 at 00:39, Roland Dreier wrote:
> It seems that there are lots of places where consumers need to
> allocate an entire ib_device_attr struct and deal with the possibility
> that ib_query_device() might fail, just to find out how many ports a
> device has.
Yes, I noticed this whe
It seems that there are lots of places where consumers need to
allocate an entire ib_device_attr struct and deal with the possibility
that ib_query_device() might fail, just to find out how many ports a
device has. We discussed this before and concluded that it was OK to
assume that the number of
Sean> Okay. I was just going by the coding style documentation
Sean> that mentioned that this was a "hard limit". If it's not
Sean> that big of a deal, then I'll only worry about excessively
Sean> long lines.
Yeah, if you read through the kernel source, you can find tons and
tons
Roland Dreier wrote:
Sean> Hal, can you check that your code stays within 80 characters
Sean> per line?
The 80 character limit is really just a guideline. It's not worth
going through contortions to fix an 85-character line.
Okay. I was just going by the coding style documentation that me
Sean> Hal, can you check that your code stays within 80 characters
Sean> per line?
The 80 character limit is really just a guideline. It's not worth
going through contortions to fix an 85-character line.
- Roland
___
openib-general mailing lis
Thanks but I'm not going to apply this. I prefer to have the locking
and the idr lookup be explicit (and it's only done in two places so
the cleanup is pretty minimal).
Thanks,
Roland
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org
Sorry, this and the follow-up patch are wrong. The if the send
succeeds then we can't free the query structure until the query
finishes up. (The query will be freed in the appropriate ->release
method in this case).
You are right that there is a memory leak though. I fixed it like
this:
Index:
Thanks for the audit. I applied this version of your patch. Does
this still look correct?
Index: infiniband/core/sa_query.c
===
--- infiniband/core/sa_query.c (revision 1164)
+++ infiniband/core/sa_query.c (working copy)
@@ -699,2
Hal Rosenstock wrote:
mad: Handle outgoing SMPs in ib_post_send_mad
The MAD layer is now ready to support the SM :-)
I have not yet handled the additional special cases: hop count increment
done by device, use send queue rather than process MAD for 0 hop SMPs).
Hal, can you check that your code sta
diff -ruNp trunk/src/linux-kernel/infiniband/core/sa_query.c.org
trunk/src/linux-kernel/infiniband/core/sa_query.c
--- trunk/src/linux-kernel/infiniband/core/sa_query.c.org 2004-11-05
13:43:10.0 -0800
+++ trunk/src/linux-kernel/infiniband/core/sa_query.c 2004-11-05 13:58:47.00
Applies on top of my previous patch...
diff -ruNp trunk/src/linux-kernel/infiniband/core/sa_query.c.org
trunk/src/linux-kernel/infiniband/core/sa_query.c
--- trunk/src/linux-kernel/infiniband/core/sa_query.c.org 2004-11-05
13:13:12.0 -0800
+++ trunk/src/linux-kernel/infiniband/core
1. Don't kfree sa_dev twice.
2. Unnecessary kref_put : In failure case, we don't seem to have a
reference until update_sm_ah is called in success case.
3. Clean up code which looks like a hack (i++ in failure).
4. Too many "i -s", no need to keep recalculating this :-)
5. Potential extra clean
I guess my bottom line is that these patches add complexity and can't
be tested at the moment, so my inclination would be to leave them out.
- R.
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To uns
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, as
Fab Tillier wrote:
If the MAD layer did provide queuing to prevent overflow for the requested
(not allocated) depth, then the CQ resize is unnecessary. I would expect
that whatever code manages the QP/CQ should provide queuing so that MAD
agents don't all have to implement queueing with respect to
On Fri, 2004-11-05 at 14:21, Roland Dreier wrote:
> Hal> 1. Are there changes planned for core/cache.c ?
>
> I've cleaned it up a little but I'm really not sure exactly what
> should be done with it.
One more thing would be to rename ts_ib_core.h to something like
ib_cache.h.
-- Hal
_
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 05, 2004 11:20 AM
>
> 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.
>
As far as I know, Tavor does not support QP resize.
> 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 h
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
On Fri, 2004-11-05 at 14:21, Sean Hefty wrote:
> I think we should go ahead an put this code in. We need to handle the
> case where the QP is sized larger than what we request anyway, to ensure
> that we don't overrun the CQ.
Does the driver do this (QP is sized larger than what was requested)
On Fri, 2004-11-05 at 14:57, Krishna Kumar wrote:
> (do you guys need patches to be rooted from a particular directory
> to be more efficient/convenient ?)
We should be patching against gen2/trunk now.
-- Hal
___
openib-general mailing list
[EMAIL PROT
Current code frees up memory in error case and dereferences it
later, plus the success case doesn't (seem to) free it up.
(do you guys need patches to be rooted from a particular directory
to be more efficient/convenient ?)
- KK
diff -ruNp 7/sa_query.c 8/sa_query.c
--- 7/sa_query.c2004-1
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.
Ac
Hal> 1. Are there changes planned for core/cache.c ?
I've cleaned it up a little but I'm really not sure exactly what
should be done with it.
Hal> 2. Shouldn't src/userspace/tools/libsdp be removed for now ?
Yeah, I'll do that.
-R.
___
open
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 th
On Thu, 2004-11-04 at 12:46, Roland Dreier wrote:
> I have just copied the roland-merge branch to
>
> https://openib.org/svn/gen2/trunk
>
> This tree will become the main development tree and will be used to
> create the tree we will submit to the kernel for inclusion. Please
> use this tree
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
mad: Handle outgoing SMPs in ib_post_send_mad
The MAD layer is now ready to support the SM :-)
I have not yet handled the additional special cases: hop count increment
done by device, use send queue rather than process MAD for 0 hop SMPs).
Index: mad_priv.h
===
mad: Restructure smi as shared between mad and agent
(adds new files smi.h, smi.c, and agent.h)
Index: agent.c
===
--- agent.c (revision 1161)
+++ agent.c (working copy)
@@ -24,6 +24,7 @@
*/
#include
+#include "smi.h"
#i
30 matches
Mail list logo
