On Tue, Oct 03, 2006 at 07:58:50AM +0200, Or Gerlitz wrote:
> Bill Hartner wrote:
> >
> > 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
http://openib.org/bugzilla/show_bug.cgi?id=261
Summary: can't configure IPoIB pkey interfaces at boot time
Product: OpenFabrics Linux
Version: 1.1rc6
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
P
Hi,
I have a configuration consisting of 6 nodes connected through a single IB switch. I am sending data from a single node to all the remaining 5 nodes using IB multicast. I get a bandwidth of not more than 1.5 - 2 Gbps. I was expecting it to be around 10 Gbps(
i.e same as point to point b/w). B
Quoting r. Robert Walsh <[EMAIL PROTECTED]>:
> Subject: Re: [openfabrics-ewg] OFED Status
>
> 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 seein
Quoting r. Woodruff, Robert J <[EMAIL PROTECTED]>:
> Subject: Drop in performance on Mellanox MT25204 single port DDR HCA
>
>
> 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 platf
Sean Hefty wrote:
> Steve Wise wrote:
>> 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?
>
Vlad,
I filed a bug for
these issues.
1) If I start IPoIB
HA with ib0 IB port shut down (from IB switch) and ib1 IB port enabled,
then IPoIB does not work because "ip monitor link all" does not report
NO-CARRIER at startup like ipoib_ha.pl is looking for. This is a major
hole.
2) /et
Bill Hartner wrote:
>
> 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
> 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)
> +ipath_cdev_init(I
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).
"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 m
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)
> C
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.
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 o
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 in
On Sun, 2006-10-01 at 05:53, Jack Morgenstein wrote:
> We received the following kernel Oops while running regression
> (see console picture attached).
>
> This looks like a possible race condition between handling umad send
> completions
> and ib_unregister_mad_agent.
>
> The Oops is at the lis
Steve Wise wrote:
> 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?
I'm currently working on m
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?
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: Ho
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 s
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
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.
_
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
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 this
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
> 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 pr
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
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
> 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-optima
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)
> +
Ramachandra K wrote:
>
> +/*
> + * target eiocs are added by writing
> + *
> + * ioc_guid=,dgid=,pkey=,name=
> + * to the create_primary sysfs attribute.
> + */
> +enum {
> + VNIC_OPT_ERR = 0,
> + VNIC_OPT_IOC_GUID = 1 << 0,
> + VNIC_OPT_DGID = 1 << 1,
> + VNIC_OPT_PKEY = 1 << 2,
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: RE
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 sho
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
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 qui
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 st
Ramachandra K wrote:
> +#include
Not needed.
> +#include
Not needed.
> +#ifdef CONFIG_INFINIBAND_VNIC_STATS
> + if (vnic->statistics.conn_time == 0) {
> + vnic->statistics.conn_time =
> + get_cycles() - vnic->statistics.start_time;
> + }
> + if (vnic->
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> 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 th
> +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 clear
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 infiniband_orig/drivers/infiniband/hw/ehca/eh
> +#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
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!
Na
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.
Somewher
> +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
op
> +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 netpat
> 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 patch
> +#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? W
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
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 Rama
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
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 +
drivers/infiniband/ulp/vnic/Kc
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 a/drivers/infiniba
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 deletions
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 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 del
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
drivers/infin
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 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
drivers/infiniband/ulp/vnic/vnic_n
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]>
---
drivers/infiniband/
Hi Roland,
This patch series adds support for the SilverStorm Virtual Ethernet I/O
Controllers (VEx) by adding a new kernel level driver.
This kernel driver:
1. Communicates with the VEx on the SilverStorm fabric switches/directors using
SilverStorm's native protocol
2. Presents a standard Et
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:
> >
> > ==
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 y
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, y
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
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 notific
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, too :-)
> In the -mm tree I have added a firs
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 mthc
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
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 t
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 addi
Updated patch based on Roland's feedback - converted a couple uses
of spinlock_irqsave to spinlock_irq, and used list manipulation
routine for cleanup.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: cm.c
===
--- cm.c
>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
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
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 s
> 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
76 matches
Mail list logo
