Subject: [BEEPwg] BEEP over Infiniband

From: Vikas Deolaliker <[email-masked]>
Date: Tue, 26 Sep 2006 14:49:28 -0700 (PDT)

Has anybody implemented/heard about BEEP over Infiniband? Given that IB gives a full L2/L3 fabric and BEEP everything else, we could use this combination to speed up various applications in SOA/Web2.0 space.

Love to hear the group's thoughts on this. 

Thanks

Vikas Deolaliker

_______________________________________________
BEEPwg mailing list
[email-masked]
http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg

---

From: Marshall Rose <[email-masked]>
Date: Wed, 27 Sep 2006 12:55:00 +0100

> Has anybody implemented/heard about BEEP over Infiniband? Given  
> that IB gives a full L2/L3 fabric and BEEP everything else, we  
> could use this combination to speed up various applications in SOA/ 
> Web2.0 space.
>

is there a transport layer between beep and infiniband that provides  
the things that tcp provides? am i missing something?

/mtr

---

From: Vijay Saraswat <[email-masked]>
Date: Wed, 27 Sep 2006 08:51:04 -0400

Marshall Rose wrote:

>> Has anybody implemented/heard about BEEP over Infiniband? Given  that 
>> IB gives a full L2/L3 fabric and BEEP everything else, we  could use 
>> this combination to speed up various applications in SOA/ Web2.0 space.
>>

(I had sent this pointer to the list earlier...)

http://www.emsl.pnl.gov/docs/parsoft/armci/

(There is also GASNet from Berkeley.)

Its not TCP, but its worth looking at whether a BEEP-like protocol might 
be layered on top.

IBM also has a LAPI product (low-level API) which should be available on 
Linux as well soon.

---

From: Marshall Rose <[email-masked]>
Date: Wed, 27 Sep 2006 14:13:17 +0100

> Its not TCP, but its worth looking at whether a BEEP-like protocol  
> might be layered on top.
>
> IBM also has a LAPI product (low-level API) which should be  
> available on Linux as well soon.

interesting. you can certainly layer beep on top of a messaging  
passing api, providing it gives you ordered, reliable delivery.  
presumably, you wouldn't need any flow management for the channels.  
so, this leaves the performance issue down to using the default  
content-transfer-encoding when moving data.

/mtr