On Mon, Aug 9, 2010 at 1:51 AM, Jason Gunthorpe
wrote:
>
> [ ... ]
>
> Further, the approach you outline in your follow on message for
> blkio, has problems.. Look at how IPOIB does NAPI to see how
> this must look.
>
> 1) ib_req_notify_cq must only be called if you are processing less
> the bud
Robert Pearson wrote:
> Several new opcodes have been added since the last time ib_pack.h was updated.
> These changes add them.
> +++ b/include/rdma/ib_pack.h
> + IB_OPCODE_CN= 0x80,
> + IB_OPCODE_XRC = 0xA0,
Is this tied t
Hey Sean,
What is the logic behind limiting the listen backlog to 128?
--
snipit from ucma.c:
enum {
UCMA_MAX_BACKLOG= 128
};
snipit from ucma_listen():
ctx->backlog = cmd.backlog > 0 && cmd.backlog < UCMA_MAX_BACKLOG ?
cmd.backlog : UCMA_M
On Sun, 2010-08-08 at 20:19 +0200, Bart Van Assche wrote:
> On Sat, Aug 7, 2010 at 6:32 PM, Roland Dreier wrote:
> > Not sure that I follow the problem you're worried about. A given
> > tasklet can only be running on one CPU at any one time -- if an
> > interrupt occurs and reschedules the taskle
Unfortunately it will probably be a while before I can look at this in
any detail, but here are some obvious things to fix:
- The actual FC/SCSI driver will need to be reviewed on
linux-s...@vger.kernel.org of course; so please CC that list.
- The ordering/split of patches seems off; in part
I think that could be relaxed.
Running OFED (and softiwarp) on larger installations,
we already had to set this to some KByte...
Bernard.
linux-rdma-ow...@vger.kernel.org wrote on 08/09/2010 04:34:31 PM:
> Hey Sean,
>
> What is the logic behind limiting the listen backlog to 128?
>
> --
>
>
I agree. I think it should default to say 1024. Further, I propose we
make this a sysctl variable such that admins can tweak it as needed.
On 08/09/2010 12:06 PM, Bernard Metzler wrote:
I think that could be relaxed.
Running OFED (and softiwarp) on larger installations,
we already had to se
> I agree. I think it should default to say 1024. Further, I propose we
> make this a sysctl variable such that admins can tweak it as needed.
The default is based on:
#define SOMAXCONN 128
I have no objection to making it adjustable.
- Sean
--
To unsubscribe from this list: send the li
On 08/09/2010 12:51 PM, Hefty, Sean wrote:
I agree. I think it should default to say 1024. Further, I propose we
make this a sysctl variable such that admins can tweak it as needed.
The default is based on:
#define SOMAXCONN 128
I have no objection to making it adjustable.
- Sea
David Dillow, on 08/09/2010 06:49 PM wrote:
On Sun, 2010-08-08 at 20:19 +0200, Bart Van Assche wrote:
On Sat, Aug 7, 2010 at 6:32 PM, Roland Dreier wrote:
Not sure that I follow the problem you're worried about. A given
tasklet can only be running on one CPU at any one time -- if an
interrupt
> For TCP, a dropped SYN will cause the peer to retransmit the SYN, and
> the connection will be eventually established. So a small backlog limit
> is probably ok for TCP. With iWARP, the connect request is TCP payload
> an on established connection. So the connection request is transmitted
> an
On Mon, 2010-08-09 at 22:45 +0400, Vladislav Bolkhovitin wrote:
> David Dillow, on 08/09/2010 06:49 PM wrote:
> > I'm not sure it makes sense to enable/disable this at runtime -- we
> > don't do it for NAPI, why do it for block devices? I'm not even sure I'd
> > want to see a config option for it i
Agreed.
Currently, if running out of backlog, the cm actively
rejects the connection with -ENOMEM back to the provider
(see ucma_event_handler(), and cm_conn_req_handler()).
That should allow the provider to zap the TCP connection,
but its not very productive ;)
Bernard.
Steve Wise wrote on 08/
> This allow rdma ucm to establish an XRC connection between two nodes. Most
> of the changes are related to modify_qp since the API is different
> whether the QP is on the send or receive side.
> To create an XRC receive QP, the cap.max_send_wr must be set to 0.
> Conversely, to create the send XR
New release for uDAPL v1.2 (1.2.19) and v2.0 (2.0.30) available at:
http://www.openfabrics.org/downloads/dapl
Latest Packages (see ChangeLog for details):
md5sum: ef98486354feb7ea930f3cd698a310fd compat-dapl-1.2.19.tar.gz
md5sum: 8177f4721f286a3d9e00b60eda74d6dc dapl-2.0.30.tar.gz
For 1.2 an
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 one cxgb4 patch that I was holding unt
> Several new opcodes have been added since the last time ib_pack.h was
> updated.
> These changes add them.
Will anything make use of these?
> diff --git a/include/rdma/ib_pack.h b/include/rdma/ib_pack.h
> index cbb50f4..df10acc 100644
> --- a/include/rdma/ib_pack.h
> +++ b/include/rdma/ib_pack.
Guys. What's goin' on out there?
drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in
initializer
drivers/power/olpc_battery.c:387: warning: initialization from incompatible
pointer type
make[2]: *** [drivers/power/olpc_battery.o] Error 1
make[1]: *** [drivers/power] Er
On Mon, 9 Aug 2010 16:43:46 -0700 Andrew Morton wrote:
>
> Guys. What's goin' on out there?
>
>
> drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in
> initializer
> drivers/power/olpc_battery.c:387: warning: initialization from incompatible
> pointer type
> make[2]:
Hi Andrew,
On Mon, 9 Aug 2010 16:43:46 -0700 Andrew Morton
wrote:
>
> Guys. What's goin' on out there?
I guess we are all so up to date that noone does 32 bit builds any
more ... Also noone is bothering to look at the build logs:
linus tree: http://kisskb.ellerman.id.au/kisskb/branch/3/
linu
On Mon, 2010-08-09 at 16:43 -0700, Andrew Morton wrote:
>
> drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in
> initializer
> drivers/power/olpc_battery.c:387: warning: initialization from incompatible
> pointer type
> make[2]: *** [drivers/power/olpc_battery.o] Error 1
On 8/9/2010 4:43 PM, Andrew Morton wrote:
Guys. What's goin' on out there?
[..]
drivers/dma/timb_dma.c: In function 'td_fill_desc':
drivers/dma/timb_dma.c:203: warning: cast to pointer from integer of different
size
The fix for this one is pending in my 2.6.36 pull request. I added the
When building the current mainline on i386 architecture, I get the following
warnings:
CC [M] drivers/infiniband/hw/amso1100/c2_vq.o
drivers/infiniband/hw/amso1100/c2_vq.c: In function ‘vq_req_alloc’:
drivers/infiniband/hw/amso1100/c2_vq.c:110:18: warning: cast from pointer to
integer of differ
Will queue up fixes as below:
> drivers/infiniband/hw/nes/nes_verbs.c: In function
> 'nes_alloc_fast_reg_page_list':
> drivers/infiniband/hw/nes/nes_verbs.c:477: warning: cast to pointer from
> integer of different size
> drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_post_send':
24 matches
Mail list logo
