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

[Guy German]

Hi,

James Lentini  wrote:
> On Sun, 31 Jul 2005, Muli Ben-Yehuda wrote:
> 
>> On Sun, Jul 31, 2005 at 06:08:11PM +0300, Guy German wrote:
>>> Hi Muli,
>>> 
>>> Wouldn't it be solved by moving the try_module_get call to the
>>> beginning of the dapl_ia_open function ?
>> 
>> No. Even if it's theoretically the first line in the function, the
>> compiler can and will create a function prologue that will run before
>> you raise the reference count (same thing with decrementing the ref
>> count at module unload time and the function epilogue). You must do
>> module reference counting before executing even one instruction from
>> the module. 
>> 
>>> You are right - try_module_get() can fail when the module is not
>>> ready to be entered. should be something like:
>>> + if (!try_module_get(THIS_MODULE))
>>> +   return -EBUSY;
>> 
>> Yes - but at the caller, not callee.
> 
> Putting this in the caller (i.e. dat_ia_open and dat_ia_close) does
> sound like a better option. 

Sounds good to me too.

> 
> Guy, can you investigate why the ib_mthca module doesn't have a
> reference count and see if it relates to hotplug? I think
> kdapl_ib and
> ib_mthca should have the same policy regarding this issue.

As I understand, consumers are working over ib_core and not over ib_mthca
directly. So, if (from a hotplug reason) ib_mthca goes down, ib_core consumers 
can get notified of the event, by an upcall.

If you take this model to dapl, I think it would influence the way dapl 
consumers
need to do things (like registering an upcall and know what to do in case 
kdapl_ib
is down). 

I also don't know how many consumers really need "dapl hotplug"...

Guy
___
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] IB Query

[Majumder, Rajib]

Hi,

I have a query regarding SDP/IB. I have 2 processes. 1 TCP client and 1 TCP 
server, both are running on the same physical host. We have IB HCA installed on 
this host.
 
Both the process communicate using SDP. 

Will there be any performance gain? 

Any clarification is appreciated. 

Thanks

Rajib  

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==

___
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

[John Partridge]

Hal/James,

Here is a patch that fixes the ia64 build problem and the warnings I had 
previously posted.
The patch ONLY fixes the problems in the trunk tree ( apply from the trunk 
subdir) and NOT
in users/jlentini, the following files also need to be fixed (should be easy 
enough for
James to hack the patch file to do it) :-

users/jlentini/linux-kernel/dat-provider/dapl_openib_cm.c
users/jlentini/linux-kernel/dat-provider/dapl_util.h

The patch is based on svn revision 2935 (copy also attached to email)
=== patch begin ==

--- src/linux-kernel/infiniband/ulp/kdapl/ib/dapl_openib_cm.c   2005-07-26 
00:00:10.0 -0500
+++ src/linux-kernel/infiniband/ulp/kdapl/ib/dapl_openib_cm.c   2005-08-01 
11:56:25.240418715 -0500
@@ -342,7 +342,7 @@
  &cm_ctx->dapl_comp);
if (status) {
printk(KERN_ERR "dapl_path_comp_handler: "
-  "ib_at_paths_by_route returned %d id %lld\n",
+  "ib_at_paths_by_route returned %d id %lu\n",
   status, cm_ctx->dapl_comp.req_id);
event = DAT_CONNECTION_EVENT_BROKEN;
goto error;
@@ -413,7 +413,7 @@
  &cm_ctx->dapl_comp);
if (status) {
printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
-  "returned %d id %lld\n", status, 
cm_ctx->dapl_comp.req_id);
+  "returned %d id %lu\n", status, 
cm_ctx->dapl_comp.req_id);
event = DAT_CONNECTION_EVENT_BROKEN;
goto error;
}
--- src/linux-kernel/infiniband/ulp/kdapl/ib/dapl_util.h2005-07-26 
00:00:10.0 -0500
+++ src/linux-kernel/infiniband/ulp/kdapl/ib/dapl_util.h2005-08-01 
11:12:16.418589653 -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__)


== patch end =

I checked that the patch does not cause a build problem on ia32. I tested that 
the modules
load OK on ia64 and ia32. Hope this helps.

John


Hal Rosenstock wrote:

Hi John,

My normal email sending is not working right now so I am using an alternate 
method.
Hope the formatting comes through OK.

On Fri, 2005-07-29 at 17:46, John Partridge wrote:

With this fix the ia64 modules all build to completion with just a 
couple of warnings :-




  CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
`dapl_path_comp_handler':
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long long int 
format, u64 arg (arg 3)
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
`dapl_rt_comp_handler':
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long long int 
format, u64 arg (arg 3)



Can you try this patch and see if it removes the warnings ?

Thanks.

-- Hal

Index: dapl_openib_cm.c
===
--- dapl_openib_cm.c(revision 2935)
+++ dapl_openib_cm.c(working copy)
@@ -341,9 +341,15 @@ static void dapl_path_comp_handler(u64 r
  &cm_ctx->dapl_path, 1,
  &cm_ctx->dapl_comp);
if (status) {
+#if defined(__ia64__)
+   printk(KERN_ERR "dapl_path_comp_handler: "
+  "ib_at_paths_by_route returned %d id %ld\n",
+  status, cm_ctx->dapl_comp.req_id);
+#else
printk(KERN_ERR "dapl_path_comp_handler: "
   "ib_at_paths_by_route returned %d id %lld\n",
   status, cm_ctx->dapl_comp.req_id);
+#endif
event = DAT_CONNECTION_EVENT_BROKEN;
goto error;
}
@@ -412,8 +418,13 @@ static void dapl_rt_comp_handler(u64 req
status = ib_at_paths_by_route(&cm_ctx->dapl_rt, 0, &cm_ctx->dapl_path, 
1,
  &cm_ctx->dapl_comp);
if (status) {
+#if defined(__ia64__)
+   printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
+  "returned %d id %ld\n", status, 
cm_ctx->dapl_comp.req_id);
+#else
printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
   "returned %d id %lld\n", status, 
cm_ctx->dapl_comp.req_id);
+#endif
event = DAT_CONNECTION_EVENT_BROKEN;
goto error;
}


--
John Partridge

Silicon Graphics Inc
Tel:  651-683-3428
Vnet: 233-3428
E-Mail: [EMAIL PROTECTED]
--- src/linux-kernel/infiniband/ulp/kdapl/ib/dapl_openib_cm.c   2005-07-26 

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] uDAPL dapltest

[Arlin Davis]

James Lentini wrote:



Ok. I reference the x86_64 build problem in my log message and 
committed it in revision 2940.


On Mon, 1 Aug 2005, Hal Rosenstock wrote:


I saw this on x86_64. Don't know about IA64.

-- Hal

-Original Message-
From: [EMAIL PROTECTED] on behalf of James Lentini
Sent: Mon 8/1/2005 1:39 PM
To: Arlin Davis
Cc: openib
Subject: [openib-general] Re: [PATCH] uDAPL dapltest


Where was the build problem being seen? x86_64 or IA64? I want to
record it in the checkin log message.



both x86_64 and IA64

-arlin



james

On Thu, 28 Jul 2005, Arlin Davis wrote:


James,

Patch to fix build problem.

-arlin


Signed-off by: Arlin Davis <[EMAIL PROTECTED]>

Index: dapltest/test/dapl_bpool.c
===
--- dapltest/test/dapl_bpool.c  (revision 2930)
+++ dapltest/test/dapl_bpool.c  (working copy)
@@ -363,8 +363,8 @@
   "BPOOL alloc_size %x\n",
   (int) bpool_ptr->alloc_size);
   DT_Tdep_PT_Printf (phead,
-"BPOOL pz_handle  %x\n",
-(int) bpool_ptr->pz_handle);
+"BPOOL pz_handle  %p\n",
+ bpool_ptr->pz_handle);
   DT_Tdep_PT_Printf (phead,
   "BPOOL num_segs   %x\n",
   (int) bpool_ptr->num_segs);


___
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 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: [Rdma-developers] Meeting(07/22) summary:OpenRDMA community development discussion

[Yaron Haviv]

> -Original Message-
> From: Fab Tillier [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 01, 2005 1:14 PM
> 
> > From: Sean Hefty [mailto:[EMAIL PROTECTED]
> >
> > Yaron Haviv wrote:
> > > we can spend time and discuss theories and intentions, at the end
of
> the
> > > day an iWarp RNIC cannot just reside under IB-Verbs without major
> > > changes to the overall infrastructure.
> >
> > I don't disagree with having a common connection library that
supports
> both
> > IB and iWarp, or that you could derive a solution from kDAPL.  But
based
> on
> > the proposed APIs that I've seen, I believe that an RNIC could
reside
> under
> > IB verbs with minimal changes, and would likely be the best
engineered
> > solution for including RNIC support in Linux.
> 
> Just for clarity, when you say verbs you exclude connection
> establishment/management, right?
> 
> I think keeping the two distinct is important in this discussion, as
it
> seems
> there is some confusion - some people refer to verbs as verbs + CM,
others
> as
> just verbs.
> 
> Here's my take from the discussions so far:
> - RNICs can probably be made to work under the IB verbs (with changes
of
> course).
> - RNICs can probably not be made to work under the IB CM (not that
I've
> seen
> this suggested).
> 

Fab, I did the same distinction between pure verbs & the broader API
(+CM, SA, ..)

I agree that pure send, receive, .. verbs are similar with minor
differences 
And we may just want to adopt them with minor changes

On the other hand it would not be efficient to try and bend the iWarp CM
model to the IB (complex) one, but rather use a simpler one, such as the
one in DAPL that fits both camps

In IB we need to use a CM and a bunch of SA queries, where the ULP
doesn't really need all that and can do with a simple BSD like
connection request (that may map to a more complex IB or iWarp model
underneath)

There are ways in the dapl/bsd like connection mechanism enough to imply
sequrity/QoS/etc' (using a src/dst IP, network implied from IP, and
kDAPL QoS or BSD TOS, ..) so a user doesn't need direct access to SA for
connections, at the most we can add some flags to it

Yaron


> - Fab

___
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] uDAPL with uCM and uAT support - version 2

[Arlin Davis]

James,

Here is version 2 with the changes you requested. Also, README updated per 
Hal's comments.

 dapl/udapl/dapl_evd_wait.c
 dapl/udapl/Makefile
 dapl/common/dapl_evd_resize.c
 dapl/openib/TODO
 dapl/openib/dapl_ib_util.c
 dapl/openib/dapl_ib_cm.c
 dapl/openib/dapl_ib_util.h
 dapl/openib/README
 dapl/openib/dapl_ib_cq.c

Signed-off by: Arlin Davis <[EMAIL PROTECTED]>

Index: dapl/udapl/dapl_evd_wait.c
===
--- dapl/udapl/dapl_evd_wait.c  (revision 2919)
+++ dapl/udapl/dapl_evd_wait.c  (working copy)
@@ -74,9 +74,10 @@
 DAPL_EVD   *evd_ptr;
 DAT_RETURN dat_status;
 DAT_EVENT  *local_event;
-DAT_BOOLEANnotify_requested = DAT_FALSE;
+DAT_BOOLEANnotify_needed = DAT_FALSE;
 DAT_BOOLEANwaitable;
 DAPL_EVD_STATE evd_state;
+DAT_COUNT  total_events,new_events;
 
 dapl_dbg_log (DAPL_DBG_TYPE_API,
  "dapl_evd_wait (%p, %d, %d, %p, %p)\n", 
@@ -124,9 +125,9 @@
 }
 
 dapl_dbg_log (DAPL_DBG_TYPE_EVD, 
- "dapl_evd_wait: EVD %p, CQ %p\n", 
-  evd_ptr,
- (void *)evd_ptr->ib_cq_handle);
+ "dapl_evd_wait: EVD %p, CQ %p, Timeout %d, Threshold %d\n", 
+  evd_ptr,(void *)evd_ptr->ib_cq_handle, time_out, threshold);
+  
 
 /*
  * Make sure there are no other waiters and the evd is active.
@@ -144,11 +145,10 @@
 evd_state = dapl_os_atomic_assign ( (DAPL_ATOMIC *)&evd_ptr->evd_state,
(DAT_COUNT) DAPL_EVD_STATE_OPEN,
(DAT_COUNT) DAPL_EVD_STATE_WAITED );
-dapl_os_unlock ( &evd_ptr->header.lock );
 
-if ( evd_state != DAPL_EVD_STATE_OPEN )
+dapl_os_unlock ( &evd_ptr->header.lock );
+if ( evd_state != DAPL_EVD_STATE_OPEN || !waitable)
 {
-   /* Bogus state, bail out */
dat_status = DAT_ERROR (DAT_INVALID_STATE,0);
goto bail;
 }
@@ -182,37 +182,54 @@
 * return right away if the ib_cq_handle associate with these evd
 * equal to IB_INVALID_HANDLE
 */
-   dapls_evd_copy_cq(evd_ptr);
-
-   if (dapls_rbuf_count(&evd_ptr->pending_event_queue) >= threshold)
-   {
-   break;
-   }
-
-   /*
-* Do not enable the completion notification if this evd is not 
-* a DTO_EVD or RMR_BIND_EVD
+   /* Logic to prevent missing completion between copy_cq (poll)
+* and completion_notify (re-arm)  
 */
-   if ( (!notify_requested) &&
- ((evd_ptr->evd_flags & DAT_EVD_DTO_FLAG) ||
-  (evd_ptr->evd_flags & DAT_EVD_RMR_BIND_FLAG)) )
+   notify_needed = DAT_TRUE;
+   new_events = 0;
+   while (DAT_TRUE)
{
-   dat_status = dapls_ib_completion_notify (
-   evd_ptr->header.owner_ia->hca_ptr->ib_hca_handle,
-   evd_ptr,
-   (evd_ptr->completion_type == DAPL_EVD_STATE_SOLICITED_WAIT) ?
-IB_NOTIFY_ON_SOLIC_COMP : IB_NOTIFY_ON_NEXT_COMP );  
-
-   DAPL_CNTR(DCNT_EVD_WAIT_CMP_NTFY);
-   /* FIXME report error */
-   dapl_os_assert(dat_status == DAT_SUCCESS);
+   dapls_evd_copy_cq(evd_ptr); /* poll for new completions */
+   total_events = dapls_rbuf_count 
(&evd_ptr->pending_event_queue); 
+   new_events = total_events - new_events;
+   if (total_events >= threshold ||
+   (!new_events && notify_needed == DAT_FALSE))
+   {
+   break;
+   } 
+   

+   /*
+* Do not enable the completion notification if this evd is not 
+* a DTO_EVD or RMR_BIND_EVD
+*/
+   if ( (evd_ptr->evd_flags & DAT_EVD_DTO_FLAG) ||
+   (evd_ptr->evd_flags & DAT_EVD_RMR_BIND_FLAG) )
+   {
+   dat_status = dapls_ib_completion_notify (
+   
evd_ptr->header.owner_ia->hca_ptr->ib_hca_handle,
+   evd_ptr,
+   (evd_ptr->completion_type == 
DAPL_EVD_STATE_SOLICITED_WAIT)
?
+   IB_NOTIFY_ON_SOLIC_COMP : 
IB_NOTIFY_ON_NEXT_COMP );  
+
+   DAPL_CNTR(DCNT_EVD_WAIT_CMP_NTFY);
+   notify_needed = DAT_FALSE;
+   new_events = total_events;
+   
+   /* FIXME report error */
+   dapl_os_assert(dat_status == DAT_SUCCESS);
+   } 
+   else 
+   {
+   break;
+   }
 
-   notify_requested = DAT_TRUE;
+   } /* while completions < threshold, 

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

[openib-general] Re: [PATCH][dapl] cleanup dapl_cookie

[James Lentini]

On Mon, 27 Jun 2005, Bernhard Fischer wrote:


Hi James,

untested.

- cleanup dapl_cookie.c: remove unneeded local variables and simplify
 branches to be consistent with dapl_rmr_cookie_alloc().

Signed-off-by: Bernhard Fischer <[EMAIL PROTECTED]>

thank you,
Bernhard



Committed in revision 2941.
___
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] uDAPL dapltest

[James Lentini]

Ok. I reference the x86_64 build problem in my log message and 
committed it in revision 2940.


On Mon, 1 Aug 2005, Hal Rosenstock wrote:


I saw this on x86_64. Don't know about IA64.

-- Hal

-Original Message-
From: [EMAIL PROTECTED] on behalf of James Lentini
Sent: Mon 8/1/2005 1:39 PM
To: Arlin Davis
Cc: openib
Subject: [openib-general] Re: [PATCH] uDAPL dapltest


Where was the build problem being seen? x86_64 or IA64? I want to
record it in the checkin log message.

james

On Thu, 28 Jul 2005, Arlin Davis wrote:


James,

Patch to fix build problem.

-arlin


Signed-off by: Arlin Davis <[EMAIL PROTECTED]>

Index: dapltest/test/dapl_bpool.c
===
--- dapltest/test/dapl_bpool.c  (revision 2930)
+++ dapltest/test/dapl_bpool.c  (working copy)
@@ -363,8 +363,8 @@
   "BPOOL alloc_size %x\n",
   (int) bpool_ptr->alloc_size);
   DT_Tdep_PT_Printf (phead,
-"BPOOL pz_handle  %x\n",
-(int) bpool_ptr->pz_handle);
+"BPOOL pz_handle  %p\n",
+ bpool_ptr->pz_handle);
   DT_Tdep_PT_Printf (phead,
   "BPOOL num_segs   %x\n",
   (int) bpool_ptr->num_segs);


___
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 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] uDAPL with uCM and uAT support

[Hal Rosenstock]

Hi,

I don't think this has been applied as yet but the following steps in README
are no longer needed and should be replaced by the below now that uAT has been 
moved to the trunk.

-- Hal

Instructions From README:

Third drop of code, includes uCM and uAT support.

build uAT library:

cd gen2/trunk/src/userspace/libibat/
./autogen.sh &&./configure && make && make install


-Original Message-
From: [EMAIL PROTECTED] on behalf of Arlin Davis
Sent: Sun 7/24/2005 8:48 PM
To: 'James Lentini'
Cc: openib-general@openib.org
Subject: [openib-general] [PATCH] uDAPL with uCM and uAT support
 
James,

Here is a third drop that adds IBAT to the uCM support. This also includes
some fixes to common code evd_wait and evd_resize.

Instructions From README:

Third drop of code, includes uCM and uAT support.
NOTE: uAT user library and kernel code in separate branch.

build uAT library from following branch:

cd gen2/branches/shaharf-ibat/src/userspace/libibat/
./autogen.sh &&./configure && make && make install

copy following uat source to latest trunk kernel src:

gen2/branches/shaharf-ibat/src/linux-kernel/infiniband/core
at.c  at_priv.h  att.c uat.c uat.h Makefile

gen2/branches/shaharf-ibat/src/linux-kernel/infiniband/include
ib_at.h ib_user_at.h
___
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][dapl] cleanup dapl_cookie

[James Lentini]

On Fri, 29 Jul 2005, Bernhard Fischer wrote:


On Thu, Jun 30, 2005 at 10:04:36AM -0400, James Lentini wrote:



On Wed, 29 Jun 2005, Bernhard Fischer wrote:


On Tue, Jun 28, 2005 at 03:39:59PM -0400, James Lentini wrote:


Hi Bernhard,

The changes look fine. Why the additional copyright? I need to be able
to explain it to my legal department.


My legaleeze states that whatever i do during work-time is contributed
to work and whatever is related to work done during leasure time has to
be attributed to /me _at_ _least_. As that snippet (which was a
test-balloon
for that category) clearly was done in my spare time, i'm forced to
attribute it accordingly :-/

Does that answer your question satisfactorily?


Thanks Bernhard. That makes sense to me. My legal inquired about the
"all rights reserved" qualifier. All the copyrights I found in the
OpenIB tree (including NetApp's) use that language. I'll run this by
them.


As rev. 2934 i do not see this patch applied. To recap, it removed some
unneeded local variables (which my compiler wasn't smart enough to
eleminate on it's own -- gcc-4.0 and gcc-HEAD) and simplified some
conditionals and branches.

Back then, i only submitted the changes to dapl_cookie.c to see if such
kind of code simplifications would be accepted or not.

James, can you please elaborate why the patch was rejected?


It wasn't rejected. With the back and forth on the copyright notice, I 
thought I was waiting for you to reply. Sorry about that. I'll dust 
off the patch and review it again.


___
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][kdapl]: adding DAT_MEM_TYPE_IA support

[James Lentini]

On Fri, 29 Jul 2005, Guy German wrote:


+   array = (u64 *)phys_addr.for_array; /* need to add for_u64_array to
union */
What does this comment mean?


I think the right way to do it is :
array = phys_addr.for_u64_array
(Givven the union consists of a new type u64* called "for_u64_array")


I believe the original idea was to have IA memory use the 
DAT_REGION_DESCRIPTION's for_pointer value.

___
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][kdapl]: inc/dec module ref count

[Muli Ben-Yehuda]

On Mon, Aug 01, 2005 at 02:51:24PM -0400, James Lentini wrote:

> There are cases when a function can fail and there is no intelligent 
> way to handle the error or report it to a user (e.g. printf(3), 
> although I don't use the void cast convention when calling printf).

Of course, I'm talking specifically about try_module_get().

Cheers,
Muli

-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

___
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][kdapl]: inc/dec module ref count

[James Lentini]

On Sun, 31 Jul 2005, Muli Ben-Yehuda wrote:


On Sun, Jul 31, 2005 at 06:08:11PM +0300, Guy German wrote:

Hi Muli,

Wouldn't it be solved by moving the try_module_get call to the
beginning of the dapl_ia_open function ?


No. Even if it's theoretically the first line in the function, the
compiler can and will create a function prologue that will run before
you raise the reference count (same thing with decrementing the ref
count at module unload time and the function epilogue). You must do
module reference counting before executing even one instruction from
the module.


You are right - try_module_get() can fail when the module is not ready
to be entered. should be something like:
+ if (!try_module_get(THIS_MODULE))
+   return -EBUSY;


Yes - but at the caller, not callee.


Putting this in the caller (i.e. dat_ia_open and dat_ia_close) does 
sound like a better option.


Guy, can you investigate why the ib_mthca module doesn't have a 
reference count and see if it relates to hotplug? I think kdapl_ib and 
ib_mthca should have the same policy regarding this issue.

___
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][kdapl]: inc/dec module ref count

[James Lentini]

On Sun, 31 Jul 2005, Muli Ben-Yehuda wrote:


On Thu, Jul 28, 2005 at 03:01:24PM -0400, James Lentini wrote:


We've been using the following convention to indicate that we don't
care about the return value:

 (void) try_module_get(THIS_MODULE);


This seems counter intuitive to me (the idea, not the syntax) -
try_module_get() can and will fail. If it doesn't matter that it
succeeds or fails, why call it at all?


There are cases when a function can fail and there is no intelligent 
way to handle the error or report it to a user (e.g. printf(3), 
although I don't use the void cast convention when calling printf).


james
___
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: [Rdma-developers] Meeting (07/22) summary:OpenRDMA community development discussion

[Jay Rosser]

The IT-API working group spent some effort on analysis of the connection 
management issues required to support both IB and iWARP in a common API 
and documented such in chapter 5 and appendix B of the IT-API 2.0 
specification:


http://www.opengroup.org/icsc/uploads/40/7237/IT-API-V2-Final.pdf

We hope it is useful for reference on this subject and as an example of 
a possible approach to resolving the issues.


Jay




 


-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On 
Behalf Of Yaron Haviv

Sent: Sunday, July 31, 2005 8:57 PM
To: Christoph Hellwig; Tom Duffy
Cc: Venkata Jagana; [EMAIL PROTECTED]; 
openib-general@openib.org
Subject: RE: [openib-general] Re: [Rdma-developers] Meeting 
(07/22) summary:OpenRDMA community development discussion


   


-Original Message-
From: [EMAIL PROTECTED] [mailto:openib-general- 
[EMAIL PROTECTED] On Behalf Of Christoph Hellwig

Sent: Friday, July 29, 2005 8:02 AM
To: Tom Duffy
Cc: Venkata Jagana; [EMAIL PROTECTED]; 
 

Christoph 
   


Hellwig; openib-general@openib.org
Subject: [openib-general] Re: [Rdma-developers] Meeting (07/22) 
summary:OpenRDMA community development discussion


On Thu, Jul 28, 2005 at 02:02:08PM -0700, Tom Duffy wrote:
 

At OLS (and in previous forums), the kernel maintainers 
   


have made it
   


*very* clear that there should only be one API.
   

_and_ that this api is neither RNIC-PI or KDAPL.  In fact 
 

for anything 
   

that doesn't look very similar to the current IB midlayer 
 

you'd need 
   


very convincing arguments.

 

I assume it is not as simplistic as that iWarp CM model is 
quite different than IB, and iWarp doesn't have SA/SM and a 
bunch of other IB specific things 

For example: 
The correct common abstraction is one where a user can issue 
a connection by using a logical end-point address (such as an 
IP), and doesn't have to deal with the IB or iWarp specific 
CM state machine or SA/SM. 

If you look at DAPL you can break it to simple Verbs (e.g. 
send, ..) where its just a simple overlay on to of the verbs 
(and may be

redundant)
However there is a second part that implements a simple 
connection establishment model (much like BSD) that can be 
mapped to both IB (CM, SA, ..) or iWarp (TCP Syn/SynAck, ARP, 
etc'), this serves couple of main

purposes:
a. make it simple for ULP developer and put the complex part 
in a common
place   
b. define a common model for different HW


we can spend time and discuss theories and intentions, at the 
end of the day an iWarp RNIC cannot just reside under 
IB-Verbs without major changes to the overall infrastructure.
Several guys spent some time looking it over and came with an 
abstraction that IS possible on top of IB & iWarp & foo, that 
is called DAPL (or IT as another similar alternative)


It would probably be wise to try and merge that effort with 
IB-verbs etc' 
(e.g. make the verbs portion of the API closer), and on the 
same time preserve the effort that was done in kDAPL to 
overcome the differences (e.g. in the CM, addressing portions)


   



The working theory is that two additional connection management
'verbs' will be proposed, both optional.

The first is a straight-forward mapping of the traditional DAT
connection establishment: i.e., do whatever you have to do in
order to listen, request a connection, accept/reject connection
requests. This is an interface that can map to existing iWARP
implementations very easily while not immediately standardizing
integration with the host TCP stack.

Connection Requests are reported in this model, but via callbacks
rather than EVDs, since it is desired to keep a verb layer interface
more spartan than kDAPL. However, the fact that connection requests
must be approved allows blocking of all requests that conflict
with host policy (as expressed in packet filtering rules).

It is also an interface that IB vendors *could* support, because
DAPL implements over IB. We could consider having a default
implementation of the methods from the DAPL code for that
purpose.

After that we need a standardized way to implement "modify qp
to RTS" in a iWARP-centric fashion. This will require agreement
on how to transfer the TCP state from the host stack to the
RNIC. This is the more flexible model that matches RDMAC
verbs and supports all connection establishment models, 
including iSER. It is inherently iWARP specific, however,

since IB connections do not start their life as TCP
connections. 

The benefit of this second additional API is that the 
preserves *all* host stack safeguards on connection 
establishment because the host stack actually establishes

the TCP connection. It does require agreement on the correct
way to extract the TCP connection from the host stack,
however. This is something that existing deployments
already do, but they aren't doing it in mainline code.
Reaching consensus on a sustainable interface for doing
this is certainly worthy of carefu

[openib-general] Re: [PATCH] uDAPL makefile

[James Lentini]

I committed the libverbs specific portion in revision 2939. I'll check 
the CQ_WAIT_OBJECT change in with the rest of your earlier patch 
(since it goes with that).


james

On Fri, 29 Jul 2005, Arlin Davis wrote:


James,

no longer need to link with mthca.so

-arlin

Signed-off by: Arlin Davis <[EMAIL PROTECTED]>


Index: dapl/udapl/Makefile
===
--- dapl/udapl/Makefile (revision 2919)
+++ dapl/udapl/Makefile (working copy)
@@ -122,7 +122,8 @@
#
ifeq ($(VERBS),openib)
PROVIDER = $(TOPDIR)/../openib
-CFLAGS   += -DOPENIB -DCQ_WAIT_OBJECT
+CFLAGS   += -DOPENIB
+#CFLAGS   += -DCQ_WAIT_OBJECT
CFLAGS   += -I/usr/local/include/infiniband
endif

@@ -232,9 +233,8 @@
endif

ifeq ($(VERBS),openib)
-LDFLAGS += -libverbs /usr/local/lib/infiniband/mthca.so -libcm
+LDFLAGS += -libverbs -libcm -libat
LDFLAGS += -rpath /usr/local/lib -L /usr/local/lib
-LDFLAGS += -rpath /usr/local/lib/infiniband -L /usr/local/lib/infiniband
PROVIDER_SRCS  = dapl_ib_util.c dapl_ib_cq.c dapl_ib_qp.c
PROVIDER_SRCS += dapl_ib_cm.c dapl_ib_mem.c
endif


___
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][kdapl]: inc/dec module ref count

[James Lentini]

On Fri, 29 Jul 2005, Guy German wrote:


Hi James,

That's an interesting point.
I don't know why the ib_mthca can be rmmod-ed at any
time, without dependencies (I guess it's a trusted env.
issue).


Is it a hotplug issue?


I need to check what happens if you rmmod ib_mthca and
then calling ia_close. It supposed to decrement
the ref count even on failure from the hca.

Any way I think that in a production level kernel
you are not supposed to do rmmod AT ALL.


I wasn't aware of that convention.
___
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] kernel VM monitor for memory registration caching

[Pete Wyckoff]

[EMAIL PROTECTED] wrote on Sun, 31 Jul 2005 13:31 +0300:
>  First of all, you have one user_delta per mm that user can poll from 
> userspace. Is it possible to make user_delta to be part of dreg_region
> instead of dreg_context and module will set it whenever
> registration becomes invalid. Field 'invalid' will be added to buf_info
> structure and pointer to it will be passed to kernel at registration
> time.
>  This way the userpace can look up cache and check if registration is
> still valid. No need to rescan cache from userspace, we already scanned
> it once from kernel after all. With your current approach userspace will
> need to search for mr_handle in the cache and invalidate the entry that
> holds it.

I still think that idea is possible.  But perhaps someone who wants
to integrate this with a cache can do so sometime.  There is no real
cache structure in this userspace test code.

>  You change vma_ops in vma to catch open/close events. What about
> nopage() method in vma_ops? We have to forward it to original vma_ops?
> 
> Something like included patch (not even compiled).

Right, good catch.  I did something a bit different to avoid kmalloc
in the common case of empty origvma->vm_ops (i.e. normal memory).
But for the sake of correctness the fix must be there.

Note that these vm_ops structures don't really stack properly.  If
there happened to be some other kernel component that decided to
take ownership of the vm_ops structure, dreg would fail to notice
that it was the "owner" of the vma already, and it might free the
ops incorrectly.  Ideally there would be a chain of these things
that would get called from higher up that would not interfere with
each other.  As it is, dreg assumes it is the ultimate owner and
that other interfering vma ops have already done their business.

This stacked usage would be the rare case.  If you're communicating
using buffers from, say, your video or sound card memory, or a
hugetlb space, or SYSV shm, this will arise.  But in the case of shm
and hugetlb and DRM video, we're okay, as they set the ops in mmap()
and don't change it, ever.  IB memory registrations cannot happen
until the memory is mapped, so dreg will always be last.  Arbitrary
uses might cause failure someday, however.

-- Pete


diff -u -p -r1.4 dreg.c
--- dreg.c  29 Jul 2005 17:17:52 -  1.4
+++ dreg.c  1 Aug 2005 17:41:00 -
@@ -96,6 +96,15 @@ static void dreg_vm_close(struct vm_area
 static void mem_deregister(struct dreg_context *dc, struct dreg_region *reg);
 
 /*
+ * Interface with VM.  It calls us back when one of these events happen on
+ * a VMA we care about.
+ */
+static struct vm_operations_struct dreg_vm_ops = {
+.open = dreg_vm_open,
+.close = dreg_vm_close,
+};
+
+/*
  * Helpful functions.
  */
 static struct dreg_context *find_context_by_mm(const struct mm_struct *mm)
@@ -161,8 +170,11 @@ static void destroy_region(struct dreg_c
 struct vm_area_struct *vma = reg->vma;
 
 pr_debug("%s: reg %p vma %p addr %lx\n", __func__, reg, vma, reg->addr);
-if (vma)
+if (vma) {
+   if (vma->vm_ops != &dreg_vm_ops)
+   kfree(vma->vm_ops);
vma->vm_ops = reg->orig_ops;
+}
 if (reg->addr)
mem_deregister(dc, reg);
 list_del(®->subordinate_list);
@@ -172,15 +184,6 @@ static void destroy_region(struct dreg_c
 }
 
 /*
- * Interface with VM.  It calls us back when one of these events happen on
- * a VMA we care about.
- */
-static struct vm_operations_struct dreg_vm_ops = {
-.open = dreg_vm_open,
-.close = dreg_vm_close,
-};
-
-/*
  * Triggered from VM activity.  Pass through to underlying vm_ops
  * if it exists after we finish.
  *
@@ -305,6 +308,10 @@ static void dreg_vm_open(struct vm_area_
  * forget about it and do not build a new region for it.
  */
 if (list_empty(&temp_new_subordinate_list)) {
+   /*
+* Do not free the newvma ops, it is just a copy, free handled when
+* original vma->vm_ops is destroyed.
+*/
newvma->vm_ops = orig_ops;
 } else {
reg = kmem_cache_alloc(dreg_region_cache, GFP_KERNEL);
@@ -318,6 +325,14 @@ static void dreg_vm_open(struct vm_area_
}
 
reg->orig_ops = orig_ops;
+   if (orig_ops) {
+   newvma->vm_ops = kmalloc(sizeof(*newvma->vm_ops), GFP_KERNEL);
+   *newvma->vm_ops = *orig_ops;
+   newvma->vm_ops->open = dreg_vm_open;
+   newvma->vm_ops->close = dreg_vm_close;
+   } else {
+   newvma->vm_ops = &dreg_vm_ops;
+   }
/* non subordinate */
reg->vma = newvma;
list_add(®->subordinate_list, &temp_new_subordinate_list);
@@ -526,7 +541,15 @@ static int dreg_write_monitor(struct dre
/* non subordinate */
reg->vma = vma;
INIT_LIST_HEAD(®->subordinate_list);
-   vma->vm_ops = &dreg_vm_ops;  /* own this vma */
+   if (reg->orig_ops) {
+   /* copy it in case it uses more than open/close */

RE: [openib-general] Re: [PATCH] uDAPL dapltest

[Hal Rosenstock]

I saw this on x86_64. Don't know about IA64.

-- Hal

-Original Message-
From: [EMAIL PROTECTED] on behalf of James Lentini
Sent: Mon 8/1/2005 1:39 PM
To: Arlin Davis
Cc: openib
Subject: [openib-general] Re: [PATCH] uDAPL dapltest
 

Where was the build problem being seen? x86_64 or IA64? I want to 
record it in the checkin log message.

james

On Thu, 28 Jul 2005, Arlin Davis wrote:

> James,
>
> Patch to fix build problem.
>
> -arlin
>
>
> Signed-off by: Arlin Davis <[EMAIL PROTECTED]>
>
> Index: dapltest/test/dapl_bpool.c
> ===
> --- dapltest/test/dapl_bpool.c  (revision 2930)
> +++ dapltest/test/dapl_bpool.c  (working copy)
> @@ -363,8 +363,8 @@
>"BPOOL alloc_size %x\n",
>(int) bpool_ptr->alloc_size);
>DT_Tdep_PT_Printf (phead,
> -"BPOOL pz_handle  %x\n",
> -(int) bpool_ptr->pz_handle);
> +"BPOOL pz_handle  %p\n",
> + bpool_ptr->pz_handle);
>DT_Tdep_PT_Printf (phead,
>"BPOOL num_segs   %x\n",
>(int) bpool_ptr->num_segs);
>
___
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 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: [Rdma-developers]Meeting(07/22) summary:OpenRDMA community development discussion

[Steve Wise]

> Then tell them to come up with an alternative.  We're not going to
> 
>  - include RNIC/PI or something similar to it
>  - pile abstraction layers or abstractions layers (the kDAPL approach)
> 
> so if the RNIC community can find anything better they should propose
> it.  OTOH they're not even able to get a NIC driver OpenSource so I'm
> not going to waste more time on them.

The current Ammasso RNIC driver is released under the GPL license now.  At
this point in time, its not openIB.  We intend to develop an open source
driver that plugs into the openIB framework and does _not_ implement
RNIC/PI.  And we'll provide this as a series of patches during development
to the openIB community for general review.   

Steve.


___
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] OpenIB scripts

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: RE: [PATCH] OpenIB scripts
> 
> > I'm fine with moving some of these scripts to trunk.
> 
> Which ones wouldn't be moved ?

I'll have to check.
There's some duplication there: there are old scripts that I use, and new
scripts that Vlad wrote. Vlad's scripts match the conventional configure,
make, make install interface, so I think thats the way we want to go.
They also should support out of kernel builds.

> > These are install scripts, they dont belong in either
> > src/linux-kernel or src/userspace.
> 
> > What about at the top level, alongside src/?
> 
> Sounds OK to me.

Good, I guess we'll wait till Sunday and add them if its fine with everyone.

-- 
MST
___
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] uDAPL dapltest

[James Lentini]

Where was the build problem being seen? x86_64 or IA64? I want to 
record it in the checkin log message.


james

On Thu, 28 Jul 2005, Arlin Davis wrote:


James,

Patch to fix build problem.

-arlin


Signed-off by: Arlin Davis <[EMAIL PROTECTED]>

Index: dapltest/test/dapl_bpool.c
===
--- dapltest/test/dapl_bpool.c  (revision 2930)
+++ dapltest/test/dapl_bpool.c  (working copy)
@@ -363,8 +363,8 @@
   "BPOOL alloc_size %x\n",
   (int) bpool_ptr->alloc_size);
   DT_Tdep_PT_Printf (phead,
-"BPOOL pz_handle  %x\n",
-(int) bpool_ptr->pz_handle);
+"BPOOL pz_handle  %p\n",
+ bpool_ptr->pz_handle);
   DT_Tdep_PT_Printf (phead,
   "BPOOL num_segs   %x\n",
   (int) bpool_ptr->num_segs);


___
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: [Rdma-developers]Meeting(07/22) summary:OpenRDMA community development discussion

[Steve Wise]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Sean Hefty
> Sent: Monday, August 01, 2005 12:26 PM
> To: Fab Tillier
> Cc: Venkata Jagana; openib-general@openib.org; Tom Duffy; 
> [EMAIL PROTECTED]; Christoph Hellwig
> Subject: Re: [openib-general] Re: 
> [Rdma-developers]Meeting(07/22) summary:OpenRDMA community 
> development discussion
> 
> Fab Tillier wrote:
> > Just for clarity, when you say verbs you exclude connection
> > establishment/management, right?
> 
> I refer to verbs as only those calls provided by the device 
> driver, so I'm 
> excluding CM, SA query, MAD services, etc.  For IB, it does 
> include the 
> creation of the special QPs.
> 
> > Here's my take from the discussions so far:
> > - RNICs can probably be made to work under the IB verbs 
> (with changes of
> > course).
> 
> I would go further and state that the RNIC community seems 
> reluctant to do so.
> 

This isn't true.  The RNIC community is actively trying to do this now.
Stay tuned for patches...

Steve.



___
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: [Rdma-developers] Meeting(07/22) summary:OpenRDMA community development discussion

[Christoph Hellwig]

On Mon, Aug 01, 2005 at 10:26:14AM -0700, Sean Hefty wrote:
> >Here's my take from the discussions so far:
> >- RNICs can probably be made to work under the IB verbs (with changes of
> >course).
> 
> I would go further and state that the RNIC community seems reluctant to do 
> so.

Then tell them to come up with an alternative.  We're not going to

 - include RNIC/PI or something similar to it
 - pile abstraction layers or abstractions layers (the kDAPL approach)

so if the RNIC community can find anything better they should propose
it.  OTOH they're not even able to get a NIC driver OpenSource so I'm
not going to waste more time on them.
___
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] OpenIB scripts

[Hal Rosenstock]

> I'm fine with moving some of these scripts to trunk.

Which ones wouldn't be moved ?

> These are install scripts, they dont belong in either
> src/linux-kernel or src/userspace.

> What about at the top level, alongside src/?

Sounds OK to me.

Thanks.

-- Hal

___
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: [Rdma-developers] Meeting(07/22) summary:OpenRDMA community development discussion

[Sean Hefty]

Fab Tillier wrote:

Just for clarity, when you say verbs you exclude connection
establishment/management, right?


I refer to verbs as only those calls provided by the device driver, so I'm 
excluding CM, SA query, MAD services, etc.  For IB, it does include the 
creation of the special QPs.



Here's my take from the discussions so far:
- RNICs can probably be made to work under the IB verbs (with changes of
course).


I would go further and state that the RNIC community seems reluctant to do so.

- Sean
___
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] OpenIB scripts

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> I don't know if you saw this but can you respond to this on the list ?

No, I didnt see this.

> Thanks.
> 
> -- Hal
> 
> -Forwarded Message-
> 
> From: Hal Rosenstock <[EMAIL PROTECTED]>
> To: openib-general@openib.org
> Subject: [openib-general] [PATCH] OpenIB scripts
> Date: 27 Jul 2005 11:31:23 -0400
> 
> Add ucm to udev rules
> 
> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]
> 
> Also, should these (https://openib.org/svn/trunk/contrib/mellanox/) be
> moved to a gen2 location ?

I'm fine with moving some of these scripts to trunk.
These are install scripts, they dont belong in either
src/linux-kernel or src/userspace.

What about at the top level, alongside src/?

> Index: 90-ib.rules
> ===
> --- 90-ib.rules (revision 2917)
> +++ 90-ib.rules (working copy)
> @@ -1,3 +1,4 @@
>  KERNEL="umad*", NAME="infiniband/%k"
>  KERNEL="issm*", NAME="infiniband/%k"
> +KERNEL="ucm", NAME="infiniband/%k", MODE="0666"
>  KERNEL="uverbs*", NAME="infiniband/%k", MODE="0666"
> 
> 

Okay.

-- 
MST
___
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: [Rdma-developers] Meeting(07/22) summary:OpenRDMA community development discussion

[Fab Tillier]

> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 01, 2005 9:46 AM
> 
> Yaron Haviv wrote:
> > we can spend time and discuss theories and intentions, at the end of the
> > day an iWarp RNIC cannot just reside under IB-Verbs without major
> > changes to the overall infrastructure.
> 
> I don't disagree with having a common connection library that supports both
> IB and iWarp, or that you could derive a solution from kDAPL.  But based on
> the proposed APIs that I've seen, I believe that an RNIC could reside under
> IB verbs with minimal changes, and would likely be the best engineered
> solution for including RNIC support in Linux.

Just for clarity, when you say verbs you exclude connection
establishment/management, right?

I think keeping the two distinct is important in this discussion, as it seems
there is some confusion - some people refer to verbs as verbs + CM, others as
just verbs.

Here's my take from the discussions so far:
- RNICs can probably be made to work under the IB verbs (with changes of
course).
- RNICs can probably not be made to work under the IB CM (not that I've seen
this suggested).

- Fab

___
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: [Rdma-developers] Meeting (07/22)summary:OpenRDMA community development discussion

[Steve Wise]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Christoph Hellwig
> Sent: Monday, August 01, 2005 11:14 AM
> To: Talpey, Thomas
> Cc: [EMAIL PROTECTED]; openib-general@openib.org
> Subject: Re: [openib-general] Re: [Rdma-developers] Meeting 
> (07/22)summary:OpenRDMA community development discussion
> 
> On Mon, Aug 01, 2005 at 07:00:48AM -0400, Talpey, Thomas wrote:
> > At 06:49 AM 8/1/2005, Caitlin Bestler wrote:
> > >After that we need a standardized way to implement "modify qp
> > >to RTS" in a iWARP-centric fashion.
> > 
> > I will add that RPC/RDMA (NFS-RDMA) does not currently require this
> > functionality, it begins all connections in RDMA mode and 
> the current
> > DAPL semantics are fine for now. This functionality would 
> be of great
> > importance to iSER however, of course.
> > 
> > In the future, NFSv4/sessions has an exchange which can to make
> > use of the iWARP step-up mode, but it is not required and we have
> > deferred implementing it in the session establishment so far.
> 
> I think taking over an existing TCP connection is a horrible idea
> and we should avoid it if possible.  The state for a TCP connection
> is very complex and it's doubtfull we can make it work 100%.
> 

Christoph, 

Can you provide more details on exactly why you think this is a horrible
idea?  I agree it will be complex, but it _could_ be scoped such that the
complexity is reduced.  For instance, the "offload" function could fail
(with EBUSY or something) if there is _any_ data pending on the socket.
Thus removing any requirement to pass down pending unacked outgoing data, or
pending data that has been received but not yet "read" by the application.
The idea here is that the applications at the top "know" they are going into
RDMA mode and have effectively quiesced the connection before attempting to
move the connection into RDMA mode.  We could, in fact, _require_ the
connect be quiesced to keep things simpler.  I'm quickly sinking into gory
details, but I want to know if you have other reasons (other than the
complextity) for why this is a bad idea.


Stevo


___
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

[John Partridge]

Yes, that's right, but, I need to test it on ia32 too to make sure it
not break anything there .

John


Talpey, Thomas wrote:

It doesn't need two printk's, the one printk just needs
to have %lu as its format (instead of %ld), right?

Tom.


At 12:21 PM 8/1/2005, John Partridge wrote:


Hal,

No the patch did not fix the warnings :-

  CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_qp.o
  CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_util.o
  CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
	drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
`dapl_path_comp_handler':
	drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long 
long int format, u64 arg (arg 3)
	drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
`dapl_rt_comp_handler':
	drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long 
long int format, u64 arg (arg 3)


Let me look at it and I will produce a patch that fixes the build 
error and the warnings OK ?


Cheers
John


Hal Rosenstock wrote:


Hi John,

My normal email sending is not working right now so I am using an 


alternate method.


Hope the formatting comes through OK.

On Fri, 2005-07-29 at 17:46, John Partridge wrote:


With this fix the ia64 modules all build to completion with just a 
couple of warnings :-




 CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 


`dapl_path_comp_handler':

drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long 


long int format, u64 arg (arg 3)

drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 


`dapl_rt_comp_handler':

drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long 


long int format, u64 arg (arg 3)



Can you try this patch and see if it removes the warnings ?

Thanks.

-- Hal

Index: dapl_openib_cm.c
===
--- dapl_openib_cm.c(revision 2935)
+++ dapl_openib_cm.c(working copy)
@@ -341,9 +341,15 @@ static void dapl_path_comp_handler(u64 r
 &cm_ctx->dapl_path, 1,
 &cm_ctx->dapl_comp);
   if (status) {
+#if defined(__ia64__)
+   printk(KERN_ERR "dapl_path_comp_handler: "
+  "ib_at_paths_by_route returned %d id %ld\n",
+  status, cm_ctx->dapl_comp.req_id);
+#else
   printk(KERN_ERR "dapl_path_comp_handler: "
  "ib_at_paths_by_route returned %d id %lld\n",
  status, cm_ctx->dapl_comp.req_id);
+#endif
   event = DAT_CONNECTION_EVENT_BROKEN;
   goto error;
   }
@@ -412,8 +418,13 @@ static void dapl_rt_comp_handler(u64 req
   status = ib_at_paths_by_route(&cm_ctx->dapl_rt, 0, 


&cm_ctx->dapl_path, 1,


 &cm_ctx->dapl_comp);
   if (status) {
+#if defined(__ia64__)
+   printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
+  "returned %d id %ld\n", status, 


cm_ctx->dapl_comp.req_id);


+#else
   printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
  "returned %d id %lld\n", status, 


cm_ctx->dapl_comp.req_id);


+#endif
   event = DAT_CONNECTION_EVENT_BROKEN;
   goto error;
   }


--
John Partridge

Silicon Graphics Inc
Tel:  651-683-3428
Vnet: 233-3428
E-Mail: [EMAIL PROTECTED]
___
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




--
John Partridge

Silicon Graphics Inc
Tel:  651-683-3428
Vnet: 233-3428
E-Mail: [EMAIL PROTECTED]
___
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: [Rdma-developers] Meeting (07/22) summary:OpenRDMA community development discussion

[Sean Hefty]

Yaron Haviv wrote:

we can spend time and discuss theories and intentions, at the end of the
day an iWarp RNIC cannot just reside under IB-Verbs without major
changes to the overall infrastructure.


I don't disagree with having a common connection library that supports both 
IB and iWarp, or that you could derive a solution from kDAPL.  But based on 
the proposed APIs that I've seen, I believe that an RNIC could reside under 
IB verbs with minimal changes, and would likely be the best engineered 
solution for including RNIC support in Linux.


- Sean
___
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: kdapl build error on ia64

[Michael S. Tsirkin]

Quoting r. John Partridge <[EMAIL PROTECTED]>:
> >+#if defined(__ia64__)
> >+   printk(KERN_ERR "dapl_path_comp_handler: "
> >+  "ib_at_paths_by_route returned %d id %ld\n",
> >+  status, cm_ctx->dapl_comp.req_id);
> >+#else
> >printk(KERN_ERR "dapl_path_comp_handler: "
> >   "ib_at_paths_by_route returned %d id 
> >   %lld\n",
> >   status, cm_ctx->dapl_comp.req_id);
> >+#endif

Why dont you just cast req_id to long long and be done with it?

-- 
MST
___
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

[Talpey, Thomas]

At 12:28 PM 8/1/2005, Talpey, Thomas wrote:
>It doesn't need two printk's, the one printk just needs
>to have %lu as its format (instead of %ld), right?

I mean %llu. (long long)




>
>Tom.
>
>
>At 12:21 PM 8/1/2005, John Partridge wrote:
>>Hal,
>>
>>No the patch did not fix the warnings :-
>>
>>CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_qp.o
>>CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_util.o
>>CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
>>  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
>>`dapl_path_comp_handler':
>>  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long 
>>long int format, u64 arg (arg 3)
>>  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
>>`dapl_rt_comp_handler':
>>  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long 
>>long int format, u64 arg (arg 3)
>>
>>Let me look at it and I will produce a patch that fixes the build 
>>error and the warnings OK ?
>>
>>Cheers
>>John
>>
>>
>>Hal Rosenstock wrote:
>>> Hi John,
>>> 
>>> My normal email sending is not working right now so I am using an 
>>alternate method.
>>> Hope the formatting comes through OK.
>>> 
>>> On Fri, 2005-07-29 at 17:46, John Partridge wrote:
>>> 
With this fix the ia64 modules all build to completion with just a 
couple of warnings :-
>>> 
>>> 
   CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
>>`dapl_path_comp_handler':
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long 
>>long int format, u64 arg (arg 3)
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
>>`dapl_rt_comp_handler':
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long 
>>long int format, u64 arg (arg 3)
>>> 
>>> 
>>> Can you try this patch and see if it removes the warnings ?
>>> 
>>> Thanks.
>>> 
>>> -- Hal
>>> 
>>> Index: dapl_openib_cm.c
>>> ===
>>> --- dapl_openib_cm.c(revision 2935)
>>> +++ dapl_openib_cm.c(working copy)
>>> @@ -341,9 +341,15 @@ static void dapl_path_comp_handler(u64 r
>>>   &cm_ctx->dapl_path, 1,
>>>   &cm_ctx->dapl_comp);
>>> if (status) {
>>> +#if defined(__ia64__)
>>> +   printk(KERN_ERR "dapl_path_comp_handler: "
>>> +  "ib_at_paths_by_route returned %d id %ld\n",
>>> +  status, cm_ctx->dapl_comp.req_id);
>>> +#else
>>> printk(KERN_ERR "dapl_path_comp_handler: "
>>>"ib_at_paths_by_route returned %d id %lld\n",
>>>status, cm_ctx->dapl_comp.req_id);
>>> +#endif
>>> event = DAT_CONNECTION_EVENT_BROKEN;
>>> goto error;
>>> }
>>> @@ -412,8 +418,13 @@ static void dapl_rt_comp_handler(u64 req
>>> status = ib_at_paths_by_route(&cm_ctx->dapl_rt, 0, 
>>&cm_ctx->dapl_path, 1,
>>>   &cm_ctx->dapl_comp);
>>> if (status) {
>>> +#if defined(__ia64__)
>>> +   printk(KERN_ERR "dapl_rt_comp_handler: 
>ib_at_paths_by_route "
>>> +  "returned %d id %ld\n", status, 
>>cm_ctx->dapl_comp.req_id);
>>> +#else
>>> printk(KERN_ERR "dapl_rt_comp_handler: 
>ib_at_paths_by_route "
>>>"returned %d id %lld\n", status, 
>>cm_ctx->dapl_comp.req_id);
>>> +#endif
>>> event = DAT_CONNECTION_EVENT_BROKEN;
>>> goto error;
>>> }
>>
>>-- 
>>John Partridge
>>
>>Silicon Graphics Inc
>>Tel:  651-683-3428
>>Vnet: 233-3428
>>E-Mail: [EMAIL PROTECTED]
>>___
>>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 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 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

[Talpey, Thomas]

It doesn't need two printk's, the one printk just needs
to have %lu as its format (instead of %ld), right?

Tom.


At 12:21 PM 8/1/2005, John Partridge wrote:
>Hal,
>
>No the patch did not fix the warnings :-
>
> CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_qp.o
> CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_util.o
> CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
>   drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
>`dapl_path_comp_handler':
>   drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long 
>long int format, u64 arg (arg 3)
>   drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
>`dapl_rt_comp_handler':
>   drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long 
>long int format, u64 arg (arg 3)
>
>Let me look at it and I will produce a patch that fixes the build 
>error and the warnings OK ?
>
>Cheers
>John
>
>
>Hal Rosenstock wrote:
>> Hi John,
>> 
>> My normal email sending is not working right now so I am using an 
>alternate method.
>> Hope the formatting comes through OK.
>> 
>> On Fri, 2005-07-29 at 17:46, John Partridge wrote:
>> 
>>>With this fix the ia64 modules all build to completion with just a 
>>>couple of warnings :-
>> 
>> 
>>>   CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
>>>drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
>`dapl_path_comp_handler':
>>>drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long 
>long int format, u64 arg (arg 3)
>>>drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
>`dapl_rt_comp_handler':
>>>drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long 
>long int format, u64 arg (arg 3)
>> 
>> 
>> Can you try this patch and see if it removes the warnings ?
>> 
>> Thanks.
>> 
>> -- Hal
>> 
>> Index: dapl_openib_cm.c
>> ===
>> --- dapl_openib_cm.c(revision 2935)
>> +++ dapl_openib_cm.c(working copy)
>> @@ -341,9 +341,15 @@ static void dapl_path_comp_handler(u64 r
>>   &cm_ctx->dapl_path, 1,
>>   &cm_ctx->dapl_comp);
>> if (status) {
>> +#if defined(__ia64__)
>> +   printk(KERN_ERR "dapl_path_comp_handler: "
>> +  "ib_at_paths_by_route returned %d id %ld\n",
>> +  status, cm_ctx->dapl_comp.req_id);
>> +#else
>> printk(KERN_ERR "dapl_path_comp_handler: "
>>"ib_at_paths_by_route returned %d id %lld\n",
>>status, cm_ctx->dapl_comp.req_id);
>> +#endif
>> event = DAT_CONNECTION_EVENT_BROKEN;
>> goto error;
>> }
>> @@ -412,8 +418,13 @@ static void dapl_rt_comp_handler(u64 req
>> status = ib_at_paths_by_route(&cm_ctx->dapl_rt, 0, 
>&cm_ctx->dapl_path, 1,
>>   &cm_ctx->dapl_comp);
>> if (status) {
>> +#if defined(__ia64__)
>> +   printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
>> +  "returned %d id %ld\n", status, 
>cm_ctx->dapl_comp.req_id);
>> +#else
>> printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
>>"returned %d id %lld\n", status, 
>cm_ctx->dapl_comp.req_id);
>> +#endif
>> event = DAT_CONNECTION_EVENT_BROKEN;
>> goto error;
>> }
>
>-- 
>John Partridge
>
>Silicon Graphics Inc
>Tel:  651-683-3428
>Vnet: 233-3428
>E-Mail: [EMAIL PROTECTED]
>___
>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 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

[John Partridge]

Hal,

No the patch did not fix the warnings :-

  CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_qp.o
  CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_util.o
  CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
`dapl_path_comp_handler':
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long 
long int format, u64 arg (arg 3)
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
`dapl_rt_comp_handler':
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long 
long int format, u64 arg (arg 3)

Let me look at it and I will produce a patch that fixes the build error and the 
warnings OK ?

Cheers
John


Hal Rosenstock wrote:

Hi John,

My normal email sending is not working right now so I am using an alternate 
method.
Hope the formatting comes through OK.

On Fri, 2005-07-29 at 17:46, John Partridge wrote:

With this fix the ia64 modules all build to completion with just a 
couple of warnings :-




  CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
`dapl_path_comp_handler':
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long long int 
format, u64 arg (arg 3)
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
`dapl_rt_comp_handler':
drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long long int 
format, u64 arg (arg 3)



Can you try this patch and see if it removes the warnings ?

Thanks.

-- Hal

Index: dapl_openib_cm.c
===
--- dapl_openib_cm.c(revision 2935)
+++ dapl_openib_cm.c(working copy)
@@ -341,9 +341,15 @@ static void dapl_path_comp_handler(u64 r
  &cm_ctx->dapl_path, 1,
  &cm_ctx->dapl_comp);
if (status) {
+#if defined(__ia64__)
+   printk(KERN_ERR "dapl_path_comp_handler: "
+  "ib_at_paths_by_route returned %d id %ld\n",
+  status, cm_ctx->dapl_comp.req_id);
+#else
printk(KERN_ERR "dapl_path_comp_handler: "
   "ib_at_paths_by_route returned %d id %lld\n",
   status, cm_ctx->dapl_comp.req_id);
+#endif
event = DAT_CONNECTION_EVENT_BROKEN;
goto error;
}
@@ -412,8 +418,13 @@ static void dapl_rt_comp_handler(u64 req
status = ib_at_paths_by_route(&cm_ctx->dapl_rt, 0, &cm_ctx->dapl_path, 
1,
  &cm_ctx->dapl_comp);
if (status) {
+#if defined(__ia64__)
+   printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
+  "returned %d id %ld\n", status, 
cm_ctx->dapl_comp.req_id);
+#else
printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
   "returned %d id %lld\n", status, 
cm_ctx->dapl_comp.req_id);
+#endif
event = DAT_CONNECTION_EVENT_BROKEN;
goto error;
}


--
John Partridge

Silicon Graphics Inc
Tel:  651-683-3428
Vnet: 233-3428
E-Mail: [EMAIL PROTECTED]
___
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: [Rdma-developers] Meeting (07/22) summary:OpenRDMA community development discussion

[Christoph Hellwig]

On Mon, Aug 01, 2005 at 07:00:48AM -0400, Talpey, Thomas wrote:
> At 06:49 AM 8/1/2005, Caitlin Bestler wrote:
> >After that we need a standardized way to implement "modify qp
> >to RTS" in a iWARP-centric fashion.
> 
> I will add that RPC/RDMA (NFS-RDMA) does not currently require this
> functionality, it begins all connections in RDMA mode and the current
> DAPL semantics are fine for now. This functionality would be of great
> importance to iSER however, of course.
> 
> In the future, NFSv4/sessions has an exchange which can to make
> use of the iWARP step-up mode, but it is not required and we have
> deferred implementing it in the session establishment so far.

I think taking over an existing TCP connection is a horrible idea
and we should avoid it if possible.  The state for a TCP connection
is very complex and it's doubtfull we can make it work 100%.

___
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] kernel VM monitor for memory registration caching

[Roland Dreier]

Gleb> Correct. We invalidate nothing in nopage handler, but if
Gleb> pagefault happens in part of vma that is not registered we
Gleb> should call original nopage() handler for the nonregistered
Gleb> page.

Oh, I see.  I thought you were saying something else.  Yes, this seems
correct and necessary.

 - 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

Re: [openib-general] kernel VM monitor for memory registration caching

[Muli Ben-Yehuda]

On Mon, Aug 01, 2005 at 06:04:27PM +0300, Gleb Natapov wrote:

> I don't like the idea of splitting VMAs if we can manage without it. You'll 
> end up having to many of them.

... or you end up duplicating the VMA functionality on a sub-vma
level. Consider:

You have a single vma with some number of pages, where some random
pages are registered and some aren't. You need to be able to check for
a given page whetehr it's registered or not, so you build some data
structure based on the stard and end address (or page, or whatever),
so that you can check if a given address is within a registered
page. But this is exactly the sort of thing that the VMA level is
built for: use the red black tree to find the vma for a given address,
then check if the vma is registered.

Linux can already cope with a large number  of vma's, I think that a
solution that does not split vma's will end up with either artificial
limitations (can't have more than two different regions within a vma)
or reimplementing vma layer functionality. Of course, I could be
completely wrong :-)

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

___
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

[Eitan Zahavi]

Title: RE: [openib-general] link availability





If you would like to connect to InfiniBand HCA cards - 
All you need to do is 
1. attach an IB cable between them
2. have IB stack running on each one of the machines (might be any stack you want)
3. have an SM run on one of the machines.


My proposal is that depending on the kernel you have installed on the machines install OpenIB (if 2.6.11 or 2.6.12) stack or Mellanox IBGD or others (for the rest)

And then start OpenSM.  


Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL



> -Original Message-
> From: Ouissem BEN FREDJ [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 01, 2005 6:45 PM
> To: openib-general@openib.org
> Subject: [openib-general] link availability
> 
> 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.
> 
> Thank you,
> Ouissem Ben Fredj
> ___
> 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 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: [Rdma-developers] Meeting (07/22) summary:OpenRDMA community development discussion

[Yaron Haviv]

> -Original Message-
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 01, 2005 11:14 AM
> To: Yaron Haviv
> Cc: Christoph Hellwig; Tom Duffy; Venkata Jagana; rdma-
> [EMAIL PROTECTED]; openib-general@openib.org
> Subject: Re: [openib-general] Re: [Rdma-developers] Meeting (07/22)
> summary:OpenRDMA community development discussion
> 
> Yaron> It would probably be wise to try and merge that effort with
> Yaron> IB-verbs etc' (e.g. make the verbs portion of the API
> Yaron> closer), and on the same time preserve the effort that was
> Yaron> done in kDAPL to overcome the differences (e.g. in the CM,
> Yaron> addressing portions)
> 
> This doesn't seem like the right approach to me but we'll be happy to
> review your patches.

So how would you reconcile the differences between IB & iWarp, and
specifically on the connection establishment portion ?
In your approach would I need to access different CM APIs for IB & for
iWarp in my ULP ?

>From my perspective the current kDAPL solves that problem (w/o any
additional patches), and we are trying to re-invent the wheel here. 

If patches are really needed they can probably applied to the kDAPL code
(i.e. remove redundant code/simplify kDAPL), however this is an
optimization that can always be done later. 

Yaron

___
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

[Hal Rosenstock]

Hi,

Yes, you just need to cable them together and run an SM on one of the nodes.

-- Hal

-Original Message-
From: [EMAIL PROTECTED] on behalf of Ouissem BEN FREDJ
Sent: Mon 8/1/2005 11:45 AM
To: openib-general@openib.org
Subject: [openib-general] link availability
 
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.

Thank you,
Ouissem Ben Fredj
___
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 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] link availability

[Ouissem BEN FREDJ]

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.

Thank you,
Ouissem Ben Fredj
___
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] IB Port State Question

[Hal Rosenstock]

Hi Sean,

An SM (either OpenSM or an embedded SM) needs to move the ports from INIT to 
ACTIVE. If you have more than 2 endports (nodes), you will need an IB switch.

-- Hal

-Original Message-
From: [EMAIL PROTECTED] on behalf of Sean Hubbell
Sent: Mon 8/1/2005 9:43 AM
To: openib-general@openib.org
Subject: [openib-general] IB Port State Question
 
Hello,

  I am new to using infiniband and have a (probably) easy question. I 
have my head node and I checked the status of my infiniband port state 
and the state is ACTIVE. I do this for the rest of my node (which is 3 
other nodes) and each port state is INIT. How does one activate the port?


Thanks,

Sean
Running cAos 2.0 on multiple Xeon 64 Bit Machines.
___
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 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: [Rdma-developers] Meeting (07/22) summary:OpenRDMA community development discussion

[Roland Dreier]

Yaron> It would probably be wise to try and merge that effort with
Yaron> IB-verbs etc' (e.g. make the verbs portion of the API
Yaron> closer), and on the same time preserve the effort that was
Yaron> done in kDAPL to overcome the differences (e.g. in the CM,
Yaron> addressing portions)

This doesn't seem like the right approach to me but we'll be happy to
review your patches.

 - 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

Re: [openib-general] kernel VM monitor for memory registration caching

[Gleb Natapov]

On Mon, Aug 01, 2005 at 05:56:22PM +0300, Muli Ben-Yehuda wrote:
> On Mon, Aug 01, 2005 at 05:50:27PM +0300, Gleb Natapov wrote:
> 
> > Correct. We invalidate nothing in nopage handler, but if pagefault
> > happens in part of vma that is not registered we should call original
> > nopage() handler for the nonregistered page.
> 
> Why not split the VMA if we're regisgtering only a part of it? that
> way a VMA if either registered or not registered (up to a page size
> granularity).
> 
I don't like the idea of splitting VMAs if we can manage without it. You'll 
end up having to many of them.

--
Gleb.
___
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] kernel VM monitor for memory registration caching

[Muli Ben-Yehuda]

On Mon, Aug 01, 2005 at 05:50:27PM +0300, Gleb Natapov wrote:

> Correct. We invalidate nothing in nopage handler, but if pagefault
> happens in part of vma that is not registered we should call original
> nopage() handler for the nonregistered page.

Why not split the VMA if we're regisgtering only a part of it? that
way a VMA if either registered or not registered (up to a page size
granularity).

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

___
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] kernel VM monitor for memory registration caching

[Gleb Natapov]

On Mon, Aug 01, 2005 at 07:43:33AM -0700, Roland Dreier wrote:
> Gleb> Why? Is that what you had in mind?
> 
> Yes, if I'm understanding your suggestion correctly, it is exactly
> what I suggested in http://article.gmane.org/gmane.linux.drivers.openib/13223
> 
Yes, they are indeed the same :)

> Gleb> This was right for vapi modules since after mlock() vma
> Gleb> boundaries was aligned with registration boundaries, but
> Gleb> this is not the case for OpenIB (correct me if I am wrong
> Gleb> here). Part of the vma can be pinned and thus be in memory
> Gleb> but other parts may be swapped out.
> 
> But the pages that aren't pinned are not part of any registered
> region, right?  So there's no reason to invalidate any registration
> because of nopage activitiy.

Correct. We invalidate nothing in nopage handler, but if pagefault
happens in part of vma that is not registered we should call original
nopage() handler for the nonregistered page.

--
Gleb.
___
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] kernel VM monitor for memory registration caching

[Roland Dreier]

Gleb> Why? Is that what you had in mind?

Yes, if I'm understanding your suggestion correctly, it is exactly
what I suggested in http://article.gmane.org/gmane.linux.drivers.openib/13223

Gleb> This was right for vapi modules since after mlock() vma
Gleb> boundaries was aligned with registration boundaries, but
Gleb> this is not the case for OpenIB (correct me if I am wrong
Gleb> here). Part of the vma can be pinned and thus be in memory
Gleb> but other parts may be swapped out.

But the pages that aren't pinned are not part of any registered
region, right?  So there's no reason to invalidate any registration
because of nopage activitiy.

 - 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

[openib-general] IB Port State Question

[Sean Hubbell]

Hello,

 I am new to using infiniband and have a (probably) easy question. I 
have my head node and I checked the status of my infiniband port state 
and the state is ACTIVE. I do this for the rest of my node (which is 3 
other nodes) and each port state is INIT. How does one activate the port?



Thanks,

Sean
Running cAos 2.0 on multiple Xeon 64 Bit Machines.
___
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

[Hal Rosenstock]

Hi John,

My normal email sending is not working right now so I am using an alternate 
method.
Hope the formatting comes through OK.

On Fri, 2005-07-29 at 17:46, John Partridge wrote:
> With this fix the ia64 modules all build to completion with just a 
> couple of warnings :-

>CC [M]  drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.o
> drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
> `dapl_path_comp_handler':
> drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:346: warning: long long int 
> format, u64 arg (arg 3)
> drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c: In function 
> `dapl_rt_comp_handler':
> drivers/infiniband/ulp/kdapl/ib/dapl_openib_cm.c:416: warning: long long int 
> format, u64 arg (arg 3)

Can you try this patch and see if it removes the warnings ?

Thanks.

-- Hal

Index: dapl_openib_cm.c
===
--- dapl_openib_cm.c(revision 2935)
+++ dapl_openib_cm.c(working copy)
@@ -341,9 +341,15 @@ static void dapl_path_comp_handler(u64 r
  &cm_ctx->dapl_path, 1,
  &cm_ctx->dapl_comp);
if (status) {
+#if defined(__ia64__)
+   printk(KERN_ERR "dapl_path_comp_handler: "
+  "ib_at_paths_by_route returned %d id %ld\n",
+  status, cm_ctx->dapl_comp.req_id);
+#else
printk(KERN_ERR "dapl_path_comp_handler: "
   "ib_at_paths_by_route returned %d id %lld\n",
   status, cm_ctx->dapl_comp.req_id);
+#endif
event = DAT_CONNECTION_EVENT_BROKEN;
goto error;
}
@@ -412,8 +418,13 @@ static void dapl_rt_comp_handler(u64 req
status = ib_at_paths_by_route(&cm_ctx->dapl_rt, 0, &cm_ctx->dapl_path, 
1,
  &cm_ctx->dapl_comp);
if (status) {
+#if defined(__ia64__)
+   printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
+  "returned %d id %ld\n", status, 
cm_ctx->dapl_comp.req_id);
+#else
printk(KERN_ERR "dapl_rt_comp_handler: ib_at_paths_by_route "
   "returned %d id %lld\n", status, 
cm_ctx->dapl_comp.req_id);
+#endif
event = DAT_CONNECTION_EVENT_BROKEN;
goto error;
}
___
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] SDP_IOCB_SIZE_MAX

[Michael S. Tsirkin]

Libor, in sdp_iocb.h we have:

sdp_iocb.h:#define SDP_IOCB_SIZE_MAX (128*1024) /* matches AIO max kvec size. */

What does the comment mean?

I seem to have no trouble passing requests bigger than 128K to SDP:

./ttcp.aio.x -r -l 100 -a 20
./ttcp.aio.x -t -l 100 -n 100 -a 20 11.4.8.155

gets:

# dmesg
ib_sdp  ERR: IOCB <0> cancel <0> flag <0140> size <100:0:100>
ib_sdp  ERR: IOCB <0> cancel <0> flag <0140> size <100:0:100>
ib_sdp  ERR: IOCB <0> cancel <0> flag <0140> size <100:0:100>


-- 
MST
___
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] kernel VM monitor for memory registration caching

[Gleb Natapov]

On Mon, Aug 01, 2005 at 06:12:24AM -0700, Roland Dreier wrote:
> Gleb>  First of all, you have one user_delta per mm that user can
> Gleb> poll from userspace. Is it possible to make user_delta to be
> Gleb> part of dreg_region instead of dreg_context and module will
> Gleb> set it whenever registration becomes invalid. Field
> Gleb> 'invalid' will be added to buf_info structure and pointer to
> Gleb> it will be passed to kernel at registration time.  This way
> Gleb> the userpace can look up cache and check if registration is
> Gleb> still valid. No need to rescan cache from userspace, we
> Gleb> already scanned it once from kernel after all. With your
> Gleb> current approach userspace will need to search for mr_handle
> Gleb> in the cache and invalidate the entry that holds it.
> 
> That idea sounds familiar ;)
Why? Is that what you had in mind?

> 
> Gleb>  You change vma_ops in vma to catch open/close events. What
> Gleb> about nopage() method in vma_ops? We have to forward it to
> Gleb> original vma_ops?
> 
> Can nopage ever affect registered memory?  The registration process
> makes sure the pages are resident and pinned, so I don't see how a
> region's mapping could ever be changed by a call to a vma's nopage method.
> 
This was right for vapi modules since after mlock() vma boundaries was
aligned with registration boundaries, but this is not the case for
OpenIB (correct me if I am wrong here). Part of the vma can be pinned and thus 
be in memory but other parts may be swapped out.

--
Gleb.
___
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 updated] sdp: cancel read with no iocb

[Michael S. Tsirkin]

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.

---

Remove sdp_warn for a legal condition.

Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Index: linux-2.6.12.2/drivers/infiniband/ulp/sdp/sdp_recv.c
===
--- linux-2.6.12.2.orig/drivers/infiniband/ulp/sdp/sdp_recv.c
+++ linux-2.6.12.2/drivers/infiniband/ulp/sdp/sdp_recv.c
@@ -942,8 +942,8 @@ static int sdp_inet_read_cancel(struct k
 * no IOCB found. The cancel is probably in a race with a completion.
 * Assume the IOCB will be completed, return appropriate value.
 */
-   sdp_warn("Cancel read with no IOCB. <%d:%d:%08lx>",
-req->ki_users, req->ki_key, req->ki_flags);
+   sdp_dbg_ctrl(NULL, "Cancel read with no IOCB. <%d:%d:%08lx>",
+req->ki_users, req->ki_key, req->ki_flags);
 
result = -EAGAIN;

-- 
MST
___
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] kernel VM monitor for memory registration caching

[Roland Dreier]

Gleb>  First of all, you have one user_delta per mm that user can
Gleb> poll from userspace. Is it possible to make user_delta to be
Gleb> part of dreg_region instead of dreg_context and module will
Gleb> set it whenever registration becomes invalid. Field
Gleb> 'invalid' will be added to buf_info structure and pointer to
Gleb> it will be passed to kernel at registration time.  This way
Gleb> the userpace can look up cache and check if registration is
Gleb> still valid. No need to rescan cache from userspace, we
Gleb> already scanned it once from kernel after all. With your
Gleb> current approach userspace will need to search for mr_handle
Gleb> in the cache and invalidate the entry that holds it.

That idea sounds familiar ;)

Gleb>  You change vma_ops in vma to catch open/close events. What
Gleb> about nopage() method in vma_ops? We have to forward it to
Gleb> original vma_ops?

Can nopage ever affect registered memory?  The registration process
makes sure the pages are resident and pinned, so I don't see how a
region's mapping could ever be changed by a call to a vma's nopage method.

 - 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

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

[Caitlin Bestler]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Talpey, Thomas
> Sent: Monday, August 01, 2005 4:01 AM
> To: openib-general@openib.org
> Cc: [EMAIL PROTECTED]
> Subject: RE: [openib-general] Re: [Rdma-developers] Meeting 
> (07/22) summary:OpenRDMA community development discussion
> 
> At 06:49 AM 8/1/2005, Caitlin Bestler wrote:
> >After that we need a standardized way to implement "modify 
> qp to RTS" 
> >in a iWARP-centric fashion.
> 
> I will add that RPC/RDMA (NFS-RDMA) does not currently 
> require this functionality, it begins all connections in RDMA 
> mode and the current DAPL semantics are fine for now. This 
> functionality would be of great importance to iSER however, of course.
> 
> In the future, NFSv4/sessions has an exchange which can to 
> make use of the iWARP step-up mode, but it is not required 
> and we have deferred implementing it in the session 
> establishment so far.
> 

Which points out the other rationale, that I forgot to mention,
many applications require only the DAPL-mode connection setup
and enabling them immediately make sense. It also avoids rushing
the TCP connection transfer discussion since most applications
will be operational.
___
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: [Rdma-developers] Meeting (07/22) summary:OpenRDMA community development discussion

[Talpey, Thomas]

At 06:49 AM 8/1/2005, Caitlin Bestler wrote:
>After that we need a standardized way to implement "modify qp
>to RTS" in a iWARP-centric fashion.

I will add that RPC/RDMA (NFS-RDMA) does not currently require this
functionality, it begins all connections in RDMA mode and the current
DAPL semantics are fine for now. This functionality would be of great
importance to iSER however, of course.

In the future, NFSv4/sessions has an exchange which can to make
use of the iWARP step-up mode, but it is not required and we have
deferred implementing it in the session establishment so far.

Tom.
___
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: [Rdma-developers] Meeting (07/22) summary:OpenRDMA community development discussion

[Caitlin Bestler]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Yaron Haviv
> Sent: Sunday, July 31, 2005 8:57 PM
> To: Christoph Hellwig; Tom Duffy
> Cc: Venkata Jagana; [EMAIL PROTECTED]; 
> openib-general@openib.org
> Subject: RE: [openib-general] Re: [Rdma-developers] Meeting 
> (07/22) summary:OpenRDMA community development discussion
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:openib-general- 
> > [EMAIL PROTECTED] On Behalf Of Christoph Hellwig
> > Sent: Friday, July 29, 2005 8:02 AM
> > To: Tom Duffy
> > Cc: Venkata Jagana; [EMAIL PROTECTED]; 
> Christoph 
> > Hellwig; openib-general@openib.org
> > Subject: [openib-general] Re: [Rdma-developers] Meeting (07/22) 
> > summary:OpenRDMA community development discussion
> > 
> > On Thu, Jul 28, 2005 at 02:02:08PM -0700, Tom Duffy wrote:
> > > At OLS (and in previous forums), the kernel maintainers 
> have made it
> > > *very* clear that there should only be one API.
> > 
> > _and_ that this api is neither RNIC-PI or KDAPL.  In fact 
> for anything 
> > that doesn't look very similar to the current IB midlayer 
> you'd need 
> > very convincing arguments.
> > 
> 
> I assume it is not as simplistic as that iWarp CM model is 
> quite different than IB, and iWarp doesn't have SA/SM and a 
> bunch of other IB specific things 
> 
> For example: 
> The correct common abstraction is one where a user can issue 
> a connection by using a logical end-point address (such as an 
> IP), and doesn't have to deal with the IB or iWarp specific 
> CM state machine or SA/SM. 
> 
> If you look at DAPL you can break it to simple Verbs (e.g. 
> send, ..) where its just a simple overlay on to of the verbs 
> (and may be
> redundant)
> However there is a second part that implements a simple 
> connection establishment model (much like BSD) that can be 
> mapped to both IB (CM, SA, ..) or iWarp (TCP Syn/SynAck, ARP, 
> etc'), this serves couple of main
> purposes:
> a. make it simple for ULP developer and put the complex part 
> in a common
> place   
> b. define a common model for different HW
> 
> we can spend time and discuss theories and intentions, at the 
> end of the day an iWarp RNIC cannot just reside under 
> IB-Verbs without major changes to the overall infrastructure.
> Several guys spent some time looking it over and came with an 
> abstraction that IS possible on top of IB & iWarp & foo, that 
> is called DAPL (or IT as another similar alternative)
> 
> It would probably be wise to try and merge that effort with 
> IB-verbs etc' 
> (e.g. make the verbs portion of the API closer), and on the 
> same time preserve the effort that was done in kDAPL to 
> overcome the differences (e.g. in the CM, addressing portions)
> 

The working theory is that two additional connection management
'verbs' will be proposed, both optional.

The first is a straight-forward mapping of the traditional DAT
connection establishment: i.e., do whatever you have to do in
order to listen, request a connection, accept/reject connection
requests. This is an interface that can map to existing iWARP
implementations very easily while not immediately standardizing
integration with the host TCP stack.

Connection Requests are reported in this model, but via callbacks
rather than EVDs, since it is desired to keep a verb layer interface
more spartan than kDAPL. However, the fact that connection requests
must be approved allows blocking of all requests that conflict
with host policy (as expressed in packet filtering rules).

It is also an interface that IB vendors *could* support, because
DAPL implements over IB. We could consider having a default
implementation of the methods from the DAPL code for that
purpose.

After that we need a standardized way to implement "modify qp
to RTS" in a iWARP-centric fashion. This will require agreement
on how to transfer the TCP state from the host stack to the
RNIC. This is the more flexible model that matches RDMAC
verbs and supports all connection establishment models, 
including iSER. It is inherently iWARP specific, however,
since IB connections do not start their life as TCP
connections. 

The benefit of this second additional API is that the 
preserves *all* host stack safeguards on connection 
establishment because the host stack actually establishes
the TCP connection. It does require agreement on the correct
way to extract the TCP connection from the host stack,
however. This is something that existing deployments
already do, but they aren't doing it in mainline code.
Reaching consensus on a sustainable interface for doing
this is certainly worthy of careful consideration, which
is why the first additional DAT-style API will be proposed.
___
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] sdp: cancel read with no iocb

[Michael S. Tsirkin]

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?

---

Remove sdp_warn for a legal condition.

Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Index: linux-2.6.12.2/drivers/infiniband/ulp/sdp/sdp_recv.c
===
--- linux-2.6.12.2.orig/drivers/infiniband/ulp/sdp/sdp_recv.c
+++ linux-2.6.12.2/drivers/infiniband/ulp/sdp/sdp_recv.c
@@ -942,8 +942,8 @@ static int sdp_inet_read_cancel(struct k
 * no IOCB found. The cancel is probably in a race with a completion.
 * Assume the IOCB will be completed, return appropriate value.
 */
-   sdp_warn("Cancel read with no IOCB. <%d:%d:%08lx>",
-req->ki_users, req->ki_key, req->ki_flags);
+   sdp_dbg_ctrl("Cancel read with no IOCB. <%d:%d:%08lx>",
+req->ki_users, req->ki_key, req->ki_flags);
 
result = -EAGAIN;


-- 
MST
___
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: [Rdma-developers] Meeting (07/22) summary:OpenRDMA community development discussion

[Venkata Jagana]

[EMAIL PROTECTED] wrote
on 07/29/2005 03:52:56 PM:

> On Fri, 29 Jul 2005 15:59:03 -0400 (EDT)
> James Lentini <[EMAIL PROTECTED]> wrote:
> 
> > 
> > 
> > On Fri, 29 Jul 2005, Woodruff, Robert J wrote:
> > 
> > > Venkat wrote,
> > >> If anyone attended any one of the summits (netconf or
kernel) and
> > >> would be great if they can shed some light on this discussion.
> > >
> > > Roland attended the kernel summit and he was
> > > also at the InfiniBand BOF where we discussed
> > > the possibility of modifying the
> > > IB verbs to also support iWarp as probably the right way
to
> > > go. Not sure if this was discussed at the kernel summit
or not,
> > > but perhaps Roland can provide some insight on that question.
> > 
> > The subject came up at the kernel summit when Jamal Hadi Salim

> > reported on the presentations at Netconf, in particular Stephen

> > Hemminger's, see http://vger.kernel.org/netconf2005.html).
> > 
> > It was noted that iWARP vendors are working with the OpenIB community

> > on a common interface. The consensus was that this is the right

> > direction.
> >
> 
> The consensus was more of wait and see what comes up.  My discussion
> at netconf was more of an informative session to get the participants
to
> know that activity is going on and some code may be coming. It was
all
> of 5 minutes at the end of a busy day, so it didn't count for much.
>

Thanks Stephen for clarifying this. 

Yes, the basic code base in OpenRDMA is currently
available
for people to start hacking. My hope is that within
next few months
we'll also have some rnic driver available so that
the basic set of
enablement layers within both user and kernel space
can be experimented
with.

Thanks
Venkat___
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