This patch corrects some corner cases in managing the RAE/RRE bits in
the mthca qp context. These bits need to be zero if the user requests
max_dest_rd_atomic of zero. The bits need to be restored to the value
implied by the qp access flags attribute in a previous (or the
current) modify-qp comma
Add limit checking on rd_atomic and dest_rd_atomic attributes:
especially for max_dest_rd_atomic, a value that is larger than HCA
capability can cause RDB overflow and corruption of another QP.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]
sae and sre bits should only be set when setting sra_max. Further, in
the old code, if the caller specifies max_rd_atomic = 0, the sre and
sae bits are still set, with the result that the QP ends up with
max_rd_atomic = 1 in effect.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-b
break only escapes from the innermost loop, and we want to escape both
loops and return an answer. Noticed by Ishai Rabinovitch.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mthca/mthca_memfree.c |2 +-
1 f
When cleaning up a CQ for a QP attached to SRQ, need to free an SRQ
WQE only if the CQE is a receive completion.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mthca/mthca_cq.c | 11 ++-
1 files changed, 1
Only change the driver's copy of the QP attributes in modify QP after
checking the modify QP command completed successfully.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/inf
Fix thinko in rd_atomic calculation: ffs(x) - 1 does not find the next
power of 2 -- it should be fls(x - 1).
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mthc
Looks right to me -- I applied it.
___
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
> James,
>
> Here is a fix for openib socket cm version. I ran into a problem
> with the latest verbs qp_modify as a result of incorrect rd_atomic
> values so I modified to use the values returned from the
> ibv_query_device() instead of hard coded values.
>
> -arlin
Sommitted in revision 4
On Fri, 9 Dec 2005, Arlin Davis wrote:
> James,
>
> I modified the IP address lookup during the open to take either a
> network name, network address, or device name. This will make the
> dat.conf setup a little easier and more flexible. I updated the
> README, and /doc/dat.conf with details
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] mthca: correct max_rd_atomic handling
>
> Michael> Right. Thats why we set it inconditionally when
> Michael> IB_QP_MAX_QP_RD_ATOMIC attribute bit is set, and
> Michael> IB_QP_MAX_QP_RD_ATOMIC is required to go to RTS
Michael> Right. Thats why we set it inconditionally when
Michael> IB_QP_MAX_QP_RD_ATOMIC attribute bit is set, and
Michael> IB_QP_MAX_QP_RD_ATOMIC is required to go to RTS.
Not for UC transport... I think this patch would break RDMA on UC QPs, right?
- R.
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] mthca: correct max_rd_atomic handling
>
> Hmm, I'm not sure about this change any more now. Why is setting swe
> being tied to sra_max?
Note its tied to IB_QP_MAX_QP_RD_ATOMIC - the attribute bit, not the value.
Well, as I see
Hmm, I'm not sure about this change any more now. Why is setting swe
being tied to sra_max? We should be able to post RDMA writes even if
reads/atomics are disabled, right?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.o
Thanks, applied.
___
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
Thanks, applied.
___
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
Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: ipoib: question
>
> > Is this better?
> >
> > -return (struct ipoib_neigh **) (neigh->ha + 24 -
> > -(offsetof(struct neighbour, ha) &
> 4));
> > +return (void*)neigh +
> >
Thanks, applied.
___
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
Thanks, applied.
___
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
IPoIB uses neighbour ops->destructor to clean up struct ipoib_neigh,
but ignores the fact that multiple neighbour objects can share
the same ops structure, so setting it to NULL affects multiple neighbours.
Fix this, by tracking all ipoib_neigh objects, and only cleaning
destructor after no neigh
osmtest/osmt_service.c: Eliminate compile warnings with gcc version4.0.0
20050519 (Red Hat 4.0.0-8)
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: osmt_service.c
===
--- osmt_service.c (revision 4478)
+++ osmt_service.
> Is this better?
>
> -return (struct ipoib_neigh **) (neigh->ha + 24 -
> -(offsetof(struct neighbour, ha) &
> 4));
> +return (void*)neigh +
> ALIGN(offsetof(struct neighbour, ha) + INFINIBAND_ALEN, x)
I guess so, with
Michael> Hardware guys confirmed that it does, as per spec:
Michael> clearing these bits is the way to tell hardware that we
Michael> have max_rd_atomic set to 0. I thought its obvious from
Michael> documentation: do you think this needs clarification?
I was just lazy and didn't e
Thanks, applied (at long last)
___
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
On 15.12.2005 [09:35:12 +0200], Michael S. Tsirkin wrote:
> Quoting r. Nishanth Aravamudan <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] add LDFLAGS to perftest/Makefile
> >
> > On 15.12.2005 [08:57:24 +0200], Michael S. Tsirkin wrote:
> > > Quoting Nishanth Aravamudan <[EMAIL PROTECTED]>:
> > > >
Fix thinko in sdp_copy_one_page: dont try to copy beyond the
page boundary.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: linux-2.6.14/drivers/infiniband/ulp/sdp/sdp_iocb.c
===
--- linux-2.6.14.orig/drivers/infiniband/
Hi!
I'm trying to use kmap_atomic from both interrupt and task context.
My idea was to do local_irq_save and then use KM_IRQ0/KM_IRQ1:
since I'm disabling interrupts I assumed that this should be safe.
The relevant code is here:
https://openib.org/svn/gen2/trunk/src/linux-kernel/infiniband/ulp/sdp/
Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: [PATCH] mthca thinko
>
> Fix thinko in mthca_table_find: break only escapes from the innermost
> loop.
> Ishai Rabinovitch
Correction: Noticed by Ishai Rabinovitch
--
MST
___
openib-general ma
This is what we are doing in ISER (creating the QP in kernel as the
connect action of a socket provider that is accessed by userspace).
Dan
On 12/8/05, Caitlin Bestler <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > What are the reasons that a qp allocated in user-space can'
On Thu, Dec 15, 2005 at 10:30:35AM +0200, Michael S. Tsirkin wrote:
> > Can someone from mellanox explain why mainline src/userspace
> > is cloned under contrib/mellanox?
>
> Thats how subversion handles tags: we are tagging mainline
> approximately weekly.
> I could put it in some other place - j
Fix thinko in mthca_table_find: break only escapes from the innermost loop.
Ishai Rabinovitch
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: openib/drivers/infiniband/hw/mthca/mthca_memfree.c
===
--- openib/drivers/infi
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] mthca: correct max_rd_atomic handling
>
> What happens if SAE and SRE are turned off and the consumer posts an
> RDMA read? Does it fail and generate an error completion?
Hardware guys confirmed that it does, as per spec: clear
good catch again, thanks -- applied
___
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
OpenSM/osm_base.h: Modify some SM constants
Default SM Key should not be 0
Also, changed default SM priority to 1 so can have lower priority SM
(and not rely on low GUID comparison). Note also that priority sense
was inverted in comment.
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: o
OpenSM/ib_types.h: Modify ib_port_info_compute_rate so that gcc version
4.0.0 20050519 (Red Hat 4.0.0-8) doesn't complain when compiling
osm_sa_path_record.c as follows:
osm_sa_path_record.c: In function ‘__osm_pr_rcv_get_path_parms’:
osm_sa_path_record.c:194: warning: control may reach end of non
Hi,
Regarding dates - Mellanox prefer not to have the workshop on Feb 5 but
from the week of 12 Feb or afterward
Tziporet
-Original Message-
From: Eitan Zahavi
Sent: Wednesday, December 14, 2005 9:25 PM
To: Bill Boas
Cc: openib-general@openib.org; [EMAIL PROTECTED]
Subject: Re: [openib-
When cleaning up a CQ for a QP attached to SRQ, need to free an SRQ wqe
only if the CQE is a receive completion.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Index: openib/drivers/infiniband/hw/mthca/mthca_cq.c
===
--- openib.
When cleaning up a CQ for a QP attached to SRQ, need to free an SRQ wqe
only if the CQE is a receive completion.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Index: openib/drivers/infiniband/hw/mthca/mthca_cq.c
===
--- openib.
When cleaning up a CQ for a QP attached to SRQ, need to free an SRQ wqe
only if the CQE is a receive completion.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Index: latest/src/userspace/libmthca/src/cq.c
===
--- latest.orig/sr
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: [PATCH applied] kill dead code around kmap_atomic
>
> kmap_atomic never returns NULL.
>
> Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Sorry, wrong patch. Here it is:
Index: linux-2.6.14/drivers/infiniband/ulp/sdp/sdp_send.c
kmap_atomic never returns NULL.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: linux-2.6.14/drivers/infiniband/ulp/ipoib/ipoib.h
===
--- linux-2.6.14.orig/drivers/infiniband/ulp/ipoib/ipoib.h 2005-11-15
21:10:49.
Quoting Grant Grundler <[EMAIL PROTECTED]>:
> On Wed, Dec 14, 2005 at 01:57:26AM -0800, [EMAIL PROTECTED] wrote:
> > Author: sagir
> > Date: 2005-12-14 01:57:24 -0800 (Wed, 14 Dec 2005)
> > New Revision: 4453
> >
> > Modified:
> >trunk/contrib/mellanox/gen2/src/userspace/perftest/rdma_lat.c
>
Antigen for Exchange found photo.zip->photo.jpg
.scr infected with VIRUS=
Win32/Mabutu.A!unpacked (CA(Vet),Sophos,CA(InoculateIT)) virus.
The file
ScanMail for Microsoft Exchange has detected virus-infected attachment(s).
Sender = [EMAIL PROTECTED]
Recipient(s) = openib-general@openib.org
Subject = [openib-general] I'm nude
Scanning time = 12/15/2005 2:25:19 AM
Engine/Pattern = 8.000-1001/3.107.00
Action on virus found:
The attachment photo
44 matches
Mail list logo
