hello allrecently i have gone through the discussions how you have decided to split the QP lock in to separate WQ locks and the locking mechanismhttp://openib.org/pipermail/openib-general/2005-February/004491.htmlin this patch it is mentioned the only place we will be taking the lock is in modify_
http://openib.org/bugzilla/show_bug.cgi?id=229
--- Comment #3 from [EMAIL PROTECTED] 2006-09-11 23:14 ---
Put email in bugzilla:
Hmm, OK.
I'd like to figure out whether this could be something other than a scheduler
issue.
Could you test on kernel 2.6.18 or 2.6.17 please?
If this is
Hmm, OK.
I'd like to figure out whether this could be something other than a scheduler
issue.
Could you test on kernel 2.6.18 or 2.6.17 please?
If this is a scheduler issue, there's a chance scheduler is more fair there.
Quoting r. Scott Weitzenkamp (sweitzen) <[EMAIL PROTECTED]>:
> Subject: RE: [
I only tested with renice -20.
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
> -Original Message-
> From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 11, 2006 11:02 PM
> To: Scott Weitzenkamp (sweitzen)
> Cc: open
Quoting r. [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Subject: [Bug 229] heavy CPU load can starve ib_mad thread on latest
> processors
>
> http://openib.org/bugzilla/show_bug.cgi?id=229
>
>
>
>
>
> --- Comment #2 from [EMAIL PROTECTED] 2006-09-11 21:54 ---
> Cisco embedded SM on a sw
When will rc4 be available? I'd also like to suggest
we not rush the final build, end of this week seems too
soon.
Scott
Weitzenkamp
SQA and Release
Manager
Server Virtualization
Business Unit
Cisco Systems
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tzip
http://openib.org/bugzilla/show_bug.cgi?id=229
--- Comment #2 from [EMAIL PROTECTED] 2006-09-11 21:54 ---
Cisco embedded SM on a switch, thus no SM on a host, only IB drivers.
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching th
Hi Michael,
> > The basic problem in the CMA is in cma_alloc_port(). If the port
number (passed
> > in as snum) is 0, the first available port starting at
> > sysctl_local_port_range[0] is used. We could instead start our search
by
> > adding an increasing counter or a random value to the l
Hi Sean,
> I don't think that this will work. The issue is that we need to walk a
list of
> IDs associated with a particular device to notify the user that the
device is
> being removed. While we're doing that, the user could try to destroy
the ID,
> which removes the ID from the device li
--- "Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
> Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> > Subject: Re: why sdp connections cost so much
> memory
> >
> > > You should not need this change with the scale
> patch
> > > I posted - after applying
> > > this, and setting the scale parame
> Could be a library function in core so that ipath etc can reuse it.
> But note how there's no dependency between drivers here - no
> reason to block change in mthca until ipath/ehca implement this functionality,
> too.
True. But FWIW, we (QLogic) could probably spin something like this
pretty
OK, I applied
[PATCH] IB/cm: do not track remote QPN in timewait state
since Sean has acked that already.
I'll review the rest in the next day or two.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listi
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: RFC: mthca: implement timewait by tracking QPNs
>
> My gut reaction is that it seems pretty ugly.
Hmm. All of it or just some bits?
> I guess we'll also need
> similar patches for ipath and ehca too -- which makes me want to have
> th
I have put the following patches in my mst-for-2.6.10 tree:
$git log --pretty=short origin..mst-for-2.6.19
commit ddfe6867088167b64962399934d21cf3e37c338b
Author: Jack Morgenstein <[EMAIL PROTECTED]>
[PATCH] IB/mthca: recover from device errors
commit 4403ad431b139b03a291263be4686363fd04138b
My gut reaction is that it seems pretty ugly. I guess we'll also need
similar patches for ipath and ehca too -- which makes me want to have
this in common code somehow.
Also timewait is really only part of the CM spec -- do we want to
limit the rate of RC QP creation in general for potential non-
Roland, all, we plan to implement the timewait handling in mthca
in time for 2.6.19:
For all connected QPs:
- upon QP destroy or move from RTS to reset/error,
start timer for the duration of packet lifetime
- until packet expires, do not reuse this QPN
This must be done to prevent stale packets
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> > As a side note, reasons for frequent loss of RTU must be investigated.
>
> A lost RTU shouldn't be any more likely than a lost REQ or REP. Is the RTU
> never showing up?
Seems like that. I know fir sure I do accept after REP but remote side never
g
Michael S. Tsirkin wrote:
> Sean, did we decide what to do for upstream yet?
> I would say we need something like the below for 2.6.19 too
> (probably just need to update node type check).
> And, I like it that this approach leaves all matters of policy
> to users (such as whether move QP to RTS af
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] CMA issue: bind selects the same port after
> close
>
> Michael S. Tsirkin wrote:
> > We have encountered an issue in CMA: if
> > I bind to port 0, destroy the id, then bind to port 0 again
> > I often get back the same po
Michael S. Tsirkin wrote:
> We have encountered an issue in CMA: if
> I bind to port 0, destroy the id, then bind to port 0 again
> I often get back the same port from both binds.
>
> TCP behaves differently - it seems to assign new port numbers
> each time.
> This is an issue for some socket pro
> - CMA can have a static variable (good to avoid clashes with a global
> 'sa_client' variable name too)
Sounds good - that's a goof on my part.
> - IPoIB does not use multicast module upstream, fix ipoib_multicast.c too.
Okay - As an FYI, I will probably submit the multicast module upstream f
OK, I added the following to my for-2.6.19 branch. The differences
from your patch are:
- CMA can have a static variable (good to avoid clashes with a global
'sa_client' variable name too)
- IPoIB does not use multicast module upstream, fix ipoib_multicast.c too.
- Simplify sa_query.c chang
We have encountered an issue in CMA: if
I bind to port 0, destroy the id, then bind to port 0 again
I often get back the same port from both binds.
TCP behaves differently - it seems to assign new port numbers
each time.
This is an issue for some socket programs that assume that
the same port num
Hi everyone. Just wanted to respond and say I'm on the alias, and will
prepare a small statement in line with what has been asked below. I
should be able to get this out in a day or two. Looking forward to
working with you all. Cheers - jamie
Jamie Riotto
Sr. Director Engineering
Server Virtuali
Krishna Kumar wrote:
> static void cma_process_remove(struct cma_device *cma_dev)
> {
> struct list_head remove_list;
> - struct rdma_id_private *id_priv;
> + struct rdma_id_private *id_priv, *tmp;
> int ret;
>
> INIT_LIST_HEAD(&remove_list);
> @@ -2344,22 +2344,20 @@
Krishna Kumar wrote:
> Re-organize code relating to cma_get_net_info() and rdma_create_id() to
> optimize error case handling (no need to alloc memory/etc as part of
> rdma_create_id() if input parameters are wrong).
Thanks! Committed with a minor adjustment to rename 'out' label 'err'.
- Sean
When using OFED-1.1-rc3 on a x86_64 system running a 2.6.17.3 debug
kernel in a RHEL4 U2 environment, I see the follwing console warning
messages when I unload the ib_madeye kernel module:
modprobe ib_madeye
modprobe -r ib_madeye
cons
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] cma_connect_ib leaks memory in failure cases.
>
> Michael S. Tsirkin wrote:
> >>cma_connect_ib leaks an struct ib_cm_id* in failure cases.
> >>
> >>Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]>
> >
> >
> > This one looks like i
Hello,
Attached
is the final reminder for InfinBand DevCon conference. If you have any
questions, please let me know.
Thank
you,
Stephanie
Stephanie Howard
Owen
Media
206.322.1167
ext. 102
[EMAIL PROTECTED]
InfiniBand DevCon Blast Final Blast - OFA.doc
Desc
Krishna Kumar wrote:
> cma_connect_ib leaks an struct ib_cm_id* in failure cases.
Thanks - committed.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http:
Yep,
that patch fixes the bug :-)
Thanks
Am Monday 11 September 2006 16:37 schrieb Roland Dreier:
> There is definitely a bug in the drivers/infiniband/ulp/iser/Kconfig
> file. ISER only depends on INFINIBAND && SCSI. However it is easily
> possible to enable INFINIBAND and SCSI without enablin
Michael S. Tsirkin wrote:
>>cma_connect_ib leaks an struct ib_cm_id* in failure cases.
>>
>>Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]>
>
>
> This one looks like it might be good for 2.6.18. Sean?
The ib_cm_id will be cleaned up if the rdma_cm_id is destroyed, as long as a
second call is n
Dotan Barak wrote:
>>The user-mode cm header files don't have the C++ stuff to identify all
>>the declarations as C. The verbs.h file has it and works fine if you
>>wanted to copy it, but all you really need is ...
>>
> Sean, please add those definitions to the libibcm header as well.
I've updated
> Scott> How about just adding netstat before the merge, so we have
> Scott> some visibility into what SDP connections are in use?
>
> That's fine. Merging upstream is somewhat long-term anyway, since
> Michael has not even posted a first candidate for review -- I expect
> SDP will requir
Scott> How about just adding netstat before the merge, so we have
Scott> some visibility into what SDP connections are in use?
That's fine. Merging upstream is somewhat long-term anyway, since
Michael has not even posted a first candidate for review -- I expect
SDP will require several go
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH v3] ib_sa: require SA registration
>
> Sean> Roland, Not sure if you've had a chance to review the SA
> Sean> patches, but any comments on any of the SA related patches?
> Sean> (SA registration, generic RMPP query sup
Bub Thomas wrote:
> with the help of your modified cmpost.c example I found out that the
> byte order in the lid your query_for_path in cmpost.c is getting into
> the ib_sa_path_rec is the opposite to the one reported by ibv_query_port.
The path record defines all fields in network-byte order.
Roland Dreier wrote:
> I haven't really read the later patches but I am planning on merging
> at least the registration stuff for 2.6.19.
I'd like to commit the SA related patches soon. There have been several
e-mails
recently about using IB multicast and the IB CM directly.
- Sean
__
> Scott> I would like to see netstat support, zcopy support, and
> Scott> ideally AIO support get added first...
>
> Better to merge first and then add features I think.
>
> - R.
>
How about just adding netstat before the merge, so we have some
visibility into what SDP connections are
Sujal, yes, thanks, makes sense. I got a "no longer there" response from
my earlier email, so Shawn won't be around to do a handoff
Jim
-Original Message-
From: Sujal Das [mailto:[EMAIL PROTECTED]
Sent: Monday, September 11, 2006 9:28 AM
To: Ryan, Jim; Shawn Hansen (shahanse); OpenFabric
Eli cohen wrote:
> On Thu, 2006-09-07 at 08:19 +0100, Paul Baxter wrote:
>>> There is an implementation of PXE for Mellanox's HCAs that can be
>>> found here: http://sourceforge.net/forum/forum.php?forum_id=494529
>>
>> Thanks for the tip
>>
>> I, too, am interested in this.
>>
>> Do you have a
Sounds like a good idea. Not sure if the EWG community knows Jamie (I do
not, for example) - it might be a good idea if Jamie introduces himself,
and specifically highlights his roles and contributions to OFA in the
past and what his vision is for OFED and its adoption by OSVs, ISVs, HPC
and enterp
Erez> Let me make sure that I understand: If INET is disabled and
Erez> we enable INFINIBAND, INFINIBAND_ADDR_TRANS will not be
Erez> enabled (because INET is disbaled). This results in the
Erez> scenario that Toralf is in. If this is correct, I agree with
Erez> your patch.
Yes
Roland Dreier wrote:
> Thanks, applied 1-5 with this minor fix for a compile warning:
>
> --- a/drivers/infiniband/ulp/iser/iser_memory.c
> +++ b/drivers/infiniband/ulp/iser/iser_memory.c
> @@ -427,9 +427,9 @@ int iser_reg_rdma_mem(struct iscsi_iser_
> iser_err("page_vec: data
Roland Dreier wrote:
> There is definitely a bug in the drivers/infiniband/ulp/iser/Kconfig
> file. ISER only depends on INFINIBAND && SCSI. However it is easily
> possible to enable INFINIBAND and SCSI without enabling INET (in fact
> they can be enabled without NET as in the original config in
Thanks, applied 1-5 with this minor fix for a compile warning:
--- a/drivers/infiniband/ulp/iser/iser_memory.c
+++ b/drivers/infiniband/ulp/iser/iser_memory.c
@@ -427,9 +427,9 @@ int iser_reg_rdma_mem(struct iscsi_iser_
iser_err("page_vec: data_size = 0x%x, length = %d,
of
Scott> I would like to see netstat support, zcopy support, and
Scott> ideally AIO support get added first...
Better to merge first and then add features I think.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Fwd: linux- 2.6.18-rc6-git1 issue 46:
> drivers/infiniband/ulp/iser/iser_verbs.c:514: undefined reference to
> `rdma_create_id'
>
> There is definitely a bug in the drivers/infiniband/ulp/iser/Kconfig
> file. ISER only depends on INFI
There is definitely a bug in the drivers/infiniband/ulp/iser/Kconfig
file. ISER only depends on INFINIBAND && SCSI. However it is easily
possible to enable INFINIBAND and SCSI without enabling INET (in fact
they can be enabled without NET as in the original config in this thread).
iser does sele
Shawn, thanks for the note and best of luck at Microsoft. I suggest we
take Shawn's recommendation and ask Jamie to continue Shawn's leadership
of the EWG.
Jim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Shawn Hansen
(shahanse)
Sent: Friday, September
OpenSM: Change QoS syntax for CA ports
Change names from hca_ to ca_ to make it clearer that these are for both
HCAs and TCAs.
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: doc/qos-config.txt
===
--- doc/qos-config.txt (
Hi,
A general doubt.
If I write a kernel program (linux kernel module) to send and receive data using IB, will it perform better then its user mode counterpart. Unlike user mode, in kernel mode, I think it is possible to allocate physically contiguous memory using "kmalloc or alloc_pages" whic
Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> Subject: Re: why sdp connections cost so much memory
>
> > You should not need this change with the scale patch
> > I posted - after applying
> > this, and setting the scale parameter to 0x1, each
> > connection should use around
> > 128K for RX. Plea
> You should not need this change with the scale patch
> I posted - after applying
> this, and setting the scale parameter to 0x1, each
> connection should use around
> 128K for RX. Please confirm.
Just setting the scale parameter to 0x1, memory
reduction is OK. But there occurred one bug,
sometim
Hi Yevgeny,
On Sun, 2006-09-10 at 02:35, Yevgeny Kliteynik wrote:
> Hi Hal
>
> This patch fixes the bug that was occurring when OSM was
> running with --run-once option (-o) and the SM port was down.
> In that case, OSM would be stuck in cond_wait forever (or until
> the port will become active)
> You should not need this change with the scale patch
> I posted - after applying
> this, and setting the scale parameter to 0x1, each
> connection should use around
> 128K for RX. Please confirm.
I have tested it again, yes, you are right. I just set
the scale parameter to 0x1, each connection co
Quoting r. Hoang-Nam Nguyen <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] ehca for OFED 1.1-rc4
>
> I guess my email client must have wrapped the lines so that the patch is
> not applicable any more. Sorry for that!
You also want to fix the mail format - you currently send each mail
in both HTML an
Fast Memory Registration (fmr) is used to register for rdma an sg whose
elements are not linearly sequential after dma mapping.
The IB verbs layer provides an "all dma memory MR (memory region)" which
can be used for RDMA-ing a dma linearly sequential buffer.
Change the code to use the dma mr ins
fix and add some debug prints related to iser
handling of memory for rdma.
Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/iser/iser_memory.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
00703cf2800ce3ac864b149ce75435b00480d9d2
diff --gi
As iser is able to use at most one rdma operation for the
execution of a scsi command, and registration of the sg
associated with scsi command has its restrictions, the code
checks if an sg is "aligned for rdma".
Alignment for rdma is measured in "fmr page" units whose
possible resolutions are dif
Currently, the data length of a command coming down from scsi-ml
is limited only by the size of its sg list (sg_tablesize). The
max data length may be different for different page size values.
By setting max_sectors, we limit the data length to
max_sectors*512 bytes.
Signed-off-by: Erez Zilber <[E
dma mapping may include a "compaction" of the sg associated with scsi command.
Hence, the size of the maximal prefix of the SG which is aligned for rdma must
be
compared against the length of the dma mapped sg (mem->dma_nents) and not
against
the size of it before it was mapped (mem->size).
Sign
Here is a series of patches that fix some bugs that were found in iSER
during testing (some were found while testing iSER on architectures
like ia64). All of them are related to memory registartion.
Thanks
Erez
___
openib-general mailing list
openib-
Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> Subject: Re: why sdp connections cost so much memory
>
>
>
> --- "Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
>
> > Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> > > Subject: Re: why sdp connections cost so much
> > memory
> > >
> > > >> You m
Ah, thanks for clarifying this.
Unfortunately this means, that there is a small chance, that "make oldconfig"
will not
work correctly in all cases, eg. upgrading a kernel to a newer version could
yield into
such failed compile step :-(
Am Monday 11 September 2006 08:33 schrieb Erez Zilber:
> To
--- "Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
> Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> > Subject: Re: why sdp connections cost so much
> memory
> >
> > >> You mean - when only a single socket is open?
> > Every one connection will cost 2M RAM. So I make
> the
> > following changes
http://openib.org/bugzilla/show_bug.cgi?id=229
--- Comment #1 from [EMAIL PROTECTED] 2006-09-11 00:58 ---
Which SM are you running ?
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
___
Quoting r. zhu shi song <[EMAIL PROTECTED]>:
> Subject: Re: why sdp connections cost so much memory
>
>
>
> >> You mean - when only a single socket is open?
> Every one connection will cost 2M RAM. So I make the
> following changes:
> #define SDP_TX_SIZE 0x4
> #define SDP_RX_SIZE 0x4
You should
>> You mean - when only a single socket is open?
Every one connection will cost 2M RAM. So I make the
following changes:
#define SDP_TX_SIZE 0x4
#define SDP_RX_SIZE 0x4
> The SDP protocol uses ARP over IPoIB for its address
> resolution.
> So you'd need to find some other way to perform
> addres
http://openib.org/bugzilla/show_bug.cgi?id=229
Summary: heavy CPU load can starve ib_mad thread on latest
processors
Product: OpenFabrics Linux
Version: 1.1rc3
Platform: All
OS/Version: RHEL 4
Status: NEW
70 matches
Mail list logo
