This replace the PCI DMA state API (include/linux/pci-dma.h) with the
DMA equivalents since the PCI DMA state API will be obsolete.
No functional change.
For further information about the background:
http://marc.info/?l=linux-netdev&m=127037540020276&w=2
Signed-off-by: FUJITA Tomonori
---
dri
> I actually think that ep->com.cm_id is always valid when
> connect_reply_upcall() is called. But I'd have to test it more. I'd
> rather not add this change unless someone convinces me that there
> actually is a path where the cm_id null...
Then would it make sense to change the code
Roland Dreier wrote:
> if (status < 0) {
> - ep->com.cm_id->rem_ref(ep->com.cm_id);
> + if (ep->com.cm_id)
> + ep->com.cm_id->rem_ref(ep->com.cm_id);
Steve, does this make sense?
I actually think that ep->com.cm_id is always valid when
connect_reply_upca
Roland Dreier wrote:
Looks fine to me... in fact I don't see how this could have avoided a
NULL deref here unless the compiler is already optimizing out this
assignment, since two lines above is
struct sk_buff *skb = NULL;
before we do
- struct cpl_act_establish *rpl = cplhdr(skb
Rather than use a variable size array allocation on the stack,
define a constant for the maximum array size possible.
Signed-off-by: Ralph Campbell
---
drivers/infiniband/hw/qib/qib.h|3 +++
drivers/infiniband/hw/qib/qib_tx.c |2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
Sure. I will work on a patch.
On Wed, 2010-06-02 at 14:37 -0700, Roland Dreier wrote:
> qib has the code
>
> void qib_disarm_piobufs_set(struct qib_devdata *dd, unsigned long *mask,
> unsigned cnt)
> {
> struct qib_pportdata *ppd, *pppd[
> if (status < 0) {
> -ep->com.cm_id->rem_ref(ep->com.cm_id);
> +if (ep->com.cm_id)
> +ep->com.cm_id->rem_ref(ep->com.cm_id);
Steve, does this make sense?
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/abou
Looks fine to me... in fact I don't see how this could have avoided a
NULL deref here unless the compiler is already optimizing out this
assignment, since two lines above is
struct sk_buff *skb = NULL;
before we do
- struct cpl_act_establish *rpl = cplhdr(skb);
Steve?
--
Roland D
> without patch:
> 1M memory region120usec
> 16M memory region 1970usec
>
> with patch v2:
> 1M memory region172usec
> 16M memory region 2030usec
So if I read this correctly this patch introduces almost a 50% overhead
in the 1M case... and probably much worse (as a fraction) in
qib has the code
void qib_disarm_piobufs_set(struct qib_devdata *dd, unsigned long *mask,
unsigned cnt)
{
struct qib_pportdata *ppd, *pppd[dd->num_pports];
it would probably be safer to avoid the variable length array pppd[] on
t
Fix warnings in windows build.
These are typecasts in several places, with a couple additional changes
needed to libibnetdisc. Windows uses ISO definitions instead of
POSIX definitions, so calls like _read, _write, etc. are used on
Windows instead of read, write. The result is that internal func
On Wed, Jun 2, 2010 at 12:00 PM, Sasha Khapyorsky wrote:
> On 11:36 Wed 02 Jun , Hal Rosenstock wrote:
>>
>> I'm saying that I think the approach proposed in the original patch is
>> better as it doesn't waste CPU although it's more complex.
>
> How do you see this, the code is almost equivale
On Wed, Jun 02, 2010 at 12:40:04PM -0500, Steve Wise wrote:
>>> I have this library I'm writing that uses libibverbs. Somehow it
>>> seems to be using the 1.0 version instead of the newer version (I'm
>>> guessing). When I call ibv_create_cq() I get a seg fault and the
>>> stack looks like t
Jason Gunthorpe wrote:
On Wed, Jun 02, 2010 at 10:50:56AM -0500, Steve Wise wrote:
I have this library I'm writing that uses libibverbs. Somehow it seems
to be using the 1.0 version instead of the newer version (I'm guessing).
When I call ibv_create_cq() I get a seg fault and the stack
Roland Dreier wrote:
> I have this library I'm writing that uses libibverbs. Somehow it
> seems to be using the 1.0 version instead of the newer version (I'm
> guessing). When I call ibv_create_cq() I get a seg fault and the
> stack looks like this:
>
> #0 0x00319d80871d in pthread
On Wed, Jun 02, 2010 at 10:50:56AM -0500, Steve Wise wrote:
> I have this library I'm writing that uses libibverbs. Somehow it seems
> to be using the 1.0 version instead of the newer version (I'm guessing).
> When I call ibv_create_cq() I get a seg fault and the stack looks like
> this:
M
From: Ben Hutchings
Date: Wed, 02 Jun 2010 17:42:29 +0100
> On Wed, 2010-05-26 at 02:16 -0700, David Miller wrote:
>> From: Eli Cohen
>> Date: Wed, 26 May 2010 12:08:52 +0300
>>
>> > So if I understand you correctly, you think that I should not bother
>> > to set a default value of 1. Each driv
> setlinebuf() is pretty intuitive to understand, compared to setvbuf().
I finally applied this; however in the end I decided to do
setvbuf(stdout, NULL, _IOLBF, 0);
instead of setlinebuf(), since in the past I've prefered more pedantic
stuff (eg posix_memalign instead of memalign) to t
> I have this library I'm writing that uses libibverbs. Somehow it
> seems to be using the 1.0 version instead of the newer version (I'm
> guessing). When I call ibv_create_cq() I get a seg fault and the
> stack looks like this:
>
> #0 0x00319d80871d in pthread_mutex_lock () from /li
On Wed, 2010-05-26 at 02:16 -0700, David Miller wrote:
> From: Eli Cohen
> Date: Wed, 26 May 2010 12:08:52 +0300
>
> > So if I understand you correctly, you think that I should not bother
> > to set a default value of 1. Each driver that cares about the value
> > of this field, will set it howeve
> g++ can be used as a (better) C compiler. Shouldn't compilation with
> g++ be supported ?
g++ is not a C compiler. C++ is not just a superset of C The
differences in the semantics of void* pointers are just one example; in
addition C++ does not have designated initializers for structures, so
On 11:36 Wed 02 Jun , Hal Rosenstock wrote:
>
> I'm saying that I think the approach proposed in the original patch is
> better as it doesn't waste CPU although it's more complex.
How do you see this, the code is almost equivalent in vl15_poller()?
Sasha
--
To unsubscribe from this list: sen
On 11:30 Wed 02 Jun , Hal Rosenstock wrote:
>
> g++ can be used as a (better) C compiler. Shouldn't compilation with
> g++ be supported ?
What would this buy for us?
BTW why is g++ better as C compiler?
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the b
Hey Roland,
I have this library I'm writing that uses libibverbs. Somehow it seems
to be using the 1.0 version instead of the newer version (I'm
guessing). When I call ibv_create_cq() I get a seg fault and the stack
looks like this:
#0 0x00319d80871d in pthread_mutex_lock () from /li
On Wed, Jun 2, 2010 at 11:31 AM, Sasha Khapyorsky wrote:
> On 06:58 Wed 02 Jun , Hal Rosenstock wrote:
>>
>> I had started with an algorithm along these lines but evolved towards
>> the proposed one based on CPU utilization. An algorithm along the
>> lines of the above wastes CPU (when "idling
On Wed, Jun 2, 2010 at 11:18 AM, Sasha Khapyorsky wrote:
> On 10:29 Wed 02 Jun , Yevgeny Kliteynik wrote:
>>
>> Right now gcc allows you to do implicit casting in both ways, g++ doesn't.
>
> OpenSM is written in C, not C++.
g++ can be used as a (better) C compiler. Shouldn't compilation with
On 06:58 Wed 02 Jun , Hal Rosenstock wrote:
>
> I had started with an algorithm along these lines but evolved towards
> the proposed one based on CPU utilization. An algorithm along the
> lines of the above wastes CPU (when "idling" and other times) which
> significantly impacts any other apps
On 10:29 Wed 02 Jun , Yevgeny Kliteynik wrote:
>
> Right now gcc allows you to do implicit casting in both ways, g++ doesn't.
OpenSM is written in C, not C++.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
On 09:05 Wed 02 Jun , Hal Rosenstock wrote:
>
> Eliminate unneeded comment
> Also, cosmetic formatting change
>
> Signed-off-by: Hal Rosenstock
Applied. Thanks.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.
On 09:04 Wed 02 Jun , Hal Rosenstock wrote:
>
> when grouping by SystemImageGUID
>
> Without doing this, find_chassisguid will always return without
> finding the already discovered chassis so no grouping occurs
> when it should
>
> Signed-off-by: Hal Rosenstock
Both applied. Thanks.
Sash
On 18:37 Tue 01 Jun , Ira Weiny wrote:
>
> From: Ira Weiny
> Date: Mon, 22 Dec 2008 11:03:59 -0800
> Subject: [PATCH] opensm/osm_perfmgr.c: Remove unnecessary lock reference from
> Performance Manager object
>
>
> Signed-off-by: Ira Weiny
Applied. Thanks.
Sasha
--
To unsubscribe from th
when grouping by SystemImageGUID
Without doing this, find_chassisguid will always return without
finding the already discovered chassis so no grouping occurs
when it should
Signed-off-by: Hal Rosenstock
---
infiniband-diags/libibnetdisc/src/chassis.c |4
1 files changed, 4 insertions(
Eliminate unneeded comment
Also, cosmetic formatting change
Signed-off-by: Hal Rosenstock
---
infiniband-diags/src/ibnetdiscover.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/infiniband-diags/src/ibnetdiscover.c
b/infiniband-diags/src/ibnetdiscover.c
index 8f08f
rather than just switches for common SystemImageGUID
Now consistent with original grouping.c from which this was ported
Signed-off-by: Hal Rosenstock
---
infiniband-diags/libibnetdisc/src/chassis.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/infiniband-diags/libibn
The patch reduces the number of MFT set MADs beeing send,
by sending only blocks that have been changed since the
last time same block was issued.
Signed-off-by: Alex Netes
---
opensm/include/opensm/osm_mcast_tbl.h | 49 ++-
opensm/opensm/osm_dump.c |2 +-
opensm/o
Hi Sasha,
On Tue, Jun 1, 2010 at 11:32 AM, Sasha Khapyorsky wrote:
> Hi Hal,
>
> On 10:11 Wed 16 Dec , Hal Rosenstock wrote:
>>
>> In order to better handle non responsive SMAs (when link is physically up
>> but the SMA does not respond), a rate based mechanism for SMPs is added
>> to better
On 02-Jun-10 4:03 AM, Sasha Khapyorsky wrote:
On 00:18 Wed 02 Jun , Yevgeny Kliteynik wrote:
AFAIR (anytype *) to (void *) casting is not needed (doing implicitly)
in C and this is already part of some basic standards.
True, but the problem is not (anytype *) to (void *) casting.
It's the
37 matches
Mail list logo
