Hal,
On Thu, 2005-02-17 at 13:12, Hal Rosenstock wrote:
> Hi Nitin,
>
> On Wed, 2005-02-16 at 17:33, Nitin Hande wrote:
> > On Wed, 2005-02-16 at 13:26, Hal Rosenstock wrote:
> > > On Wed, 2005-02-16 at 16:08, Nitin Hande wrote:
> > > > Hal,
> > [snip..]
[snip...]
> > > >
> > > >
> >
> > Bef
On Tue, Feb 22, 2005 at 01:10:21PM -0800, Tom Duffy wrote:
> On Sun, 2005-02-20 at 02:05 +0200, Michael S. Tsirkin wrote:
> > I think we also should replace __inline__ with inline everywhere.
Thanks, I've commited the change.
-Libor
> Index: sdp_queue.h
> ==
On Tue, Feb 22, 2005 at 12:14:45PM +0200, Michael S. Tsirkin wrote:
>
> sdp_inet.c, inside _sdp_inet_listen, we have:
>
> #if 0 /* BUG 2034 workaround. */
> conn->backlog_max = backlog;
> #else
> conn->backlog_max = 1024;
> #endif
>
> What gives? what wo
On Sun, Feb 20, 2005 at 03:16:40PM +0200, Michael S. Tsirkin wrote:
> Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> > And here I would have thought SDP_CONN_HOLD as a macro would have
> > bugged people more. :)
> >
> > -Libor
> >
>
> Regarding conn_hold/conn_put (macro or not):
> 1. conn_pu
On Mon, Feb 21, 2005 at 03:32:00PM +0200, Michael S. Tsirkin wrote:
> Some extern (non-static) variables did not start with sdp_ or anything
> like that. Here's a fix.
Thanks, applied and commited. I did change a few lines to keep them
under 80 columns wide.
-Libor
_
With the latest patch, most of the reject receive handling in the CM
should be in place. Currently, the handling simply involves passing
the message up to the user and transitioning the cm_id to the correct
state. Specifically:
* code 6 - invalid comm id -- Possibly indicates a remote system
This patch properly places a local cm_id into the timewait state after
receiving a stale connection reject message. It also fixes a missing
newline character at the end of the file that somehow got mangled with
my last checkin.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Index: infiniband/core
The following patch adds reject handling for reject code 4, timeout.
The update requires searching for the local cm_id based on the remote
CA GUID and remote communication ID.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Index: infiniband/core/cm.c
===
On Sun, 2005-02-20 at 02:05 +0200, Michael S. Tsirkin wrote:
> That does not seem to be the case for __sdp_inet_write_space, or for
> other stuff in sdp_proto.h, so I think these functions shall have proper names
> starting with an alphanumeric.
If functions (or structs) are static, does it make s
OK, here's the patch.
Cast u64 values to unsigned long long inside sdp_dbg_data() to get rid
of compiler warnings on 64-bit archs when building with
INFINIBAND_SDP_DEBUG_DATA turned on.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Index: infiniband/ulp/sdp/sdp_write.c
==
On Tue, Feb 22, 2005 at 02:38:00PM -0800, Roland Dreier wrote:
> Speaking of missing patches, I still see a lot of warnings from SDP on
> 64-bit archs because of "%ll" printk formats being used to print u64
> values inside of sdp_debug_data statements. Is there a patch floating
> around for this o
Speaking of missing patches, I still see a lot of warnings from SDP on
64-bit archs because of "%ll" printk formats being used to print u64
values inside of sdp_debug_data statements. Is there a patch floating
around for this or do you want me to write one?
- R.
On Tue, Feb 22, 2005 at 12:57:00PM -0800, Tom Duffy wrote:
> On Tue, 2005-02-22 at 12:20 -0800, Libor Michalek wrote:
> > Thanks Tom, I've applied and commited the patches.
>
> Did you choose not to apply these changes, or was this a simple
> oversight?
Yup, it was an oversight. I had to hand
Title: j
Opt-in Email Special Offer unsubscribe
me
SEARCH
On Mon, Feb 21, 2005 at 08:12:57PM +0200, Michael S. Tsirkin wrote:
> Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> > On Thu, Feb 17, 2005 at 04:03:59PM +0200, Michael S. Tsirkin wrote:
> > > Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> > > > Possible Issues
> > > >
> > > > - Memory lockin
On Tue, 2005-02-22 at 23:27 +0200, Michael S. Tsirkin wrote:
> To clarify: please dont replace CHECK macros, with if, rather
> we shall remove them altogether from the code.
> As Libor pointed out elsewhere, this has a nice effect of
> turning many int functions into void, documenting in a cleaner
On Sun, Feb 20, 2005 at 02:45:15PM +0200, Michael S. Tsirkin wrote:
> Hi!
> sdp_advt seems to re-implement linked list.
> Why is not the standard linked list used?
There is some redundancy between the different lists even within
the sdp code base. There are three objects, iocb, buff, and advt
wh
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: Re: Re: [PATCH][SDP][14/22] Whitespace clean up in sdp_proto.h
>
> Quoting r. Tom Duffy <[EMAIL PROTECTED]>:
> > Subject: Re: [openib-general] Re: Re: [PATCH][SDP][14/22] Whitespace clean
> > up in sdp_proto.h
> >
> > On Tue, 2005
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: [PATCH] Rename debug_level to ipoib_debug_level
>
> This renames the variable "debug_level" to "ipoib_debug_level" in the
> IPoIB module to avoid name clashes if IPoIB is built into the kernel.
> SDP has the same variable name so this fixes
Quoting r. Tom Duffy <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] Re: Re: [PATCH][SDP][14/22] Whitespace clean up
> in sdp_proto.h
>
> On Tue, 2005-02-22 at 22:32 +0200, Michael S. Tsirkin wrote:
> > Good. By the way, do you plan to keep the convention of writing
> > 0 == foo?
> >
> > I
This renames the variable "debug_level" to "ipoib_debug_level" in the
IPoIB module to avoid name clashes if IPoIB is built into the kernel.
SDP has the same variable name so this fixes "allyesconfig" for now.
module_param_named() is used to prevent the user-variable parameter
name from changing.
L
On Tue, 2005-02-22 at 22:32 +0200, Michael S. Tsirkin wrote:
> Good. By the way, do you plan to keep the convention of writing
> 0 == foo?
>
> I personally dislike it (and Linux expressed the same santiment at some
> point), this practice unnecessary with gcc
> which warns if you write if (foo = 0
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] 1/2 separate locking for send and receive q in mthca
>
> Michael> Instead of doing this, how about something else I would
> Michael> prefer: we could avoid locking the QP on CQ poll
> Michael> altogether, if there is
On Sun, 2005-02-20 at 02:05 +0200, Michael S. Tsirkin wrote:
> I think we also should replace __inline__ with inline everywhere.
Index: sdp_queue.h
===
--- sdp_queue.h (revision 1865)
+++ sdp_queue.h (working copy)
@@ -73,7 +73,7 @@ s
On Tue, 2005-02-22 at 12:20 -0800, Libor Michalek wrote:
> Thanks Tom, I've applied and commited the patches.
Did you choose not to apply these changes, or was this a simple
oversight?
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: sdp_inet.c
==
Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> Subject: Re: Re: [PATCH][SDP][14/22] Whitespace cleanup in sdp_proto.h
>
> On Sun, Feb 20, 2005 at 10:07:43AM -0800, Tom Duffy wrote:
> > On Sun, 2005-02-20 at 02:05 +0200, Michael S. Tsirkin wrote:
> > >
> > > I think we also should replace __inlin
On Sun, Feb 20, 2005 at 02:15:04AM +0200, Michael S. Tsirkin wrote:
> Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> >
> > -int _sdp_link_path_rec_get(struct sdp_path_info *info)
> > +static int _sdp_link_path_rec_get(struct sdp_path_info *info)
> Good stuff.
> One comment though - one can give
On Sun, Feb 20, 2005 at 02:11:37AM +0200, Michael S. Tsirkin wrote:
> Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> >
> > And here I would have thought SDP_CONN_HOLD as a macro would have
> > bugged people more. :)
>
> Didn't get that far yet :)
>
> I also wander whether we could get rid of
On Sun, Feb 20, 2005 at 10:07:43AM -0800, Tom Duffy wrote:
> On Sun, 2005-02-20 at 02:05 +0200, Michael S. Tsirkin wrote:
> >
> > I think we also should replace __inline__ with inline everywhere.
> >
> > Also, I think the convention is to add __ before inline functions
> > if they are an implement
On Fri, Feb 18, 2005 at 04:44:22PM -0800, Tom Duffy wrote:
> This series of patches cleans up the whitespace in SDP. Mostly it removes
> the extra line that was after every conditional, but it also removes
> unneeded brackets around single line conditionals as well.
Thanks Tom, I've applied and
Michael> OK, since this is getting complicated, lets start with
Michael> keeping a separate lock for completions. The posting
Michael> thread will take it before stopping the interface.
Michael> Roland, if it makes sence I'll implement it tomorrow.
Let's just hold off on this unt
Michael> Would you like help with (2)? Specifically, how should
Michael> are backport patches split up? I guess per file? Still,
Michael> it seems unlikely they can be made independent, right?
No thanks, I think I can handle it. I'm planning on making the
patches independent and per
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: ANNOUNCE: First usable version of userspace verbs
>
> I'm happy to announce the initial availability of userspace verbs
> support for brave testers.
>
> To try this out, check out the roland-uverbs subversion branch:
>
> svn co https:/
This patch adds initial support for handling CM reject messages. It
should work with the following reject codes: 1-3, 5, 8-9, 11-23,
26-29, 32-33. (These are basically rejections by the remote consumer,
versus by the remote CM.)
I still need to determine the proper handling for the reject codes
I'm happy to announce the initial availability of userspace verbs
support for brave testers.
To try this out, check out the roland-uverbs subversion branch:
svn co https://openib.org/svn/gen2/branches/roland-uverbs
and build as usual. Select CONFIG_INFINIBAND_USER_VERBS to build
userspace v
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: [PATCH] ipoib: dont lock tx on completion
>
> Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
>
> By testing again, and waking the net queue if completions arrived,
> we can avoid taking the tx lock on send completion in ip over
Michael> Instead of doing this, how about something else I would
Michael> prefer: we could avoid locking the QP on CQ poll
Michael> altogether, if there is a separate last polled index that
Michael> is written only by cq poll and read by qp post. This
Michael> index update woul
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: [PATCH] initialize device_cap_flags in mthca
>
> device_cap_flags are uninitialized in mthca.
>
> Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
This was reporting the RQ_SIG capability which is now gone.
Here's an update.
Ind
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH] 1/2 separate locking for send and
> receive q in mthca
>
> I finally got around to reviewing this, and I think I see a problem.
> It seems that if we get, say, a send completion followed by a receive
> completio
Thanks, good catch... applied.
- R.
I really need to start testing with CONFIG_SLAB_DEBUG again...
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.
list_for_each_entry() should be list_for_each_entry_safe()
in ipoib_mcast_dev_flush(). Here is the patch. Please review it.
Signed-off-by: Shirley Ma <[EMAIL PROTECTED]>
diff -urpN infiniband/ulp/ipoib/ipoib_multicast.c
infiniband-down/ulp/ipoib/ipoib_multicast.c
--- infiniband/ulp/ipoib/ipoib_
I've also committed this trivial fix to make SDP build again.
- R.
Index: infiniband/ulp/sdp/sdp_conn.c
===
--- infiniband/ulp/sdp/sdp_conn.c (revision 1857)
+++ infiniband/ulp/sdp/sdp_conn.c (working copy)
@@ -1174,7 +1
Thanks, I've finally applied this.
- R.
___
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
Michael> Since device_cap_flags is a set of ORed values, make the
Michael> result unsigned. Also to be in line with other flags.
This doesn't seem to make any practical difference, since the largest
device cap flag is 1<<15, and even if it were 1<<31 we never do any
non-bitwise arithmetic
I finally got around to reviewing this, and I think I see a problem.
It seems that if we get, say, a send completion followed by a receive
completion, we will not update which wq is locked so we'll update the
receive queue with the send queue locked. Is this true?
- R.
__
Shirley, can you read Documentation/SubmittingPatches, and if the
declaration in that file applies, resend your patches with a
"Signed-off-by:" line?
Thanks,
Roland
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/lis
Hello,
In an effort to improve our customer service and the speed with which we answer
your e-mails, we have created a new web-based contact system on the neopets.com
site, which is located at http://www.neopets.com/contact.phtml . From this new
Contact Us page, you are able to send abuse rep
Replace for(;;) break with a proper C loop.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: sdp_conn.c
===
--- sdp_conn.c (revision 1857)
+++ sdp_conn.c (working copy)
@@ -837,19 +837,14 @@ void sdp_conn_internal_lock(
sdp_inet.c, inside _sdp_inet_listen, we have:
#if 0 /* BUG 2034 workaround. */
conn->backlog_max = backlog;
#else
conn->backlog_max = 1024;
#endif
What gives? what would be the proper fix as opposed to a work-around?
--
MST - Michael S. Tsirkin
__
SDP_CONN_PUT was called before SDP_CONN_UNLOCK.
If this is the last reference, the connection could be removed
and an attempt to unlock would crash.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: sdp_inet.c
===
--- sdp_
Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> Subject: Re: SDP_CONN_LOCK
>
> On Thu, Feb 17, 2005 at 05:35:17PM +0200, Michael S. Tsirkin wrote:
> > Hi, Libor!
> > Could you please explain what are the SDP_CONN_LOCK
> > and friends doing in SDP?
> >
> > It seems they just implement exclusiv
51 matches
Mail list logo
