I think the white space is meant to look like this. I did look at
whether the "sq_cqes = 0;" should only be done if netif_queue_stopped().
In the end I decided this was what was intended, but it would be
better if someone more familiar with the code reviewed it.
Reported-by: Julia Lawall
Signed-
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
This will get the 2.6.36 merge window pile, which ac
Hey Steve... is the prerequisite for this in drivers/net/cxgb4 upstream now?
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a mess
thanks, applied
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
> > No objection to adding this and I will include it for my next pull. But
> > out of curiousity what arch are you seeing this on? I'm not seeing any
> > problems on x86 and I haven't heard any complaints about -next so I'm
> > curious what the error you're seeing is.
> sparc64 allmodconfi
Walukiewicz, Miroslaw wrote:
My patch was implemented using the most effective method available for current version of code and it is ready and working as a functionality.
[...] I will start a new discussion regarding an optimization of the post_send/post_recv path. Thank you for reminder.
Hi Mi
> It is not clear whether the assignment should be part of the if branch
> suggested by its indentation. The patch preserves the current semantics.
Thanks. Chien/Faisal -- are the current semantics correct or should we
add braces { } to match the indentation? From a quick look at the code,
I
From: Julia Lawall
It is not clear whether the assignment should be part of the if branch
suggested by its indentation. The patch preserves the current semantics.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@r disable braces4@
position p1,p2;
stat
Hi,
I'm running ib_send_bw (version 1.20) over ConnectX HCAs on an
Infiniscale III switch. If I run:
ib_send_bw -s 256 -c RC
I get 790 MB/s
ib_send_bw -s 256 -c UD
still gets me 790 MB/s
ib_send_bw -s 256 -c UD -g 1
which runs over a multicast GID/LID gets 790 MB/s when there are two
HCAs on
From: Roland Dreier
Date: Thu, 05 Aug 2010 09:29:58 -0700
> No objection to adding this and I will include it for my next pull. But
> out of curiousity what arch are you seeing this on? I'm not seeing any
> problems on x86 and I haven't heard any complaints about -next so I'm
> curious what the
Atomic ops are optional. Mellanox and QLogic HCAs support them,
I don't know about the other HCAs.
There are two kinds supported. QLogic's driver does them in
the host driver so they are atomic with respect to all the CPUs
in the host. Mellanox uses HCA wide atomic which means the
HCA will do a me
> I am told that the customer has modified the SRP code, which is why I cannot
> go by the ib_srp.c code.
Can you not ask the customer?? Or if you have the object code, look for
calls to srq functions in the binary??
> 1. Would the Syndrome field show CC INVALID if SRQ were being used?
>
> I have the envious task of figuring out whether SRQ is being used in
> an SRP application (which I have very little knowledge about). I
> only have IB transport layer traces from the customer. From the
> traces I can see Valid Credits in the Syndrome field of the AETH in
> RDMA_ReadRes
Ralph:
I am told that the customer has modified the SRP code, which is why I cannot go
by the ib_srp.c code.
Hence, I am trying to figure out from the IB transport traces whether SRQ is
being used or not.
1. Would the Syndrome field show CC INVALID if SRQ were being used? If so, in
which IB me
SRP doesn't use a SRQ.
Look at drivers/infiniband/ulp/srp/ib_srp.c for
ib_create_qp() and the init_attr.cap.max_recv_wr is set
and init_attr.ib_srq is not set.
On Thu, 2010-08-05 at 09:38 -0700, Suresh Shelvapille wrote:
> Folks:
>
> I have the envious task of figuring out whether SRQ is being u
Could someone who is OFED IPoIB knowledgeable help me understand which IPoIB
side starts the RC connection establishment (Tx REQ) to an ARP unknown remote
host?
I tried reading the Linux IPoIB code and realized it's been too many years
since writing Linux network drivers (2001) and found mysel
> How about adding blk-iopoll support in ib_srp ? blk-iopoll is the NAPI
> equivalent for block devices. More information about blk-iopoll can be
> found here: http://lkml.org/lkml/2009/8/6/395.
Wow, I was not aware of that work at all. Thanks for the pointer.
Anyway, yes, that does look l
Folks:
I have the envious task of figuring out whether SRQ is being used in an SRP
application (which I have very little
knowledge about). I only have IB transport layer traces from the customer.
>From the traces I can see Valid Credits in the Syndrome field of the AETH in
>RDMA_ReadResponse_Fi
> In general - none of our new features going to be included and I wish
> to understand the reason behind it (I hope it's not personal :-)
It's not personal -- it was a combination of when things were ready and
when I had time to work on things, and unfortunately it all lined up so
I wasn't able
> Without this I'm getting build errors with Linus's current tree.
> Apologies if this is already fixed in the RDMA git tree.
>
> diff --git a/drivers/infiniband/hw/qib/qib.h
b/drivers/infiniband/hw/qib/qib.h
> index 3593983..312ca9a 100644
> --- a/drivers/infiniband/hw/qib/qib.h
>
> Hi guys, here are a few trivial patches I have for nes. Let me know if
> you see any problems with them.
All three patches look good, thank you.
Chien
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Wed, 04 Aug 2010 11:50:05 -0700
Roland Dreier wrote:
> Looks fine to me. ehca guys, any objection?
We don't have any objections.
Acked-by: Alexander Schmidt
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More m
Hello Or,
My patch was implemented using the most effective method available for current
version of code and it is ready and working as a functionality.
For me another thing then functionality is an optimization of the existing SW
paths in infiniband code and modification earlier written code
This patch implements IPv4 MGID to MLID mapping in the same scheme as multicast
IP to MAC mapping.
Users may choose multicast IPs to use the same MLID or not.
Slava Strebkov wrote:
> When option is enabled, same mlid may be assigned to
> multicast groups created by IPoIB IPv4.
> If there is no d
When option is enabled, same mlid may be assigned to
multicast groups created by IPoIB IPv4.
If there is no difference in 23 lsb bits of MGID,
multicast group will got same mlid.
Signed-off-by: Slava Strebkov
---
opensm/include/opensm/osm_subnet.h |3 +-
opensm/opensm/main.c
Walukiewicz, Miroslaw wrote:
Hello Roland, What about a series from Aleksey Senin [...] And my patch
RDMA/nes: IB_QPT_RAW_PACKET QP type support for nes driver
https://patchwork.kernel.org/patch/110252
Hi Mirek,
Reading your response @ http://marc.info/?l=linux-rdma&m=127954552519544
to the
Hello Roland,
What about a series from Aleksey Senin
[PATCH V1 0/4] New RAW_PACKET QP type
[PATCH V1 1/4] Rename RAW_ETY to RAW_ETHERTYPE
[PATCH V1 2/4] New RAW_PACKET QP type definition
[PATCH V1 3/4] Security check on QP type
[PATCH V1 4/4] Add RAW_PACKET to ib_attach/detach mcast calls
An
On 8/5/2010 2:33 AM, Roland Dreier wrote:
Hi Roland,
>
> Here are a few topics I'm tracking that are not ready in time for the
> 2.6.36 window and will need to wait for 2.6.37 at least:
>
> - XRC. While I think we made significant progress here, the fact is
>that this is not ready to merge
On Wed, Aug 4, 2010 at 10:40 PM, Roland Dreier wrote:
>
> > I believe this is a wrong approach for this problem. You are
> > workarounding it, not solving, and introducing a bad side effect of
> > additional context switch per command, so increasing its processing
> > latency. It doesn't matte
29 matches
Mail list logo
