[ewg] RE: [PATCH 0/4]: add kfifo from upstream for SLES9 & RH4

[Vladimir Sokolovsky]

> -Original Message-
> From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 30, 2007 5:12 PM
> To: Erez Zilber
> Cc: Michael S. Tsirkin; Steve Wise; Vladimir Sokolovsky;
> ewg@lists.openfabrics.org
> Subject: Re: [PATCH 0/4]: add kfifo from upstream for SLES9 & RH4
> 
> > The following patches add kfifo to ibcore (for SLES9 & RH4). kfifo
is
> taken from upstream code.
> 
> Thanks, applied to 1.2.c and ofed_kernel.
> Vlad already took 1.2.c, and will I guess take ofed_kernel
> after it passes his checks.
> 
> --
> MST

Compilation passed.
~vlad/ofed_kernel.git updated


Regards,
Vladimir


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

Re: [ewg] Re: [ofa-general] reminder: OFED meeting today at 9am PST

[Jeff Squyres]

On Jul 30, 2007, at 7:10 PM, Steve Wise wrote:

Yes, you missed it; the call was over about half an hour ago.  I  
[re-]posted the dial-in info about 3 hours before the call this  
morning on the ewg list.


I see.  That's why I missed it. I'm not on the ewg list.

Are all attendees expected to be on the ewg list?


It's an OFED-specific call, so I generally post the call info just to  
the EWG list (there's been some backlash before about posting OFED- 
specific stuff on the general list and/or not on the ewg list).


--
Jeff Squyres
Cisco Systems

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

Re: [ewg] Re: [ofa-general] reminder: OFED meeting today at 9am PST

[Steve Wise]

Jeff Squyres wrote:
Yes, you missed it; the call was over about half an hour ago.  I 
[re-]posted the dial-in info about 3 hours before the call this morning 
on the ewg list.




I see.  That's why I missed it. I'm not on the ewg list.

Are all attendees expected to be on the ewg list?


Steve.




On Jul 30, 2007, at 12:55 PM, Steve Wise wrote:

Am I missing the call info?  I tried an older conf id, and it didn't 
work.  Can you please post the conf call info along with the meeting 
notification?


Thanks,

Steve.


Tziporet Koren wrote:

Hi All,
We will have our bi-weekly OFED meeting today at 9am PST
Agenda:
- Status update
- Bugzilla cleanup
If you have more agenda items please send them
Tziporet
___
general mailing list
[EMAIL PROTECTED]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit 
http://openib.org/mailman/listinfo/openib-general


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg





___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

Re: [ewg] Re: [ofa-general] reminder: OFED meeting today at 9am PST

[Jeff Squyres]

[shrug]  I sent it today at 8:21am US Eastern time:

http://lists.openfabrics.org/pipermail/ewg/2007-July/004075.html

Maybe check your spam folder?



On Jul 30, 2007, at 3:18 PM, Parks Fields wrote:


At 11:03 AM 7/30/2007, Jeff Squyres wrote:
Yes, you missed it; the call was over about half an hour ago.  I  
[re-] posted the dial-in info about 3 hours before the call this  
morning on

the ewg list.




I am on the EWG list and didn't see it. :-(





On Jul 30, 2007, at 12:55 PM, Steve Wise wrote:


Am I missing the call info?  I tried an older conf id, and it
didn't work.  Can you please post the conf call info along with the
meeting notification?

Thanks,

Steve.


Tziporet Koren wrote:

Hi All,
We will have our bi-weekly OFED meeting today at 9am PST
Agenda:
- Status update
- Bugzilla cleanup
If you have more agenda items please send them
Tziporet
___
general mailing list
[EMAIL PROTECTED]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/  
openib-general


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg



--
Jeff Squyres
Cisco Systems

___
general mailing list
[EMAIL PROTECTED]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

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


   * Correspondence *

This email contains no programmatic content that requires  
independent ADC review



--
Jeff Squyres
Cisco Systems

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

Re: [ewg] Re: [ofa-general] reminder: OFED meeting today at 9am PST

[Parks Fields]

At 11:03 AM 7/30/2007, Jeff Squyres wrote:
Yes, you missed it; the call was over about half an hour ago.  I 
[re-] posted the dial-in info about 3 hours before the call this morning on

the ewg list.




I am on the EWG list and didn't see it. :-(





On Jul 30, 2007, at 12:55 PM, Steve Wise wrote:


Am I missing the call info?  I tried an older conf id, and it
didn't work.  Can you please post the conf call info along with the
meeting notification?

Thanks,

Steve.


Tziporet Koren wrote:

Hi All,
We will have our bi-weekly OFED meeting today at 9am PST
Agenda:
- Status update
- Bugzilla cleanup
If you have more agenda items please send them
Tziporet
___
general mailing list
[EMAIL PROTECTED]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/ 
openib-general


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg



--
Jeff Squyres
Cisco Systems

___
general mailing list
[EMAIL PROTECTED]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

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


   * Correspondence *

This email contains no programmatic content that requires independent 
ADC review  



___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

Re: [ewg] Re: [ofa-general] reminder: OFED meeting today at 9am PST

[Jeff Squyres]

Yes, you missed it; the call was over about half an hour ago.  I [re-] 
posted the dial-in info about 3 hours before the call this morning on  
the ewg list.



On Jul 30, 2007, at 12:55 PM, Steve Wise wrote:

Am I missing the call info?  I tried an older conf id, and it  
didn't work.  Can you please post the conf call info along with the  
meeting notification?


Thanks,

Steve.


Tziporet Koren wrote:

Hi All,
We will have our bi-weekly OFED meeting today at 9am PST
Agenda:
- Status update
- Bugzilla cleanup
If you have more agenda items please send them
Tziporet
___
general mailing list
[EMAIL PROTECTED]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/ 
openib-general


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg



--
Jeff Squyres
Cisco Systems

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] reminder: OFED meeting today at 9am PST

[Steve Wise]

Am I missing the call info?  I tried an older conf id, and it didn't 
work.  Can you please post the conf call info along with the meeting 
notification?


Thanks,

Steve.


Tziporet Koren wrote:

Hi All,

We will have our bi-weekly OFED meeting today at 9am PST

Agenda:
- Status update
- Bugzilla cleanup

If you have more agenda items please send them

Tziporet
___
general mailing list
[EMAIL PROTECTED]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

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


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [PATCH 0/4]: add kfifo from upstream for SLES9 & RH4

[Michael S. Tsirkin]

> The following patches add kfifo to ibcore (for SLES9 & RH4). kfifo is taken 
> from upstream code.

Thanks, applied to 1.2.c and ofed_kernel.
Vlad already took 1.2.c, and will I guess take ofed_kernel
after it passes his checks.

-- 
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] reminder: OFED meeting today at 9am PST

[Tziporet Koren]

Hi All,

We will have our bi-weekly OFED meeting today at 9am PST

Agenda:
- Status update
- Bugzilla cleanup

If you have more agenda items please send them

Tziporet
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: Why isn't kfifo get built with ib-core for RH4?

[Steve Wise]

Michael S. Tsirkin wrote:

Quoting Erez Zilber <[EMAIL PROTECTED]>:
Subject: Why isn't kfifo get built with ib-core for RH4?

Michael,


I saw that kfifo that was built with ib-core for RH4 was removed:


http://www2.openfabrics.org/git/?p=~vlad/ofed_kernel.git;a=commit;h=afe4186a2b383e58d9937d0b2fe2ddfb03cd7268


I can't think of a reason. Likely just an oversight.


Why was it removed? open-iscsi cannot be loaded without it. If nobody
else is using it,


This was added here:
ac758ec6bff062844a5a42141aa5da492b2cb02b
so I think it's needed by Chelsio.
Steve?



Yes the chelsio rdma driver uses kfifos.


I can move it to iscsi_scsi_addons.patch and build it
with libiscsi.


I think we should just re-add it in core. Patch?

While we are at it: as a separate cleanup,
can you please remove the file from kernel_addons/./backport
and just check out the file from kernel/kfifo.c.
Just like we do with e.g. klist.c. OK?



___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] [PATCH 2/2] IB/iser: move open-iscsi crypto functions to kernel_addons (RHEL4)

[Erez Zilber]

move open-iscsi crypto functions to kernel_addons (RHEL4)

Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>
---
 .../backport/2.6.9_U3/include/linux/crypto.h   |   55 ++--
 .../backport/2.6.9_U4/include/linux/crypto.h   |   55 ++--
 .../backport/2.6.9_U5/include/linux/crypto.h   |   55 ++--
 .../backport/2.6.9_U3/add_open_iscsi.patch |   94 
 .../backport/2.6.9_U4/add_open_iscsi.patch |   94 
 .../backport/2.6.9_U5/add_open_iscsi.patch |   94 
 6 files changed, 147 insertions(+), 300 deletions(-)

diff --git a/kernel_addons/backport/2.6.9_U3/include/linux/crypto.h 
b/kernel_addons/backport/2.6.9_U3/include/linux/crypto.h
index aecccde..0f02f6f 100644
--- a/kernel_addons/backport/2.6.9_U3/include/linux/crypto.h
+++ b/kernel_addons/backport/2.6.9_U3/include/linux/crypto.h
@@ -1,11 +1,54 @@
-#ifndef LINUX_CRYPTO_BACKPORT_H
-#define LINUX_CRYPTO_BACKPORT_H
+#ifndef BACKPORT_LINUX_CRYPTO_H
+#define BACKPORT_LINUX_CRYPTO_H
 
 #include_next 
 
-#define crypto_hash_init(desc) crypto_digest_init(*desc)
-#define crypto_hash_digest(desc, sg, nbytes, out) crypto_digest_digest(*desc, 
sg, 1, out)
-#define crypto_hash_update(desc, sg, nbytes) crypto_digest_update(*desc, sg, 1)
-#define crypto_hash_final(desc, out) crypto_digest_final(*desc, out)
+#define CRYPTO_ALG_ASYNC   0x0080
+
+struct hash_desc
+{
+   struct crypto_tfm *tfm;
+   u32 flags;
+};
+
+static inline int crypto_hash_init(struct hash_desc *desc)
+{
+   crypto_digest_init(desc->tfm);
+   return 0;
+}
+
+static inline int crypto_hash_digest(struct hash_desc *desc,
+struct scatterlist *sg,
+unsigned int nbytes, u8 *out)
+{
+   crypto_digest_digest(desc->tfm, sg, (nbytes+(PAGE_SIZE-1)) / PAGE_SIZE, 
out);
+   return nbytes;
+}
+
+static inline int crypto_hash_update(struct hash_desc *desc,
+struct scatterlist *sg,
+unsigned int nbytes)
+{
+   crypto_digest_update(desc->tfm, sg, (nbytes+(PAGE_SIZE-1)) / PAGE_SIZE);
+   return nbytes;
+}
+
+static inline int crypto_hash_final(struct hash_desc *desc, u8 *out)
+{
+   crypto_digest_final(desc->tfm, out);
+   return 0;
+}
+
+static inline struct crypto_tfm *crypto_alloc_hash(const char *alg_name,
+   u32 type, u32 mask)
+{
+   struct crypto_tfm *ret = crypto_alloc_tfm(alg_name ,type);
+   return ret ? ret : ERR_PTR(-ENOMEM);
+}
+
+static inline void crypto_free_hash(struct crypto_tfm *tfm)
+{
+   crypto_free_tfm(tfm);
+}
 
 #endif
diff --git a/kernel_addons/backport/2.6.9_U4/include/linux/crypto.h 
b/kernel_addons/backport/2.6.9_U4/include/linux/crypto.h
index aecccde..0f02f6f 100644
--- a/kernel_addons/backport/2.6.9_U4/include/linux/crypto.h
+++ b/kernel_addons/backport/2.6.9_U4/include/linux/crypto.h
@@ -1,11 +1,54 @@
-#ifndef LINUX_CRYPTO_BACKPORT_H
-#define LINUX_CRYPTO_BACKPORT_H
+#ifndef BACKPORT_LINUX_CRYPTO_H
+#define BACKPORT_LINUX_CRYPTO_H
 
 #include_next 
 
-#define crypto_hash_init(desc) crypto_digest_init(*desc)
-#define crypto_hash_digest(desc, sg, nbytes, out) crypto_digest_digest(*desc, 
sg, 1, out)
-#define crypto_hash_update(desc, sg, nbytes) crypto_digest_update(*desc, sg, 1)
-#define crypto_hash_final(desc, out) crypto_digest_final(*desc, out)
+#define CRYPTO_ALG_ASYNC   0x0080
+
+struct hash_desc
+{
+   struct crypto_tfm *tfm;
+   u32 flags;
+};
+
+static inline int crypto_hash_init(struct hash_desc *desc)
+{
+   crypto_digest_init(desc->tfm);
+   return 0;
+}
+
+static inline int crypto_hash_digest(struct hash_desc *desc,
+struct scatterlist *sg,
+unsigned int nbytes, u8 *out)
+{
+   crypto_digest_digest(desc->tfm, sg, (nbytes+(PAGE_SIZE-1)) / PAGE_SIZE, 
out);
+   return nbytes;
+}
+
+static inline int crypto_hash_update(struct hash_desc *desc,
+struct scatterlist *sg,
+unsigned int nbytes)
+{
+   crypto_digest_update(desc->tfm, sg, (nbytes+(PAGE_SIZE-1)) / PAGE_SIZE);
+   return nbytes;
+}
+
+static inline int crypto_hash_final(struct hash_desc *desc, u8 *out)
+{
+   crypto_digest_final(desc->tfm, out);
+   return 0;
+}
+
+static inline struct crypto_tfm *crypto_alloc_hash(const char *alg_name,
+   u32 type, u32 mask)
+{
+   struct crypto_tfm *ret = crypto_alloc_tfm(alg_name ,type);
+   return ret ? ret : ERR_PTR(-ENOMEM);
+}
+
+static inline void crypto_free_hash(struct crypto_tfm *tfm)
+{
+   crypto_free_tfm(tfm);
+}
 
 #endif
diff --git a/kernel_addons/backport/2.6.9_U5/include/linux/crypto.h 
b/kernel_addons/backport/2.6.9_U5/include/linux/crypto.h
index aecccd

[ewg] [PATCH 1/2] IB/iser: move open-iscsi crypto functions to kernel_addons (SLES10, RHEL5)

[Erez Zilber]

move open-iscsi crypto functions to kernel_addons (SLES10, RHEL5)

Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>
---
 .../backport/2.6.16_sles10/include/linux/crypto.h  |   54 
 .../2.6.16_sles10_sp1/include/linux/crypto.h   |   54 
 .../backport/2.6.18_FC6/include/linux/crypto.h |   54 
 .../2.6.16_sles10/open-iscsi-tx-hash-fixes.patch   |  278 
 .../open-iscsi-tx-hash-fixes.patch |  278 
 .../2.6.18_FC6/open-iscsi-tx-hash-fixes.patch  |  278 
 6 files changed, 162 insertions(+), 834 deletions(-)
 create mode 100644 kernel_addons/backport/2.6.16_sles10/include/linux/crypto.h
 create mode 100644 
kernel_addons/backport/2.6.16_sles10_sp1/include/linux/crypto.h
 create mode 100644 kernel_addons/backport/2.6.18_FC6/include/linux/crypto.h
 delete mode 100644 
kernel_patches/backport/2.6.16_sles10/open-iscsi-tx-hash-fixes.patch
 delete mode 100644 
kernel_patches/backport/2.6.16_sles10_sp1/open-iscsi-tx-hash-fixes.patch
 delete mode 100644 
kernel_patches/backport/2.6.18_FC6/open-iscsi-tx-hash-fixes.patch

diff --git a/kernel_addons/backport/2.6.16_sles10/include/linux/crypto.h 
b/kernel_addons/backport/2.6.16_sles10/include/linux/crypto.h
new file mode 100644
index 000..0f02f6f
--- /dev/null
+++ b/kernel_addons/backport/2.6.16_sles10/include/linux/crypto.h
@@ -0,0 +1,54 @@
+#ifndef BACKPORT_LINUX_CRYPTO_H
+#define BACKPORT_LINUX_CRYPTO_H
+
+#include_next 
+
+#define CRYPTO_ALG_ASYNC   0x0080
+
+struct hash_desc
+{
+   struct crypto_tfm *tfm;
+   u32 flags;
+};
+
+static inline int crypto_hash_init(struct hash_desc *desc)
+{
+   crypto_digest_init(desc->tfm);
+   return 0;
+}
+
+static inline int crypto_hash_digest(struct hash_desc *desc,
+struct scatterlist *sg,
+unsigned int nbytes, u8 *out)
+{
+   crypto_digest_digest(desc->tfm, sg, (nbytes+(PAGE_SIZE-1)) / PAGE_SIZE, 
out);
+   return nbytes;
+}
+
+static inline int crypto_hash_update(struct hash_desc *desc,
+struct scatterlist *sg,
+unsigned int nbytes)
+{
+   crypto_digest_update(desc->tfm, sg, (nbytes+(PAGE_SIZE-1)) / PAGE_SIZE);
+   return nbytes;
+}
+
+static inline int crypto_hash_final(struct hash_desc *desc, u8 *out)
+{
+   crypto_digest_final(desc->tfm, out);
+   return 0;
+}
+
+static inline struct crypto_tfm *crypto_alloc_hash(const char *alg_name,
+   u32 type, u32 mask)
+{
+   struct crypto_tfm *ret = crypto_alloc_tfm(alg_name ,type);
+   return ret ? ret : ERR_PTR(-ENOMEM);
+}
+
+static inline void crypto_free_hash(struct crypto_tfm *tfm)
+{
+   crypto_free_tfm(tfm);
+}
+
+#endif
diff --git a/kernel_addons/backport/2.6.16_sles10_sp1/include/linux/crypto.h 
b/kernel_addons/backport/2.6.16_sles10_sp1/include/linux/crypto.h
new file mode 100644
index 000..0f02f6f
--- /dev/null
+++ b/kernel_addons/backport/2.6.16_sles10_sp1/include/linux/crypto.h
@@ -0,0 +1,54 @@
+#ifndef BACKPORT_LINUX_CRYPTO_H
+#define BACKPORT_LINUX_CRYPTO_H
+
+#include_next 
+
+#define CRYPTO_ALG_ASYNC   0x0080
+
+struct hash_desc
+{
+   struct crypto_tfm *tfm;
+   u32 flags;
+};
+
+static inline int crypto_hash_init(struct hash_desc *desc)
+{
+   crypto_digest_init(desc->tfm);
+   return 0;
+}
+
+static inline int crypto_hash_digest(struct hash_desc *desc,
+struct scatterlist *sg,
+unsigned int nbytes, u8 *out)
+{
+   crypto_digest_digest(desc->tfm, sg, (nbytes+(PAGE_SIZE-1)) / PAGE_SIZE, 
out);
+   return nbytes;
+}
+
+static inline int crypto_hash_update(struct hash_desc *desc,
+struct scatterlist *sg,
+unsigned int nbytes)
+{
+   crypto_digest_update(desc->tfm, sg, (nbytes+(PAGE_SIZE-1)) / PAGE_SIZE);
+   return nbytes;
+}
+
+static inline int crypto_hash_final(struct hash_desc *desc, u8 *out)
+{
+   crypto_digest_final(desc->tfm, out);
+   return 0;
+}
+
+static inline struct crypto_tfm *crypto_alloc_hash(const char *alg_name,
+   u32 type, u32 mask)
+{
+   struct crypto_tfm *ret = crypto_alloc_tfm(alg_name ,type);
+   return ret ? ret : ERR_PTR(-ENOMEM);
+}
+
+static inline void crypto_free_hash(struct crypto_tfm *tfm)
+{
+   crypto_free_tfm(tfm);
+}
+
+#endif
diff --git a/kernel_addons/backport/2.6.18_FC6/include/linux/crypto.h 
b/kernel_addons/backport/2.6.18_FC6/include/linux/crypto.h
new file mode 100644
index 000..0f02f6f
--- /dev/null
+++ b/kernel_addons/backport/2.6.18_FC6/include/linux/crypto.h
@@ -0,0 +1,54 @@
+#ifndef BACKPORT_LINUX_CRYPTO_H
+#define BACKPORT_LINUX_CRYPTO_H
+
+#include_next 
+
+#define CRYPTO_ALG_ASYNC   0x0

[ewg] [PATCH 0/2] IB/iser: move open-iscsi crypto functions to kernel_addons

[Erez Zilber]

The following patches move open-iscsi crypto functions from kernel_patches to 
kernel_addons. By doing so, we also solve a bug in iscsi tx hash that caused an 
oops when crc32c was used for data digest.

Vlad - can you include this fix for OFED 1.2.1? 

-- 


Erez Zilber   |  972-9-971-7689

Software Engineer, Storage Team

Voltaire – _The Grid Backbone_

 __

 www.voltaire.com 



  


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Scalable reliable connection

[Michael S. Tsirkin]

Here's some background on what SRC is.  This is basically slide 6 in Dror's
talk, for those that missed the talk.

 * * *

SRC is an extension supported by recent Mellanox hardware
which is geared toward reducing the number of QPs
required for all-to-all communication on systems
with a high number of jobs per node.

===
Motivation:
===
Given N nodes with J jobs per node, number of QPs required
for all-to-all communication is:

With RC:
O((N * J) ^ 2)

Since each job out of O(N * J) jobs must create a single QP
to communicate with each one of O(N * J) other jobs.

With SRC:
O(N ^ 2 * J)

This is achived by using a single send queue (per job, out of O(N * J) 
jobs)
to send data to all J jobs running on a specific node (out of O(N) 
nodes).
Hardware uses new "SRQ number" field in packet header to
multiplex receive WRs and WCs to private memory of each job.

This is similiar idea to IB RD.
Q: Why not use RD then?
A: Because no hardware supports it.

Details:

===
Verbs extension:
===

- There is a new transport/QP type "SRC".
- There is a new object type "SRC domain"
- Each SRQ gets new (optional) attributes:
SRC domain
SRC SRQ number
SRC CQ
  SRQ must have either all 3 of these or none of these attributes

- QPs of type SRC have all the same attributes as regular RC QPs
  connected to SRQ, except that:
  A. Each SRC QP has a new required attribute "SRC domain"
  B. SRC QPs do *not* have "SRQ" attribute
(do not have a specific SRQ associated with them)

===
Protocol extension:
===
SRC QP behaviour: Requestor
- Post send WR for this QP type is extended with SRQ number field
  This number is sent as part of packet header
- SRC Packets follow rules for RC packets on the wire, exactly
  What is different is their handling at the responder side

SRC QP behaviour: Responder
Each incoming packet passes transport checks with respect
to the SRC QP, following RC rules, exactly.

After this, SRQ number in packet header is used to look up
a specific SRQ. SRC domain of the resulting SRQ must be equal
to SRC domain of the QP, otherwise a NAK is sent,
and QP moves to error state.

If the SRC domains match, receive WR and receive WC processing
are as follows:

- RC Send
  - Rather than using SRQ to which the QP is attached,
SRQ is looked up by SRQ number in the packet.
Receive WR is taken from this SRQ.
  - Completions are generated on the CQ specified in the SRQ

- RDMA/Atomic
  - Rather than using PD to which the QP is attached,
SRQ is looked up by SRQ number in the packet.
PD of this SRQ is used for protection checks.
===
 
-- 
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

Re: [ewg] Re: [ofa-general] RE: OFA website edits

[Tziporet Koren]

Arlin Davis wrote:


I would like to propose adding project directories under 
http://www.openfabrics.org/downloads/  where appropriate and give 
maintainers access. For example:


Jeff,  please add the following directories with maintainer access as 
follow (or grant access at a maintainer group level):


http://www.openfabrics.org/downloads/sdp (eitan)
SDP should be on the name of Jim Mott (jimmott) since he is the 
maintainer of SDP and not Eitan.


Tziporet
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] OFED teleconference today

[Jeff Squyres]

Friendly reminder: the OFED teleconference is several hours from now  
(Monday, July 30, 2007).


Noon US eastern / 9am US Pacific / 7pm Israel
1. Monday, Jul 30, code 210062024
2. Monday, Aug 13, code 210062024
3. Monday, Aug 27, code 210062024

US/Canada:  +1.866.432.9903
India:  +91.80.4103.3979
Israel: +972.9.892.7026
Others: http://cisco.com/en/US/about/doing_business/conferencing/

--
Jeff Squyres
Cisco Systems

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Gleb Natapov]

On Mon, Jul 30, 2007 at 03:10:57PM +0300, Michael S. Tsirkin wrote:
> > > It seems what you are missing is what SRC is, not how to use the API.
> > 
> > So tell us.
> 
> This calls for a separate document. From feedback from Sonoma I really assumed
> people have it figured out.
> 
> Let's open a separate thread, and there I will try writing up
> what SRC is from the protocol point of view.
> 
No problem. Start it :)

--
Gleb.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Michael S. Tsirkin]

> > It seems what you are missing is what SRC is, not how to use the API.
> 
> So tell us.

This calls for a separate document. From feedback from Sonoma I really assumed
people have it figured out.

Let's open a separate thread, and there I will try writing up
what SRC is from the protocol point of view.


-- 
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Gleb Natapov]

On Mon, Jul 30, 2007 at 02:21:30PM +0300, Michael S. Tsirkin wrote:
> > Quoting Gleb Natapov <[EMAIL PROTECTED]>:
> > Subject: Re: [ofa-general] RFC: SRC API
> > 
> > On Mon, Jul 30, 2007 at 12:16:39PM +0300, Michael S. Tsirkin wrote:
> > > More code examples:
> > > 
> > > Create an SRC QP, part of SRC domain:
> > > 
> > >   attr.qp_type = IBV_QPT_SRC;
> > >   attr.src_domain = d;
> > >   qp = ibv_create_qp(pd, &attr);
> > > 
> > > Given remote SRQ number, send data to this SRQ over an SRC QP:
> > > 
> > >   wr.src_remote_srq_num = src_remote_srq_num;
> > >   ib_post_send(qp, &wr);
> > > 
> > > Note: SRQ number needs to be exchanged as part of CM private data
> > >   or some other protocol.
> > > 
> > You are too brief. I can come up with one linears based on the API by
> > myself. I am trying to understand how sharing of SRC between processes
> > will work and your example doesn't show this.
> 
> It seems what you are missing is what SRC is, not how to use the API.
So tell us. Because it seems I am not the only one judging by
presentation I've got from Ishai. In this presentation he propose to
create separate receive QPs and send QPs. Is this how it meant to be
working if SRC domain is shared between processes? Because frankly, I don't
see how it can be used in any other way.

> I'll have a working example when I get closer to implementation.
> For now you'll have to look up Dror's preso if you want to
> understand what SRC is.
I looked at Dror's presentation not once. If we are talking about the
same presentation there is no much details there except additional field
in the header with destination SRQ number so HW will be able to demux a packet 
in
the right SRQ.

> 
> > Can I connected the same
> > SRC to different QPs? If yes, can I send packet to any SRQ connected to
> > the SRC through any QP connected to the same SRC?
> 
> Yes to both.
And can I attach SRQ to SRC domain without creating QP? I suppose yes.

> 
> > If yes how is this
> > different from having regular QPs?
> 
> With regular QP you can only send to a single SRQ.
> But again, look at Dror's preso.
> 
Yes but I can use the same QP for sending and receiving (this is a Queue
Pair after all). Now I'll have to create QP for send and QP for receive.
Overall number of QPs may still be smaller though...

--
Gleb.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Michael S. Tsirkin]

> Quoting Gleb Natapov <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] RFC: SRC API
> 
> On Mon, Jul 30, 2007 at 12:16:39PM +0300, Michael S. Tsirkin wrote:
> > More code examples:
> > 
> > Create an SRC QP, part of SRC domain:
> > 
> > attr.qp_type = IBV_QPT_SRC;
> > attr.src_domain = d;
> > qp = ibv_create_qp(pd, &attr);
> > 
> > Given remote SRQ number, send data to this SRQ over an SRC QP:
> > 
> > wr.src_remote_srq_num = src_remote_srq_num;
> > ib_post_send(qp, &wr);
> > 
> > Note: SRQ number needs to be exchanged as part of CM private data
> >   or some other protocol.
> > 
> You are too brief. I can come up with one linears based on the API by
> myself. I am trying to understand how sharing of SRC between processes
> will work and your example doesn't show this.

It seems what you are missing is what SRC is, not how to use the API.
I'll have a working example when I get closer to implementation.
For now you'll have to look up Dror's preso if you want to
understand what SRC is.

> Can I connected the same
> SRC to different QPs? If yes, can I send packet to any SRQ connected to
> the SRC through any QP connected to the same SRC?

Yes to both.

> If yes how is this
> different from having regular QPs?

With regular QP you can only send to a single SRQ.
But again, look at Dror's preso.

-- 
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] [PATCH 4/4]: Add kfifo to ibcore for RH4

[Erez Zilber]

Add kfifo to ibcore for RH4. kfifo is taken from upstream code.

Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>

diff --git a/kernel_patches/backport/2.6.9_U2/linux_stuff_to_2_6_17.patch 
b/kernel_patches/backport/2.6.9_U2/linux_stuff_to_2_6_17.patch
index c437e83..e51c3a7 100644
--- a/kernel_patches/backport/2.6.9_U2/linux_stuff_to_2_6_17.patch
+++ b/kernel_patches/backport/2.6.9_U2/linux_stuff_to_2_6_17.patch
@@ -12,6 +12,13 @@ index 000..58cf933
 +++ b/drivers/infiniband/core/netevent.c
 @@ -0,0 +1 @@
 +#include "src/netevent.c"
+diff --git a/drivers/infiniband/core/kfifo.c b/drivers/infiniband/core/kfifo.c
+new file mode 100644
+index 000..58cf933
+--- /dev/null
 b/drivers/infiniband/core/kfifo.c
+@@ -0,0 +1 @@
++#include "../../kernel/kfifo.c"
 diff --git a/drivers/infiniband/core/Makefile 
b/drivers/infiniband/core/Makefile
 index 50fb1cd..456bfd0 100644
 --- a/drivers/infiniband/core/Makefile
@@ -20,4 +27,4 @@ index 50fb1cd..456bfd0 100644
  
  ib_uverbs-y :=uverbs_main.o uverbs_cmd.o 
uverbs_marshall.o
 +
-+ib_core-y +=  genalloc.o netevent.o
++ib_core-y +=  genalloc.o netevent.o kfifo.o
diff --git a/kernel_patches/backport/2.6.9_U3/linux_stuff_to_2_6_17.patch 
b/kernel_patches/backport/2.6.9_U3/linux_stuff_to_2_6_17.patch
index c437e83..e51c3a7 100644
--- a/kernel_patches/backport/2.6.9_U3/linux_stuff_to_2_6_17.patch
+++ b/kernel_patches/backport/2.6.9_U3/linux_stuff_to_2_6_17.patch
@@ -12,6 +12,13 @@ index 000..58cf933
 +++ b/drivers/infiniband/core/netevent.c
 @@ -0,0 +1 @@
 +#include "src/netevent.c"
+diff --git a/drivers/infiniband/core/kfifo.c b/drivers/infiniband/core/kfifo.c
+new file mode 100644
+index 000..58cf933
+--- /dev/null
 b/drivers/infiniband/core/kfifo.c
+@@ -0,0 +1 @@
++#include "../../kernel/kfifo.c"
 diff --git a/drivers/infiniband/core/Makefile 
b/drivers/infiniband/core/Makefile
 index 50fb1cd..456bfd0 100644
 --- a/drivers/infiniband/core/Makefile
@@ -20,4 +27,4 @@ index 50fb1cd..456bfd0 100644
  
  ib_uverbs-y :=uverbs_main.o uverbs_cmd.o 
uverbs_marshall.o
 +
-+ib_core-y +=  genalloc.o netevent.o
++ib_core-y +=  genalloc.o netevent.o kfifo.o
diff --git a/kernel_patches/backport/2.6.9_U4/linux_stuff_to_2_6_17.patch 
b/kernel_patches/backport/2.6.9_U4/linux_stuff_to_2_6_17.patch
index c437e83..e51c3a7 100644
--- a/kernel_patches/backport/2.6.9_U4/linux_stuff_to_2_6_17.patch
+++ b/kernel_patches/backport/2.6.9_U4/linux_stuff_to_2_6_17.patch
@@ -12,6 +12,13 @@ index 000..58cf933
 +++ b/drivers/infiniband/core/netevent.c
 @@ -0,0 +1 @@
 +#include "src/netevent.c"
+diff --git a/drivers/infiniband/core/kfifo.c b/drivers/infiniband/core/kfifo.c
+new file mode 100644
+index 000..58cf933
+--- /dev/null
 b/drivers/infiniband/core/kfifo.c
+@@ -0,0 +1 @@
++#include "../../kernel/kfifo.c"
 diff --git a/drivers/infiniband/core/Makefile 
b/drivers/infiniband/core/Makefile
 index 50fb1cd..456bfd0 100644
 --- a/drivers/infiniband/core/Makefile
@@ -20,4 +27,4 @@ index 50fb1cd..456bfd0 100644
  
  ib_uverbs-y :=uverbs_main.o uverbs_cmd.o 
uverbs_marshall.o
 +
-+ib_core-y +=  genalloc.o netevent.o
++ib_core-y +=  genalloc.o netevent.o kfifo.o
diff --git a/kernel_patches/backport/2.6.9_U5/linux_stuff_to_2_6_17.patch 
b/kernel_patches/backport/2.6.9_U5/linux_stuff_to_2_6_17.patch
index c437e83..e51c3a7 100644
--- a/kernel_patches/backport/2.6.9_U5/linux_stuff_to_2_6_17.patch
+++ b/kernel_patches/backport/2.6.9_U5/linux_stuff_to_2_6_17.patch
@@ -12,6 +12,13 @@ index 000..58cf933
 +++ b/drivers/infiniband/core/netevent.c
 @@ -0,0 +1 @@
 +#include "src/netevent.c"
+diff --git a/drivers/infiniband/core/kfifo.c b/drivers/infiniband/core/kfifo.c
+new file mode 100644
+index 000..58cf933
+--- /dev/null
 b/drivers/infiniband/core/kfifo.c
+@@ -0,0 +1 @@
++#include "../../kernel/kfifo.c"
 diff --git a/drivers/infiniband/core/Makefile 
b/drivers/infiniband/core/Makefile
 index 50fb1cd..456bfd0 100644
 --- a/drivers/infiniband/core/Makefile
@@ -20,4 +27,4 @@ index 50fb1cd..456bfd0 100644
  
  ib_uverbs-y :=uverbs_main.o uverbs_cmd.o 
uverbs_marshall.o
 +
-+ib_core-y +=  genalloc.o netevent.o
++ib_core-y +=  genalloc.o netevent.o kfifo.o

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] [PATCH 3/4]: use kfifo from upstream instead of addons for SLES9

[Erez Zilber]

use kfifo from upstream instead of kernel_addons for SLES9.

Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>
---
 .../linux_stuff_to_2_6_5-7_244.patch   |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git 
a/kernel_patches/backport/2.6.5_sles9_sp3/linux_stuff_to_2_6_5-7_244.patch 
b/kernel_patches/backport/2.6.5_sles9_sp3/linux_stuff_to_2_6_5-7_244.patch
index 390e57d..c9b5e4c 100644
--- a/kernel_patches/backport/2.6.5_sles9_sp3/linux_stuff_to_2_6_5-7_244.patch
+++ b/kernel_patches/backport/2.6.5_sles9_sp3/linux_stuff_to_2_6_5-7_244.patch
@@ -32,7 +32,7 @@ index 000..58cf933
 --- /dev/null
 +++ b/drivers/infiniband/core/kfifo.c
 @@ -0,0 +1 @@
-+#include "src/kfifo.c"
++#include "../../kernel/kfifo.c"
 diff --git a/drivers/infiniband/core/Makefile 
b/drivers/infiniband/core/Makefile
 index 50fb1cd..456bfd0 100644
 --- a/drivers/infiniband/core/Makefile
-- 
1.5.2


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] [PATCH 2/4]: rm kfifo.c from kernel_addons

[Erez Zilber]

rm kfifo.c from kernel_addons (SLES9 & RH4) since it is checked out from 
upstream code.

Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>

diff --git a/kernel_addons/backport/2.6.5_sles9_sp3/include/src/kfifo.c 
b/kernel_addons/backport/2.6.5_sles9_sp3/include/src/kfifo.c
deleted file mode 100644
index 5d1d907..000
--- a/kernel_addons/backport/2.6.5_sles9_sp3/include/src/kfifo.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/*
- * A simple kernel FIFO implementation.
- *
- * Copyright (C) 2004 Stelian Pop <[EMAIL PROTECTED]>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/**
- * kfifo_init - allocates a new FIFO using a preallocated buffer
- * @buffer: the preallocated buffer to be used.
- * @size: the size of the internal buffer, this have to be a power of 2.
- * @gfp_mask: get_free_pages mask, passed to kmalloc()
- * @lock: the lock to be used to protect the fifo buffer
- *
- * Do NOT pass the kfifo to kfifo_free() after use ! Simply free the
- * struct kfifo with kfree().
- */
-struct kfifo *kfifo_init(unsigned char *buffer, unsigned int size,
-gfp_t gfp_mask, spinlock_t *lock)
-{
-   struct kfifo *fifo;
-
-   /* size must be a power of 2 */
-   BUG_ON(size & (size - 1));
-
-   fifo = kmalloc(sizeof(struct kfifo), gfp_mask);
-   if (!fifo)
-   return ERR_PTR(-ENOMEM);
-
-   fifo->buffer = buffer;
-   fifo->size = size;
-   fifo->in = fifo->out = 0;
-   fifo->lock = lock;
-
-   return fifo;
-}
-EXPORT_SYMBOL(kfifo_init);
-
-/**
- * kfifo_alloc - allocates a new FIFO and its internal buffer
- * @size: the size of the internal buffer to be allocated.
- * @gfp_mask: get_free_pages mask, passed to kmalloc()
- * @lock: the lock to be used to protect the fifo buffer
- *
- * The size will be rounded-up to a power of 2.
- */
-struct kfifo *kfifo_alloc(unsigned int size, gfp_t gfp_mask, spinlock_t *lock)
-{
-   unsigned char *buffer;
-   struct kfifo *ret;
-
-   /*
-* round up to the next power of 2, since our 'let the indices
-* wrap' tachnique works only in this case.
-*/
-   if (size & (size - 1)) {
-   BUG_ON(size > 0x8000);
-   size = roundup_pow_of_two(size);
-   }
-
-   buffer = kmalloc(size, gfp_mask);
-   if (!buffer)
-   return ERR_PTR(-ENOMEM);
-
-   ret = kfifo_init(buffer, size, gfp_mask, lock);
-
-   if (IS_ERR(ret))
-   kfree(buffer);
-
-   return ret;
-}
-EXPORT_SYMBOL(kfifo_alloc);
-
-/**
- * kfifo_free - frees the FIFO
- * @fifo: the fifo to be freed.
- */
-void kfifo_free(struct kfifo *fifo)
-{
-   kfree(fifo->buffer);
-   kfree(fifo);
-}
-EXPORT_SYMBOL(kfifo_free);
-
-/**
- * __kfifo_put - puts some data into the FIFO, no locking version
- * @fifo: the fifo to be used.
- * @buffer: the data to be added.
- * @len: the length of the data to be added.
- *
- * This function copies at most 'len' bytes from the 'buffer' into
- * the FIFO depending on the free space, and returns the number of
- * bytes copied.
- *
- * Note that with only one concurrent reader and one concurrent
- * writer, you don't need extra locking to use these functions.
- */
-unsigned int __kfifo_put(struct kfifo *fifo,
-unsigned char *buffer, unsigned int len)
-{
-   unsigned int l;
-
-   len = min(len, fifo->size - fifo->in + fifo->out);
-
-   /*
-* Ensure that we sample the fifo->out index -before- we
-* start putting bytes into the kfifo.
-*/
-
-   smp_mb();
-
-   /* first put the data starting from fifo->in to buffer end */
-   l = min(len, fifo->size - (fifo->in & (fifo->size - 1)));
-   memcpy(fifo->buffer + (fifo->in & (fifo->size - 1)), buffer, l);
-
-   /* then put the rest (if any) at the beginning of the buffer */
-   memcpy(fifo->buffer, buffer + l, len - l);
-
-   /*
-* Ensure that we add the bytes to the kfifo -before-
-* we update the fifo->in index.
-*/
-
-   smp_wmb();
-
-   fifo->in += len;
-
-   return len;
-}
-EXPORT_SYMBOL(__kfifo_put);
-
-/**
- * __kfifo_get - gets some data from the FIFO, no locking version
- * @fifo: the fifo to be used.
- * @buffer: where the data must 

[ewg] [PATCH 1/4]: Checkout kfifo.c from upstream

[Erez Zilber]

Checkout kfifo.c from kernel.org.

diff --git a/ofed_scripts/ofed_checkout.sh b/ofed_scripts/ofed_checkout.sh
index 86fc8b8..6c16835 100755
--- a/ofed_scripts/ofed_checkout.sh
+++ b/ofed_scripts/ofed_checkout.sh
@@ -36,6 +36,7 @@ ex git checkout $1 `git-ls-tree -r --name-only $1 \
 include/scsi/iscsi_if.h \
 include/scsi/libiscsi.h \
 include/scsi/scsi_transport_iscsi.h \
+kernel/kfifo.c \
 lib/klist.c \
 `
 ex git update-ref HEAD $1

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] [PATCH 0/4]: add kfifo from upstream for SLES9 & RH4

[Erez Zilber]

Michael S. Tsirkin wrote:
>> Quoting Erez Zilber <[EMAIL PROTECTED]>:
>> Subject: Why isn't kfifo get built with ib-core for RH4?
>>
>> Michael,
>>
>>
>> I saw that kfifo that was built with ib-core for RH4 was removed:
>>
>>
>> http://www2.openfabrics.org/git/?p=~vlad/ofed_kernel.git;a=commit;h=afe4186a2b383e58d9937d0b2fe2ddfb03cd7268
> 
> I can't think of a reason. Likely just an oversight.
> 
>> Why was it removed? open-iscsi cannot be loaded without it. If nobody
>> else is using it,
> 
> This was added here:
> ac758ec6bff062844a5a42141aa5da492b2cb02b
> so I think it's needed by Chelsio.
> Steve?
>   
>> I can move it to iscsi_scsi_addons.patch and build it
>> with libiscsi.
> 
> I think we should just re-add it in core. Patch?
> 
> While we are at it: as a separate cleanup,
> can you please remove the file from kernel_addons/./backport
> and just check out the file from kernel/kfifo.c.
> Just like we do with e.g. klist.c. OK?
> 

The following patches add kfifo to ibcore (for SLES9 & RH4). kfifo is taken 
from upstream code.

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Gleb Natapov]

On Mon, Jul 30, 2007 at 12:16:39PM +0300, Michael S. Tsirkin wrote:
> More code examples:
> 
> Create an SRC QP, part of SRC domain:
> 
>   attr.qp_type = IBV_QPT_SRC;
>   attr.src_domain = d;
>   qp = ibv_create_qp(pd, &attr);
> 
> Given remote SRQ number, send data to this SRQ over an SRC QP:
> 
>   wr.src_remote_srq_num = src_remote_srq_num;
>   ib_post_send(qp, &wr);
> 
> Note: SRQ number needs to be exchanged as part of CM private data
>   or some other protocol.
> 
You are too brief. I can come up with one linears based on the API by
myself. I am trying to understand how sharing of SRC between processes
will work and your example doesn't show this. Can I connected the same
SRC to different QPs? If yes, can I send packet to any SRQ connected to
the SRC through any QP connected to the same SRC?  If yes how is this
different from having regular QPs?

--
Gleb.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Michael S. Tsirkin]

More code examples:

Create an SRC QP, part of SRC domain:

attr.qp_type = IBV_QPT_SRC;
attr.src_domain = d;
qp = ibv_create_qp(pd, &attr);

Given remote SRQ number, send data to this SRQ over an SRC QP:

wr.src_remote_srq_num = src_remote_srq_num;
ib_post_send(qp, &wr);

Note: SRQ number needs to be exchanged as part of CM private data
  or some other protocol.

-- 
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Gleb Natapov]

On Mon, Jul 30, 2007 at 12:01:40PM +0300, Michael S. Tsirkin wrote:
> Some code examples:
>   /* create a domain and share it: */
> 
>   struct ibv_src_domain * d = ibv_get_new_src_domain(ctx);
>   int fd = open(path, O_CREAT | O_RDWR, mode);
>   ibv_share_src_domain(d, fd);
> 
>   /* get a reference to a shared domain: */
> 
>   int fd = open(path, O_CREAT | O_RDWR, mode);
>   struct ibv_src_domain * d = ibv_get_shared_src_domain(ctx, fd);
> 
>   /* once done: */
>   ibv_put_src_domain(d);
> 
> Note: when all users do put, domain is destroyed.
> 
OK. I am more interested in how SRC is connected to a QP in different processes.
How a process will be able to do sends to different processes through one QP, 
etc...

--
Gleb.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Michael S. Tsirkin]

Some code examples:
/* create a domain and share it: */

struct ibv_src_domain * d = ibv_get_new_src_domain(ctx);
int fd = open(path, O_CREAT | O_RDWR, mode);
ibv_share_src_domain(d, fd);

/* get a reference to a shared domain: */

int fd = open(path, O_CREAT | O_RDWR, mode);
struct ibv_src_domain * d = ibv_get_shared_src_domain(ctx, fd);

/* once done: */
ibv_put_src_domain(d);

Note: when all users do put, domain is destroyed.

-- 
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Gleb Natapov]

On Mon, Jul 30, 2007 at 11:52:21AM +0300, Michael S. Tsirkin wrote:
> > On Sun, Jul 29, 2007 at 05:04:31PM +0300, Michael S. Tsirkin wrote:
> > > Hello!
> > > Here is an API proposal for support of the SRC
> > > (scalable reliable connected) protocol extension in libibverbs.
> > > 
> > > This adds APIs to:
> > > - manage SRC domains
> > > 
> > > - share SRC domains between processes,
> > >   by means of creating a 1:1 association
> > >   between an SRC domain and a file.
> > > 
> > > Notes:
> > > - The file is specified by means of a file descriptor,
> > >   this makes it possible for the user to manage file
> > >   creation/deletion in the most flexible manner
> > >   (e.g. tmpfile can be used).
> > > 
> > > - I envision implementing this sharing mechanism in kernel by means
> > >   of a per-device tree, with inode as a key and domain object
> > >   as a value.
> > >  
> > > Please comment.
> > Can you provide a pseudo code of an application using this API?
> > Especially QP sharing part.
> 
> There's no QP sharing here.
> You mean SRC domain sharing?
> 
Yes. Sorry.

--
Gleb.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Michael S. Tsirkin]

> On Sun, Jul 29, 2007 at 05:04:31PM +0300, Michael S. Tsirkin wrote:
> > Hello!
> > Here is an API proposal for support of the SRC
> > (scalable reliable connected) protocol extension in libibverbs.
> > 
> > This adds APIs to:
> > - manage SRC domains
> > 
> > - share SRC domains between processes,
> >   by means of creating a 1:1 association
> >   between an SRC domain and a file.
> > 
> > Notes:
> > - The file is specified by means of a file descriptor,
> >   this makes it possible for the user to manage file
> >   creation/deletion in the most flexible manner
> >   (e.g. tmpfile can be used).
> > 
> > - I envision implementing this sharing mechanism in kernel by means
> >   of a per-device tree, with inode as a key and domain object
> >   as a value.
> >  
> > Please comment.
> Can you provide a pseudo code of an application using this API?
> Especially QP sharing part.

There's no QP sharing here.
You mean SRC domain sharing?

-- 
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

[ewg] Re: [ofa-general] RFC: SRC API

[Gleb Natapov]

On Sun, Jul 29, 2007 at 05:04:31PM +0300, Michael S. Tsirkin wrote:
> Hello!
> Here is an API proposal for support of the SRC
> (scalable reliable connected) protocol extension in libibverbs.
> 
> This adds APIs to:
> - manage SRC domains
> 
> - share SRC domains between processes,
>   by means of creating a 1:1 association
>   between an SRC domain and a file.
> 
> Notes:
> - The file is specified by means of a file descriptor,
>   this makes it possible for the user to manage file
>   creation/deletion in the most flexible manner
>   (e.g. tmpfile can be used).
> 
> - I envision implementing this sharing mechanism in kernel by means
>   of a per-device tree, with inode as a key and domain object
>   as a value.
>  
> Please comment.
Can you provide a pseudo code of an application using this API?
Especially QP sharing part.

> 
> Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
> 
> ---
> 
> diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
> index acc1b82..503f201 100644
> --- a/include/infiniband/verbs.h
> +++ b/include/infiniband/verbs.h
> @@ -370,6 +370,11 @@ struct ibv_ah_attr {
>   uint8_t port_num;
>  };
>  
> +struct ibv_src_domain {
> + struct ibv_context *context;
> + uint32_thandle;
> +};
> +
>  enum ibv_srq_attr_mask {
>   IBV_SRQ_MAX_WR  = 1 << 0,
>   IBV_SRQ_LIMIT   = 1 << 1
> @@ -389,7 +394,8 @@ struct ibv_srq_init_attr {
>  enum ibv_qp_type {
>   IBV_QPT_RC = 2,
>   IBV_QPT_UC,
> - IBV_QPT_UD
> + IBV_QPT_UD,
> + IBV_QPT_SRC
>  };
>  
>  struct ibv_qp_cap {
> @@ -408,6 +414,7 @@ struct ibv_qp_init_attr {
>   struct ibv_qp_cap   cap;
>   enum ibv_qp_typeqp_type;
>   int sq_sig_all;
> + struct ibv_src_domain  *src_domain;
>  };
>  
>  enum ibv_qp_attr_mask {
> @@ -526,6 +533,7 @@ struct ibv_send_wr {
>   uint32_tremote_qkey;
>   } ud;
>   } wr;
> + uint32_tsrc_remote_srq_num;
>  };
>  
>  struct ibv_recv_wr {
> @@ -553,6 +561,10 @@ struct ibv_srq {
>   pthread_mutex_t mutex;
>   pthread_cond_t  cond;
>   uint32_tevents_completed;
> +
> + uint32_tsrc_srq_num;
> + struct ibv_src_domain  *src_domain;
> + struct ibv_cq  *src_cq;
>  };
>  
>  struct ibv_qp {
> @@ -570,6 +582,8 @@ struct ibv_qp {
>   pthread_mutex_t mutex;
>   pthread_cond_t  cond;
>   uint32_tevents_completed;
> +
> + struct ibv_src_domain  *src_domain;
>  };
>  
>  struct ibv_comp_channel {
> @@ -912,6 +926,25 @@ struct ibv_srq *ibv_create_srq(struct ibv_pd *pd,
>  struct ibv_srq_init_attr *srq_init_attr);
>  
>  /**
> + * ibv_create_src_srq - Creates a SRQ associated with the specified 
> protection
> + *   domain and src domain.
> + * @pd: The protection domain associated with the SRQ.
> + * @src_domain: The SRC domain associated with the SRQ.
> + * @src_cq: CQ to report completions for SRC packets on.
> + *
> + * @srq_init_attr: A list of initial attributes required to create the SRQ.
> + *
> + * srq_attr->max_wr and srq_attr->max_sge are read the determine the
> + * requested size of the SRQ, and set to the actual values allocated
> + * on return.  If ibv_create_srq() succeeds, then max_wr and max_sge
> + * will always be at least as large as the requested values.
> + */
> +struct ibv_srq *ibv_create_src_srq(struct ibv_pd *pd,
> +struct ibv_src_domain *src_domain,
> +struct ibv_cq *src_cq,
> +struct ibv_srq_init_attr *srq_init_attr);
> +
> +/**
>   * ibv_modify_srq - Modifies the attributes for the specified SRQ.
>   * @srq: The SRQ to modify.
>   * @srq_attr: On input, specifies the SRQ attributes to modify.  On output,
> @@ -1074,6 +1107,44 @@ int ibv_detach_mcast(struct ibv_qp *qp, union ibv_gid 
> *gid, uint16_t lid);
>   */
>  int ibv_fork_init(void);
>  
> +/**
> + * ibv_alloc_src_domain - Allocate an SRC domain
> + * Returns a reference to an SRC domain.
> + * Use ibv_put_src_domain to free the reference.
> + * @context: Device context
> + */
> +struct ibv_src_domain *ibv_get_new_src_domain(struct ibv_context *context);
> +
> +/**
> + * ibv_share_src_domain - associate the src domain with a file.
> + * Establishes a connection between an SRC domain object and a file 
> descriptor.
> + *
> + * @d: SRC domain to share
> + * @fd: descriptor for a file to associate with the domain
> + */
> +int ibv_share_src_domain(struct ibv_src_domain *d, int fd);
> +
> +/**
> + * ibv_unshare_src_domain - disassociate the src domain from a file.
> + * Subsequent calls to ibv_get_shared_src_domain will fail.
> + * @d: SRC domain to unshare
> + */
> +int ibv_unshare_src_domain(struct ibv_src_domain *d);
> +
> +/**
> + * ibv_get_src_domain - get a reference to shared SRC domain
> + * @

[ewg] Re: Why isn't kfifo get built with ib-core for RH4?

[Michael S. Tsirkin]

> Quoting Erez Zilber <[EMAIL PROTECTED]>:
> Subject: Why isn't kfifo get built with ib-core for RH4?
> 
> Michael,
> 
> 
> I saw that kfifo that was built with ib-core for RH4 was removed:
> 
> 
> http://www2.openfabrics.org/git/?p=~vlad/ofed_kernel.git;a=commit;h=afe4186a2b383e58d9937d0b2fe2ddfb03cd7268

I can't think of a reason. Likely just an oversight.

> 
> Why was it removed? open-iscsi cannot be loaded without it. If nobody
> else is using it,

This was added here:
ac758ec6bff062844a5a42141aa5da492b2cb02b
so I think it's needed by Chelsio.
Steve?

> I can move it to iscsi_scsi_addons.patch and build it
> with libiscsi.

I think we should just re-add it in core. Patch?

While we are at it: as a separate cleanup,
can you please remove the file from kernel_addons/./backport
and just check out the file from kernel/kfifo.c.
Just like we do with e.g. klist.c. OK?

-- 
MST
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg