While looking over the ehca driver from the perspective of adding a
peek CQ operation, I noticed some code that looked funny.
In hipz_set_cqx_n0() and hipz_set_cqx_n1(), what is the point of the
calls to hipz_galpa_load_cq()? The return value is discarded. I see
that hipz_galpa_load_cq()
On Fri, 29 Sep 2006, Bryan O'Sullivan wrote:
On Fri, 2006-09-29 at 12:26 -0400, James Lentini wrote:
Balkanizing the OFA repository into corporate repositories would be a
mistake.
Nobody is suggesting this. However, separating the mess that is the
current SVN trunk into a set of
James Unfortunately this does happen. Sean has already said he
James can only access git trees at kernel.org.
I think he just said that he can only access git trees via http://.
- R.
___
openib-general mailing list
openib-general@openib.org
James Unfortunately this does happen. Sean has already said he
James can only access git trees at kernel.org.
I think he just said that he can only access git trees via http://.
I can access git://git.kernel.org or http://git.somewhere.else.
- Sean
Hello Roland!
Below is a patch of ehca, which fixes a bug (crash) that occured when ib_ehca
is loaded after ib_ipoib. This patch initializes struct ehca_shca with
struct device*, then creates internal resources and finally registers the
ehca IB device. And that is the proper sequence to do.
In
Looks OK but your mailer mangled the patch. Please resend in a form
that can be applied...
Also:
In addition to that this patch contains a very small format improvement
in our tracing function.
please send unrelated changes as separate patches.
So this should come as two patches -- one to
I am testing an app in development on RHEL 4 U3 using uDAPL. The app runs OK
on gen1 stacks, but cannot run on any OFED based stack I have tried on RHEL 4
U3. The symptom is RDMAs not getting completion. A completion notification is
sent, but
mthca_poll_cq() finds no completion. I debugged
Bill I am testing an app in development on RHEL 4 U3 using uDAPL.
Bill The app runs OK on gen1 stacks, but cannot run on any OFED
Bill based stack I have tried on RHEL 4 U3. The symptom is RDMAs
Bill not getting completion. A completion notification is sent,
Bill but
Roland Dreier wrote:
Bill I am testing an app in development on RHEL 4 U3 using uDAPL.
Bill The app runs OK on gen1 stacks, but cannot run on any OFED
Bill based stack I have tried on RHEL 4 U3. The symptom is RDMAs
Bill not getting completion. A completion notification is
James Lentini wrote:
It is likely that companies will restrict developers at HCA
vendor X from contributing code to HCA vendor Y's repository.
I doubt it.
Unfortunately this does happen. Sean has already said he can only
access git trees at kernel.org.
That appears to be a matter of
Bill At 1st, I thought that was the case, a fork, however, I do
Bill not think get_user_pages(), and the increment of the ref
Bill count, will guarantee the page struct does not change for
Bill RHEL 4 U3, I need to verify that though.
Are you doing a fork()? If so then, yes, you
Roland Dreier wrote:
Bill At 1st, I thought that was the case, a fork, however, I do
Bill not think get_user_pages(), and the increment of the ref
Bill count, will guarantee the page struct does not change for
Bill RHEL 4 U3, I need to verify that though.
Are you doing a
On Sun, 2006-10-01 at 09:50 +0200, Michael S. Tsirkin wrote:
Quoting r. Tseng-Hui (Frank) Lin [EMAIL PROTECTED]:
Subject: RE: FW: Mstflint - not working on ppc64 andwhendriver is notloaded
on AMD
The ppc64 problem is actually in pci_64.c. Here is the patch:
cut here
Adds the driver main files. These files implement netdev
registration, netdev functions and state maintenance of the
virtual NIC corresponding to the various events associated
with the Virtual Ethernet IOC (VEx) connection.
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
Adds the driver netpath files. These files implement
the netpath layer. Netpath is an an abstraction of a connection
to the VEx.
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
drivers/infiniband/ulp/vnic/vnic_netpath.c | 250
Adds the driver viport files. These files implement the state machine
for the communication protocol with the VEx.
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
drivers/infiniband/ulp/vnic/vnic_viport.c | 936 +
drivers/infiniband/ulp/vnic/vnic_viport.h | 175
Adds the files that implement the data transfer part of the
communication protocol with the VEx. The RDMA of ethernet
packets is implemented in here.
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
drivers/infiniband/ulp/vnic/vnic_data.c| 1065
Adds the files that implement interaction with the core IB stack.
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
drivers/infiniband/ulp/vnic/vnic_ib.c | 709 +
drivers/infiniband/ulp/vnic/vnic_ib.h | 167
2 files changed, 876 insertions(+), 0
Adds the files that handle various configurable parameters of the
driver configuration of virtual NIC, control, data connections
to the VEx and general IB connection parameters.
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
drivers/infiniband/ulp/vnic/vnic_config.c | 739
Adds the files that implement the sysfs interface of the driver.
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
drivers/infiniband/ulp/vnic/vnic_sys.c | 1118
drivers/infiniband/ulp/vnic/vnic_sys.h | 51 +
2 files changed, 1169 insertions(+), 0
Adds the driver utility file. This file contains utility
macros for debugging etc
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
drivers/infiniband/ulp/vnic/vnic_util.h | 286 +++
1 files changed, 286 insertions(+), 0 deletions(-)
diff --git
Adds the Kconfig and Makefile for the driver.
Modifies the top level Infiniband Kconfig and Makefile to include VNIC.
Signed-off-by: Ramachandra K [EMAIL PROTECTED]
---
drivers/infiniband/Kconfig |2 ++
drivers/infiniband/Makefile |1 +
Ramachandra This patch series is intended for your infiniband.git
Ramachandra for-2.6.19 branch. It also has been tested against
Ramachandra the for-2.6.20 branch.
Well, no way is this going to be merged into 2.6.19 at this stage in
the release cycle (the merge window is closing in a
Is this communication protocols documented anywhere? How does this
feature compare to IPoIB and SDP?
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Roland Dreier wrote:
Ramachandra This patch series is intended for your infiniband.git
Ramachandra for-2.6.19 branch. It also has been tested against
Ramachandra the for-2.6.20 branch.
Well, no way is this going to be merged into 2.6.19 at this stage in
the release cycle (the merge
+#ifdef CONFIG_INFINIBAND_VNIC_STATS
+extern cycles_t recv_ref;
+#endif /* CONFIG_INFINIBAND_VNIC_STATS */
put this declaration in a header file somewhere, not inside a function
in a .c file.
Also is it really worth having CONFIG_INFINIBAND_VNIC_STATS? Who
Looks OK but your mailer mangled the patch. Please resend in a form
that can be applied...
please send unrelated changes as separate patches.
So this should come as two patches -- one to fix the device
registration, and one to change your debug formatting.
ok, will resend those two patches
+if (netpath-timer_state == NETPATH_TS_ACTIVE) {
+del_timer_sync(netpath-timer);
+}
kernel style is just to do
if (netpath-timer_state == NETPATH_TS_ACTIVE)
del_timer_sync(netpath-timer);
this could be fixed many places.
+void
+viport = (struct viport *)kmalloc(sizeof(struct viport), GFP_KERNEL);
+memset(viport, 0, sizeof(struct viport));
cast from void * is not necessary. memset can be replaced by just
using kzalloc().
- R.
___
openib-general mailing list
Hi Roland/Michael,
One of my coworkers in Champaign is seeing a performance
issue with the latest SVN driver and the OFED 1.1 Mellanox
driver on certain platforms.
On the older SVN somewhere around 7500 the Mellanox driver
did not save and restore certain PCI registers before a reset.
Hi Roland!
Below is a patch of ehca, which fixes a bug (crash) that occured when ib_ehca
is loaded after ib_ipoib. This patch initializes struct ehca_shca with
struct device*, then creates internal resources and finally registers the
ehca IB device. And that is the proper sequence to do.
Thanks!
+#define hton8(x)(x)
+#define hton16(x) __cpu_to_be16(x)
+#define hton32(x) __cpu_to_be32(x)
+#define hton64(x) __cpu_to_be64(x)
+
+#define ntoh8(x)(x)
+#define ntoh16(x) __be16_to_cpu(x)
+#define ntoh32(x) __be32_to_cpu(x)
+#define ntoh64(x) __be64_to_cpu(x)
Hi,
here is the 2nd patch of ehca with a small format improvement in ehca debug
function.
Thanks!
Nam Nguyen
Signed-off-by: Hoang-Nam Nguyen [EMAIL PROTECTED]
---
ehca_tools.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -Nurp
+sid = 0x10LL 56 |
+0x00LL 48 |
+0x06LL 40 |
+0x6aLL 32 |
+0x00LL 24 |
+0x00LL 16 |
+0x00LL 8 | ((be64_to_cpu(params-ioc_guid) 32) 0xFF);
What is this magic number code doing?? Wouldn't it be clearer just to
use the
Ramachandra In that case, can you please consider this for the
Ramachandra for-2.6.20 branch ?
I'm happy to keep this in a vex branch or something like that, but as
the emails I just sent show, this is not ready for merging yet (which
is to be expected -- it's never been reviewed).
I
Does using the tune_pci=1 module option for ib_mthca bring the
performance back up?
The reason the driver was changed to work this way is that presumably
the BIOS is setting the PCI configuration as it does for a reason. So
you might want investigate why the BIOS sets MaxReadReq down to 128 in
Ramachandra K wrote:
+#include linux/kernel.h
Not needed.
+#include linux/version.h
Not needed.
+#ifdef CONFIG_INFINIBAND_VNIC_STATS
+ if (vnic-statistics.conn_time == 0) {
+ vnic-statistics.conn_time =
+ get_cycles() - vnic-statistics.start_time;
+
Ramachandra K wrote:
Adds the driver viport files. These files implement the state machine
for the communication protocol with the VEx.
This looks like a cut-and-paste of the main driver file, and has the
same big problem of a single huge state machine function and a bunch of
tiny trivial
Bryan This looks like a cut-and-paste of the main driver file,
Bryan and has the same big problem of a single huge state machine
Bryan function and a bunch of tiny trivial stubs that all serve
Bryan to obfuscate the code.
Yes, in general it seems like this all could be made quite
Roland wrote,
However tune_pci=1 will make the driver override this setting if you
really know what you're doing.
- R.
Peter, can you give this a try ?
I think you set this in /etc/modprobe.conf
add the line,
options mthca tune_pci=1
Also, we need to understand why the BIOS in your platform
Ramachandra K wrote:
Adds the files that implement the data transfer part of the
communication protocol with the VEx. The RDMA of ethernet
packets is implemented in here.
I see no sparse annotations to indicate endianness or user visibility of
any data throughout the driver. The driver
Adding:
Options ib_mthca tune_pci=1
Puts MaxReadReq = 4096.
I get 1250MB/s bandwidth.
-- Peter
-Original Message-
From: Woodruff, Robert J
Sent: Monday, October 02, 2006 3:51 PM
To: Roland Dreier; Hartman, Peter
Cc: Michael S. Tsirkin; openib-general; EWG; Hartman, Peter
Subject:
Ramachandra K wrote:
+/*
+ * target eiocs are added by writing
+ *
+ * ioc_guid=EIOC GUID,dgid=dest GID,pkey=P_key,name=interface_name
+ * to the create_primary sysfs attribute.
+ */
+enum {
+ VNIC_OPT_ERR = 0,
+ VNIC_OPT_IOC_GUID = 1 0,
+ VNIC_OPT_DGID = 1 1,
+
Ramachandra K wrote:
+#define PRINT(level, x, fmt, arg...) \
+ printk(level %s: %s: %s, line %d: fmt, \
+MODULE_NAME, x, __FILE__, __LINE__, ##arg)
Use dev_info and friends instead of printk.
+#define hton8(x) (x)
+#define
Adding:
Options ib_mthca tune_pci=1
Puts MaxReadReq = 4096.
I get 1250MB/s bandwidth.
Is that good? I lost track from the beginning of the thread.
I would suggest working with your platform people to figure out why
the BIOS is setting the PCI Express parameters to non-optimal
Roland wrote,
Is that good? I lost track from the beginning of the thread.
I would suggest working with your platform people to figure out why
the BIOS is setting the PCI Express parameters to non-optimal values.
- R.
Yes. 1250Mbytes/sec is what we expect.
You say the 128 value comes from
Robert Yes. 1250Mbytes/sec is what we expect. You say the 128
Robert value comes from the BIOS ? If so, we need to discuss this
Robert with our BIOS team to find out why they limit it to 128,
Robert perhaps it is a BIOS bug.
Yes, I believe that the BIOS is the only place that
From: Scott Weitzenkamp (sweitzen)
Sent: Monday, October 02, 2006 4:22 PM
To: Kuchimanchi, Ramachandra; Roland Dreier (rdreier)
Cc: openib-General
Subject: Re: [openib-general] [PATCH 0/10] [RFC] Support for
SilverStorm
Virtual Ethernet I/O controller (VEx)
Is this communication protocols
Thanks, applied both patches.
___
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
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
We're through the bulk of our 2.6.19 merge, but
Michael We could just let the user specify the Id Ext when adding
Michael the device. How does this sound?
Yes, that makes the most sense -- just add another optional option for
use when adding a target.
- R.
___
openib-general mailing list
Hey Roland/Sean,
What is the status of the rdma_cm branch in Roland's infiniband.git
tree? It doesn't have the iwarp stuff in it. I'm wondering if it can
be merged with the 2.6.19 stuff to create a branch that was iwarp + ucma
support? Or is that a dumb idea?
Steve.
Steve Hey Roland/Sean, What is the status of the rdma_cm branch
Steve in Roland's infiniband.git tree? It doesn't have the iwarp
Steve stuff in it. I'm wondering if it can be merged with the
Steve 2.6.19 stuff to create a branch that was iwarp + ucma
Steve support? Or is
Hi Michael!
Please consider this patch of ehca for ofed-1.1 as it fixes a bug
(crash) that occured when ib_ehca is loaded after ib_ipoib.
This patch initializes struct ehca_shca with struct device*, then
creates internal resources and finally registers the ehca IB device.
And that is the proper
Michael,
here is the 2nd patch of ehca with a small format improvement in ehca
debug function. It would be great if we could include it for ofed-1.1.
Note that I created this patch against the dir openib-1.1 extracted
from ofed-1.1-rc6/SOURCES/openib-1.1.tgz.
Thanks!
Nam Nguyen
Signed-off-by:
Woodruff, Robert J wrote:
Aviram wrote,
Pending that IPoIB HA is solved would like to issue RC7 that suppose to
be final. Is everyone OK with this approach?
Aviram
Sounds good,
What is the target date for RC7 ?
Do we have a new target date?
Hal Rosenstock wrote:
Is there a possibility that there is a double deletion from a list
somewhere?
Perhaps but I don't see it. Sean ? Roland ?
I looked at this and couldn't find anything obviously wrong. I was waiting to
hear back to Michael's question about module unload being
Robert Walsh wrote:
The attached patch fixes this problem by deferring creation of our
diagpkt device until at least one piece of hardware has been found.
Of course, if I'd actually attached the patch, it might have been a bit
more useful :-)
IB/ipath - initialize diagpkt file on device init
The attached patch fixes this problem by deferring creation of our
diagpkt device until at least one piece of hardware has been found.
Michael: this will fix the OFED testing problem you were seeing.
Roland: please queue for 2.6.19.
Regards,
Robert.
Aviram, can I try Mellanox binary RPMs?
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: Scott Weitzenkamp (sweitzen)
Sent: Sunday, October 01, 2006 9:31 PM
To: 'Aviram Gutman'; Scott Weitzenkamp (sweitzen)
Cc:
Bryan O'Sullivan [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Have you tested your driver against the -mm tree?
No.
To the best of my knowledge the irq handling of your hypertransport card
is a complete and total hack that works only by chance.
And a happy Monday morning to you,
Ramachandra In that case, can you please consider this for the
Ramachandra for-2.6.20 branch ?
I'm happy to keep this in a vex branch or something like that, but as
the emails I just sent show, this is not ready for merging yet (which
is to be expected -- it's never been reviewed).
modprobe would go into the D state and stay there.
Why? What was the process stuck sleeping on?
From: Robert Walsh [EMAIL PROTECTED]
I assume this is supposed to be Signed-off-by: ?
+void ipath_diagpkt_add(void)
+{
+if (diagpkt_count == 0)
+
63 matches
Mail list logo
