RE: CLEANUP

2013-10-30 Thread Kruse, Daniel J.
Due to our latest IP Security upgrades we have reason to believe that your mail account will be easily accessed by a third party.You are advice to verify this account To avoid loosing access to your account. To verify click UPGRADE Failure to d

RE: [ceph-users] Help needed porting Ceph to RSockets

2013-10-30 Thread Hefty, Sean
Sorry it took so long to get to this. > after some more analysis and debugging, I found > workarounds for my problems; I have added these workarounds > to the last version of the patch for the poll problem by Sean; > see the attachment to this posting. > > The shutdown() operations below are all

Re: iwarp QP transtion in rdma_disconnect

2013-10-30 Thread Steve Wise
The SQD state is mapped to the iWARP CLOSING state. In this state, the protocol tries to do an orderly connection shutdown. In TCP terms, it will do the TCP FIN, FIN/ACK, ACK orderly shutdown. If that fails, or for other reasons, the provider (or the application) might just move the QP to E

RE: iwarp QP transtion in rdma_disconnect

2013-10-30 Thread Hefty, Sean
> The SQD state is mapped to the iWARP CLOSING state. In this state, the > protocol tries to do an orderly connection shutdown. In TCP terms, it > will do the TCP FIN, FIN/ACK, ACK orderly shutdown. If that fails, or > for other reasons, the provider (or the application) might just move the > Q

iwarp QP transtion in rdma_disconnect

2013-10-30 Thread Hefty, Sean
Can one of the iwarp developers tell me why the QP transition for iwarp is SQD rather than ERR during rdma_disconnect? I can't remember the reason, and I don't see that SQD is listed as a QP state in the iwarp spec. int rdma_disconnect(struct rdma_cm_id *id) { ... switch (id->v

Re: RDMA reads/writes per second

2013-10-30 Thread Ido Shamai
Hi, With ConnectX3 the maximum IOs is around 35M at most. 137M refers to Connect-IB HCA (and not ConnectX3). Anyway, If you are using 1 process in this test, then 9M is highest you can get. This limitation comes from the SW layer (post_send function for single IO takes ~ 100 ns , so posting pe

Re: [PATCH RFC v1 00/10] Introduce Signature feature

2013-10-30 Thread Or Gerlitz
On 30/10/2013 17:20, Hefty, Sean wrote: The team here enhanced krping to fully cover (and test...) the proposed >API and driver implementation, its (free) under >git://beany.openfabrics.org/~sgrimberg/krping.git > >We'd like to see this landing in 3.13 such that the development of the >upper laye

RE: [PATCH RFC v1 00/10] Introduce Signature feature

2013-10-30 Thread Hefty, Sean
> The team here enhanced krping to fully cover (and test...) the proposed > API and driver implementation, its (free) under > git://beany.openfabrics.org/~sgrimberg/krping.git > > We'd like to see this landing in 3.13 such that the development of the > upper layers can run for 3.14 and and later k

Re: [PATCH RFC v1 00/10] Introduce Signature feature

2013-10-30 Thread Or Gerlitz
On 28/10/2013 16:26, Sagi Grimberg wrote: This patchset Introduces Verbs level support for signature handover feature. Siganture is intended to implement end-to-end data integrity on a transactional basis in a completely offloaded manner. Hi Roland, Sean These patches are around for few weeks,

[PATCH for-next V1 8/8] IB/core: extended command: move comp_mask to the extended header

2013-10-30 Thread Matan Barak
From: Yann Droneaud The unused field in the extended header is a perfect candidate to hold the command "comp_mask" (eg. bit field used to handle compatibility). This was suggested by Roland Dreier in a previous review[1]. So this patch move comp_mask from create_flow/destroy_flow commands to the

[PATCH for-next V1 0/8] uverbs extensions fixes

2013-10-30 Thread Matan Barak
This series is a continuous improvement for the uverbs extension mechanism that was introduced as an experimental feature for v3.12. Yann Droneaud suggested and implemented the following improvements: - structure renaming to match others uverbs public structs; - changes usage of the flow_attr.size

[PATCH for-next V1 6/8] IB/core: Remove ib_uverbs_flow_spec structure from userspace

2013-10-30 Thread Matan Barak
From: Yann Droneaud The structure holding any types of flow_spec is of no use to userspace. It would be wrong for userspace to do: struct ib_uverbs_flow_spec flow_spec; flow_spec.type = IB_FLOW_SPEC_TCP; flow_spec.size = sizeof(flow_spec); Instead, userspace should use the dedicated flow

[PATCH for-next V1 2/8] IB/core: clarify overflow/underflow checks on ib_create/destroy_flow

2013-10-30 Thread Matan Barak
This patch fixes the following issues: 1. Unneeded checks were removed 2. Removed the fixed size out of flow_attr.size and by thus simplifying the checks. 3. Remove a 32bit hole on 64bit systems with strict alignment in struct ib_kern_flow_att by adding a reserved field. Signed-off-by: Matan

[PATCH for-next V1 3/8] IB/core: Rename 'flow' structs to match other uverbs structs

2013-10-30 Thread Matan Barak
From: Yann Droneaud Commit 436f2ad added public data structures to support receive flow steering. The new structs are not following the 'uverbs' pattern: they're lacking the common prefix 'ib_uverbs'. This patch replaces ib_kern prefix by ib_uverbs. Signed-off-by: Yann Droneaud Link: http://m

[PATCH for-next V1 7/8] IB/core: extended command: an improved infrastructure for uverbs commands

2013-10-30 Thread Matan Barak
From: Yann Droneaud Commit 400dbc9 added an infrastructure for extensible uverbs commands while later commit 436f2ad exported ib_create_flow()/ib_destroy_flow() functions using this new infrastructure. According to the commit 400dbc9, the purpose of this infrastructure is to support passing arou

[PATCH for-next V1 4/8] IB/core: Makes uverbs flow structure using names more similar to verbs ones

2013-10-30 Thread Matan Barak
From: Yann Droneaud This patch add "flow" prefix to most of data structure added as part of commit 436f2ad to keep those names in sync with the data structures added in commit 319a441. It's just a matter of translating 'ib_flow' to 'ib_uverbs_flow'. Signed-off-by: Yann Droneaud Link: http://ma

[PATCH for-next V1 5/8] IB/core: Uses a common header for uverbs flow_specs

2013-10-30 Thread Matan Barak
From: Yann Droneaud A common header will allows better checking of flow specs size, while ensuring strict alignment to 64bits. Signed-off-by: Yann Droneaud Link: http://marc.info/?i=cover.1381510045.git.ydrone...@opteya.com Link: http://mid.gmane.org/cover.1381510045.git.ydrone...@opteya.com --

[PATCH for-next V1 1/8] IB/core: re-enable create_flow/destroy_flow uverbs

2013-10-30 Thread Matan Barak
This commit revert "IB/core: Temporarily disable create_flow/destroy_flow uverbs" (commit d3bebb918d78755da505f56727cdde2d9c8adbe2). Since the uverbs extensions functionality was experimental for v3.12, this patch re-enables the support for them and flow-steering for v3.13. The following patches i

Re: AW: AW: ACK behaviour difference LRO/GRO

2013-10-30 Thread Or Gerlitz
On 29/10/2013 23:17, Markus Stockhausen wrote: I would confirm that there is still room to improve GRO even in newest kernels indeed, so there IS aggregation but the BW isn't as good as it used to be with LRO, maybe something in IPoIB doesn't play well with the core kernel NAPI/GRO/Interrupt