Re: [openib-general] SDP - What are the platforms that support SDP ?

[Tom Duffy]

On Jan 5, 2006, at 11:59 AM, Richard Frank wrote:


Besides OpenIB for Linux and Windows ?

Solaris ?


Sun had a fully working SDP for Solaris that got cut from Solaris 10  
right at the last moment.  I am not sure what the current status is,  
but I know there were folks that were trying to resurrect it for  
Solaris 11 if not a 10 update.


Perhaps the code could be put out as part of OpenSolaris?

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Fwd: SDP

[Tom Duffy]

Nitin,

I found this email stuck in the back of my inbox.  I am sorry I  
haven't been able to get back to you.  Perhaps somebody on the list  
can better answer your questions.


Begin forwarded message:


From: Nitin Hande <[EMAIL PROTECTED]>
Date: November 2, 2005 4:11:01 PM PST
To: Tom Duffy <[EMAIL PROTECTED]>
Subject: Re: SDP
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050512)

Hi Tom


Tom Duffy wrote:

On Oct 4, 2005, at 4:38 PM, Nitin Hande wrote:

Tom

I have a question. The current SDP implementation on OpenIB I   
believe now creates a socket of AF_INET_SDP type ?.
While you have choosen AF_INET_SDP, what does this family imply.?  
How is it connected to AF_INET family ? (I can tell my reasoning:  
While doing ARP, AF_INET_SDP relies on IPoIB to find the peer MAC  
address. While IPoIB is a AF_INET family, there is some co-relation  
between AF_INET_SDP and AF_INET family. MAC address resolved  
through AF_INET is accepted in AF_INET_SDP. This will not be  
acceptable, say for AF_IPX family, if there was any reason to do it  
like that). What I am trying to find out is what is that relation ?


My second question, is rather than defining AF_INET_SDP, have you  
thought if we can open a SDP connection with
socket(AF_INET, SOCK_STREAM, IPPROTO_SDP) which perhaps suits more  
than AF_INET_SDP ? (It is only the transport protocol that is  
different, but the address actually belong to AF_INET family).


Your comments ?

Nitin



___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH applied] return -ENOPROTOOPT on an unsupported socket option

[Tom Duffy]

On Dec 19, 2005, at 3:05 PM, Michael S. Tsirkin wrote:

Hmm. Which option do you have in mind, specifically?


LINGER comes to mind.  But something like SYNCNT, WINDOW_CLAMP, or  
QUICKACK doesn't make much sense on SDP, so why not just say we  
support it?



The right thing, in my eyes, is to emulate a TCP socket.
So we dont want to support options that TCP doesnt support.


TCP supports many more options.  Perhaps we should special case those.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH applied] return -ENOPROTOOPT on an unsupported socket option

[Tom Duffy]

On Dec 19, 2005, at 6:44 AM, Michael S. Tsirkin wrote:



Make more ltp tests pass: return -ENOPROTOOPT on an unsupported  
socket option.


This one is a bit controversial.  We had the discussion in the past  
about doing this, but the problem is that some applications won't run  
if a particular sockopt is not supported on SDP.  Some socket opts  
don't make much sense on SDP/Infiniband, others work as intended.


-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: SDP problems with 64K page size

[Tom Duffy]

On Sep 25, 2005, at 3:45 AM, Michael S. Tsirkin wrote:


Roland, I might check in the patch that you posted to work around
this problem for 64K page users, until I have a final fix ready.
Is that OK with everyone?



It looks harmless in the 4K or 16K case.  Go for it.

-tduffy

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: sdp: kill sdp buff pool

[Tom Duffy]

On Sep 11, 2005, at 12:22 AM, Michael S. Tsirkin wrote:

It turns out I didnt post that patch yet.
It might not apply cleanly now since I didnt yet update it after
recent changes. Do you want to see it?


Doesn't really matter at this point.  What was left in it that hasn't  
changed?


-tduffy

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: sdp: kill sdp buff pool

[Tom Duffy]

On Sep 8, 2005, at 9:18 AM, Michael S. Tsirkin wrote:

Up to 720 from around 700 MB/sec with 128KB buffers.


Nice, not shabby at all.


Another re-implementation of kmem_cache, I guess :)
Do you prefer replacing them all with sdp_buff_pool_put?


Yeah, I think so.  Simpler...


Yep, simple replacing of sdp lists with list_head (mega patch that  
I posted

previously) hurts performance by some 10%, and I didnt yet figure why.


Which patch was that?  Did that include the sdp_buff.[ch] changes I  
posted?  I don't remember that going across the list and a quick  
search didn't illuminate anything.


-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: sdp: kill sdp buff pool

[Tom Duffy]

On Sep 8, 2005, at 4:41 AM, Michael S. Tsirkin wrote:



SDP seems to have a re-implementation of kmem_cache in sdp_buff.
Killing it actually results in a small bandwidth increase
for both bcopy and zcopy versions, so I plan to put this in.



Can you please post some numbers?



Note that sdp_buff_pool_chain_link is now same as sdp_buff_pool_put,
and sdp_buff_pool_chain_put is now a nop, but I decided to
keep it in for now, just in case there's another use for it.



like what?


 sdp_buff.c  |  388 + 
+--

 sdp_dev.h   |7 -
 sdp_inet.c  |   17 --
 sdp_proc.c  |6
 sdp_proc.h  |   11 -
 sdp_proto.h |   10 -
 6 files changed, 50 insertions(+), 389 deletions(-)



I love patches like this.  Much better than what I had done ;)

-tduffy

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH] [CM] 3/6 SDP updates to bind cm_id's to a device

[Tom Duffy]

On Sep 7, 2005, at 10:13 AM, Sean Hefty wrote:
I use madeye to dump CM MAD traffic.  I can use that to verify that  
cm_id states are correct based on which messages have been  
received.  I did try to make these states internal to the CM a few  
months ago, but did not want to remove them from the API until all  
clients no longer access them.  I believe that once SDP is fixed,  
these can be moved into the internal structure to avoid this issue  
in the future.


I remember this discussion.  And thanks for taking the time to update  
SDP.  Sounds like a good plan going forward.


-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] SDP Revision

[Tom Duffy]

On 9/5/05, Majumder, Rajib <[EMAIL PROTECTED]> wrote:
> hi,
> 
> What's the latest stable revision of SDP? What rev of gen2 stack is 
> recommended at a minimum for RHEL AS 3.0?

Just go for the latest version of SDP.  There haven't been any major
patches recently, so it should be in good shape.  You should use a
2.6.13 kernel with that.  Or use one of the back port patches (which
are less widely tested, I think).  I would recommend updating to RHEL
4.0 as this is 2.6-based and should work better with openib.  Other
distro option would be Fedora Core 4 which is even closer to working
with the latest kernel.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] SDP message loss

[Tom Duffy]

On 9/4/05, Majumder, Rajib <[EMAIL PROTECTED]> wrote:
> hi,
> 
> We are doing some proof of concept over SDP. During that we noticed that not 
> all messages are received by the data sink.
> Can there by a message loss in SDP? If yes, what could be the possible 
> reasons?

No, there shouldn't be a loss.  SDP uses the reliable connected mode
of Infiniband.  It is possible that there is bug in the software, but
the hardware should be delivering all of the bits.

> In this case, is there any diagnostic tool, eg. a packet filter, that can 
> give us some idea?

Have you tried some of the simpler test ulps?  Or DAPL which also uses
RC?  That would help narrow it down to SDP.

> We are using RHAS 3.0.

Hrm, that is old and 2.4-based.  Not that it should really matter as I
am assuming you are compilng your own kernel...and got all the 2.6
userland stuff on there.  But, in any event, that shouldn't have any
impact on this problem.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] SDP: Use linux/list.h in sdp_buff.[ch]

[Tom Duffy]

On Tue, 2005-08-30 at 09:10 +0300, Michael S. Tsirkin wrote: 
> Quoting r. Tom Duffy <[EMAIL PROTECTED]>:
> > I just got back from vacation and I am still waiting for a machine so  
> > I can setup a rudimentary IB network at home to test my code.  I have  
> > a patch that converts sdp_buff.[ch] to use linux/list.h (glad you  
> > didn't decide to work on that), but I want to test it before  
> > submitting to the list (it compiles!).
> 
> I actually need that ASAP so that I can finally use
> list_for_each and such instead of the stupid wrappers in
> sdp_buff for my zcopy code.
> Tom, could you please post the patch?

Note: This patch is *UNTESTED*.  Please verify before committing.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: drivers/infiniband/ulp/sdp/sdp_buff.c
===
--- drivers/infiniband/ulp/sdp/sdp_buff.c   (revision 3240)
+++ drivers/infiniband/ulp/sdp/sdp_buff.c   (working copy)
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2005 Topspin Communications.  All rights reserved.
  * Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
+ * Copyright (c) 2005 Tom Duffy ([EMAIL PROTECTED])
  *
  * This software is available to you under a choice of one of two
  * licenses.  You may choose to be licensed under the terms of the GNU
@@ -52,31 +53,18 @@ static inline struct sdpc_buff *do_buff_
 {
struct sdpc_buff *buff;
 
-   if (!pool->head)
+   if (list_empty(&pool->head))
return NULL;
 
if (fifo)
-   buff = pool->head;
+   buff = list_entry(pool->head.next, struct sdpc_buff, list);
else
-   buff = pool->head->prev;
+   buff = list_entry(pool->head.prev, struct sdpc_buff, list);
 
if (!test_func || !test_func(buff, usr_arg)) {
-   if (buff->next == buff && buff->prev == buff)
-   pool->head = NULL;
-   else {
-   buff->next->prev = buff->prev;
-   buff->prev->next = buff->next;
-
-   pool->head = buff->next;
-   }
-
+   list_del(&buff->list);
pool->size--;
-
-   buff->next = NULL;
-   buff->prev = NULL;
-   buff->pool = NULL;
-   }
-   else
+   } else
buff = NULL;
 
return buff;
@@ -91,20 +79,10 @@ static inline void do_buff_q_put(struct 
/* fifo: false == tail, true == head */
BUG_ON(buff->pool);
 
-   if (!pool->head) {
-   buff->next = buff;
-   buff->prev = buff;
-   pool->head = buff;
-   } else {
-   buff->next = pool->head;
-   buff->prev = pool->head->prev;
-
-   buff->next->prev = buff;
-   buff->prev->next = buff;
-
-   if (fifo)
-   pool->head = buff;
-   }
+   if (fifo)
+   list_add(&buff->list, &pool->head);
+   else
+   list_add_tail(&buff->list, &pool->head);
 
pool->size++;
buff->pool = pool;
@@ -116,10 +94,12 @@ static inline void do_buff_q_put(struct 
 static inline struct sdpc_buff *sdp_buff_q_look(struct sdpc_buff_q *pool,
int fifo)
 {
-   if (!pool->head || fifo)
-   return pool->head;
+   if (list_empty(&pool->head))
+   return NULL;
+   if (fifo)
+   return list_entry(pool->head.next, struct sdpc_buff, list);
else
-   return pool->head->prev;
+   return list_entry(pool->head.prev, struct sdpc_buff, list);
 }
 
 /*
@@ -128,28 +108,11 @@ static inline struct sdpc_buff *sdp_buff
 static inline void do_buff_q_remove(struct sdpc_buff_q *pool,
struct sdpc_buff *buff)
 {
-   struct sdpc_buff *prev;
-   struct sdpc_buff *next;
-
BUG_ON(pool != buff->pool);
 
-   if (buff->next == buff && buff->prev == buff)
-   pool->head = NULL;
-   else {
-   next = buff->next;
-   prev = buff->prev;
-   next->prev = prev;
-   prev->next = next;
-
-   if (pool->head == buff)
-   pool->head = next;
-   }
-
+   list_del(&buff->list);
pool->size--;
-
buff->pool = NULL;
-   buff->next = NULL;
-   buff->prev = NULL;
 }
 
 /*
@@ -157,7 +120,7 @@ static inline void do_buff_q_remove(stru
  */
 void sdp_buff_q_init(struct sdpc_buff_q *pool)
 {
-   pool->head = NULL;
+   INIT_LIST_HEAD(&pool->hea

Re: [openib-general] SDP and Socket Options

[Tom Duffy]

On Aug 29, 2005, at 11:34 PM, Majumder, Rajib wrote:

2) what socket options are not supported?


Most of them, actually.  The relevant piece of code should be  
illuminating:


From sdp_inet.c:1461

switch (optname) {
case TCP_NODELAY:
conn->nodelay = value ? 1 : 0;

if (conn->nodelay > 0)
(void)sdp_send_flush(conn);

break;

< snip SDP specific options >

default:
sdp_warn("SETSOCKOPT unimplemented option <%d:%d>  
conn <%d>.",

 level, optname, conn->hashent);
break;
}

I think we should fail these all other options and not just print a  
warning and return.  Until we can characterize all of them.


So, set result to -ENOPROTOOPT instead of just breaking.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] sdp: use linux/list.h in sdp_link.c

[Tom Duffy]

On Aug 29, 2005, at 8:00 AM, Michael S. Tsirkin wrote:


The following kills sdp_link.h and converts sdp_link.c to use linux/ 
list.h

Locking is still missing here.



Cool, cool.  I was going go get to this eventually.

I just got back from vacation and I am still waiting for a machine so  
I can setup a rudimentary IB network at home to test my code.  I have  
a patch that converts sdp_buff.[ch] to use linux/list.h (glad you  
didn't decide to work on that), but I want to test it before  
submitting to the list (it compiles!).


-tduffy

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] sdp: split sdp_inet_send to subroutines

[Tom Duffy]

On Aug 22, 2005, at 7:17 AM, Michael S. Tsirkin wrote:


The following is not yet applied. Opinions on othis?


Is there a reason to do this?  Other than just to have smaller  
functions.  Not that it is a bad thing, just wanted to know if you  
plan on reusing the smaller subroutines elsewhere.


-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] sdp: fix oops in sdp_link.c

[Tom Duffy]

On Aug 22, 2005, at 8:47 AM, Michael S. Tsirkin wrote:



Hi!
I was getting the following oopsen in sdp_link.c
I plan to commit the fix (below) tomorrow, after some more testing.
Comments?



Yeah, looks good.  This is why people hate goto's.

-tduffy

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] SDP: fix oops with port reuse

[Tom Duffy]

On Aug 16, 2005, at 10:12 AM, Michael S. Tsirkin wrote:

Its a mystery then. IMO, even if we agree on using list_del_init
(as discussed below) we should add a BUG_ON(!conn->src_port) as
a sanity check.


Yeah, let's do that.


Doesnt INIT_LIST_HEAD do this?

list_del_init seems to be an exact match for our case: its
a function that is safe to call twice on the same entry,
and it lets you check that entry is on some list by !list_empty.

Example: kernel/posix-timers.c


Sounds good.  Are you going to code up a patch?

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] SDP: fix oops with port reuse

[Tom Duffy]

On Aug 16, 2005, at 8:30 AM, Michael S. Tsirkin wrote:

Why not? You cant really bind to port 0, can you?


I don't think so.  It was Libor who objected to this, so he must have  
had a reason.




Maybe its a good idea to init bind_next at socket creation, at  
port_put

we could call list_del_init, and/or use list_empty to figure out
whether the socket is on the bind list.


Do you mean we would setup the bind_next field to point to itself?



Yes.


Other option is to initialize and check for LIST_POISON[12].




This is normally reserved for list heads.



What's list_del_init for then?


Resetting a list?

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: sdp_msgs.h

[Tom Duffy]

On Aug 16, 2005, at 8:44 AM, Michael S. Tsirkin wrote:


Tom, do you think we should change struct names in
sdp_msgs.h to start with sdp_?


Are you worried about name collisions?  I don't really care one way  
or the other.  Go ahead if you want.


-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [PATCH] SDP: fix oops with port reuse

[Tom Duffy]

On Aug 16, 2005, at 2:19 AM, Michael S. Tsirkin wrote:This is what I committed. I'm not against making sdp_inet_port_put void,looking at libsdp this shouldnt introduce any problems, but lets make ita separate patch.I agree that changing it to void should be done separately.  But, I thought that we didn't want to remove the port unless it was really on the list and that just checking if the src_port was set wouldn't guarantee this.Maybe its a good idea to init bind_next at socket creation, at port_putwe could call list_del_init, and/or use list_empty to figure outwhether the socket is on the bind list.Do you mean we would setup the bind_next field to point to itself?  This is normally reserved for list heads.-tduffy___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH] sockaddr_ll change for IPoIB interface

[Tom Duffy]

On Aug 12, 2005, at 9:07 AM, Roland Dreier wrote:


Tom> But, Fedora will rebuild their binary once this change is in.
Tom> If the Linux developers cared about this sort of thing, it
Tom> would version all its kernel structs and put padding at the
Tom> end to ensure new fields could be added.  It has opted for
Tom> the cleaner (technical) solution of having all the apps
Tom> recompile.  Sure there will be a little bit of growing pain,
Tom> but in the end, it won't have all kinds of backwards
Tom> compatibility cruft lying around.

No, this is absolutely not true.  The kernel-user ABI is very stable,
and with very few exceptions, you should be able to take binaries that
worked on kernel 1.0 and run them on a modern kernel.  For example,


The in-kernel ABI and API can and do change all the time, but that's a
different story.


I don't want to get into a big debate about this.  If a good solution  
can be had that will both maintain compatibility and allow for IB, I  
would welcome that.  On the other hand, most of the interesting apps  
have broken on Linux in the past few years.  Some examples:


- Loki games
- Word Perfect 8
- Crossover office/plugin
- java

I know that lots of that has to do with gcc, threading, or glibc  
instability, but clearly most interesting binaries that were around  
in the 1.0 days will not run on todays stuff.


Can we do an audit of what stuff will break with this change?  If it  
is a handful of applications that we all have the source to, maybe it  
won't be that big of a deal.


Maybe the better approach is to simply submit the struct change.  And  
let the maintainers object if they want ABI stability.   If they do,  
ask them for an elegant solution ;)


-tduffy


___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH] sockaddr_ll change for IPoIB interface

[Tom Duffy]

On Aug 12, 2005, at 7:51 AM, Roland Dreier wrote:


Tom> Do we need backward compatibility?

Hal> I'm not sure but I think this was a recommendation from
Hal> Roland.

Yes, of course we need backward compatibility.  We can't put a change
into the kernel that breaks userspace binaries.

For example, the old Fedora binary of arping has to continue to work,
even if you use a new kernel.


But, Fedora will rebuild their binary once this change is in.  If the  
Linux developers cared about this sort of thing, it would version all  
its kernel structs and put padding at the end to ensure new fields  
could be added.  It has opted for the cleaner (technical) solution of  
having all the apps recompile.  Sure there will be a little bit of  
growing pain, but in the end, it won't have all kinds of backwards  
compatibility cruft lying around.


-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH] sockaddr_ll change for IPoIB interface

[Tom Duffy]

On Aug 11, 2005, at 2:38 PM, Hal Rosenstock wrote:

Can anyone think of another approach to do this and keep backward
compatibility ?


Do we need backward compatibility?  How about the stuff that includes  
if_packet.h gets rebuilt?  You are adding to the end of the struct,  
after all.


-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: GONE from Sun as of Aug 5, 2005

[Tom Duffy]

On Aug 8, 2005, at 12:16 AM, Michael S. Tsirkin wrote:Tom, I'd like to start doing checkins directly to SDP trunk.As I said, I'm already working on it a big percentage of my time,as part of my day job, and there's a setup here in Mellanox Israelto stress-test SDP.Sounds fine.  I wouldn't object.This could work similiar to the way core is co-maintained bySean, Hal and Roland: all patches send to openib-general:trivial patches checked in directly, bigger things wait a bitfor review.Let me know whether this works for you.This would work fine.  Go for it.-tduffy___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: sdp: cant unload ib_ipoib module

[Tom Duffy]

On 8/7/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Drop net_device and rtable references after path lookup is done.

Thanks, applied in revision 3029.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] RE: [PATCH ] osmtest general cleanups

[Tom Duffy]

On 8/7/05, Liran Sorani <[EMAIL PROTECTED]> wrote:
> Hi , Hal. 
> I've a few minor fixes (several white space glitches) , pls take the
> attached file , instead of the previous  , 
> thanks  Liran. 

Please post patches inline.  Even if you do attach the patch 'cause
your mailer munges whitespace, at least the patch can be reviewed
inside of an email reader.  Also, please make sure the mime type is
correct on attached patches: patches are not application/octet-stream.

Thanks,

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: sdp: cant unload ib_ipoib module

[Tom Duffy]

On 8/7/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> The patch also seems to break loopback. Did you test it in that
> configuration?

No, I will test and fix before committing.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] flush_scheduled_work on SDP module unload

[Tom Duffy]

On 8/4/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Need to flush scheduled work on SDP module unload: make sure
> that a deferred iocb isnt outstanding.

Thanks, committed in revision 3009.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] flush_scheduled_work on SDP module unload

[Tom Duffy]

On 8/4/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Need to flush scheduled work on SDP module unload: make sure
> that a deferred iocb isnt outstanding.

Is this still needed?  Or was it just from the incorrect printout?

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH updated] sdp: cancel read with no iocb

[Tom Duffy]

On 8/1/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> > Subject: sdp: cancel read with no iocb
> >
> > Libor, I'm seeing these messages:
> >
> > ib_sdp WARN: Cancel read with no IOCB. <2:0:0005>
> >
> > It seems that this warning is printed in a legal state where
> > a deferred iocb is canceled. Shouldnt this sdp_warn be replaced
> > with sdp_dbg_ctrl?
> 
> Ugh, that patch broke compilation with debug on.
> Here's a better one.

Thanks, applied.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] SDP: priority is now unsigned int

[Tom Duffy]

On 7/25/05, Tom Duffy <[EMAIL PROTECTED]> wrote:
> sk_alloc() takes an "unsigned int __nocast priority" instead of an int.
> This was changed in 2.6.13-rc3.

I committed this change as revision 2991.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] SDP: use linux/list.h for advt table

[Tom Duffy]

On 7/25/05, Tom Duffy <[EMAIL PROTECTED]> wrote:
> This patch changes sdp_advt.[ch] to use linux lists.  I didn't change
> the API, but it may be a good idea now that the lists are done a bit
> differently.

I committed this patch as version 2990.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] iWARP Branch

[Tom Duffy]

On 8/5/05, Ryan, Jim <[EMAIL PROTECTED]> wrote:
> Tom, this comes from a discussion just concluded. TomT is talking about
> a significant amount of code that seemed best suited to a branch. That's
> what Matt suggested and TomT was complying with the request you saw

Fair enough.  Sorry for being out of the loop.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] iWARP Branch

[Tom Duffy]

On 8/5/05, Tom Tucker <[EMAIL PROTECTED]> wrote:
> Could you please create a branch so that we can drop our driver?

How about a patch?

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [RFC] IPoIB sockaddr_ll changes

[Tom Duffy]

> The latter is but is removing the whitespace. Should that not be done ?

Maybe in a different patch.

> The former is a commentary typo.

I just don't want people to confuse the issues.  One idea per patch,
that sort of thing.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [RFC] IPoIB sockaddr_ll changes

[Tom Duffy]

On 05 Aug 2005 11:42:17 -0400, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> I would like to get comments on this prior to sending this over to
> kernel land.

> --- net/packet/af_packet.c.orig 2005-06-29 19:00:53.0 -0400
> +++ net/packet/af_packet.c  2005-08-05 11:23:24.0 -0400
> @@ -140,7 +140,7 @@ dev->hard_header == NULL (ll header is a
> mac.raw -> data
> data -> data
> 
> -   We should set nh.raw on output to correct posistion,
> +   We should set nh.raw on output to correct position,
> packet classifier depends on it.
>   */
> 
> @@ -315,7 +315,7 @@ static int packet_sendmsg_spkt(struct ki
> struct net_device *dev;
> unsigned short proto=0;
> int err;
> -
> +
> /*
>  *  Get and verify the address.
>  */

Both of these are whitespace changes that shouldn't be sent with this patch.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: SDP and uCM.

[Tom Duffy]

> From: Libor Michalek [mailto:[EMAIL PROTECTED]
>   No. I don't have any private patches to commit, and it does not look
> like I'll have time to look at and test all the patches that have been
> posted. Sorry.

Do you have any test scripts or procedures that you use to verify correctness 
or look for regressions when somebody sends you an SDP patch?

Thanks,

-tduffy


___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: SDP and uCM.

[Tom Duffy]

On Thu, 2005-08-04 at 14:26 -0700, Libor Michalek wrote:
>   At the end of this week I will be leaving Cisco and will no longer
> have the time, or access to the equipment, needed to maintain the SDP
> or uCM code. It would seem ideal for Sean Hefty to take over the uCM
> code if he has the time and desire. I also think that Tom Duffy would
> be the right person to maintain the SDP code, unless he doesn't think
> he has the time. In which case Michael Tsirkin knows the code very well
> and would hopefully consider taking over the code.

Libor, do you plan on checking anything else into SDP before you give
over maintainership?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] [PATCH 1/2] kDAPL: remove inline functions

[Tom Duffy]

On Thu, 2005-08-04 at 20:30 +0300, Or Gerlitz wrote:
> >This is almost exactly what is there now.  Not really a change.  I don't 
> >like 
> > the multiple indirections to get to the function table, but this can be 
> > simplified later.  
>  
> Indeed, it can be simplified a little, but why not having this simplification 
> in the kdapl 
> registry level ("dat") as it is in ib_core calling ib_verbs and libibverbs 
> calling libmthca,
> while the verbs consumer does not have to go into those indirections at all 
> but rather
> just call a well understood/defined api? are you suggesting to apply such a 
> chance also
> to the verbs?

I don't understand what you mean?  What change would happen in verbs?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [RFC] Move InfiniBand .h files

[Tom Duffy]

On Thu, 2005-08-04 at 10:32 -0700, Roland Dreier wrote:
> I would like to get people's reactions to moving the InfiniBand .h
> files from their current location in drivers/infiniband/include/ to
> include/linux/rdma/.  If we agree that this is a good idea then I'll
> push this change as soon as 2.6.14 starts.

I think it is a great idea.

> The advantages of doing this are:
> 
>   - The headers become more easily accessible to other parts of the
> tree that might want to use IB support.  For example, an NFS/RDMA
> client probably wants to live under fs/
>   - It makes it easier to build IB modules outside the tree, since
> include/linux gets put in /lib/modules//build.  I realize
> that we don't really care about out-of-tree modules, but it is
> convenient to be able to develop and distribute new drivers that
> build against someone's existing kernels.
>   - We can kill off the ugly
> 
> EXTRA_CFLAGS += -Idrivers/infiniband/include
> 
> lines in our Makefiles.

One more advantage:

   - It shows our willingness to push past just infiniband.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] [PATCH 1/2] kDAPL: remove inline functions

[Tom Duffy]

On Thu, 2005-08-04 at 17:13 +0300, Or Gerlitz wrote:
> Tom,
> 
> Wouldn't it be simple to come with a patch that applies only to the
> "dat" code ie 
> (gen2/trunk/src/linux-kernel/infiniband/ulp/kdapl/kdapl.h and/or api.c)
> which does 
> not require --any-- code change at the cosumer side? 
> 
> that is, with the patch you sent, a call to dat_pz_create at in consumer
> code was changed 
> 
> from
>   -ret = dat_pz_create (ia, &pz);
> to
>   +   ret = ia->common.provider->pz_create (ia, &pz);
> 
> so cant it be done with dat_pz_create being a function (or define)
> calling to 
> 
>   ia->common.provider->pz_create(ia, &pz);
> 
> similar to what is done by ib_core / libibverbs calling ib_mthca /
> libmthca 
> 
> This makes the consumer code simpler and no changes are need in current
> consumers

This is almost exactly what is there now.  Not really a change.  I don't
like the multiple indirections to get to the function table, but this
can be simplified later.  Using the function table to call the function
is a well established practice within the Linux kernel -- look at struct
file_operations for a good example usage.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] sdp: cant unload ib_ipoib module

[Tom Duffy]

On Thu, 2005-08-04 at 10:45 -0400, Hal Rosenstock wrote:
> > Perhaps you need my sdp_inet_port_put() patch?
> 
> Yes, this was from before that patch but I thought that patch was to
> resolve an oops with port reuse. I don't see the relation between the
> two. Is this not the case ?

It was just a wild ass guess, since my SDP tree is a bit different from
trunk.  But the port_put() code is called on shutdown of the socket.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] [iSER]How to get the dat_headers_1_1.tgz

[Tom Duffy]

On Thu, 2005-08-04 at 09:06 -0400, Kanevsky, Arkady wrote:
> How about http://www.datcollaborative.org/dat_headers_1_1.tgz .
> Tom,
> does this serves the purpose?

Great!  Thank you very much.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] [iSER]How to get the dat_headers_1_1.tgz

[Tom Duffy]

> application/x-compressed attachment (dat_headers_1_1.tgz),
> "dat_headers_1_1.tgz"

I think you missed my point.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general] [iSER]How to get the dat_headers_1_1.tgz

[Tom Duffy]

On Wed, 2005-08-03 at 15:18 -0400, Kanevsky, Arkady wrote:
> The files are available to all.

http://groups.yahoo.com/group/dat-discussions/files/dat_headers_1_1.tgz
> To access Yahoo! Groups...
> 
> you need a Yahoo! ID. 
> Don't have a Yahoo! ID?
> Signing up is easy.

that is *not* available to all...

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH 1/2] kDAPL: remove inline functions

[Tom Duffy]

On Tue, 2005-08-02 at 15:00 -0700, Tom Duffy wrote:
> This patch removes all the inline functions, instead just call the
> functions from the function table.  It also removes the _func from the
> names as this is obvious by its type.

James,

Any chance of merging these?

-tduffy



signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Perftest problems

[Tom Duffy]

On Tue, 2005-07-26 at 11:07 -0400, Spencer Whitman wrote:
> I'm trying to run either of the perf tests and i'm seg faulting on the 
> client side =( .  For rdma_lat the client segfaults but the server seems 
> to fail silently.  For rdma_bw the client segfaults and the server dies 
> with the msg:
> server read: Address family not supported by protocol
> 0/45: Couldn't read remote address
> 
> Any ideas or help?

Are all the needed ib_* modules loaded?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] configuration management for OpenIB

[Tom Duffy]

On Wed, 2005-08-03 at 11:53 -0700, Roland Dreier wrote:
> Git cons:
>  - Requires periodic repacking of repository for efficiency

Doesn't git have a very inefficient way creating blame files or creating
a line-by-line versioned file?

Or does repacking fix this?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] RE: [BUG]OpenSM double free or corruption

[Tom Duffy]

On Tue, 2005-08-02 at 15:29 -0700, Roland Dreier wrote:
> This message is just a warning, not an error.  Does anyone have any
> suggestions on how to rephrase it to make it clear that this is not a
> fatal condition and that the driver is continuing to load?

**NOT** FATAL: HCA FW version 4.5.3 is old (4.6.2 is current).
Life continues.  If you have problems, try updating your HCA FW.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] RE: where can i find functions that "convert" enumerated values t o string?

[Tom Duffy]

On Wed, 2005-08-03 at 08:12 +0300, Dotan Barak wrote:
> During debug of problems in tests/real application this can help
> allot. 
> I think that it better to write "QP ts type is RC" instead of "QP ts
> type is 0"...

Can't you the human look in the header and do the translation?  Seems
better than bloating the kernel with tons of strings and case
statements.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [iSER]How to get the dat_headers_1_1.tgz

[Tom Duffy]

On Wed, 2005-08-03 at 17:14 +0800, Ian Jiang wrote:
> It's known to all that the kDAPL 1.1 is needed to build the iSER. I failed 
> to get
>   http://groups.yahoo.com/group/dat-discussions/files/dat_headers_1_1.tgz
> because only the members of the group could access this file

This is dumb.  Can Arkady just open the files up to anyone?

If not, groups.yahoo.com should not be used for an open source project.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH 2/2] kdapltest: use new function API

[Tom Duffy]

This patch fixes up kdapltest with the new function API.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: gen2/utils/src/linux-kernel/kdapl/dapltest/test/dapl_performance_util.c
===
--- gen2/utils/src/linux-kernel/kdapl/dapltest/test/dapl_performance_util.c 
(revision 2952)
+++ gen2/utils/src/linux-kernel/kdapl/dapltest/test/dapl_performance_util.c 
(working copy)
@@ -65,7 +65,7 @@ DT_Performance_Test_Create (
 test_ptr->ia = ia;
 test_ptr->cmd = &pt_ptr->Params.u.Performance_Cmd;
 
-ret = dat_ia_query (test_ptr->ia,
+ret = ia->common.provider->ia_query (test_ptr->ia,
NULL,
&test_ptr->ia_attr,
NULL);
@@ -101,7 +101,7 @@ DT_Performance_Test_Create (
 test_ptr->creq_evd_length = DT_PERF_DFLT_EVD_LENGTH;
 
 /* create a protection zone */
-ret = dat_pz_create (test_ptr->ia, &test_ptr->pz);
+ret = test_ptr->ia->common.provider->pz_create (test_ptr->ia, 
&test_ptr->pz);
 if ( 0 != ret)
 {
DT_Tdep_PT_Printf (phead, "Test[" F64x "]: dat_pz_create error: %s\n",
@@ -182,7 +182,7 @@ DT_Performance_Test_Create (
 test_ptr->ep_context.ep_attr.max_request_dtos = pipeline_len;
 
 /* Create EP */
-ret = dat_ep_create (test_ptr->ia,  /* IA   */
+ret = ia->common.provider->ep_create (test_ptr->ia, /* IA   */
 test_ptr->pz,   /* PZ   */
 test_ptr->recv_evd_hdl, /* recv */
 test_ptr->reqt_evd_hdl, /* request  */
@@ -318,7 +318,7 @@ DT_Performance_Test_Destroy (
  */
 if (test_ptr->ep_context.ep)
 {
-   ret = dat_ep_disconnect (test_ptr->ep_context.ep,
+   ret = test_ptr->ep_context.ep->common.provider->ep_disconnect 
(test_ptr->ep_context.ep,
DAT_CLOSE_ABRUPT_FLAG);
if (ret != 0)
{
@@ -340,7 +340,7 @@ DT_Performance_Test_Destroy (
 if ( NULL != ep)
 {
/* Destroy the EP */
-   ret = dat_ep_free (ep);
+   ret = ep->common.provider->ep_free (ep);
if (ret != 0)
{
DT_Tdep_PT_Printf (phead, "Test[" F64x "]: dat_ep_free error: %s\n",
@@ -402,7 +402,7 @@ DT_Performance_Test_Destroy (
 /* clean up the PZ */
 if (test_ptr->pz)
 {
-   ret = dat_pz_free (test_ptr->pz);
+   ret = test_ptr->pz->common.provider->pz_free (test_ptr->pz);
if (ret != 0)
{
DT_Tdep_PT_Printf (phead, "Test[" F64x "]: dat_pz_free error: %s\n",
@@ -462,7 +462,7 @@ DT_performance_post_rdma_op (
pre_ctxt_num = DT_Mdep_GetContextSwitchNum ();
pre_ts = DT_Mdep_GetTimeStamp ();
 
-   ret = dat_ep_post_rdma_write (ep_context->ep,
+   ret = ep_context->ep->common.provider->ep_post_rdma_write 
(ep_context->ep,
 op->num_segs,
 iov,
 cookie,
@@ -479,7 +479,7 @@ DT_performance_post_rdma_op (
pre_ctxt_num = DT_Mdep_GetContextSwitchNum ();
pre_ts = DT_Mdep_GetTimeStamp ();
 
-   ret = dat_ep_post_rdma_read (ep_context->ep,
+   ret = ep_context->ep->common.provider->ep_post_rdma_read 
(ep_context->ep,
op->num_segs,
iov,
cookie,
Index: gen2/utils/src/linux-kernel/kdapl/dapltest/test/dapl_performance_client.c
===
--- gen2/utils/src/linux-kernel/kdapl/dapltest/test/dapl_performance_client.c   
(revision 2952)
+++ gen2/utils/src/linux-kernel/kdapl/dapltest/test/dapl_performance_client.c   
(working copy)
@@ -103,7 +103,7 @@ DT_Performance_Test_Client_Connect (
   test_ptr->base_port, test_ptr->ep_context.port));
 
 retry:
-ret = dat_ep_connect (test_ptr->ep_context.ep,
+ret = test_ptr->ep_context.ep->common.provider->ep_connect 
(test_ptr->ep_context.ep,
 test_ptr->remote_ia_addr,
 test_ptr->ep_context.port,
 DAT_TIMEOUT_MAX,
@@ -297,7 +297,7 @@ DT_Performance_Test_Client_Phase2 (
{
pre_ts = DT_Mdep_GetTimeStamp ();
 
-   ret = dat_ep_post_rdma_write (ep_context->ep,
+   ret = ep_context->ep->common.provider->ep_post_rdma_write 
(ep_context->ep,
  op->num_segs,
  iov,
  cookie,
@@ -308,7 +308,7 @@ DT_Performance_Test_Client_Phase2 (
{
pr

[openib-general] [PATCH 1/2] kDAPL: remove inline functions

[Tom Duffy]

This patch removes all the inline functions, instead just call the
functions from the function table.  It also removes the _func from the
names as this is obvious by its type.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.13-rc5-openib/drivers/infiniband/ulp/kdapl/kdapl.h
===
--- linux-2.6.13-rc5-openib/drivers/infiniband/ulp/kdapl/kdapl.h
(revision 2952)
+++ linux-2.6.13-rc5-openib/drivers/infiniband/ulp/kdapl/kdapl.h
(working copy)
@@ -572,11 +572,9 @@ enum dat_upcall_policy {
 */
 };
 
-typedef void (*DAT_UPCALL_FUNC) (void *, const struct dat_event *, boolean_t);
-
 struct dat_upcall_object {
void *instance_data;
-   DAT_UPCALL_FUNC upcall_func;
+   void (*upcall)(void *, const struct dat_event *, boolean_t);
 };
 
 /* Define NULL upcall */
@@ -736,113 +734,104 @@ struct dat_provider {
const char *ia_name;
void *extension;
 
-   int (*ia_open_func)(const char *, int, struct dat_evd **,
-   struct dat_ia **);
-   int (*ia_query_func)(struct dat_ia *, struct dat_evd **,
-struct dat_ia_attr *, struct dat_provider_attr *);
-   int (*ia_close_func)(struct dat_ia *, enum dat_close_flags);
-   int (*ia_memtype_hint_func)(struct dat_ia *, enum dat_mem_type, u64,
-   enum dat_mem_optimize_flags, u64 *, u64 *);
-   int (*cr_query_func)(struct dat_cr *, struct dat_cr_param *);
-   int (*cr_accept_func)(struct dat_cr *, struct dat_ep *, int, 
- const void*);
-   int (*cr_reject_func)(struct dat_cr *);
-   int (*cr_handoff_func)(struct dat_cr *, DAT_CONN_QUAL);
-   int (*evd_kcreate_func)(struct dat_ia *, int, enum dat_upcall_policy,
-   const struct dat_upcall_object *, 
-   enum dat_evd_flags, struct dat_evd **);
-   int (*evd_query_func)(struct dat_evd *, struct dat_evd_param *);
-   int (*evd_modify_upcall_func)(struct dat_evd *, enum dat_upcall_policy,
- const struct dat_upcall_object *);
-   int (*evd_resize_func)(struct dat_evd *, int);
-   int (*evd_post_se_func)(struct dat_evd *, const struct dat_event *);
-   int (*evd_dequeue_func)(struct dat_evd *, struct dat_event *);
-   int (*evd_free_func)(struct dat_evd *);
-   int (*ep_create_func)(struct dat_ia *, struct dat_pz *, struct dat_evd 
*,
- struct dat_evd *, struct dat_evd *, 
- const struct dat_ep_attr *, struct dat_ep **);
-   int (*ep_query_func)(struct dat_ep *, struct dat_ep_param *);
-   int (*ep_modify_func)(struct dat_ep *, enum dat_ep_param_mask,
- const struct dat_ep_param *);
-   int (*ep_connect_func)(struct dat_ep *, struct sockaddr *, 
DAT_CONN_QUAL,
-  unsigned long, int, const void *, enum dat_qos, 
-  enum dat_connect_flags);
-
-   int (*ep_dup_connect_func)(struct dat_ep *, struct dat_ep *, 
-  unsigned long, int, const void *, 
-  enum dat_qos);
-   int (*ep_disconnect_func)(struct dat_ep *, enum dat_close_flags);
-   int (*ep_post_send_func)(struct dat_ep *, int, struct dat_lmr_triplet 
*, 
-DAT_DTO_COOKIE, enum dat_completion_flags);
-   int (*ep_post_recv_func)(struct dat_ep *, int, struct dat_lmr_triplet 
*, 
-DAT_DTO_COOKIE, enum dat_completion_flags);
-   int (*ep_post_rdma_read_func)(struct dat_ep *, int, 
- struct dat_lmr_triplet *, DAT_DTO_COOKIE,
- const struct dat_rmr_triplet *,
- enum dat_completion_flags);
-   int (*ep_post_rdma_write_func)(struct dat_ep *, int,
-  struct dat_lmr_triplet *, DAT_DTO_COOKIE,
-  const struct dat_rmr_triplet *,
-  enum dat_completion_flags);
-   int (*ep_get_status_func)(struct dat_ep *, enum dat_ep_state *,
- boolean_t *, boolean_t *);
-
-   int (*ep_free_func)(struct dat_ep *);
-   int (*lmr_kcreate_func)(struct dat_ia *, enum dat_mem_type,
-   DAT_REGION_DESCRIPTION, u64, struct dat_pz *, 
-   enum dat_mem_priv_flags, 
-   enum dat_mem_optimize_flags, struct dat_lmr **,
-   DAT_LMR_CONTEXT *, DAT_RMR_CONTEXT *, u64 *, 
-   u64 *);
-   int (*lmr_query_func)(struct dat_lmr *, struct dat_lmr_param *);
-   int (*lmr_free_func)(struct dat_lmr *);
-

RE: [openib-general] sdp: cant unload ib_ipoib module

[Tom Duffy]

On Tue, 2005-08-02 at 16:08 +0300, Hal Rosenstock wrote:
> This was reported back a while ago. The simplest scenario I have found to 
> reproduce this is as follows:
> 
> After using SDP, and unload SDP and then unload IPoIB and
> got the following:
> 
> unregister_netdevice: waiting for ib0 to become free. Usage count = 1
> 
> The simplest way I found to recreate this is:
> 1. Bring up IPoIB and then SDP
> 2. Run tcp.aio.x -t 
> (no server/receiver)
> 3. Wait for connection refused
> 4. Unload SDP and then IPoIB

[EMAIL PROTECTED] ~]# modprobe ib_ipoib
ip_tables: (C) 2000-2002 Netfilter core team
[EMAIL PROTECTED] ~]# ifconfig ib0 192.168.0.26 up
[EMAIL PROTECTED] ~]# ping 192.168.0.0 -b
WARNING: pinging broadcast address
PING 192.168.0.0 (192.168.0.0) 56(84) bytes of data.
64 bytes from 192.168.0.26: icmp_seq=0 ttl=64 time=0.057 ms
64 bytes from 192.168.0.233: icmp_seq=0 ttl=64 time=0.159 ms (DUP!)
<-- snip -->
[EMAIL PROTECTED] rc]# modprobe ib_sdp
[EMAIL PROTECTED] ~]# ./ttcp -t -l 65536 -n 10 -a 20 localhost -p
5002
ttcp-t: buflen = 65536 nbuf = 10 align = 16384/0 port = 5002
localhost
ttcp-t: socket
ttcp-t: connect: Connection refused
errno=111
[EMAIL PROTECTED] ~]# rmmod ib_sdp
[EMAIL PROTECTED] ~]# rmmod ib_ipoib
[EMAIL PROTECTED] ~]#

I can even shoot stuff over the wire and not have unload issues.

What is the problem?  Perhaps you need my sdp_inet_port_put() patch?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] kdapl build error on ia64

[Tom Duffy]

On Tue, 2005-08-02 at 09:54 -0400, Hal Rosenstock wrote:
> I believe that users/jlentini is now obsolete and the trunk supercedes
> this so this is fine.

James, do you want to delete users/jlentini so as to not confuse
anybody?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] kdapl build error on ia64

[Tom Duffy]

On Mon, 2005-08-01 at 17:23 -0500, John Partridge wrote:
> Hal/James,
> 
> Here is a patch that fixes the ia64 build problem and the warnings

Please sign your patches.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] kdapl build error on ia64

[Tom Duffy]

On Fri, 2005-07-29 at 16:46 -0500, John Partridge wrote:
> I searched the archives and don't see a solution, but I think I've tracked it 
> down
> to a bug in ulp/kdapl/ib/dapl_util.h
> 
> root on mig133  > diff -ruN dapl_util.h dapl_util.h-johnip

Please use diff -ruNp.  See FAQ question 10.

> === diff ===
> 
>   --- dapl_util.h 2005-07-29 16:36:17.514669886 -0500
>   +++ dapl_util.h-johnip  2005-07-29 16:37:11.514578548 -0500
>   @@ -71,7 +71,7 @@
> 
>#ifdef __ia64__
> 
>   -   current_value = ia64_cmpxchg("acq", v, match_value, new_value, 
> 4);
>   +   current_value = ia64_cmpxchg(acq, v, match_value, new_value, 4);
> 
>   #elif defined (__PPC__)

Please kill dapl_os_atomic_assign().  Just use cmpxchg() directly
instead.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH] SDP: use linux/list.h for binds

[Tom Duffy]

On Tue, 2005-07-19 at 16:29 -0700, Libor Michalek wrote:
> > >   Thanks. I've applied the patch since it's better then what was there.
> > > However, the longer term solution needs to use a full hash table, the 
> > > linear list is problematic when there are a lot of connections, and each
> > > port_get() needs to traverse the entire list to check for collisions.
> > 
> > Or a tree?
> 
>   A tree would be fine as well, I was just thinking anything that has
> a src_port lookup time of O(log n) instead of O(n). Also the tcp code
> uses it's own hash table for it's port lookup. (net/ipv4/tcp_ipv4.c)
> That seems like it might be overkill...

Is anyone looking at moving this over to use rbtree.h?  If not, I will
take a look.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] link availability

[Tom Duffy]

On Mon, 2005-08-01 at 17:45 +0200, Ouissem BEN FREDJ wrote:
> Hello,
> 
> Is it possible to link directly two Infiniband cards type InfiniCom 
> InfiniServ 7000 (MT23108) , without using any interconnect switch ?
> In that case, could you tell me how.

Please refer to the FAQ (specifically question 2):

https://openib.org/tiki/tiki-index.php?page=OpenIBFAQ

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] AT: cleanup some sparse warnings

[Tom Duffy]

On Thu, 2005-07-28 at 13:59 -0700, Sean Hefty wrote:
> Tom Duffy wrote:
> > This patch cleans up a few sparse warnings in AT.
> >  
> > Index: linux-2.6.13-rc3-openib/drivers/infiniband/core/at_priv.h
> >  
> >  #define IB_ATS_SERVICE_NAME "DAPL Address Translation Service"
> > -#define IB_ATS_SERVICE_ID   cpu_to_be64(0x1ce100415453)
> > -#define IB_ATS_LAST_SERVICE_ID  cpu_to_be64(0x1ce1ff415453)
> > +#define IB_ATS_SERVICE_ID   cpu_to_be64(0x1ce100415453ULL)
> > +#define IB_ATS_LAST_SERVICE_ID  cpu_to_be64(0x1ce1ff415453ULL)
> >  #define IB_ATS_OPENIB_MAGIC_KEY cpu_to_be16(IB_OPENIB_OUI & 0x)
> 
> I usually use __constant_cpu_to_be* to byte swap constants.  (I think I did 
> it to allow the use of the #define in case statements.)

I am not sure what you are getting at.  This patch corrects the error:

drivers/infiniband/core/at.c:102:12: warning: constant 0x1ce100415453 is so 
big it is long

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Re: [Rdma-developers] Meeting (07/22) summary: OpenRDMA community development discussion

[Tom Duffy]

On Thu, 2005-07-28 at 10:52 -0700, Venkata Jagana wrote:   
> 5)  OpenIB enablement of iWARP announcement 
> 
>Not much time left to discuss in detail the OpenIB announcement
> of iWARP enablement 
>and what it means to OpenRDMA in terms of any additional
> conflict. 
> 
>Venkat has clarified that based on previous email and conf call
> discussions between 
>openRDMA and openIB groups that these two groups are
> complimentary to each other 
>in terms of Upper layer protocols support but there is a
> conflict around modified Gen2 verbs 
>usage versus RNIC-PI. 
> 
> RNIC vendors seem to be quite strongly committed to supporting
> RNIC-PI. 
> 
> There are different views expressed regarding the convergence
> of gen2 verbs and RNIC-PI. 
> One view is that the convergence in the interfaces need to
> happen over a period of time so that 
>  there will be a single PI supporting both IB and iWARP in the
> linux mainline kernel. 
> 
> The other view regarding the convergence is that there is no
> need to have this convergence happen 
> since they can coexist in the kernel at the sametime with
> different APIs. 
> 
>  Only the time will tell what will happen but ultimately, it
> depends upon what the linux kernel maintainers 
>   have to say. 

At OLS (and in previous forums), the kernel maintainers have made it
*very* clear that there should only be one API.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] AT: cleanup some sparse warnings

[Tom Duffy]

This patch cleans up a few sparse warnings in AT.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.13-rc3-openib/drivers/infiniband/core/at.c
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/core/at.c(revision 2931)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/core/at.c(working copy)
@@ -224,7 +224,7 @@ static void ib_dev_remove(struct ib_at_d
ib_dev->pend_op = 0;
 
dev_put(ib_dev->netdev);
-   ib_dev->netdev = 0;
+   ib_dev->netdev = NULL;
ib_dev->old_ip = 0;
ib_dev->ip = 0;
ib_dev->valid = 0;
@@ -325,7 +325,7 @@ static int ib_devs_changed(void)
 
for (i = 0; i < n; i++)
if (netdev == ibdevs[i]) {
-   ibdevs[i] = 0;  /* dev handled - not new */
+   ibdevs[i] = NULL; /* dev handled - not new */
break;
}
 
@@ -1165,7 +1165,7 @@ static int resolve_route(struct route_re
}
 
if (req->pend.type == IBAT_REQ_ATS)
-   return resolve_ats_route(req, 0);
+   return resolve_ats_route(req, NULL);
 
WARN("bad req %p type %d", req, req->pend.type);
return -1;
@@ -1401,7 +1401,7 @@ int ib_at_paths_by_route(struct ib_at_ib
IBAT_REQ_PATHREC, same_path_req);
 
if (req_start(&pending_reqs, &preq->pend, parent))
-   resolve_path(preq, 0);
+   resolve_path(preq, NULL);
 
return 0;   /* async req */
 }
@@ -1454,7 +1454,7 @@ int ib_at_ips_by_gid(union ib_gid *gid, 
IBAT_REQ_ATSARP, same_ats_ips_req);
 
if (req_start(&pending_reqs, &areq->pend, parent))
-   resolve_ats_ips(areq, 0);
+   resolve_ats_ips(areq, NULL);
 
return 0;   /* async req */
 }
@@ -1526,11 +1526,11 @@ static struct packet_type ib_at_arp_type
 };
 
 static struct notifier_block ib_at_netdev_notifier = {
-   notifier_call:  inetaddr_event,
+   .notifier_call = inetaddr_event,
 };
 
 static struct notifier_block ib_at_inetaddr_notifier = {
-   notifier_call:  inetaddr_event,
+   .notifier_call = inetaddr_event,
 };
 
 static int ib_at_init(void)
Index: linux-2.6.13-rc3-openib/drivers/infiniband/core/at_priv.h
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/core/at_priv.h   (revision 2931)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/core/at_priv.h   (working copy)
@@ -130,8 +130,8 @@ static const struct ib_field ats_rec_tab
 IB_SA_SERVICE_REC_SERVICE_GID)
 
 #define IB_ATS_SERVICE_NAME "DAPL Address Translation Service"
-#define IB_ATS_SERVICE_ID   cpu_to_be64(0x1ce100415453)
-#define IB_ATS_LAST_SERVICE_ID  cpu_to_be64(0x1ce1ff415453)
+#define IB_ATS_SERVICE_ID   cpu_to_be64(0x1ce100415453ULL)
+#define IB_ATS_LAST_SERVICE_ID  cpu_to_be64(0x1ce1ff415453ULL)
 #define IB_ATS_OPENIB_MAGIC_KEY cpu_to_be16(IB_OPENIB_OUI & 0x)
 
 //#define WARN(fmt, ...)   while (0) {}


___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

RE: [openib-general][PATCH][kdapltest]: inc/dec module ref count

[Tom Duffy]

On Thu, 2005-07-28 at 14:27 +0300, Guy German wrote:
> Right.
> I was not sure this policy regards kdapltest as well.

kdapltest can be an abomination since it never has to make it upstream.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] uat: make uat.c compile on 2.6.13-rc3

[Tom Duffy]

This patch is similar to the one for ucm.  It updates the class code to
work with 2.6.13-rc3.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.13-rc3-openib/drivers/infiniband/core/uat.c
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/core/uat.c   (revision 2928)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/core/uat.c   (working copy)
@@ -806,8 +806,8 @@ static struct file_operations ib_uat_fop
 };
 
 
-static struct class_simple *ib_uat_class;
-static struct cdev   ib_uat_cdev;
+static struct class *ib_uat_class;
+static struct cdev   ib_uat_cdev;
 
 static int __init ib_uat_init(void)
 {
@@ -827,17 +827,14 @@ static int __init ib_uat_init(void)
goto err_cdev;
}
 
-   ib_uat_class = class_simple_create(THIS_MODULE, "infiniband_uat");
+   ib_uat_class = class_create(THIS_MODULE, "infiniband_uat");
if (IS_ERR(ib_uat_class)) {
result = PTR_ERR(ib_uat_class);
uat_dbg("Error <%d> creating class\n", result);
goto err_class;
}
 
-   class_simple_device_add(ib_uat_class,
-   IB_UAT_DEV,
-   NULL,
-   "uat");
+   class_device_create(ib_uat_class, IB_UAT_DEV, NULL, "uat");

idr_init(&ctx_id_table);
init_MUTEX(&ctx_id_mutex);
@@ -853,8 +850,8 @@ err_chr:
 
 static void __exit ib_uat_cleanup(void)
 {
-   class_simple_device_remove(IB_UAT_DEV);
-   class_simple_destroy(ib_uat_class);
+   class_device_destroy(ib_uat_class, IB_UAT_DEV);
+   class_destroy(ib_uat_class);
cdev_del(&ib_uat_cdev);
unregister_chrdev_region(IB_UAT_DEV, 1);
 }


___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: ib_uat kernel oops

[Tom Duffy]

On Wed, 2005-07-27 at 21:27 -0400, Hal Rosenstock wrote:
> Which IBAT are you using ? It is the one in the trunk or the one on
> shaharf-ibat branch ?

uat.[ch] isn't in trunk yet, right?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] SDP: remove linux/version.h

[Tom Duffy]

[ Libor, sorry for the dup's, my sendmail is fucked ]

No need for linux/version.h in SDP, either.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_main.h
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_main.h   
(revision 2918)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_main.h   
(working copy)
@@ -69,7 +69,6 @@
 /*
  * kernel includes
  */
-#include 
 #include 
 #include 
 #include 


___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] SDP: priority is now unsigned int

[Tom Duffy]

sk_alloc() takes an "unsigned int __nocast priority" instead of an int.
This was changed in 2.6.13-rc3.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_proto.h
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_proto.h  
(revision 2909)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_proto.h  
(working copy)
@@ -260,7 +260,7 @@ int sdp_proc_dump_device(char *buffer,
 
 struct sdp_sock *sdp_conn_table_lookup(s32 entry);
 
-struct sdp_sock *sdp_conn_alloc(int priority);
+struct sdp_sock *sdp_conn_alloc(unsigned int priority);
 
 int sdp_conn_alloc_ib(struct sdp_sock *conn,
  struct ib_device *device, 
Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(revision 2909)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(working copy)
@@ -1132,7 +1130,7 @@ extern struct proto sdp_sk_proto;
 /*
  * sdp_conn_alloc - allocate a new socket, and init.
  */
-struct sdp_sock *sdp_conn_alloc(int priority)
+struct sdp_sock *sdp_conn_alloc(unsigned int priority)
 {
struct sdp_sock *conn;
struct sock *sk;
@@ -1140,7 +1138,7 @@ struct sdp_sock *sdp_conn_alloc(int prio
 
sk = sk_alloc(dev_root_s.proto, priority, &sdp_sk_proto, 1);
if (!sk) {
-   sdp_dbg_warn(NULL, "socket alloc error for protocol. <%d:%d>",
+   sdp_dbg_warn(NULL, "socket alloc error for protocol. <%d:%u>",
 dev_root_s.proto, priority);
return NULL;
}

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] SDP: fix oops with port reuse

[Tom Duffy]

On Mon, 2005-07-25 at 12:20 -0700, Libor Michalek wrote:
>   The original code at the begining of sdp_inet_port_put() was checking
> to see if the connection was already in the bind list, and returning an
> error if it was not in the list. The error check that's there now is
> doing something different, and we return success if the connection
> is not in the bind list and has a put() done on it.
> 
>   If we are regularly doing a put on a socket not in the bind list,
> the function should be made void, and the check for list membership
> not generate an error...

Something like this?

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_inet.c
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_inet.c   
(revision 2909)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_inet.c   
(working copy)
@@ -1100,7 +1100,7 @@ static int sdp_inet_setopt(struct socket
SDP_MSG_HDR_SIZE));
break;
case SDP_UNBIND:
-   result = sdp_inet_port_put(conn);
+   sdp_inet_port_put(conn);
break;
default:
sdp_warn("SETSOCKOPT unimplemented option <%d:%d> conn <%d>.",
Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_proto.h
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_proto.h  
(revision 2909)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_proto.h  
(working copy)
@@ -287,7 +287,7 @@ struct sdp_sock *sdp_inet_listen_lookup(
 
 int sdp_inet_port_get(struct sdp_sock *conn, u16 port);
 
-int sdp_inet_port_put(struct sdp_sock *conn);
+void sdp_inet_port_put(struct sdp_sock *conn);
 
 void sdp_inet_port_inherit(struct sdp_sock *parent, struct sdp_sock *child);
 
Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(revision 2909)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(working copy)
@@ -490,19 +490,17 @@ done:
 /*
  * sdp_inet_port_put - unbind a socket from a port.
  */
-int sdp_inet_port_put(struct sdp_sock *conn)
+void sdp_inet_port_put(struct sdp_sock *conn)
 {
unsigned long flags;
-
-   if (list_empty(&dev_root_s.bind_list))
-   return -EADDRNOTAVAIL;
+   struct sdp_sock *i, *j;
 
spin_lock_irqsave(&dev_root_s.bind_lock, flags);
-   list_del(&conn->bind_next);
+   list_for_each_entry_safe(i, j, &dev_root_s.bind_list, bind_next)
+   if (conn == i)
+   list_del(&conn->bind_next);
conn->src_port = 0;
spin_unlock_irqrestore(&dev_root_s.bind_lock, flags);
-
-   return 0;
 }
 
 /*
@@ -694,7 +692,7 @@ void sdp_conn_put(struct sdp_sock *conn)
/*
 * If the socket is bound, return the port
 */
-   (void)sdp_inet_port_put(conn);
+   sdp_inet_port_put(conn);
 
sdp_conn_stat_dump(conn);
/*

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] SDP: fix oops with port reuse

[Tom Duffy]

This patch fixes an oops that I introduced in my conversion to use linux
lists for binds (committed in revision 2874).  If two sockets tried to
use the same port, after failing to get the port (again), it would
attempt a put and the second attempt would oops the machine.  This patch
fixes the problem that looked like this:

Unable to handle kernel NULL pointer dereference at 0008 RIP:
{:ib_sdp:sdp_inet_port_put+62}
PGD 0
Oops: 0002 [1] PREEMPT SMP
CPU 0
Modules linked in: ib_sdp ib_cm ipv6 parport_pc lp parport autofs4 i2c_dev 
i2c_core nfs lockd rfcomm l2cap bluetooth pcmcia yenta_socket rsrc_nonstatic 
pcmcia_core sunrpc ext3 jbd dm_mod video hotkey container button battery ac 
ohci_hcd tpm_atmel tpm hw_random shpchp ib_mthca ib_ipoib ib_sa ib_mad ib_core 
tg3 floppy mptspi xfs exportfs mptscsih mptbase sd_mod scsi_mod
Pid: 8914, comm: ttcp Not tainted 2.6.13-rc3openib
RIP: 0010:[] {:ib_sdp:sdp_inet_port_put+62}
RSP: 0018:81006d79fdc8  EFLAGS: 00010002
RAX:  RBX: 8100085f90b8 RCX: 8100085f9670
RDX:  RSI: 0213 RDI: 8831d0b8
RBP: 8100085f90b8 R08:  R09: 8100757f8e28
R10: 81006d79fd54 R11:  R12: 8100085f9634
R13: 8100085f9640 R14: 81003f8db050 R15: 
FS:  2aad7900() GS:80514800() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 0008 CR3: 00101000 CR4: 06e0
Process ttcp (pid: 8914, threadinfo 81006d79e000, task 81007366a030)
Stack: 8100085f90b8 8830d78b 0213 883091d0
   810023c2b110 802f2b29 81003fff3100 810023c2b110
    0213
Call Trace:{:ib_sdp:sdp_conn_put+171} 
{:ib_sdp:sdp_inet_release+816}
   {release_sock+25} {sock_release+25}
   {sock_close+53} {__fput+178}
   {filp_close+104} 
{put_files_struct+116}
   {do_exit+535} {do_group_exit+252}
   {system_call+126}

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- drivers/infiniband/ulp/sdp/sdp_conn.c   (revision 2904)
+++ drivers/infiniband/ulp/sdp/sdp_conn.c   (working copy)
@@ -498,7 +498,8 @@ int sdp_inet_port_put(struct sdp_sock *c
return -EADDRNOTAVAIL;
 
spin_lock_irqsave(&dev_root_s.bind_lock, flags);
-   list_del(&conn->bind_next);
+   if (conn->src_port)
+   list_del(&conn->bind_next);
conn->src_port = 0;
spin_unlock_irqrestore(&dev_root_s.bind_lock, flags);
 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] SDP: use linux/list.h for advt table

[Tom Duffy]

This patch changes sdp_advt.[ch] to use linux lists.  I didn't change
the API, but it may be a good idea now that the lists are done a bit
differently.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

 sdp_advt.c |   51 +--
 sdp_advt.h |7 ---
 2 files changed, 17 insertions(+), 41 deletions(-)

Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_advt.c
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_advt.c   
(revision 2900)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_advt.c   
(working copy)
@@ -33,6 +33,8 @@
  * $Id$
  */
 
+#include 
+
 #include "sdp_main.h"
 
 static kmem_cache_t *sdp_advt_cache = NULL;
@@ -68,7 +70,6 @@ struct sdpc_advt *sdp_advt_create(void)
  */
 void sdp_advt_destroy(struct sdpc_advt *advt)
 {
-   BUG_ON(advt->next || advt->prev);
/*
 * return the object to its cache
 */
@@ -81,29 +82,16 @@ void sdp_advt_destroy(struct sdpc_advt *
 struct sdpc_advt *sdp_advt_q_get(struct sdpc_advt_q *table)
 {
struct sdpc_advt *advt;
-   struct sdpc_advt *next;
-   struct sdpc_advt *prev;
 
-   advt = table->head;
-   if (!advt)
+   if (list_empty(&table->head))
return NULL;
 
-   if (advt->next == advt && advt->prev == advt)
-   table->head = NULL;
-   else {
-   next = advt->next;
-   prev = advt->prev;
-   next->prev = prev;
-   prev->next = next;
+   advt = list_entry(table->head.next, struct sdpc_advt, list);
 
-   table->head = next;
-   }
+   list_del(&advt->list);
 
table->size--;
 
-   advt->next = NULL;
-   advt->prev = NULL;
-
return advt;
 }
 
@@ -112,7 +100,10 @@ struct sdpc_advt *sdp_advt_q_get(struct 
  */
 struct sdpc_advt *sdp_advt_q_look(struct sdpc_advt_q *table)
 {
-   return table->head;
+   if (list_empty(&table->head))
+   return NULL;
+   
+   return list_entry(table->head.next, struct sdpc_advt, list);
 }
 
 /*
@@ -120,25 +111,9 @@ struct sdpc_advt *sdp_advt_q_look(struct
  */
 void sdp_advt_q_put(struct sdpc_advt_q *table, struct sdpc_advt *advt)
 {
-   struct sdpc_advt *next;
-   struct sdpc_advt *prev;
-
BUG_ON(advt->table);
 
-   if (!table->head) {
-   advt->next = advt;
-   advt->prev = advt;
-   table->head = advt;
-   }
-   else {
-   next = table->head;
-   prev = next->prev;
-
-   prev->next = advt;
-   advt->prev = prev;
-   advt->next = next;
-   next->prev = advt;
-   }
+   list_add_tail(&advt->list, &table->head);
 
table->size++;
 }
@@ -148,7 +123,7 @@ void sdp_advt_q_put(struct sdpc_advt_q *
  */
 void sdp_advt_q_init(struct sdpc_advt_q *table)
 {
-   table->head = NULL;
+   INIT_LIST_HEAD(&table->head);
table->size = 0;
 }
 
@@ -157,11 +132,11 @@ void sdp_advt_q_init(struct sdpc_advt_q 
  */
 void sdp_advt_q_clear(struct sdpc_advt_q *table)
 {
-   struct sdpc_advt *advt;
+   struct sdpc_advt *advt, *tmp;
/*
 * drain the table of any objects
 */
-   while ((advt = sdp_advt_q_get(table)))
+   list_for_each_entry_safe(advt, tmp, &table->head, list)
sdp_advt_destroy(advt);
 }
 
Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_advt.h
===
--- linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_advt.h   
(revision 2900)
+++ linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_advt.h   
(working copy)
@@ -36,6 +36,8 @@
 #ifndef _SDP_ADVT_H
 #define _SDP_ADVT_H
 
+#include 
+
 #include "sdp_queue.h"
 
 /*
@@ -47,8 +49,7 @@
  * SDP read/write advertisments
  */
 struct sdpc_advt {
-   struct sdpc_advt   *next;  /* next structure in table */
-   struct sdpc_advt   *prev;  /* previous structure in table */
+   struct list_head list;
u32 type; /* element type. (for generic queue) */
struct sdpc_advt_q *table; /* table to which this object belongs */
void (*release)(struct sdpc_advt *advt); /* release the object */
@@ -67,7 +68,7 @@ struct sdpc_advt {
  * table for holding SDP advertisments.
  */
 struct sdpc_advt_q {
-   struct sdpc_advt *head; /* double linked list of advertisments */
+   struct list_head head; /* double linked list of advertisments */
s32 size;   /* current number of advertisments in table */
 };
 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] IBM eHCA Device Driver for gen2 IB stack

[Tom Duffy]

On 7/22/05, Matt L. Leininger <[EMAIL PROTECTED]> wrote:
>How about including this driver into the OpenIB svn tree rather than
> having it as a separate SF project.

They will need to dual license the code for that to happen -- they
need GPL too, not just BSD.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] IBM eHCA Device Driver for gen2 IB stack

[Tom Duffy]

On 7/22/05, IBMEHCA DD <[EMAIL PROTECTED]> wrote:
>  
> Hi, 
> we've completed the first alpha code drop of the Power5 IBM eHCA Device
> Driver for the for the gen2 openib.org stack. 
> We're running IPoIB and ibv userspace programs successfully with this code
> in our lab setup. 
>  
> The source files can be downloaded from 
> https://sourceforge.net/projects/ibmehcad/ 
> ehca2_0011e 

Please use C comment style.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] 2.6.12 Kernel OpenIB support

[Tom Duffy]

On Fri, 2005-07-15 at 13:48 -0700, Roland Dreier wrote:
> I'm not sure what the right solution is yet.  Long term I guess
> sockaddr_ll should grow.  I think that right now the address is being
> cut off -- so arping.c can probably be fixed by replacing all uses of
> foo.sll_halen with min(foo.sll_halen, sizeof foo.sll_addr).

Filed bug and submitted patch (for Fedora anyways):

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163383

-tduffy

diff -urp iputils/arping.c iputils.tom/arping.c
--- iputils/arping.c2005-07-15 13:51:15.533632784 -0700
+++ iputils.tom/arping.c2005-07-15 13:50:47.967823000 -0700
@@ -59,6 +59,8 @@ int received = 0, brd_recv, req_recv;
 #define MS_TDIFF(tv1,tv2) ( ((tv1).tv_sec-(tv2).tv_sec)*1000 + \
   ((tv1).tv_usec-(tv2).tv_usec)/1000 )
 
+#define min(x,y) ((x)<(y) ? (x) : (y))
+
 void usage(void)
 {
fprintf(stderr,
@@ -476,7 +478,7 @@ main(int argc, char **argv)
}
 
he = me;
-   memset(he.sll_addr, -1, he.sll_halen);
+   memset(he.sll_addr, -1, min(he.sll_halen, sizeof he.sll_addr));
 
if (!quiet) {
printf("ARPING %s ", inet_ntoa(dst));

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [ANNOUNCE] Initial checkin of SRP initiator

[Tom Duffy]

On Thu, 2005-07-14 at 18:10 -0700, Roland Dreier wrote:
> Tom> svn propdel svn:executable ib_srp.[ch]
> Tom> please.
> 
> Weird:
> 
> svn proplist 
> https://openib.org/svn/gen2/trunk/src/linux-kernel/infiniband/ulp/srp/ib_srp.{c,h}
> Properties on 
> 'https://openib.org/svn/gen2/trunk/src/linux-kernel/infiniband/ulp/srp/ib_srp.c':
>   svn:keywords
> Properties on 
> 'https://openib.org/svn/gen2/trunk/src/linux-kernel/infiniband/ulp/srp/ib_srp.h':
>   svn:keywords

Huh, I wonder why they were executable in my tree.  Never mind.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] 2.6.12 Kernel OpenIB support

[Tom Duffy]

On Fri, 2005-07-15 at 10:38 -0700, Roland Dreier wrote:
> Tom> Hrm, my arping on Fedora Core 4 now does real bad stuff:
> 
> Is it allocating a buffer as big as an ethernet address and then
> trying to put a 20-byte IPoIB address in it?

It seems to be happening at line 479 of arping.c:

memset(he.sll_addr, -1, he.sll_halen);

where he.sll_addr is 8 big, he.sll_halen is 20

So, yeah.

BTW, FC4 compiles with -Wp,-D_FORTIFY_SOURCE=2 so it is now catching it.

Should struct sockaddr_ll be modified in include/linux/if_packet.h to
accommodate larger addresses?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [ANNOUNCE] Initial checkin of SRP initiator

[Tom Duffy]

On Fri, 2005-07-08 at 22:13 -0700, Roland Dreier wrote:
> I just checked in a first version of a SCSI RDMA Protocol (SRP)
> initiator under infiniband/ulp/srp.

svn propdel svn:executable ib_srp.[ch]

please.

Also, I noticed a couple "if (0)" in ib_srp.c.  Do you plan to make a
debug level value or just delete these?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] SDP: use linux/list.h for hca port list

[Tom Duffy]

This patch changes the NULL terminated port list in the sdp hca object
to a Linux list_head.  It also removes the sdev_hca *next member from
the sdev_hca struct as this is never used, AFAICT.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- drivers/infiniband/ulp/sdp/sdp_conn.c   (revision 2861)
+++ drivers/infiniband/ulp/sdp/sdp_conn.c   (working copy)
@@ -994,10 +974,10 @@ int sdp_conn_alloc_ib(struct sdp_sock *c
 {
struct ib_qp_init_attr *init_attr;
struct ib_qp_attr *qp_attr;
-   struct sdev_hca_port  *port = NULL;
-   struct sdev_hca   *hca = NULL;
+   struct sdev_hca_port  *port;
+   struct sdev_hca   *hca;
intattr_mask = 0;
-   intresult;
+   intresult = 0;
 
/*
 * look up correct HCA and port
@@ -1006,11 +986,13 @@ int sdp_conn_alloc_ib(struct sdp_sock *c
if (!hca)
return -ERANGE;
 
-   for (port = hca->port_list; port; port = port->next)
-   if (hw_port == port->index)
+   list_for_each_entry(port, &hca->port_list, list)
+   if (hw_port == port->index) {
+   result = 1;
break;
+   }
 
-   if (!port)
+   if (!result)
return -ERANGE;
/*
 * allocate creation parameters
@@ -1740,14 +1722,14 @@ int sdp_proc_dump_device(char *buffer, i
 static void sdp_device_init_one(struct ib_device *device)
 {
struct ib_fmr_pool_param fmr_param_s;
-   struct sdev_hca_port *port;
+   struct sdev_hca_port *port, *tmp;
struct sdev_hca *hca;
int result;
int port_count;
/*
 * allocate per-HCA structure
 */
-   hca = kmalloc(sizeof(struct sdev_hca), GFP_KERNEL);
+   hca = kmalloc(sizeof *hca, GFP_KERNEL);
if (!hca) {
sdp_warn("Error allocating HCA <%s> memory.", device->name);
return;
@@ -1755,12 +1737,10 @@ static void sdp_device_init_one(struct i
/*
 * init and insert into list.
 */
-   memset(hca, 0, sizeof(struct sdev_hca));
+   memset(hca, 0, sizeof *hca);
 
-   hca->fmr_pool = NULL;
-   hca->mem_h= NULL;
-   hca->pd   = NULL;
-   hca->ca   = device;
+   hca->ca = device;
+   INIT_LIST_HEAD(&hca->port_list);
/*
 * protection domain
 */
@@ -1798,17 +1778,15 @@ static void sdp_device_init_one(struct i
 * create SDP memory pool
 */
hca->fmr_pool = ib_create_fmr_pool(hca->pd, &fmr_param_s);
-   if (IS_ERR(hca->fmr_pool)) {
-   sdp_warn("Warning, could not creating HCA <%s> FMR pool <%ld>",
+   if (IS_ERR(hca->fmr_pool))
+   sdp_warn("Warning, could not create HCA <%s> FMR pool <%ld>",
 device->name, PTR_ERR(hca->fmr_pool));
-   }
+
/*
 * port allocation
 */
-   for (port_count = 0; 
-port_count < device->phys_port_cnt;
-port_count++) {
-   port = kmalloc(sizeof(struct sdev_hca_port), GFP_KERNEL);
+   for (port_count = 0; port_count < device->phys_port_cnt; port_count++) {
+   port = kmalloc(sizeof *port, GFP_KERNEL);
if (!port) {
sdp_warn("Error allocating HCA <%s> port <%d:%d>",
 device->name, port_count,
@@ -1817,11 +1795,10 @@ static void sdp_device_init_one(struct i
goto error;
}
 
-   memset(port, 0, sizeof(struct sdev_hca_port));
+   memset(port, 0, sizeof *port);
 
-   port->index= port_count + 1;
-   port->next = hca->port_list;
-   hca->port_list = port;
+   port->index = port_count + 1;
+   list_add(&port->list, &hca->port_list);
 
result = ib_query_gid(hca->ca, 
  port->index, 
@@ -1840,11 +1817,8 @@ static void sdp_device_init_one(struct i
return;
 
 error:
-   while (hca->port_list) {
-   port = hca->port_list;
-   hca->port_list = port->next;
-   port->next = NULL;
-
+   list_for_each_entry_safe(port, tmp, &hca->port_list, list) {
+   list_del(&port->list);
kfree(port);
}
 
@@ -1865,7 +1839,7 @@ error:
  */
 static void sdp_device_remove_one(struct ib_device *device)
 {
-   struct sdev_hca_port *port;
+   struct sdev_hca_port *port, *tmp;
struct sdev_hca *hca;
 

[openib-general] [PATCH] SDP: use linux/list.h for binds

[Tom Duffy]

This patch replaces the null terminated linked list for connections
bound to a port and instead uses the list.h library from core Linux.

I have tested this on a few machines doing several ttcp's at once, but
please inspect to verify correctness.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   (revision 2861)
+++ linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   (working copy)
@@ -392,8 +392,8 @@ int sdp_inet_port_get(struct sdp_sock *c
 * simple linked list of sockets ordered on local port number.
 */
if (port > 0) {
-   for (look = dev_root_s.bind_list, port_ok = 1;
-look; look = look->bind_next) {
+   port_ok = 1;
+   list_for_each_entry(look, &dev_root_s.bind_list, bind_next) {
srch = sk_sdp(look);
/*
 * 1) same port
@@ -451,16 +451,19 @@ int sdp_inet_port_get(struct sdp_sock *c
 
for (counter = (top_port - low_port) + 1; counter > 0;
 counter--) {
+   int found = 0;
rover++;
if (rover < low_port || rover > top_port)
rover = low_port;
 
-   for (look = dev_root_s.bind_list;
-look && look->src_port != port;
-look = look->bind_next)
-   do {} while(0); /* pass */
+   list_for_each_entry(look, &dev_root_s.bind_list,
+   bind_next)
+   if (look->src_port == port) {
+   found = 1;
+   break;
+   }
 
-   if (!look) {
+   if (!found) {
port = rover;
break;
}
@@ -474,14 +477,9 @@ int sdp_inet_port_get(struct sdp_sock *c
 
conn->src_port = port;
/*
-* insert into listening list.
+* insert into bind list.
 */
-   conn->bind_next = dev_root_s.bind_list;
-   dev_root_s.bind_list = conn;
-   conn->bind_p_next = &dev_root_s.bind_list;
-
-   if (conn->bind_next)
-   conn->bind_next->bind_p_next = &conn->bind_next;
+   list_add(&conn->bind_next, &dev_root_s.bind_list);
 
result = 0;
 done:
@@ -496,25 +494,14 @@ int sdp_inet_port_put(struct sdp_sock *c
 {
unsigned long flags;
 
-   if (!conn->bind_p_next)
+   if (list_empty(&dev_root_s.bind_list))
return -EADDRNOTAVAIL;
-   /*
-* lock table
-*/
-   spin_lock_irqsave(&dev_root_s.bind_lock, flags);
-   /*
-* remove from bind list.
-*/
-   if (conn->bind_next)
-   conn->bind_next->bind_p_next = conn->bind_p_next;
-
-   *(conn->bind_p_next) = conn->bind_next;
 
-   conn->bind_p_next = NULL;
-   conn->bind_next = NULL;
+   spin_lock_irqsave(&dev_root_s.bind_lock, flags);
+   list_del(&conn->bind_next);
conn->src_port = 0;
-
spin_unlock_irqrestore(&dev_root_s.bind_lock, flags);
+
return 0;
 }
 
@@ -530,18 +517,11 @@ void sdp_inet_port_inherit(struct sdp_so
 */
spin_lock_irqsave(&dev_root_s.bind_lock, flags);
 
-   BUG_ON(child->bind_p_next);
BUG_ON(child->src_port != parent->src_port);
/*
-* insert into listening list.
+* insert into bind list.
 */
-   child->bind_next = parent->bind_next;
-   parent->bind_next = child;
-   child->bind_p_next = &parent->bind_next;
-
-   if (child->bind_next)
-   child->bind_next->bind_p_next = &child->bind_next;
-
+   list_add(&child->bind_next, &dev_root_s.bind_list);
spin_unlock_irqrestore(&dev_root_s.bind_lock, flags);
 }
 
@@ -1917,7 +1897,7 @@ int sdp_conn_table_init(int proto_family
 * list
 */
INIT_LIST_HEAD(&dev_root_s.listen_list);
-   dev_root_s.bind_list = NULL;
+   INIT_LIST_HEAD(&dev_root_s.bind_list);
 
spin_lock_init(&dev_root_s.sock_lock);
spin_lock_init(&dev_root_s.bind_lock);
Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h
===
--- linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h   (revision 2861)
+++ linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h   (

Re: [openib-general] 2.6.12 Kernel OpenIB support

[Tom Duffy]

On Wed, 2005-07-13 at 15:32 -0400, William Jordan wrote:
> I upgraded my iputils (from the Fedora Core 4 source RPM,
> iputils-20020927-22). The new version doesn't work. But, instead of
> arping returning -1 responses, it reports 0 responses, so at least
> ifup works without complaining about the address already being in use.
> However, if the address really is in use, it doesn't catch it.

Hrm, my arping on Fedora Core 4 now does real bad stuff:

Bringing up interface ib0:  *** buffer overflow detected ***: arping terminated
=== Backtrace: =
/lib64/libc.so.6(__chk_fail+0x2f)[0x2acc923f]
arping(main+0x48f)[0x67df]
/lib64/libc.so.6(__libc_start_main+0xdc)[0x2ac084cc]
arping[0x59b9]
=== Memory map: 
3b77c0-3b77c1a000 r-xp  08:02 168058 
/lib64/ld-2.3.5.so
3b77d19000-3b77d1a000 r--p 00019000 08:02 168058 
/lib64/ld-2.3.5.so
3b77d1a000-3b77d1b000 rw-p 0001a000 08:02 168058 
/lib64/ld-2.3.5.so
2aaab000-2aaac000 rw-p 2aaab000 00:00 0
2aad6000-2aad7000 rw-p 2aad6000 00:00 0
2aad7000-2aae8000 r-xp  08:02 684
/lib64/libresolv-2.3.5.so
2aae8000-2abe8000 ---p 00011000 08:02 684
/lib64/libresolv-2.3.5.so
2abe8000-2abe9000 r--p 00011000 08:02 684
/lib64/libresolv-2.3.5.so
2abe9000-2abea000 rw-p 00012000 08:02 684
/lib64/libresolv-2.3.5.so
2abea000-2abec000 rw-p 2abea000 00:00 0
2abec000-2ad1a000 r-xp  08:02 168062 
/lib64/libc-2.3.5.so
2ad1a000-2ae19000 ---p 0012e000 08:02 168062 
/lib64/libc-2.3.5.so
2ae19000-2ae1d000 r--p 0012d000 08:02 168062 
/lib64/libc-2.3.5.so
2ae1d000-2ae1f000 rw-p 00131000 08:02 168062 
/lib64/libc-2.3.5.so
2ae1f000-2ae25000 rw-p 2ae1f000 00:00 0
2ae25000-2ae32000 r-xp  08:02 168371 
/lib64/libgcc_s-4.0.0-20050520.so.1
2ae32000-2af31000 ---p d000 08:02 168371 
/lib64/libgcc_s-4.0.0-20050520.so.1
2af31000-2af32000 rw-p c000 08:02 168371 
/lib64/libgcc_s-4.0.0-20050520.so.1
4000-8000 r-xp  08:02 16803329   
/sbin/arping
55657000-55658000 rw-p 3000 08:02 16803329   
/sbin/arping
55658000-55679000 rw-p 55658000 00:00 0  [heap]
7fbb6000-7fbcc000 rw-p 7fbb6000 00:00 0  
[stack]ff60-ffe0 ---p  00:00 0  
[vdso]




signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] kDAPL: ready for gen2/trunk/ inclusion?

[Tom Duffy]

On Wed, 2005-07-13 at 16:19 +0200, Christoph Hellwig wrote:
> After re-evaluting things: none, just don't merged it.

into gen2/trunk?

> We want an RDMA layer in the kernel, and it looks like Catalin's
> extension of the IB layer to cover iWarp aswell is the better choice,
> in combination of taking some utility routines from kdapl and adjust
> them to work directly ontop of that.

I agree Caitlin's proposal looks good.  I appreciate concrete examples
of how to move forward.  Let's then create a branch of trunk to start
the merge work.

What routines from kDAPL are you happy with?  What is worth keeping?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 3/27] Add MAD helper functions

[Tom Duffy]

On Mon, 2005-07-11 at 22:38 +0400, Alexey Dobriyan wrote:
> $ make allmodconfig >/dev/null
> $ make C=2 CHECK="sparse -Wbitwise" drivers/infiniband/ 2>&1 | tee 
> ../W_infiniband
>   [snip]
> $ grep -c "warning: " ../W_infiniband
> 430

These seem to be mostly coming from cpu_to_be*() and be*_to_cpu().  Is
there a good rule of thumb for fixing these warnings?

Thanks,

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] kDAPL: ready for gen2/trunk/ inclusion?

[Tom Duffy]

Now that the majority of the cleanup is complete, I think kDAPL is ready
to be moved to gen2/trunk.

This would also be a good time to get NFSoRDMA ported to kDAPL as the
API is unlikely to change too much in the future.

What do others think?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH 26/29v2] Add kernel portion of user CM implementation

[Tom Duffy]

[ un-cc lkml ]

On Mon, 2005-07-11 at 19:16 -0400, Hal Rosenstock wrote:
> > [ also, in future patch bombs, could you please set the references
> > header so that the message thread properly, thanks ]
> 
> How do I do this ?

Attached is the script I use to sent patchbombs.  Thanks to Greg Kroah
and Roland Dreier.

-tduffy

#!/usr/bin/perl -w

# horrible hack of a script to send off a large number of email messages,
# one after each other, all chained together.  This is useful for large
# numbers of patches.
#
# Use at your own risk
#
# greg kroah-hartman Jan 8, 2002
# <[EMAIL PROTECTED]>
#
# modifications by Roland Dreier <[EMAIL PROTECTED]> June 30, 2004 
# changes by Tom Duffy <[EMAIL PROTECTED]> July 15, 2004
#   - include references header for better threading
#
# Released under the artistic license.
#

#
# modify these options each time you run the script
#
$to = 'openib-general@openib.org';
#$to = '[EMAIL PROTECTED]';
#$to = '[EMAIL PROTECTED]';

# If you want to chain the first post, fill this in
$initial_reply_to = '';

# a list of patches to send out
@files = (
['0-message','Use Linux standard linked lists'],
['dat1','convert the cr list to linux native'],
['dat2','convert the lmr list to linux native'],
['dat3','convert the rmr list to linux native'],
['dat4','convert the pz list to linux native'],
['dat5','convert the evd list to linux native'],
['dat6','convert the psp and rsp lists to linux native'],
['dat7','convert the srq list to linux native'],
['dat8','convert the hcas ia list to linux native'],
['dat9','remove all vestiges of dapls linked list implementation'],
);

# count to start subject line [PATCH][n/N] part from
$initial_count = 0;

# Put your name and address here
$from = 'Tom Duffy <[EMAIL PROTECTED]>';

# Don't need to change anything below here...

use Mail::Sendmail;

# we make a "fake" message id by taking the current number
# of seconds since the beginning of Unix time and tacking on
# a random number to the end, in case we are called quicker than
# 1 second since the last time we were called.
sub make_message_id
{
my $date = `date "+\%s"`;
chomp($date);
my $pseudo_rand = int (rand(4200));
$message_id = "<[EMAIL PROTECTED]>";
print "new message id = $message_id\n";
}

sub send_message
{
%mail = (   To  =>  $to,
From=>  $from,
Subject =>  $subject,
Message =>  $message,
'In-Reply-To'   =>  $reply_to,
'References'=>  $references,
'Message-ID'=>  $message_id,
'X-Mailer'  =>  "Evolution 2.2.2",
'Content-Transfer-Encoding' => "8bit",
);

$mail{smtp} = 'localhost';

sendmail(%mail) or die $Mail::Sendmail::error;

print "OK. Log says:\n", $Mail::Sendmail::log;
print "\n\n"
}


$reply_to = $initial_reply_to;
$references = $reply_to;
make_message_id();
$count = $initial_count;
$tot = $#files + $initial_count;

foreach $t (@files) {
$F = $$t[0];
open F or die "can't open file $$t[0]";
undef $/;
$message = ; # slurp the whole file in
close F;
$/ = "\n";
$subject = "[PATCH $count/$tot] kDAPL: " . $$t[1];
send_message();

#   sleep 10;

# set up for the next message
$reply_to = $message_id;
$references = $references . " " . $message_id;
make_message_id();
++$count;
}

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Proposal for mapping DAT_RETURN values to ERRNO values

[Tom Duffy]

On Thu, 2005-06-30 at 10:44 -0400, James Lentini wrote:
> I'm going to be on vacation next week. I'll make the conversion when I 
> return on the 11th. If anyone else has comments, please send them by 
> July 10th.

Do you have a patch that implements the errno changes?  Are you going to
add in a new OUT dat_return *int parameter for kdat.h compat?  If so,
please make this a CONFIG_DAT_COMPAT.

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH 26/29v2] Add kernel portion of user CM implementation

[Tom Duffy]

On Mon, 2005-07-11 at 16:59 -0400, Hal Rosenstock wrote:
> Add kernel portion of user CM implementation

Hal, does this compile?  As it doesn't seem to include the patch I sent
to openib-general changing class_simple to class, I don't think it
should work on 2.6.13-rc.

[ also, in future patch bombs, could you please set the references
header so that the message thread properly, thanks ]

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.13-rc2-openib/drivers/infiniband/core/ucm.c
===
--- linux-2.6.13-rc2-openib/drivers/infiniband/core/ucm.c   (revision 2832)
+++ linux-2.6.13-rc2-openib/drivers/infiniband/core/ucm.c   (working copy)
@@ -1339,7 +1339,7 @@ static struct file_operations ib_ucm_fop
 };
 
 
-static struct class_simple *ib_ucm_class;
+static struct class *ib_ucm_class;
 static struct cdev   ib_ucm_cdev;
 
 static int __init ib_ucm_init(void)
@@ -1360,17 +1360,14 @@ static int __init ib_ucm_init(void)
goto err_cdev;
}
 
-   ib_ucm_class = class_simple_create(THIS_MODULE, "infiniband_cm");
+   ib_ucm_class = class_create(THIS_MODULE, "infiniband_cm");
if (IS_ERR(ib_ucm_class)) {
result = PTR_ERR(ib_ucm_class);
printk(KERN_ERR "UCM: Error <%d> creating class\n", result);
goto err_class;
}
 
-   class_simple_device_add(ib_ucm_class,
-   IB_UCM_DEV,
-   NULL,
-   "ucm");
+   class_device_create(ib_ucm_class, IB_UCM_DEV, NULL, "ucm");

idr_init(&ctx_id_table);
init_MUTEX(&ctx_id_mutex);
@@ -1386,8 +1383,8 @@ err_chr:
 
 static void __exit ib_ucm_cleanup(void)
 {
-   class_simple_device_remove(IB_UCM_DEV);
-   class_simple_destroy(ib_ucm_class);
+   class_device_destroy(ib_ucm_class, IB_UCM_DEV);
+   class_destroy(ib_ucm_class);
cdev_del(&ib_ucm_cdev);
unregister_chrdev_region(IB_UCM_DEV, 1);
 }

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: Gen2 build/update process

[Tom Duffy]

On Mon, 2005-07-11 at 22:57 +0300, Michael S. Tsirkin wrote:
> Sure, I have such scripts.
> Where's the good place to put them?

wiki

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Gen2 build/update process

[Tom Duffy]

On Mon, 2005-07-11 at 15:46 -0400, Sayantan Sur wrote:
> I am building the user level support. Currently, that requires manual
> autogen, config, make, make install in lots of subdirectories. I was
> wondering if someone has a script to automate the build process. This
> will also ensure that new adopters don't get any dependency wrong.

ideally, these will be packaged as rpms, deps, or ebuilds and included
with your favorite distribution.

btw, if you do learn a recipe that works for you, please update the wiki
to share your experiences.

Thanks,

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Gen2 build/update process

[Tom Duffy]

Sayantan Sur wrote:


Hi,

Is there any plan to have any formal install procedure instead of the
current process of going into subdirectories and building?

If someone has build scripts to share, that'll be real nice.
 



What are you trying to build?  Kernel build should not need to do this.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] OpenIB DAT_Return merging and kdat.h

[Tom Duffy]

Caitlin Bestler wrote:


Given both of those factors, I believe it makes more sense
to preserve the full DAT_RETURN value (including detail error
data) as an out parameter. kdat.h could then simply turn it 
into the functional return for compatability clients and there

would be no loss of information. Either that or we could work
out on a case by case basis how kdat.h would be able to restore
the original error value. This may be possible with data in
the struct, since multiple outstanding errors on a single 
object would not seem to be likely (or perhaps more appropriately

worthy of providing detailed error diagnostics for, since it
probably represents a totally hosed application).
 



If we decide to add in a compatibility layer with a dat_return 
*parameter, or some other mechanism, this should be a compile time option.


-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: [PATCH 3/27] Add MAD helper functions

[Tom Duffy]

Alexey Dobriyan wrote:


unsigned int __nocast gfp_mask, please. 430 or so infiniband sparse warnings
is not a reason to add more.
 

Can you please elaborate on the sparse warnings that you are seeing 
throughout the rest of infiniband?


Thanks,

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [oops] recent opensm crash

[Tom Duffy]

On 01 Jul 2005 13:24:37 -0400, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> I found one problem associated with this and just checked in a patch.
> I'm not sure whether there is another one behind this or not. Any
> reliable way to recreate this ?

No, it happened after being up for weeks one time when I was bringing
an interface down and back up again.  I will report if I get another
crash later.

Thanks,

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH] kDAPL: remove redundant kfree checks

[Tom Duffy]

kfree() already checks for NULL.  No need to do it twice.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-kernel/dat-provider/dapl_cookie.c
===
--- linux-kernel/dat-provider/dapl_cookie.c (revision 2761)
+++ linux-kernel/dat-provider/dapl_cookie.c (working copy)
@@ -157,8 +157,7 @@ u32 dapl_cb_create(struct dapl_cookie_bu
  */
 void dapl_cb_free(struct dapl_cookie_buffer *buffer)
 {
-   if (NULL != buffer->pool) 
-   kfree(buffer->pool);
+   kfree(buffer->pool);
 }
 
 /*
Index: linux-kernel/dat-provider/dapl_ring_buffer_util.c
===
--- linux-kernel/dat-provider/dapl_ring_buffer_util.c   (revision 2761)
+++ linux-kernel/dat-provider/dapl_ring_buffer_util.c   (working copy)
@@ -149,7 +149,7 @@ bail:
  */
 void dapl_rbuf_destroy(struct dapl_ring_buffer *rbuf)
 {
-   if ((NULL == rbuf) || (NULL == rbuf->base))
+   if (!rbuf)
return;
 
kfree(rbuf->base);
Index: linux-kernel/dat-provider/dapl_ep.c
===
--- linux-kernel/dat-provider/dapl_ep.c (revision 2761)
+++ linux-kernel/dat-provider/dapl_ep.c (working copy)
@@ -47,11 +47,9 @@ static void dapl_ep_dealloc(struct dapl_
dapl_cb_free(&ep->req_buffer);
dapl_cb_free(&ep->recv_buffer);
 
-   if (ep->recv_iov)
-   kfree(ep->recv_iov);
+   kfree(ep->recv_iov);
 
-   if (ep->send_iov)
-   kfree(ep->send_iov);
+   kfree(ep->send_iov);
 
kfree(ep);
 }
Index: linux-kernel/dat-provider/dapl_evd.c
===
--- linux-kernel/dat-provider/dapl_evd.c(revision 2761)
+++ linux-kernel/dat-provider/dapl_evd.c(working copy)
@@ -265,9 +265,7 @@ static u32 dapl_evd_dealloc(struct dapl_
dapl_rbuf_destroy(&evd->free_event_queue);
dapl_rbuf_destroy(&evd->pending_event_queue);
 
-   if (evd->events) {
-   kfree(evd->events);
-   }
+   kfree(evd->events);
 
kfree(evd);
 
Index: linux-kernel/dat/api.c
===
--- linux-kernel/dat/api.c  (revision 2761)
+++ linux-kernel/dat/api.c  (working copy)
@@ -524,8 +524,7 @@ out_unlock:
spin_unlock_irqrestore(&dat_provider_list_lock, flags);
 out:
if (status != DAT_SUCCESS)
-   if (entry)
-   kfree(entry);
+   kfree(entry);
return status;
 }
 EXPORT_SYMBOL(dat_registry_add_provider);

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [PATCH] user_mad: In send_handler, only return header on timeout

[Tom Duffy]

Hal,

Would you mind versioning your patches?  That way I don't think you are
just resending the same email.

Thanks,

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCHv2] SDP: use linux/list.h for listen conns

[Tom Duffy]

This patch changes sdp to use Linux native lists for the listen conn
list.  The first version had a bug where if the listen list was empty,
the lookup would return a bogus conn.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   (revision 2763)
+++ linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   (working copy)
@@ -291,21 +291,11 @@ int sdp_inet_listen_start(struct sdp_soc
conn->state  = SDP_CONN_ST_LISTEN;
conn->accept_next = conn;
conn->accept_prev = conn;
-   /*
-* table lock
-*/
-   spin_lock_irqsave(&dev_root_s.listen_lock, flags);
-   /*
-* insert into listening list.
-*/
-   conn->lstn_next = dev_root_s.listen_list;
-   dev_root_s.listen_list = conn;
-   conn->lstn_p_next = &dev_root_s.listen_list;
-
-   if (conn->lstn_next)
-   conn->lstn_next->lstn_p_next = &conn->lstn_next;
 
+   spin_lock_irqsave(&dev_root_s.listen_lock, flags);
+   list_add(&conn->lstn_next, &dev_root_s.listen_list);
spin_unlock_irqrestore(&dev_root_s.listen_lock, flags);
+
return 0;
 }
 
@@ -323,22 +313,11 @@ int sdp_inet_listen_stop(struct sdp_sock
}
 
listen_conn->state  = SDP_CONN_ST_CLOSED;
-   /*
-* table lock
-*/
-   spin_lock_irqsave(&dev_root_s.listen_lock, flags);
-   /*
-* remove from listening list.
-*/
-   if (listen_conn->lstn_next)
-   listen_conn->lstn_next->lstn_p_next = listen_conn->lstn_p_next;
-
-   *(listen_conn->lstn_p_next) = listen_conn->lstn_next;
-
-   listen_conn->lstn_p_next = NULL;
-   listen_conn->lstn_next = NULL;
 
+   spin_lock_irqsave(&dev_root_s.listen_lock, flags);
+   list_del(&listen_conn->lstn_next);
spin_unlock_irqrestore(&dev_root_s.listen_lock, flags);
+
/*
 * reject and delete all pending connections
 */
@@ -367,7 +346,7 @@ int sdp_inet_listen_stop(struct sdp_sock
  */
 struct sdp_sock *sdp_inet_listen_lookup(u32 addr, u16 port)
 {
-   struct sdp_sock *conn;
+   struct sdp_sock *conn, *ret = NULL;
unsigned long flags;
/*
 * table lock
@@ -376,15 +355,16 @@ struct sdp_sock *sdp_inet_listen_lookup(
/*
 * first find a listening connection
 */
-   for (conn = dev_root_s.listen_list; conn; conn = conn->lstn_next)
+   list_for_each_entry(conn, &dev_root_s.listen_list, lstn_next)
if (port == conn->src_port &&
(INADDR_ANY == conn->src_addr || addr == conn->src_addr)) {
sdp_conn_hold(conn);
+   ret = conn;
break;
}
 
spin_unlock_irqrestore(&dev_root_s.listen_lock, flags);
-   return conn;
+   return ret;
 }
 
 /*
@@ -1936,7 +1916,7 @@ int sdp_conn_table_init(int proto_family
/*
 * list
 */
-   dev_root_s.listen_list = NULL;
+   INIT_LIST_HEAD(&dev_root_s.listen_list);
dev_root_s.bind_list = NULL;
 
spin_lock_init(&dev_root_s.sock_lock);
Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h
===
--- linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h   (revision 2763)
+++ linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h   (working copy)
@@ -36,6 +36,8 @@
 #ifndef _SDP_CONN_H
 #define _SDP_CONN_H
 
+#include 
+
 #include "sdp_advt.h"
 #include "sdp_iocb.h"
 #include "sdp_dev.h"
@@ -336,8 +338,7 @@ struct sdp_sock {
/*
 * table managment
 */
-   struct sdp_sock *lstn_next;/* next conn in the chain */
-   struct sdp_sock **lstn_p_next; /* previous next conn in the chain */
+   struct list_head lstn_next;
 
struct sdp_sock *bind_next;/* next conn in the chain */
struct sdp_sock **bind_p_next; /* previous next conn in the chain */
Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_dev.h
===
--- linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_dev.h(revision 2763)
+++ linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_dev.h(working copy)
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 /*
  * sdp types
@@ -186,7 +187,7 @@ struct sdev_root {
/*
 * connection managment
 */
-   struct sdp_sock *listen_list;   /* list of listening connections */
+   struct list_head listen_list;
struct sdp_sock *bind_list; /* connections bound to a port. */
/

[openib-general] [oops] recent opensm crash

[Tom Duffy]

#0  stack_dump () at src/stack.c:72
72  if (!__builtin_frame_address(2))
(gdb) bt
#0  stack_dump () at src/stack.c:72
#1  0x2acbd1a6 in handler (x=11) at src/stack.c:151
#2  
#3  __osm_sm_mad_ctrl_send_err_cb (bind_context=0x550dd8, p_madw=0x567820)
at osm_sm_mad_ctrl.c:832
#4  0x2aaaeeed in osm_vendor_send (h_bind=0x586920, p_madw=0x567820,
resp_expected=1) at osm_vendor_ibumad.c:889
#5  0x0042ef72 in __osm_vl15_poller (p_ptr=0x552620) at osm_madw.h:933
#6  0x2adc911e in __cl_thread_wrapper (arg=0x0) at cl_thread.c:61
#7  0x0036d28060aa in start_thread () from /lib64/tls/libpthread.so.0
#8  0x0036d19c53d3 in clone () from /lib64/tls/libc.so.6
#9  0x in ?? ()

I was bringing up and down an node when this happened.

Attached are the last 500 lines from osm.log.

-tduffy
base_ver0x1
mgmt_class..0x81
class_ver...0x1
method..0x1 (SubnGet)
status..0x0
hop_ptr.0x0
hop_count...0x1
trans_id0x16c6a
attr_id.0x16 (P_KeyTable)
resv0x0
attr_mod0x5
m_key...0x
dr_slid.0x
dr_dlid.0x

Initial path: [0][1]
Return path:  [0][0]
Reserved: [0][0][0][0][0][0][0]

00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 
00

00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 
00

00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 
00

00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 
00

Jun 30 14:59:00 [43806960] -> osm_vendor_send: [
Jun 30 14:59:00 [43005960] -> PortInfo dump:
port number.0x8
node_guid...0x0006170d
port_guid...0x0006170d
m_key...0x
subnet_prefix...0x
base_lid0x0
master_sm_base_lid..0x0
capability_mask.0x0
diag_code...0x0
m_key_lease_period..0x0
local_port_num..0x7
link_width_enabled..0x3
link_width_supported0x3
link_width_active...0x0
link_speed_supported0x1
port_state..DOWN
state_info2.0x22
m_key_protect_bits..0x0
lmc.0x0
link_speed..0x11
mtu_smsl0x10
vl_cap..0x40
vl_high_limit...0x0
vl_arb_high_cap.0x20
vl_arb_low_cap..0x20
mtu_cap.0x5
vl_stall_life...0x8
vl_enforce..0x10
m_key_violations0x0
p_key_violations0x0
q_key_violations0x0
guid_cap0x0
subnet_timeout..0x0
resp_time_value.0x0
error_threshold.0xFF
Jun 30 14:59:00 [43005960] -> Capabilities Mask:
Jun 30 14:59:00 [43005960] -> __osm_pi_rcv_process_switch_port: [
Jun 30 14:59:00 [43005960] -> __osm_pi_rcv_process_switch_port: ]
Jun 30 14:59:00 [43005960] -> __osm_pi_rcv_get_pkey_slvl_vla_tables: [
Jun 30 14:59:00 [43005960] -> osm_physp_has_pkey: [
Jun 30 14:59:00 [43005960] -> osm_req_get: [
Jun 30 14:59:00 [43005960] -> osm_mad_pool_get: [
Jun 30 14:59:00 [43806960] -> __osm_mtl_send_callback: Completed Sending 
R

[openib-general] [PATCH] SDP: use linux/list.h for listen conns

[Tom Duffy]

This patch changes sdp to use Linux native lists for the listen conn
list.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   (revision 2763)
+++ linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   (working copy)
@@ -291,21 +291,11 @@ int sdp_inet_listen_start(struct sdp_soc
conn->state  = SDP_CONN_ST_LISTEN;
conn->accept_next = conn;
conn->accept_prev = conn;
-   /*
-* table lock
-*/
-   spin_lock_irqsave(&dev_root_s.listen_lock, flags);
-   /*
-* insert into listening list.
-*/
-   conn->lstn_next = dev_root_s.listen_list;
-   dev_root_s.listen_list = conn;
-   conn->lstn_p_next = &dev_root_s.listen_list;
-
-   if (conn->lstn_next)
-   conn->lstn_next->lstn_p_next = &conn->lstn_next;
 
+   spin_lock_irqsave(&dev_root_s.listen_lock, flags);
+   list_add(&conn->lstn_next, &dev_root_s.listen_list);
spin_unlock_irqrestore(&dev_root_s.listen_lock, flags);
+
return 0;
 }
 
@@ -323,22 +313,11 @@ int sdp_inet_listen_stop(struct sdp_sock
}
 
listen_conn->state  = SDP_CONN_ST_CLOSED;
-   /*
-* table lock
-*/
-   spin_lock_irqsave(&dev_root_s.listen_lock, flags);
-   /*
-* remove from listening list.
-*/
-   if (listen_conn->lstn_next)
-   listen_conn->lstn_next->lstn_p_next = listen_conn->lstn_p_next;
-
-   *(listen_conn->lstn_p_next) = listen_conn->lstn_next;
-
-   listen_conn->lstn_p_next = NULL;
-   listen_conn->lstn_next = NULL;
 
+   spin_lock_irqsave(&dev_root_s.listen_lock, flags);
+   list_del(&listen_conn->lstn_next);
spin_unlock_irqrestore(&dev_root_s.listen_lock, flags);
+
/*
 * reject and delete all pending connections
 */
@@ -376,7 +355,7 @@ struct sdp_sock *sdp_inet_listen_lookup(
/*
 * first find a listening connection
 */
-   for (conn = dev_root_s.listen_list; conn; conn = conn->lstn_next)
+   list_for_each_entry(conn, &dev_root_s.listen_list, lstn_next)
if (port == conn->src_port &&
(INADDR_ANY == conn->src_addr || addr == conn->src_addr)) {
sdp_conn_hold(conn);
@@ -1936,7 +1915,7 @@ int sdp_conn_table_init(int proto_family
/*
 * list
 */
-   dev_root_s.listen_list = NULL;
+   INIT_LIST_HEAD(&dev_root_s.listen_list);
dev_root_s.bind_list = NULL;
 
spin_lock_init(&dev_root_s.sock_lock);
Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h
===
--- linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h   (revision 2763)
+++ linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.h   (working copy)
@@ -36,6 +36,8 @@
 #ifndef _SDP_CONN_H
 #define _SDP_CONN_H
 
+#include 
+
 #include "sdp_advt.h"
 #include "sdp_iocb.h"
 #include "sdp_dev.h"
@@ -336,8 +338,7 @@ struct sdp_sock {
/*
 * table managment
 */
-   struct sdp_sock *lstn_next;/* next conn in the chain */
-   struct sdp_sock **lstn_p_next; /* previous next conn in the chain */
+   struct list_head lstn_next;
 
struct sdp_sock *bind_next;/* next conn in the chain */
struct sdp_sock **bind_p_next; /* previous next conn in the chain */
Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_dev.h
===
--- linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_dev.h(revision 2763)
+++ linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_dev.h(working copy)
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 /*
  * sdp types
@@ -186,7 +187,7 @@ struct sdev_root {
/*
 * connection managment
 */
-   struct sdp_sock *listen_list;   /* list of listening connections */
+   struct list_head listen_list;
struct sdp_sock *bind_list; /* connections bound to a port. */
/*
 * list locks

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] RE: [dat-discussions] comments on DAT registry in OpenIB

[Tom Duffy]

On Wed, 2005-06-29 at 20:19 -0700, Caitlin Bestler wrote:
> Source compatability for an existing Provider is *not* maintained by
> OpenIB
> kDAPL because there are fields *missing* from the Provider Info. That
> *will*
> result in a compilation error.

I have no problem with there being a header file with allows for source
compatibility.  This header would be maintained by OpenIB, but never
included in upstream.  I think James has a start of such a header called
kdat.h.  It needs a bunch more to make it follow the DAT conventions.

-tduffy



signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Proposal for mapping DAT_RETURN values to ERRNO values

[Tom Duffy]

On 6/28/05, James Lentini <[EMAIL PROTECTED]> wrote:
> 
> The attached PDF, prepared by Itamar Rabenstein of Mellanox, contains
> a proposed mapping from DAT_RETURN values to ERRNO values.

These all look very good.  Thanks Itamar for putting this doc together.

-tduffy
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] [PATCH][RESEND] SDP: update TODO to point to wiki

[Tom Duffy]

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.12-rc6-openib/drivers/infiniband/ulp/sdp/TODO
===
--- linux-2.6.12-rc6-openib/drivers/infiniband/ulp/sdp/TODO (revision 2597)
+++ linux-2.6.12-rc6-openib/drivers/infiniband/ulp/sdp/TODO (working copy)
@@ -1,58 +1,3 @@
-SDP 
+Please refer to the TODO at:
 
-  - Cosmetic cleanup as needed.
-
-  - Reduce connection state machine complexity. Specifically there exists
-redundant tracking of connection state which should be merged for
-improved readability and maintainability.
-
-  - Add full connection cleanup once Connection Manager IDLE is in place.
-
-  - Reduce code bloat.
-
-  - Enable FMRs once mthca support is provided.
-
-  - Provide real support for SO_{RCV,SND}BUF
-- internal posted buffers
-- QP WQ size
-- CQ size
-
-  - Create slow start algorithm for posted receive buffers to improve
-memory consumption in large connection count applications, especially
-for connections that are predominately sending data.
-
-  - sdp_link needs locking protection.
-
-  - sdp_link request cancellation support.
-
-  - SDP RDMA support for blocking socket operations.
-
-  - IPv6 addressing
-
-  - Alternate Path Migration (APM) support.
-
-  - Keepalive (zero byte RDMA write)
-
-  - Socket duplication (i.e. suspend)
-
-Possible Issues
-
-  - SDP address resolution requires looking at the IPoIB device's private
-data structure inorder to determine interface's SGID, Port, and PKey.
-
-  - Memory locking for AIO requires a call to do_mlock() which is not a
-kernel exported function, the method for calling the function is not
-standard.
-
-Other
-
-  - Kernel level transparent socket switch for dynamic TCP/SDP selection.
-(Possible SDP port mapper protocol from RDMAC)
-
-  - Extended Sockets API (ES-API). Initial Linux AIO based implemetation?
-
-  - New SOCK_DGRAM protocol?
-
-  - NFS over SDP.
-
-  - QP striping?
\ No newline at end of file
+https://openib.org/tiki/tiki-index.php?page=SDPTodoList

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] Re: SDP: still getting sk_alloc() panic, any ideas?

[Tom Duffy]

On Tue, 2005-06-28 at 11:19 -0700, Libor Michalek wrote:
>   Here's a patch to reorder listen_lookup() in req_handler() and a few
> other fixups, such as making a couple int return functions void.

Great, that fixes the panic.

Thanks,

-tduffy


signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general