On 13-10-11 04:41 AM, Alexander Gordeev wrote:
> On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote:
>> Just to help us all understand "the loop" issue..
>>
>> Here's an example of driver code which uses the existing MSI-X interfaces,
>> for a device which can work with either 16, 8, 4, 2, o
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 extended command head
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 around provider (eg. hardw
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://marc.info/?i=cover.13815
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
---
include/uapi/rdma/i
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_spec structure for
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://marc.info/?i=cover.13815
Flow spec length don't depend on the size of the command
header: they are part of different layers.
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
---
drivers/infiniband/core/uv
In patch "IB/core: clarify overflow/underflow checks on ib_create/destroy_flow",
the meaning of the size field was modified to only represent
the size of the flow_spec appended to the flow_attr structure.
The size of the flow_attr structure must be added when
allocating memory for the whole flow_a
Hi,
As requested by Or Gerlitz, I've rebased my previous fixes [1]
against Matan Barak patch [2]. I've added two patches to fix issues
left or introduced by this patch.
Regarding the previous patchset [1], I've kept the public data
structure improving and renaming patches, but, in order to minimiz
From: 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.
On 10/10/2013 02:19 PM, Bart Van Assche wrote:
> Certain storage configurations, e.g. a sufficiently large array of
> hard disks in a RAID configuration, need a queue depth above 64 to
> achieve optimal performance. Hence make the queue depth configurable.
>
Hello Bart,
It's better to mention use
On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote:
> Just to help us all understand "the loop" issue..
>
> Here's an example of driver code which uses the existing MSI-X interfaces,
> for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt.
> This is from a new driver I'm
13 matches
Mail list logo
