Re: [openib-general] [PATCH] huge pages support
Oh that one I have not seen... but it looks like this is the approach I took in VAPI and somehow it looked cumbersome to me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier Sent: Sunday, August 20, 2006 7:02 PM To: Tziporet Koren Cc: Openib-general@openib.org Subject: Re: [PATCH] huge pages support Roland Sure, you are building the OFED release so you can put Roland whatever you want into it. ...although maybe it would be a good idea to follow the approach of the second patch posted, and make multiple get_user_pages() calls, skipping along by HPAGE_SIZE. This avoids having all the extra work of follow_hugetlb_page() creating extra fake pages and then calling put_page() many times. - 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 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] Mellanox SRP target implementation
Dipak Neog (dneog) wrote: Hi, Can anybody tell me where to find and download the mellanox SRP target implementation code which was supposed to be released to openib? Thanks, Dipak Mellanox SRP target is under: https://openib.org/svn/trunk/contrib/mellanox/gen1/ib_srpt/ Note that we have made some fixes from the time we posted this code. The code is also available as part of Mellanox gen1 package - IBGD (available on Mellanox web site) Tziporet ___ 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] cmpost: allow cmpost to build with latest RDMA CM
Sean, as I understand cmpost.c and simple.c where originally pure libibcm examples. Is there any other test code utilizing the libibcm? Thanks Thomas -Original Message- From: Sean Hefty [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 6:09 PM To: Bub Thomas Cc: Sean Hefty; openib-general@openib.org; Erez Cohen Subject: Re: [openib-general] [PATCH] cmpost: allow cmpost to build with latest RDMA CM Bub Thomas wrote: Can I still use the LID, GUID and SubnetID for connection establishment then? Then Gen1 counterpart has no IP over IB running. If IPoIB is not running, then you will need to use the IB CM directly. The RDMA CM uses ARP to resolve IP addresses to GIDs. I'm using OFED-1.0.1. Do you have a quick link where to find the latest Headers? (Sorry for the dumb question) https://openfabrics.org/svn/gen2/trunk/src/ https://openfabrics.org/svn/gen2/trunk/src/userspace/libibcm https://openfabrics.org/svn/gen2/trunk/src/userspace/librdmacm https://openfabrics.org/svn/gen2/trunk/src/linux-kernel/infiniband/ - 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] libibcm can't open /dev/infiniband/ucm0
Sean, ib_ ucm is already loaded!? Here is the list of all loaded ib modules and their dependencies: ib_rds 37656 0 ib_ucm 21512 0 ib_srp 33924 0 ib_sdp 45468 0 rdma_cm26760 3 rdma_ucm,ib_rds,ib_sdp ib_addr10504 1 rdma_cm ib_cm 39952 3 ib_ucm,ib_srp,rdma_cm ib_local_sa14232 2 rdma_ucm,rdma_cm findex 6784 1 ib_local_sa ib_ipoib 59800 0 ib_sa 18196 4 ib_srp,rdma_cm,ib_local_sa,ib_ipoib ib_uverbs 47408 1 rdma_ucm ib_umad20272 0 ib_ipath 70424 0 ipath_core179524 1 ib_ipath ib_mthca 140336 0 ib_mad 43304 5 ib_cm,ib_local_sa,ib_sa,ib_umad,ib_mthca ib_core59520 14 ib_rds,ib_ucm,ib_srp,ib_sdp,rdma_cm,ib_cm,ib_local_sa,ib_ipoib,ib_sa,ib_ uverbs,ib_umad,ib_ipath,ib_mthca,ib_mad scsi_mod 140177 6 ib_srp,qla2xxx,scsi_transport_fc,libata,mptscsih,sd_mod Thanks Thomas -Original Message- From: Sean Hefty [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 6:06 PM To: Bub Thomas Cc: openib-general@openib.org Subject: Re: [openib-general] libibcm can't open /dev/infiniband/ucm0 Bub Thomas wrote: It seems as if the problem I had there was not in my code but the libibcm not being able to open the device /dev/infiniband/ucm0. You will need to load ib_ucm, which exports the IB CM to userspace. - 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 v3 0/6] Tranport Neutral Verbs Proposal.
Hi Roland Sean, What is your opinion on this patch set ? Anything else needs to be done for acceptance ? Thanks, - KK [EMAIL PROTECTED] wrote on 08/16/2006 11:42:35 AM: Hi James, Sorry for the delay, we had a long weekend. My opinion is that the create_qp taking generic parameters is correct, only subsequent calls may need to use transport specific calls/arguments. Infact rdma_create_qp uses the ibv_create_qp (now changed to rdmav_create_qp) call internally. If you want to have a generic rdmav_create_qp() call, there needs to be programmatic way for the API consumer to determine what type of QP (iWARP vs. IB) was created. I don't see any way to do that in your patch: I think the QP is associated with the transport type indirectly through the context. It can be queried with ibv_get_transport_type verb. A renamed rdma_get_transport type would probably suffice. Correct. Opening the device using rdmav_open_device with argument provided by the ULP will provide the context, which is used by subsequent calls to transparently make use of other calls. Either Steve or I can provide the rdmav_get_transport_type() call to return the actual device (transport) type. I like the new approach you are taking (keeping 1 verbs library and adding rdmav_ symbol names). This change to transport neutral names is long overdue. When you finish with the userspace APIs, I hope you will update the kernel APIs as well. Sure. Thanks, - KK ___ 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] QP SQD State processing.
Hello all, I am facing a problem in interprating the statement given in the IB Spec. It is regarding asynchronous event generation by QP in SQD state. the Spec says C10-35 When transitioning into the SQD state, the QP/EE's send logic must cease processing any additional messages. It must also complete any outstanding messages on a message boundary, and process any incoming acknowledgements. The CI must not begin processing additional messages which had not begun execution when the state transition occurred. what is the meaning of message boundary...?? Is it a descriptor which is underprocessing Or it means something else? How HCA behaves? whether HCA generates event immediatly after processing completion of current descriptor or after completing all the descreptors for which DB ring is done? Thanks ___ 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] opensm: truncate log file when fs is overflowed
On Sun, 2006-08-20 at 12:05, Sasha Khapyorsky wrote: In case when OpenSM log file overflows filesystem and write() fails with 'No space left on device' try to truncate the log file and wrap-around logging. Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED] Thanks. Applied. -- 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] [PATH TRIVIAL] opensm: management/Makefile: build rules improvement
On Sun, 2006-08-20 at 12:24, Sasha Khapyorsky wrote: Some minor additions to management/Makefile build rules - now this will run autogen.sh and ./configure (without options) if needed. Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED] Thanks. Applied. -- 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] [PATCH 08/13] IB/ehca: qp
On Thu, 2006-08-17 at 16:11, Roland Dreier wrote:
[snip...]
diff --git a/drivers/infiniband/hw/ehca/ehca_sqp.c
b/drivers/infiniband/hw/ehca/ehca_sqp.c
new file mode 100644
index 000..d2c5552
--- /dev/null
+++ b/drivers/infiniband/hw/ehca/ehca_sqp.c
@@ -0,0 +1,123 @@
+/*
+ * IBM eServer eHCA Infiniband device driver for Linux on POWER
+ *
+ * SQP functions
+ *
+ * Authors: Khadija Souissi [EMAIL PROTECTED]
+ * Heiko J Schick [EMAIL PROTECTED]
[snip...]
+
+extern int ehca_create_aqp1(struct ehca_shca *shca, struct ehca_sport
*sport);
+extern int ehca_destroy_aqp1(struct ehca_sport *sport);
+
+extern int ehca_port_act_time;
+
+/**
+ * ehca_define_sqp - Defines special queue pair 1 (GSI QP). When special
queue
+ * pair is created successfully, the corresponding port gets active.
+ *
+ * Define Special Queue pair 0 (SMI QP) is still not supported.
+ *
+ * @qp_init_attr: Queue pair init attributes with port and queue pair type
+ */
+
+u64 ehca_define_sqp(struct ehca_shca *shca,
+ struct ehca_qp *ehca_qp,
+ struct ib_qp_init_attr *qp_init_attr)
+{
+
+ u32 pma_qp_nr = 0;
+ u32 bma_qp_nr = 0;
+ u64 ret = H_SUCCESS;
+ u8 port = qp_init_attr-port_num;
+ int counter = 0;
+
+ EDEB_EN(7, port=%x qp_type=%x,
+ port, qp_init_attr-qp_type);
+
+ shca-sport[port - 1].port_state = IB_PORT_DOWN;
+
+ switch (qp_init_attr-qp_type) {
+ case IB_QPT_SMI:
+ /* function not supported yet */
+ break;
+ case IB_QPT_GSI:
+ ret = hipz_h_define_aqp1(shca-ipz_hca_handle,
+ ehca_qp-ipz_qp_handle,
+ ehca_qp-galpas.kernel,
+ (u32) qp_init_attr-port_num,
+ pma_qp_nr, bma_qp_nr);
+
+ if (ret != H_SUCCESS) {
+ EDEB_ERR(4, Can't define AQP1 for port %x. rc=%lx,
+ port, ret);
+ goto ehca_define_aqp1;
+ }
+ break;
+ default:
+ ret = H_PARAMETER;
+ goto ehca_define_aqp1;
+ }
+
+ while ((shca-sport[port - 1].port_state != IB_PORT_ACTIVE)
+(counter ehca_port_act_time)) {
+ EDEB(6, ... wait until port %x is active,
+ port);
+ msleep_interruptible(1000);
+ counter++;
+ }
+
+ if (counter == ehca_port_act_time) {
+ EDEB_ERR(4, Port %x is not active., port);
+ ret = H_HARDWARE;
+ }
+
+ehca_define_aqp1:
+ EDEB_EX(7, ret=%lx, ret);
+
+ return ret;
+}
I, for one, was hoping that the timer based transition to active for QP1
would have been resolved before being submitted. Any idea on the plan to
resolve this ?
-- 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] [PATCH 08/13] IB/ehca: qp
I, for one, was hoping that the timer based transition to active for QP1 would have been resolved before being submitted. Any idea on the plan to resolve this ? -- Hal We're testing it. As I mentioned before, this requires a change in the system firmware. I personally don't think this will show up in firmware in time for 2.6.19 merge window. So unfortunately we still need that loop. Regards . . . Christoph 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] OpenSM/osm_sa_path_record.c: In __osm_pr_rcv_get_lid_pair_path, remove double calculation of reversible path
OpenSM/osm_sa_path_record.c: In __osm_pr_rcv_get_lid_pair_path, remove
double calculation of reversible path
Pointed out by Sasha Khapyorsky [EMAIL PROTECTED]
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: opensm/osm_sa_path_record.c
===
--- opensm/osm_sa_path_record.c (revision 9021)
+++ opensm/osm_sa_path_record.c (working copy)
@@ -728,7 +728,7 @@ __osm_pr_rcv_get_lid_pair_path(
rev_path_status = __osm_pr_rcv_get_path_parms( p_rcv, p_pr, p_dest_port,
p_src_port, src_lid_ho,
comp_mask, rev_path_parms );
- path_parms.reversible = (rev_path_status == IB_SUCCESS);
+ path_parms.reversible = ( rev_path_status == IB_SUCCESS );
/* did we get a Reversible Path compmask ? */
/*
@@ -738,11 +738,6 @@ __osm_pr_rcv_get_lid_pair_path(
*/
if( comp_mask IB_PR_COMPMASK_REVERSIBLE )
{
-/* now try the reversible path */
-rev_path_status = __osm_pr_rcv_get_path_parms( p_rcv, p_pr, p_dest_port,
- p_src_port, src_lid_ho,
- comp_mask, rev_path_parms
);
-path_parms.reversible = (rev_path_status == IB_SUCCESS);
if( (! path_parms.reversible ( p_pr-num_path 0x80 ) ) )
{
osm_log( p_rcv-p_log, OSM_LOG_DEBUG,
___
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] restore missing PCI registers after reset
Quoting r. Greg KH [EMAIL PROTECTED]:
Subject: Re: restore missing PCI registers after reset
On Wed, Jul 26, 2006 at 07:32:26PM +0300, Michael S. Tsirkin wrote:
Quoting r. Greg KH [EMAIL PROTECTED]:
I think pci_restore_state() already restores the msi and msix state,
take a look at the latest kernel version :)
Yes, I know :)
but I am not talking abotu MSI/MSI-X, I am talking about the following:
PCI-X device: PCI-X command register
PCI-X bridge: upstream and downstream split transaction registers
PCI Express : PCI Express device control and link control registers
these register values include maxumum MTU for PCI express and other vital
data.
Make up a patch that shows how you would save these in a generic way and
we can discuss it. I know people have talked about saving the extended
PCI config space for devices that need it, so that might be all you
need to do here.
Like this?
--
Restore PCI Express capability registers after PM event.
This includes maxumum MTU for PCI express and other vital data.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 9f79dd6..198b200 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -443,6 +443,52 @@ pci_power_t pci_choose_state(struct pci_
EXPORT_SYMBOL(pci_choose_state);
+static int __pci_save_pcie_state(struct pci_dev *dev)
+{
+ int pos, i = 0;
+ struct pci_cap_saved_state *save_state;
+ u16 *cap;
+
+ pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
+ if (pos = 0)
+ return 0;
+
+ save_state = kzalloc(sizeof(struct pci_cap_saved_state) + sizeof(u16) *
4,
+ GFP_KERNEL);
+ if (!save_state) {
+ printk(KERN_ERR Out of memory in pci_save_pcie_state\n);
+ return -ENOMEM;
+ }
+ cap = (u16 *)save_state-data[0];
+
+ pci_read_config_word(dev, pos + PCI_EXP_DEVCTL, cap[i++]);
+ pci_read_config_word(dev, pos + PCI_EXP_LNKCTL, cap[i++]);
+ pci_read_config_word(dev, pos + PCI_EXP_SLTCTL, cap[i++]);
+ pci_read_config_word(dev, pos + PCI_EXP_RTCTL, cap[i++]);
+ pci_add_saved_cap(dev, save_state);
+ return 0;
+}
+
+static void __pci_restore_pcie_state(struct pci_dev *dev)
+{
+ int i = 0, pos;
+ struct pci_cap_saved_state *save_state;
+ u16 *cap;
+
+ save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+ pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
+ if (!save_state || pos = 0)
+ return;
+ cap = (u16 *)save_state-data[0];
+
+ pci_write_config_word(dev, pos + PCI_EXP_DEVCTL, cap[i++]);
+ pci_write_config_word(dev, pos + PCI_EXP_LNKCTL, cap[i++]);
+ pci_write_config_word(dev, pos + PCI_EXP_SLTCTL, cap[i++]);
+ pci_write_config_word(dev, pos + PCI_EXP_RTCTL, cap[i++]);
+ pci_remove_saved_cap(save_state);
+ kfree(save_state);
+}
+
/**
* pci_save_state - save the PCI configuration space of a device before
suspending
* @dev: - PCI device that we're dealing with
@@ -458,6 +504,8 @@ pci_save_state(struct pci_dev *dev)
return i;
if ((i = pci_save_msix_state(dev)) != 0)
return i;
+ if ((i = __pci_save_pcie_state(dev)) != 0)
+ return i;
return 0;
}
@@ -471,6 +519,9 @@ pci_restore_state(struct pci_dev *dev)
int i;
int val;
+ /* PCI Express register must be restored first */
+ __pci_restore_pcie_state(dev);
+
/*
* The Base Address register should be programmed before the command
* register(s)
--
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] [PATCH v3 0/6] Tranport Neutral Verbs Proposal.
Krishna Hi Roland Sean, What is your opinion on this patch set Krishna ? Anything else needs to be done for acceptance ? It's a very low priority for me, since it's a pain to merge and a pain to maintain, and I don't see any urgency in renaming functions. I'll try to get to it after everything else I want for libibverbs 1.1 is done (expose device type, memory windows, reregister memory region at least) - 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] [PATCH] huge pages support
Eli Oh that one I have not seen... but it looks like this is the Eli approach I took in VAPI and somehow it looked cumbersome to Eli me. I guess you could benchmark and see if there's a measurable difference. put_page() is an atomic operation so doing it 512 times more often seems like it might be significant. - 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] [PATCHv2] osm: OSM crash TRIVIAL bug fix
Hi Hal. My answers below. I did check the code using the setup that discovered it. This patch should make its way into both trunk and OFED 1.1 branch. Please let me know if there is anything else required for it. Thanks, Yevgeny On Thu, 2006-08-17 at 09:35 -0400, Hal Rosenstock wrote: Hi Yevgeny, On Thu, 2006-08-17 at 09:28, Yevgeny Kliteynik wrote: Hi Hal. This line wrapped so there is something wrong with your mailer. I'm using a different mailer now, so I hope that it's ok now. Guess we'll see with your next patch with a long line... + m-v = NULL; /* just make sure we do not point tofree'd madw */ Also, is this line really needed (and if so why) ? I know you did say it cleans up old pointers to retrieved madw but this shouldn't be accessed, right ? You're right, it shouldn't be accessed. Does the fix checked in work as is now ? Did you reverify ? Yes, I did. But generally, it's a good practice to assign a null to any pointer that points to a freed memory, and should not be in use any more. It's also good practice that when an issue is found in one place to look for other occurences of the same issue. I'm also not sure this is the general approach that OpenSM takes. Right, I will try to clean these areas once I get to read them. -- Hal Also, if this is added here, there are other places where the same thing should be done ? I just examined this area of code, so this is what I saw. -- Regards, Yevgeny Kliteynik Mellanox Technologies LTD Tel: +972-4-909-7200 ext: 394 Fax: +972-4-959-3245 P.O. Box 586 Yokneam 20692 ISRAEL ___ 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] [PATCHv2] osm: OSM crash TRIVIAL bug fix
Hi Yevgeny, On Mon, 2006-08-21 at 11:27, Yevgeny Kliteynik wrote: Hi Hal. My answers below. I did check the code using the setup that discovered it. This patch should make its way into both trunk and OFED 1.1 branch. It's been on both since 8/14. -- Hal Please let me know if there is anything else required for it. Thanks, Yevgeny On Thu, 2006-08-17 at 09:35 -0400, Hal Rosenstock wrote: Hi Yevgeny, On Thu, 2006-08-17 at 09:28, Yevgeny Kliteynik wrote: Hi Hal. This line wrapped so there is something wrong with your mailer. I'm using a different mailer now, so I hope that it's ok now. Guess we'll see with your next patch with a long line... + m-v = NULL; /* just make sure we do not point tofree'd madw */ Also, is this line really needed (and if so why) ? I know you did say it cleans up old pointers to retrieved madw but this shouldn't be accessed, right ? You're right, it shouldn't be accessed. Does the fix checked in work as is now ? Did you reverify ? Yes, I did. But generally, it's a good practice to assign a null to any pointer that points to a freed memory, and should not be in use any more. It's also good practice that when an issue is found in one place to look for other occurences of the same issue. I'm also not sure this is the general approach that OpenSM takes. Right, I will try to clean these areas once I get to read them. -- Hal Also, if this is added here, there are other places where the same thing should be done ? I just examined this area of code, so this is what I saw. ___ 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] [openfabrics-ewg] Rollup patch for ipath and OFED
On Wed, 2006-08-16 at 21:49 +0300, Michael S. Tsirkin wrote: Woops, only now noticed that this was wrt the ipath driver, not mthca as I thought. Of course I didn't mean it - I don't edit ipath code in SVN, pathscale guys do that. We don't actually use SVN to develop the driver either. For kernel stuff, I think it's become just a dumping ground for changes that people have made in their own private trees. This makes it not a suitable place to be pulling driver sources from. b ___ 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] REMINDER: The InfiniBand Trade Association and the OpenFabrics Alliance Fall 2006 Developers Conference (Sept. 25)
Hello everyone, A reminder to mark your calendar for the InfiniBand Trade Association (IBTA) and the OpenFabrics Alliance (OFA) Fall 2006 Developers Conference on September 25, 2006 at the Moscone Center West in San Francisco. The event is being held in co-location with the Fall 2006 Intel Developer Forum. If you are an application developer, systems vendor, hardware/software solution provider or end user of the technology, please join us for presentations and collaborative sessions that will highlight the recent advancements of the InfiniBand specification and available software solutions. The one-day conference begins at 8:30 a.m. with keynotes from Jim Pappas, director of initiative marketing at Intel Corporation, and Krish Ramakrishnan, vice president and general manager of Server Switching at Cisco. In addition, we have an exciting day planned including: End users sharing experiences on real-life deployment and usage of the technology Highlights of the recent advancements of the InfiniBand specification by IBTA Updates on available InfiniBand-supported software solutions from OFA and industry partners Collaborative sessions and discussions about future joint developments between IBTA and OFA Attendees who register by September 1st can do so for the early-bird rate of $149. Afterwards, the standard registration fee is $199. To register for the event, please visit: www.acteva.com/go/IBTAOFADevCon06 Special discount offered to those registering for IDF: If you havent yet registered for IDF, we invite you to take advantage of an exclusive discount being offered to those attending the IBTA and OFA conference. Attendees may purchase conference passes to IDF at a discounted rate of $700 a savings of $995 off the standard rate. To register for IDF and receive this discount, please visit: www.intel.com/idf/us/fall2006/registration IBTA and OFA Member Bulk Code: FCAGRCTA The Intel Developer Forum in San Francisco offers attendees over 130 hours of technology training to choose from, led by top Intel and industry engineers who provide critical training that will help you solve your day-to-day, real-time problems. Linh Dinh For OFA IBTA 206-322-1167, ext. 115 [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] [openfabrics-ewg] Rollup patch for ipath and OFED
Brian Wrote, On Wed, 2006-08-16 at 21:49 +0300, Michael S. Tsirkin wrote: Woops, only now noticed that this was wrt the ipath driver, not mthca as I thought. Of course I didn't mean it - I don't edit ipath code in SVN, pathscale guys do that. We don't actually use SVN to develop the driver either. For kernel stuff, I think it's become just a dumping ground for changes that people have made in their own private trees. This makes it not a suitable place to be pulling driver sources from. b I am just looking for stable HCA drivers that will work with the rest of the latest code that is in SVN. Sean is putting all his changes into SVN and we need to test them with the HCA drivers and the rest of the stack. At this point, I have not a clue where the latest code is for all the different components and it is making life very difficult. I assumed that the latest working code would be put into SVN, as it has been in the past. If this is not the case, then please tell me where I can get the latest HCA drivers that will work with Sean's latest code that is in SVN. woody ___ 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 v3 0/6] Tranport Neutral Verbs Proposal.
Krishna Kumar2 wrote: What is your opinion on this patch set ? Anything else needs to be done for acceptance ? I don't have any issues with it, but Roland would need to commit the changes to verbs as the first step. - 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] libibcm can't open /dev/infiniband/ucm0
Bub Thomas wrote: Here is the list of all loaded ib modules and their dependencies: ib_rds 37656 0 ib_ucm 21512 0 Did you update udev rules to create the device? - 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] cmpost: allow cmpost to build with latest RDMA CM
Bub Thomas wrote: as I understand cmpost.c and simple.c where originally pure libibcm examples. simple.c was originally a pure libibcm example, but it never actually established any connections. Cmpost has always relied on a separate library to obtain path record information. Is there any other test code utilizing the libibcm? Cmpost is the only test code that I've written to use the libibcm. - 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] [PATCH] opensm: osm_sa_path_record: mcast destination detection fix
Return error when mcast destination is not consistently indicated.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
osm/opensm/osm_sa_path_record.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/osm/opensm/osm_sa_path_record.c b/osm/opensm/osm_sa_path_record.c
index caa9f32..6b0fb28 100644
--- a/osm/opensm/osm_sa_path_record.c
+++ b/osm/opensm/osm_sa_path_record.c
@@ -1486,7 +1486,7 @@ __osm_pr_match_mgrp_attributes(
/**
**/
-static boolean_t
+static int
__osm_pr_rcv_check_mcast_dest(
IN osm_pr_rcv_t* const p_rcv,
IN const osm_madw_t* const p_madw )
@@ -1494,7 +1494,7 @@ __osm_pr_rcv_check_mcast_dest(
const ib_path_rec_t* p_pr;
const ib_sa_mad_t* p_sa_mad;
ib_net64_t comp_mask;
- boolean_tis_multicast = FALSE;
+ unsigned is_multicast = 0;
OSM_LOG_ENTER( p_rcv-p_log, __osm_pr_rcv_check_mcast_dest );
@@ -1514,11 +1514,13 @@ __osm_pr_rcv_check_mcast_dest(
{
if( cl_ntoh16( p_pr-dlid ) = IB_LID_MCAST_START_HO
cl_ntoh16( p_pr-dlid ) = IB_LID_MCAST_END_HO )
- is_multicast = TRUE;
-else if( is_multicast )
+ is_multicast = 1;
+else if( is_multicast ) {
osm_log( p_rcv-p_log, OSM_LOG_ERROR,
__osm_pr_rcv_check_mcast_dest: ERR 1F12:
PathRecord request indicates MGID but not MLID\n );
+ return -1;
+}
}
Exit:
@@ -1693,6 +1695,7 @@ osm_pr_rcv_process(
cl_qlist_t pr_list;
ib_net16_t sa_status;
osm_port_t* requester_port;
+ int ret;
OSM_LOG_ENTER( p_rcv-p_log, osm_pr_rcv_process );
@@ -1737,7 +1740,10 @@ osm_pr_rcv_process(
cl_plock_acquire( p_rcv-p_lock );
/* Handle multicast destinations separately */
- if( __osm_pr_rcv_check_mcast_dest( p_rcv, p_madw ) )
+ if( (ret = __osm_pr_rcv_check_mcast_dest( p_rcv, p_madw )) 0)
+goto Exit;
+
+ if(ret 0)
goto McastDest;
osm_log( p_rcv-p_log, OSM_LOG_DEBUG,
___
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] opensm: osm_sa_path_record: mcast destination detection fix
On Mon, 2006-08-21 at 13:22, Sasha Khapyorsky wrote:
Return error when mcast destination is not consistently indicated.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
Thanks. Applied (to both trunk and 1.1) with the following minor changes
below:
osm/opensm/osm_sa_path_record.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/osm/opensm/osm_sa_path_record.c b/osm/opensm/osm_sa_path_record.c
index caa9f32..6b0fb28 100644
--- a/osm/opensm/osm_sa_path_record.c
+++ b/osm/opensm/osm_sa_path_record.c
@@ -1486,7 +1486,7 @@ __osm_pr_match_mgrp_attributes(
/**
**/
-static boolean_t
+static int
__osm_pr_rcv_check_mcast_dest(
IN osm_pr_rcv_t* const p_rcv,
IN const osm_madw_t* const p_madw )
@@ -1494,7 +1494,7 @@ __osm_pr_rcv_check_mcast_dest(
const ib_path_rec_t* p_pr;
const ib_sa_mad_t* p_sa_mad;
ib_net64_t comp_mask;
- boolean_tis_multicast = FALSE;
+ unsigned is_multicast = 0;
OSM_LOG_ENTER( p_rcv-p_log, __osm_pr_rcv_check_mcast_dest );
@@ -1514,11 +1514,13 @@ __osm_pr_rcv_check_mcast_dest(
{
if( cl_ntoh16( p_pr-dlid ) = IB_LID_MCAST_START_HO
cl_ntoh16( p_pr-dlid ) = IB_LID_MCAST_END_HO )
- is_multicast = TRUE;
-else if( is_multicast )
+ is_multicast = 1;
+else if( is_multicast ) {
osm_log( p_rcv-p_log, OSM_LOG_ERROR,
__osm_pr_rcv_check_mcast_dest: ERR 1F12:
PathRecord request indicates MGID but not MLID\n );
+ return -1;
I made this go through the exit so the routine end log message is put
into the log.
+}
}
Exit:
@@ -1693,6 +1695,7 @@ osm_pr_rcv_process(
cl_qlist_t pr_list;
ib_net16_t sa_status;
osm_port_t* requester_port;
+ int ret;
OSM_LOG_ENTER( p_rcv-p_log, osm_pr_rcv_process );
@@ -1737,7 +1740,10 @@ osm_pr_rcv_process(
cl_plock_acquire( p_rcv-p_lock );
/* Handle multicast destinations separately */
- if( __osm_pr_rcv_check_mcast_dest( p_rcv, p_madw ) )
+ if( (ret = __osm_pr_rcv_check_mcast_dest( p_rcv, p_madw )) 0)
I added a send of SA status error for IB_MAD_STATUS_INVALID_FIELD here
as well as an unlock.
+goto Exit;
+
+ if(ret 0)
goto McastDest;
osm_log( p_rcv-p_log, OSM_LOG_DEBUG,
-- 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] [PATCH] opensm: osm_sa_path_record: mcast destination detection fix
On 13:45 Mon 21 Aug , Hal Rosenstock wrote:
On Mon, 2006-08-21 at 13:22, Sasha Khapyorsky wrote:
Return error when mcast destination is not consistently indicated.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
Thanks. Applied (to both trunk and 1.1) with the following minor changes
below:
osm/opensm/osm_sa_path_record.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/osm/opensm/osm_sa_path_record.c
b/osm/opensm/osm_sa_path_record.c
index caa9f32..6b0fb28 100644
--- a/osm/opensm/osm_sa_path_record.c
+++ b/osm/opensm/osm_sa_path_record.c
@@ -1486,7 +1486,7 @@ __osm_pr_match_mgrp_attributes(
/**
**/
-static boolean_t
+static int
__osm_pr_rcv_check_mcast_dest(
IN osm_pr_rcv_t* const p_rcv,
IN const osm_madw_t* const p_madw )
@@ -1494,7 +1494,7 @@ __osm_pr_rcv_check_mcast_dest(
const ib_path_rec_t* p_pr;
const ib_sa_mad_t* p_sa_mad;
ib_net64_t comp_mask;
- boolean_tis_multicast = FALSE;
+ unsigned is_multicast = 0;
OSM_LOG_ENTER( p_rcv-p_log, __osm_pr_rcv_check_mcast_dest );
@@ -1514,11 +1514,13 @@ __osm_pr_rcv_check_mcast_dest(
{
if( cl_ntoh16( p_pr-dlid ) = IB_LID_MCAST_START_HO
cl_ntoh16( p_pr-dlid ) = IB_LID_MCAST_END_HO )
- is_multicast = TRUE;
-else if( is_multicast )
+ is_multicast = 1;
+else if( is_multicast ) {
osm_log( p_rcv-p_log, OSM_LOG_ERROR,
__osm_pr_rcv_check_mcast_dest: ERR 1F12:
PathRecord request indicates MGID but not MLID\n );
+ return -1;
I made this go through the exit so the routine end log message is put
into the log.
Right.
Now there is 'is_multicast = -1' - you may want to change is_multicast
type to int (now it is unsigned).
+}
}
Exit:
@@ -1693,6 +1695,7 @@ osm_pr_rcv_process(
cl_qlist_t pr_list;
ib_net16_t sa_status;
osm_port_t* requester_port;
+ int ret;
OSM_LOG_ENTER( p_rcv-p_log, osm_pr_rcv_process );
@@ -1737,7 +1740,10 @@ osm_pr_rcv_process(
cl_plock_acquire( p_rcv-p_lock );
/* Handle multicast destinations separately */
- if( __osm_pr_rcv_check_mcast_dest( p_rcv, p_madw ) )
+ if( (ret = __osm_pr_rcv_check_mcast_dest( p_rcv, p_madw )) 0)
I added a send of SA status error for IB_MAD_STATUS_INVALID_FIELD here
as well as an unlock.
Sure.
Sasha
+goto Exit;
+
+ if(ret 0)
goto McastDest;
osm_log( p_rcv-p_log, OSM_LOG_DEBUG,
-- 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] [PATCH] opensm: osm_sa_path_record: mcast destination detection fix
On Mon, 2006-08-21 at 13:59, Sasha Khapyorsky wrote:
On 13:45 Mon 21 Aug , Hal Rosenstock wrote:
On Mon, 2006-08-21 at 13:22, Sasha Khapyorsky wrote:
Return error when mcast destination is not consistently indicated.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
Thanks. Applied (to both trunk and 1.1) with the following minor changes
below:
osm/opensm/osm_sa_path_record.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/osm/opensm/osm_sa_path_record.c
b/osm/opensm/osm_sa_path_record.c
index caa9f32..6b0fb28 100644
--- a/osm/opensm/osm_sa_path_record.c
+++ b/osm/opensm/osm_sa_path_record.c
@@ -1486,7 +1486,7 @@ __osm_pr_match_mgrp_attributes(
/**
**/
-static boolean_t
+static int
__osm_pr_rcv_check_mcast_dest(
IN osm_pr_rcv_t* const p_rcv,
IN const osm_madw_t* const p_madw )
@@ -1494,7 +1494,7 @@ __osm_pr_rcv_check_mcast_dest(
const ib_path_rec_t* p_pr;
const ib_sa_mad_t* p_sa_mad;
ib_net64_t comp_mask;
- boolean_tis_multicast = FALSE;
+ unsigned is_multicast = 0;
OSM_LOG_ENTER( p_rcv-p_log, __osm_pr_rcv_check_mcast_dest );
@@ -1514,11 +1514,13 @@ __osm_pr_rcv_check_mcast_dest(
{
if( cl_ntoh16( p_pr-dlid ) = IB_LID_MCAST_START_HO
cl_ntoh16( p_pr-dlid ) = IB_LID_MCAST_END_HO )
- is_multicast = TRUE;
-else if( is_multicast )
+ is_multicast = 1;
+else if( is_multicast ) {
osm_log( p_rcv-p_log, OSM_LOG_ERROR,
__osm_pr_rcv_check_mcast_dest: ERR 1F12:
PathRecord request indicates MGID but not MLID\n );
+ return -1;
I made this go through the exit so the routine end log message is put
into the log.
Right.
Now there is 'is_multicast = -1' - you may want to change is_multicast
type to int (now it is unsigned).
Thanks. Just did that (to both trunk and 1.1).
-- Hal
+}
}
Exit:
@@ -1693,6 +1695,7 @@ osm_pr_rcv_process(
cl_qlist_t pr_list;
ib_net16_t sa_status;
osm_port_t* requester_port;
+ int ret;
OSM_LOG_ENTER( p_rcv-p_log, osm_pr_rcv_process );
@@ -1737,7 +1740,10 @@ osm_pr_rcv_process(
cl_plock_acquire( p_rcv-p_lock );
/* Handle multicast destinations separately */
- if( __osm_pr_rcv_check_mcast_dest( p_rcv, p_madw ) )
+ if( (ret = __osm_pr_rcv_check_mcast_dest( p_rcv, p_madw )) 0)
I added a send of SA status error for IB_MAD_STATUS_INVALID_FIELD here
as well as an unlock.
Sure.
Sasha
+goto Exit;
+
+ if(ret 0)
goto McastDest;
osm_log( p_rcv-p_log, OSM_LOG_DEBUG,
-- 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
[openib-general] OFED 1.1-rc2 is ready
Hi, OFED 1.1-RC2 is avilable on https://openib.org/svn/gen2/branches/1.1/ofed/releases/ File: OFED-1.1-rc2.tgz Please report any issues in bugzilla http://openib.org/bugzilla/ Tziporet Vlad - Release details: Build_id: OFED-1.1-rc2 openib-1.1 (REV=9037) # User space https://openib.org/svn/gen2/branches/1.1/src/userspace Git: ref: refs/heads/ofed_1_1 commit a13195d7ca0f047f479a58b2a81ff2b796eb8fa4 # MPI mpi_osu-0.9.7-mlx2.2.0.tgz openmpi-1.1-1.src.rpm mpitests-2.0-0.src.rpm OS support: === Novell: - SLES 9.0 SP3* - SLES10 (official release)* Redhat: - Redhat EL4 up3 - Redhat EL4 up4* (not supported yet) kernel.org: - Kernel 2.6.17* * Changed from 1.0 release Note: Redhat EL4 up2, Fedora C4 and SuSE Pro 10 were dropped from the list. We keep the backport patches for these OSes and make sure OFED compile and loaded properly but will not do full QA cycle. Systems: * x86_64 * x86 * ia64 * ppc64 Main changes from OFED-1.1-rc1: === 1. ipath driver: - Compilation pass on all systems, except SLES9 SP3. - See list of changes in the ipath driver at the end 2. SDP: - Fixed issue with 32 bit systems run out of low memory when opening hundreds of sockets. - Added out of band and message peek support; telnet and ftp are now working 3. SRP - a new srp_daemon was added - see explanation at the end 4. IPoIB: High availability support using a daemon in user level. Daemon is located under /userspace/ipoibtools/. See explanation at the end. 5. Added Madeye utility 6. Added verbs fork support. Should work from kernel 2.6.16 7. Fatal error support in mthca 8. iSER support in install script for SLES 10 was fixed 9. Diagnostic tools does not requires opensm installation. For this the following changes were done to opensm RPM: opensm-devel was removed New packages were added: libosmcomp libosmcomp-devel libosmvendor libosmvendor-devel libopensm libopensm-devel 10. bug fixes: - SRP: Add local_ib_device/local_ib_port attributes to srp scsi_host - mthca: fence bit supported; fixed deadlock in destroy qp - ipoib: connectivity lost on sm lid change - OSM: fix to work with Cisco stack Limitations and known issues: = 1. SDP: For Mellanox Sinai HCAs one must use latest FW version (1.1.000). 2. SDP: Get peer name is not working properly 3. SDP: Scalability issue when many connections are opened 4. ipath driver does not compile on SLES9 SP3 5. RHEL4 up4 is not supported due to problems in the backport patches. Missing features that should be completed for RC3: == 1. Core: Huge pages fix 2. IPoIB high availability does not support multicast groups 3. Support RHEL4 up4 Changes in the ipath driver: * lock resource limit counters correctly * fix for crash on module unload, if cfgports portcnt * fix handling of kpiobufs * drop requirement that PIO buffers be mmaped write-only * merge ipath_core and ib_ipath drivers * simplify layering code * simplify debugging code after ipath_core and ib_ipath merger * remove stale references to userspace SMA * More changes to support InfiniPath on PowerPC 970 systems. * add new minor device to allow sending of diag packets * do not allow use of CQ entries with invalid counts * account for attached QPs correctly * support new QLogic product naming scheme * add serial number to hardware freeze error message * be more strict about testing the modify QP verb * validate path_mig_state properly * put a limit on the number of QPs that can be created * handle sq_sig_all field correctly * allow SMA to be disabled * fix return value from ipath_poll * print warning if LID not acquired within one minute * allow direct control of Rx polarity inversion srp_daemon explanation: === srp_daemon is a tool that identifies SRP targets in the fabric. Each srp_daemon instance is operating on one port. On boot it performs a full rescan of the fabric and waits to srp_daemon events: - a join of a new target to the fabric - a change in the capabilities of a machine that becomes a target - an SA change - an expiration of a predefined timeout When there is an SA change or a timeout expiration srp_daemon perform a full rescan of the fabric. for each target srp_daemon finds, it checks if it is already connected to that port, if it is not connected, srp_daemon can either print the target details or connect to it. Run srp_daemon -h for usage. IPoIB HA daemon: The IPoIB HA daemon can be configured in /etc/infiniband/openib.conf file: # Enable
Re: [openib-general] [openfabrics-ewg] OFED 1.1-rc2 is ready
On 21:49 Mon 21 Aug , Tziporet Koren wrote: Hi, OFED 1.1-RC2 is avilable on https://openib.org/svn/gen2/branches/1.1/ofed/releases/ File: OFED-1.1-rc2.tgz BTW, Why it is necessary to put binary *.tgz files under Subversion? We are not going to change it and not interesting in history tracking. Sasha Please report any issues in bugzilla http://openib.org/bugzilla/ Tziporet Vlad - Release details: Build_id: OFED-1.1-rc2 openib-1.1 (REV=9037) # User space https://openib.org/svn/gen2/branches/1.1/src/userspace Git: ref: refs/heads/ofed_1_1 commit a13195d7ca0f047f479a58b2a81ff2b796eb8fa4 # MPI mpi_osu-0.9.7-mlx2.2.0.tgz openmpi-1.1-1.src.rpm mpitests-2.0-0.src.rpm OS support: === Novell: - SLES 9.0 SP3* - SLES10 (official release)* Redhat: - Redhat EL4 up3 - Redhat EL4 up4* (not supported yet) kernel.org: - Kernel 2.6.17* * Changed from 1.0 release Note: Redhat EL4 up2, Fedora C4 and SuSE Pro 10 were dropped from the list. We keep the backport patches for these OSes and make sure OFED compile and loaded properly but will not do full QA cycle. Systems: * x86_64 * x86 * ia64 * ppc64 Main changes from OFED-1.1-rc1: === 1. ipath driver: - Compilation pass on all systems, except SLES9 SP3. - See list of changes in the ipath driver at the end 2. SDP: - Fixed issue with 32 bit systems run out of low memory when opening hundreds of sockets. - Added out of band and message peek support; telnet and ftp are now working 3. SRP - a new srp_daemon was added - see explanation at the end 4. IPoIB: High availability support using a daemon in user level. Daemon is located under /userspace/ipoibtools/. See explanation at the end. 5. Added Madeye utility 6. Added verbs fork support. Should work from kernel 2.6.16 7. Fatal error support in mthca 8. iSER support in install script for SLES 10 was fixed 9. Diagnostic tools does not requires opensm installation. For this the following changes were done to opensm RPM: opensm-devel was removed New packages were added: libosmcomp libosmcomp-devel libosmvendor libosmvendor-devel libopensm libopensm-devel 10. bug fixes: - SRP: Add local_ib_device/local_ib_port attributes to srp scsi_host - mthca: fence bit supported; fixed deadlock in destroy qp - ipoib: connectivity lost on sm lid change - OSM: fix to work with Cisco stack Limitations and known issues: = 1. SDP: For Mellanox Sinai HCAs one must use latest FW version (1.1.000). 2. SDP: Get peer name is not working properly 3. SDP: Scalability issue when many connections are opened 4. ipath driver does not compile on SLES9 SP3 5. RHEL4 up4 is not supported due to problems in the backport patches. Missing features that should be completed for RC3: == 1. Core: Huge pages fix 2. IPoIB high availability does not support multicast groups 3. Support RHEL4 up4 Changes in the ipath driver: * lock resource limit counters correctly * fix for crash on module unload, if cfgports portcnt * fix handling of kpiobufs * drop requirement that PIO buffers be mmaped write-only * merge ipath_core and ib_ipath drivers * simplify layering code * simplify debugging code after ipath_core and ib_ipath merger * remove stale references to userspace SMA * More changes to support InfiniPath on PowerPC 970 systems. * add new minor device to allow sending of diag packets * do not allow use of CQ entries with invalid counts * account for attached QPs correctly * support new QLogic product naming scheme * add serial number to hardware freeze error message * be more strict about testing the modify QP verb * validate path_mig_state properly * put a limit on the number of QPs that can be created * handle sq_sig_all field correctly * allow SMA to be disabled * fix return value from ipath_poll * print warning if LID not acquired within one minute * allow direct control of Rx polarity inversion srp_daemon explanation: === srp_daemon is a tool that identifies SRP targets in the fabric. Each srp_daemon instance is operating on one port. On boot it performs a full rescan of the fabric and waits to srp_daemon events: - a join of a new target to the fabric - a change in the capabilities of a machine that becomes a target - an SA change - an expiration of a predefined timeout When there is an SA change or a timeout expiration srp_daemon perform a full rescan of the fabric. for
Re: [openib-general] [openfabrics-ewg] Rollup patch for ipath and OFED
Woodruff, Robert J wrote: making life very difficult. I assumed that the latest working code would be put into SVN, as it has been in the past. If this is not the case, then please tell me where I can get the latest HCA drivers that will work with Sean's latest code that is in SVN. woody You can take the code from the new OFED 1.1-rc2 Tziporet ___ 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] [openfabrics-ewg] Rollup patch for ipath and OFED
Quoting r. Woodruff, Robert J [EMAIL PROTECTED]: Subject: RE: [openfabrics-ewg] Rollup patch for ipath and OFED Brian Wrote, On Wed, 2006-08-16 at 21:49 +0300, Michael S. Tsirkin wrote: Woops, only now noticed that this was wrt the ipath driver, not mthca as I thought. Of course I didn't mean it - I don't edit ipath code in SVN, pathscale guys do that. We don't actually use SVN to develop the driver either. For kernel stuff, I think it's become just a dumping ground for changes that people have made in their own private trees. This makes it not a suitable place to be pulling driver sources from. b I am just looking for stable HCA drivers that will work with the rest of the latest code that is in SVN. Sean is putting all his changes into SVN and we need to test them with the HCA drivers and the rest of the stack. At this point, I have not a clue where the latest code is for all the different components and it is making life very difficult. I assumed that the latest working code would be put into SVN, as it has been in the past. If this is not the case, then please tell me where I can get the latest HCA drivers that will work with Sean's latest code that is in SVN. Simply put, ideally each component should be developed separately against upstream versions of the rest of them. Maybe Sean can start publishing git trees with his stuff? AFAIK, there are several developments - sa cache, multicast module, userspace cma access ... and these could even go into separate branches, making it easy for people to mix and match. Sean? -- 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] [openfabrics-ewg] Rollup patch for ipath and OFED
Quoting r. Woodruff, Robert J [EMAIL PROTECTED]: Bottom line is we either need to keep the code in the trunk up to date or remove it, but having multiple data bases with different versions is somewhat confusing. Since kernel level code is in kernel.org git trees, as long as we do keep kernel code in subversion this automatically implies multiple different databases. No? -- 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] [openfabrics-ewg] Rollup patch for ipath and OFED
Michael wrote, Quoting r. Woodruff, Robert J [EMAIL PROTECTED]: Bottom line is we either need to keep the code in the trunk up to date or remove it, but having multiple data bases with different versions is somewhat confusing. Since kernel level code is in kernel.org git trees, as long as we do keep kernel code in subversion this automatically implies multiple different databases. No? -- MST Yes, there are multiple databases and this is confusing. However, I don't think there are any backport patches and such in the kernel.org trees, so we need some database somewhere that has the latest version of code under development that people can test against, otherwise it seems likely that people would be developing and testing against different branches and when time comes to integrate it all for the next kernel release, there could be issues that arise. In the past, we always kept the latest development version of the code in SVN and could easily build it to test. I have said this in the past but will say it again, if people want to use git instead of SVN for the kernel code, then that is fine, but if that is to be the case, then we should have one git tree somewhere that has all the latest code that we can pull from and then remove the kernel code from SVN to avoid confusion. woody ___ 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] [openfabrics-ewg] Rollup patch for ipath and OFED
Michael S. Tsirkin wrote: Simply put, ideally each component should be developed separately against upstream versions of the rest of them. While this sounds good, it implies that the components are somewhat isolated from each other, which often isn't the case. Maybe Sean can start publishing git trees with his stuff? AFAIK, there are several developments - sa cache, multicast module, userspace cma access ... and these could even go into separate branches, making it easy for people to mix and match. OpenFabrics as an organization made the decision to use SVN as its code repository for open-source development. We've discussed using something else a few times, without ever reaching consensus. Until OpenFabrics decides to move to a different source control tool or follow a different development model, I think it's best for all developers to be consistent. - 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] [openfabrics-ewg] Rollup patch for ipath and OFED
Quoting r. Woodruff, Robert J [EMAIL PROTECTED]: We should have one git tree somewhere that has all the latest code that we can pull from I just don't think latest code is a well defined entity in a distributed development environment. -- 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] [openfabrics-ewg] Rollup patch for ipath and OFED
Michael S. Tsirkin wrote: Quoting r. Woodruff, Robert J [EMAIL PROTECTED]: We should have one git tree somewhere that has all the latest code that we can pull from I just don't think latest code is a well defined entity in a distributed development environment. kernel.org is well defined. How are we any different? ___ 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] [openfabrics-ewg] Rollup patch for ipath and OFED
Arlin kernel.org is well defined. How are we any different? Sure, there is the Linus's latest tree. But there's also Len Brown's latest ACPI tree, James Bottomley's latest SCSI tree, Jeff Garzik's latest net driver tree, etc. - 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] [openfabrics-ewg] Rollup patch for ipath and OFED
Quoting r. Arlin Davis [EMAIL PROTECTED]: We should have one git tree somewhere that has all the latest code that we can pull from I just don't think latest code is a well defined entity in a distributed development environment. kernel.org is well defined. How are we any different? It depends on what you are talking about. Pls look again at http://www.kernel.org/: The latest stable version of the Linux kernel is:2.6.17.9 The latest prepatch for the stable Linux kernel tree is: 2.6.18-rc4 The latest snapshot for the stable Linux kernel tree is: 2.6.18-rc4-git1 kernel.org *stable kernels* are well defined. And we have the same with OFED releases and it is not different - so are you saying Woody can just take latest OFED release? If so I agree. But *development* is not usually done on stable tree - it is merged there. See the difference? -- 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] [openfabrics-ewg] Rollup patch for ipath and OFED
But *development* is not usually done on stable tree - it is merged there. See the difference? Let's keep this simple. We submit patches (which are expected to compile and run) against the latest code. Today, that is the tip of gen2 branch in SVN. - 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] [PATCH v3] ib_sa: require SA registration
Require registration with SA module, to prevent module text
from going away while sa query callback is still running,
and update all users.
Signed-off-by: Michael S. Tsirkin mst at mellanox.co.il
Signed-off-by: Sean Hefty sean.hefty at intel.com
---
Changes from the previous post include:
* Move struct ib_sa_client definition external.
Index: include/rdma/ib_sa.h
===
--- include/rdma/ib_sa.h(revision 8928)
+++ include/rdma/ib_sa.h(working copy)
@@ -1,6 +1,7 @@
/*
* Copyright (c) 2004 Topspin Communications. All rights reserved.
* Copyright (c) 2005 Voltaire, Inc. All rights reserved.
+ * Copyright (c) 2006 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -36,6 +37,9 @@
#ifndef IB_SA_H
#define IB_SA_H
+#include asm/atomic.h
+
+#include linux/completion.h
#include linux/compiler.h
#include rdma/ib_verbs.h
@@ -250,11 +254,28 @@ struct ib_sa_service_rec {
u64 data64[2];
};
+struct ib_sa_client {
+ atomic_t users;
+ struct completion comp;
+};
+
+/**
+ * ib_sa_register_client - Register an SA client.
+ */
+void ib_sa_register_client(struct ib_sa_client *client);
+
+/**
+ * ib_sa_unregister_client - Deregister an SA client.
+ * @client: Client object to deregister.
+ */
+void ib_sa_unregister_client(struct ib_sa_client *client);
+
struct ib_sa_query;
void ib_sa_cancel_query(int id, struct ib_sa_query *query);
-int ib_sa_path_rec_get(struct ib_device *device, u8 port_num,
+int ib_sa_path_rec_get(struct ib_sa_client *client,
+ struct ib_device *device, u8 port_num,
struct ib_sa_path_rec *rec,
ib_sa_comp_mask comp_mask,
int timeout_ms, int retries, gfp_t gfp_mask,
@@ -264,7 +285,8 @@ int ib_sa_path_rec_get(struct ib_device
void *context,
struct ib_sa_query **query);
-int ib_sa_mcmember_rec_query(struct ib_device *device, u8 port_num,
+int ib_sa_mcmember_rec_query(struct ib_sa_client *client,
+struct ib_device *device, u8 port_num,
u8 method,
struct ib_sa_mcmember_rec *rec,
ib_sa_comp_mask comp_mask,
@@ -275,7 +297,8 @@ int ib_sa_mcmember_rec_query(struct ib_d
void *context,
struct ib_sa_query **query);
-int ib_sa_service_rec_query(struct ib_device *device, u8 port_num,
+int ib_sa_service_rec_query(struct ib_sa_client *client,
+struct ib_device *device, u8 port_num,
u8 method,
struct ib_sa_service_rec *rec,
ib_sa_comp_mask comp_mask,
@@ -288,6 +311,7 @@ int ib_sa_service_rec_query(struct ib_de
/**
* ib_sa_mcmember_rec_set - Start an MCMember set query
+ * @client:SA client
* @device:device to send query on
* @port_num: port number to send query on
* @rec:MCMember Record to send in query
@@ -312,7 +336,8 @@ int ib_sa_service_rec_query(struct ib_de
* cancel the query.
*/
static inline int
-ib_sa_mcmember_rec_set(struct ib_device *device, u8 port_num,
+ib_sa_mcmember_rec_set(struct ib_sa_client *client,
+ struct ib_device *device, u8 port_num,
struct ib_sa_mcmember_rec *rec,
ib_sa_comp_mask comp_mask,
int timeout_ms, int retries, gfp_t gfp_mask,
@@ -322,7 +347,7 @@ ib_sa_mcmember_rec_set(struct ib_device
void *context,
struct ib_sa_query **query)
{
- return ib_sa_mcmember_rec_query(device, port_num,
+ return ib_sa_mcmember_rec_query(client, device, port_num,
IB_MGMT_METHOD_SET,
rec, comp_mask,
timeout_ms, retries, gfp_mask, callback,
@@ -331,6 +356,7 @@ ib_sa_mcmember_rec_set(struct ib_device
/**
* ib_sa_mcmember_rec_delete - Start an MCMember delete query
+ * @client:SA client
* @device:device to send query on
* @port_num: port number to send query on
* @rec:MCMember Record to send in query
@@ -355,7 +381,8 @@ ib_sa_mcmember_rec_set(struct ib_device
* cancel the query.
*/
static inline int
-ib_sa_mcmember_rec_delete(struct ib_device *device, u8 port_num,
+ib_sa_mcmember_rec_delete(struct ib_sa_client *client,
+ struct ib_device *device, u8 port_num,
struct ib_sa_mcmember_rec *rec,
ib_sa_comp_mask comp_mask,
int timeout_ms, int retries, gfp_t gfp_mask,
@@ -365,7 +392,7 @@ ib_sa_mcmember_rec_delete(struct ib_devi
void
[openib-general] [PATCH 1/2] ib_sa: add generic RMPP query interface
The following patch adds a generic interface to send MADs to the SA.
The primary motivation of adding these calls is to expand the SA query
interface to include RMPP responses for users wanting more than a
single attribute returned from a query (e.g. multipath record queries).
The implementation of existing SA query routines was layered on top
of the generic query interface.
Signed-off-by: Sean Hefty sean.hefty at intel.com
---
This patch applies on top of the SA registration patch:
http://openib.org/pipermail/openib-general/2006-August/025267.html
--- infiniband/include/rdma/ib_sa.h 2006-08-21 16:37:12.700292000 -0700
+++ infiniband.user/include/rdma/ib_sa.h2006-08-21 16:37:52.126298336
-0700
@@ -82,6 +82,32 @@ enum {
IB_SA_ATTR_INFORM_INFO_REC = 0xf3
};
+/* Length of SA attributes on the wire */
+enum {
+ IB_SA_ATTR_CLASS_PORTINFO_LEN = 72,
+ IB_SA_ATTR_NOTICE_LEN = 80,
+ IB_SA_ATTR_INFORM_INFO_LEN = 36,
+ IB_SA_ATTR_NODE_REC_LEN = 108,
+ IB_SA_ATTR_PORT_INFO_REC_LEN= 58,
+ IB_SA_ATTR_SL2VL_REC_LEN= 16,
+ IB_SA_ATTR_SWITCH_REC_LEN = 21,
+ IB_SA_ATTR_LINEAR_FDB_REC_LEN = 72,
+ IB_SA_ATTR_RANDOM_FDB_REC_LEN = 72,
+ IB_SA_ATTR_MCAST_FDB_REC_LEN= 72,
+ IB_SA_ATTR_SM_INFO_REC_LEN = 25,
+ IB_SA_ATTR_LINK_REC_LEN = 6,
+ IB_SA_ATTR_GUID_INFO_REC_LEN= 72,
+ IB_SA_ATTR_SERVICE_REC_LEN = 176,
+ IB_SA_ATTR_PARTITION_REC_LEN= 72,
+ IB_SA_ATTR_PATH_REC_LEN = 64,
+ IB_SA_ATTR_VL_ARB_REC_LEN = 72,
+ IB_SA_ATTR_MC_MEMBER_REC_LEN= 52,
+ IB_SA_ATTR_TRACE_REC_LEN= 46,
+ IB_SA_ATTR_MULTI_PATH_REC_LEN = 56,
+ IB_SA_ATTR_SERVICE_ASSOC_REC_LEN= 80,
+ IB_SA_ATTR_INFORM_INFO_REC_LEN = 60
+};
+
enum ib_sa_selector {
IB_SA_GTE = 0,
IB_SA_LTE = 1,
@@ -270,10 +296,83 @@ void ib_sa_register_client(struct ib_sa_
*/
void ib_sa_unregister_client(struct ib_sa_client *client);
+struct ib_sa_iter;
+
+/**
+ * ib_sa_iter_create - Create an iterator that may be used to walk through
+ * a list of returned SA records.
+ * @mad_recv_wc: A received response from the SA.
+ *
+ * This call allocates an iterator that is used to walk through a list of
+ * SA records. Users must free the iterator by calling ib_sa_iter_free.
+ */
+struct ib_sa_iter *ib_sa_iter_create(struct ib_mad_recv_wc *mad_recv_wc);
+
+/**
+ * ib_sa_iter_free - Release an iterator.
+ * @iter: The iterator to free.
+ */
+void ib_sa_iter_free(struct ib_sa_iter *iter);
+
+/**
+ * ib_sa_iter_next - Move an iterator to reference the next attribute and
+ * return the attribute.
+ * @iter: The iterator to move.
+ *
+ * The referenced attribute will be in wire format. The funtion returns NULL
+ * if there are no more attributes to return.
+ */
+void *ib_sa_iter_next(struct ib_sa_iter *iter);
+
+/**
+ * ib_sa_attr_size - Return the length of an SA attribute on the wire.
+ * @attr_id: Attribute identifier.
+ */
+int ib_sa_attr_size(__be16 attr_id);
+
struct ib_sa_query;
void ib_sa_cancel_query(int id, struct ib_sa_query *query);
+/**
+ * ib_sa_send_mad - Send a MAD to the SA.
+ * @client:SA client
+ * @device:device to send query on
+ * @port_num: port number to send query on
+ * @method:MAD method to use in the send.
+ * @attr:Reference to attribute in wire format to send in MAD.
+ * @attr_id:Attribute type identifier.
+ * @comp_mask:component mask to send in MAD
+ * @timeout_ms:time to wait for response, if one is expected
+ * @retries:number of times to retry request
+ * @gfp_mask:GFP mask to use for internal allocations
+ * @callback:function called when query completes, times out or is
+ * canceled
+ * @context:opaque user context passed to callback
+ * @sa_query:query context, used to cancel query
+ *
+ * Send a message to the SA. If a response is expected (timeout_ms is
+ * non-zero), the callback function will be called when the query completes.
+ * Status is 0 for a successful response, -EINTR if the query
+ * is canceled, -ETIMEDOUT is the query timed out, or -EIO if an error
+ * occurred sending the query. Mad_recv_wc will reference any returned
+ * response from the SA. It is the responsibility of the caller to free
+ * mad_recv_wc by call ib_free_recv_mad() if it is non-NULL.
+ *
+ * If the return value of ib_sa_send_mad() is negative, it is an
+ * error code. Otherwise it is a query ID that can be used to cancel
+ * the query.
+ */
+int ib_sa_send_mad(struct ib_sa_client *client,
+ struct ib_device *device, u8 port_num,
+ int method, void *attr, __be16 attr_id,
+ ib_sa_comp_mask comp_mask,
+ int timeout_ms, int retries, gfp_t gfp_mask,
+ void (*callback)(int status,
+ struct ib_mad_recv_wc *mad_recv_wc,
+ void *context),
+
[openib-general] [PATCH 2/2] ib_local_sa: use SA iterator routines to walk RMPP response
Convert local SA to use the new SA iterator routines for walking a
list of attributes in an RMPP response returned by the SA. This
replaces a local SA specific implementation.
Signed-off-by: Sean Hefty sean.hefty at intel.com
---
--- infiniband/core/local_sa.c 2006-08-21 16:40:23.760246472 -0700
+++ infiniband.user/core/local_sa.c 2006-08-21 16:48:28.403569488 -0700
@@ -107,16 +107,6 @@ struct sa_db_device {
struct sa_db_port port[0];
};
-/* Define path record format to enable needed checks against MAD data. */
-struct ib_path_rec {
- u8 reserved[8];
- u8 dgid[16];
- u8 sgid[16];
- __be16 dlid;
- __be16 slid;
- u8 reserved2[20];
-};
-
struct ib_sa_cursor {
struct ib_sa_cursor *next;
};
@@ -194,60 +184,29 @@ static int insert_attr(struct index_root
static void update_path_rec(struct sa_db_port *port,
struct ib_mad_recv_wc *mad_recv_wc)
{
- struct ib_mad_recv_buf *recv_buf;
- struct ib_sa_mad *mad = (void *) mad_recv_wc-recv_buf.mad;
+ struct ib_sa_iter *iter;
struct ib_path_rec_info *path_info;
- struct ib_path_rec ib_path, *path = NULL;
- int i, attr_size, left, offset = 0;
+ void *attr;
- attr_size = be16_to_cpu(mad-sa_hdr.attr_offset) * 8;
- if (attr_size sizeof ib_path)
+ iter = ib_sa_iter_create(mad_recv_wc);
+ if (IS_ERR(iter))
return;
down_write(lock);
port-update++;
- list_for_each_entry(recv_buf, mad_recv_wc-rmpp_list, list) {
- for (i = 0; i IB_MGMT_SA_DATA;) {
- mad = (struct ib_sa_mad *) recv_buf-mad;
-
- left = IB_MGMT_SA_DATA - i;
- if (left sizeof ib_path) {
- /* copy first piece of the attribute */
- memcpy(ib_path, mad-data[i], left);
- path = ib_path;
- offset = left;
- break;
- } else if (offset) {
- /* copy the second piece of the attribute */
- memcpy((void*) path + offset, mad-data[i],
- sizeof ib_path - offset);
- i += attr_size - offset;
- offset = 0;
- } else {
- path = (void *) mad-data[i];
- i += attr_size;
- }
-
- if (!path-slid)
- goto unlock;
-
- path_info = kmalloc(sizeof *path_info, GFP_KERNEL);
- if (!path_info)
- goto unlock;
-
- ib_sa_unpack_attr(path_info-rec, path,
- IB_SA_ATTR_PATH_REC);
-
- if (insert_attr(port-index, port-update,
- path_info-rec.dgid.raw,
- path_info-cursor)) {
- kfree(path_info);
- goto unlock;
- }
+ while ((attr = ib_sa_iter_next(iter))
+ (path_info = kmalloc(sizeof *path_info, GFP_KERNEL))) {
+
+ ib_sa_unpack_attr(path_info-rec, attr, IB_SA_ATTR_PATH_REC);
+ if (insert_attr(port-index, port-update,
+ path_info-rec.dgid.raw,
+ path_info-cursor)) {
+ kfree(path_info);
+ break;
}
}
-unlock:
up_write(lock);
+ ib_sa_iter_free(iter);
}
static void recv_handler(struct ib_mad_agent *mad_agent,
___
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] ib_usa: support userspace SA queries and multicast
Add support for userspace SA queries and multicast join operations.
This allows a userspace library to issue SA queries and join
IB multicast groups.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
This patch depends on the generic RMPP query interface:
http://openib.org/pipermail/openib-general/2006-August/025268.html
Index: include/rdma/ib_usa.h
===
--- include/rdma/ib_usa.h (revision 0)
+++ include/rdma/ib_usa.h (revision 0)
@@ -0,0 +1,123 @@
+/*
+ * Copyright (c) 2006 Intel Corporation. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef IB_USA_H
+#define IB_USA_H
+
+#include linux/types.h
+#include rdma/ib_sa.h
+
+#define IB_USA_ABI_VERSION 1
+
+#define IB_USA_EVENT_DATA 256
+
+enum {
+ IB_USA_CMD_SEND_MAD,
+ IB_USA_CMD_GET_EVENT,
+ IB_USA_CMD_GET_DATA,
+ IB_USA_CMD_JOIN_MCAST,
+ IB_USA_CMD_FREE_ID,
+ IB_USA_CMD_GET_MCAST
+};
+
+enum {
+ IB_USA_EVENT_MAD,
+ IB_USA_EVENT_MCAST
+};
+
+struct ib_usa_cmd_hdr {
+ __u32 cmd;
+ __u16 in;
+ __u16 out;
+};
+
+struct ib_usa_send_mad {
+ __u64 response; /* unused - reserved */
+ __u64 uid;
+ __u64 node_guid;
+ __u64 comp_mask;
+ __u64 attr;
+ __u8 port_num;
+ __u8 method;
+ __be16 attr_id;
+ __u32 timeout_ms;
+ __u32 retries;
+};
+
+struct ib_usa_join_mcast {
+ __u64 response;
+ __u64 uid;
+ __u64 node_guid;
+ __u64 comp_mask;
+ __u64 mcmember_rec;
+ __u8 port_num;
+};
+
+struct ib_usa_id_resp {
+ __u32 id;
+};
+
+struct ib_usa_free_resp {
+ __u32 events_reported;
+};
+
+struct ib_usa_free_id {
+ __u64 response;
+ __u32 id;
+};
+
+struct ib_usa_get_event {
+ __u64 response;
+};
+
+struct ib_usa_event_resp {
+ __u64 uid;
+ __u32 id;
+ __u32 event;
+ __u32 status;
+ __u32 data_len;
+ __u8 data[IB_USA_EVENT_DATA];
+};
+
+struct ib_usa_get_data {
+ __u64 response;
+ __u32 id;
+};
+
+struct ib_usa_get_mcast {
+ __u64 response;
+ __u64 node_guid;
+ __u8 mgid[16];
+ __u8 port_num;
+};
+
+#endif /* IB_USA_H */
Index: core/usa.c
===
--- core/usa.c (revision 0)
+++ core/usa.c (revision 0)
@@ -0,0 +1,772 @@
+/*
+ * Copyright (c) 2006 Intel Corporation. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+
Re: [openib-general] why sdp connections cost so much memory
Do you find the same problem? zhu __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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 v3 0/6] Tranport Neutral Verbs Proposal.
Hi Roland, Krishna Hi Roland Sean, What is your opinion on this patch set Krishna ? Anything else needs to be done for acceptance ? It's a very low priority for me, since it's a pain to merge and a pain to maintain I understand. If you feel that I can reduce the pain by sending an up-todate patch set, let me know. thanks, - KK I'll try to get to it after everything else I want for libibverbs 1.1 is done (expose device type, memory windows, reregister memory region at least) - 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
