On 2/2/2010 5:54 PM, Hal Rosenstock wrote:
Will Mellanox be adding this option to the IB spec rather than keep it
as vendor proprietary ?
Yes, it's in our plans
Tziporet
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kerne
Eric Dumazet wrote:
Le mardi 02 février 2010 à 23:30 -0500, Amerigo Wang a écrit :
This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports,
it can be used like ip_local_port_range, but this is used to
reserve ports for third-party applications which use fixed
port numbers within ip_loca
Le mardi 02 février 2010 à 23:30 -0500, Amerigo Wang a écrit :
> This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports,
> it can be used like ip_local_port_range, but this is used to
> reserve ports for third-party applications which use fixed
> port numbers within ip_local_port_range.
>
This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports,
it can be used like ip_local_port_range, but this is used to
reserve ports for third-party applications which use fixed
port numbers within ip_local_port_range.
This only affects the applications which call socket functions
like bi
Hi,
You can either do a "simple send" after RDMA write or you can also poll on last
byte... While I was working on it, I had done and I never ran into problem with
either of the method.
Someone also quoted texts from Infiniband Spec, but I would also suggest to
read iWARP spec if you are going
From: Ira Weiny
Date: Tue, 2 Feb 2010 17:43:20 -0800
Subject: [PATCH] libibnetdisc: fix typo in man page for ibnd_show_progress
Signed-off-by: Ira Weiny
---
.../libibnetdisc/man/ibnd_discover_fabric.3|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/infiniband-
From: Ira Weiny
Date: Tue, 2 Feb 2010 14:06:03 -0800
Subject: [PATCH] libibnetdisc: add ibnd_set_max_smps_on_wire call
In addition update ibnetdiscover, iblinkinfo, and ibqueryerrors to use
this function.
Signed-off-by: Ira Weiny
---
.../libibnetdisc/include/infiniband/ibnetdisc.h
From: Ira Weiny
Date: Fri, 22 Jan 2010 17:33:30 -0800
Subject: [PATCH] libibnetdisc: Convert to a multi-smp algorithm
Allow for multiple SMP's to be on the wire at a single time. This
algorithm splits the processing of SMP's to a small smp engine which
may be useful to s
Sasha,
Following up on our thread regarding having multiple outstanding SMP's in
libibnetdisc.
These 2 patches implement that as well as add a function to set the max
outstanding the lib will use.
I left the default here to be 4. On a large cluster there seems to be some
variance with using
>Will Mellanox be adding this option to the IB spec rather than keep it
>as vendor proprietary ?
Along with that question, what is the use case for this feature? The only
benefit mentioned was saving a few bytes of memory, at the cost of carrying
extra network headers. Atomics are only 64-bits t
The patch below reduces the number of IB interrupts from two interrupts per
srp_queuecommand() call to one. Send completion events are now processed via
polling instead of letting the HCA trigger an interrupt for each send
completion event. Receive completion events still trigger an interrupt.
Sig
This change is not useful by itself, but sets us up for a future change
that allows us to support more than IB_UVERBS_MAX_DEVICES in a system.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/uverbs_main.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers
Eliminate some padding in the structure by rearranging the members.
sizeof(struct ib_uverbs_event_file) is now 72 bytes (from 80) and
more members now fit in the first cacheline.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/uverbs.h |4 ++--
1 files changed, 2 insertions(+), 2 de
Some large systems may support more than IB_UVERBS_MAX_DEVICES
(currently 32).
This change allows us to support more devices in a backwards-compatible
manner. The first IB_UVERBS_MAX_DEVICES keep the same major/minor
device numbers that they've always had.
If there are more than IB_UVERBS_MAX_DEV
This change is not useful by itself, but it sets us up for a future
change that allows us to dynamically allocate device numbers in case
we have more than IB_UVERBS_MAX_DEVICES in the system.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/uverbs_main.c | 12 +++-
1 files chang
We no longer need this data structure, as it was used to associate
an inode back to a struct ib_umad_port during ->open().
But now that we're embedding a struct cdev in struct ib_umad_port,
we can use the container_of() macro to go from the inode back to
the device instead.
Signed-off-by: Alex Ch
Some large systems may support more than IB_UCM_MAX_DEVICES
(currently 32).
This change allows us to support more devices in a backwards-compatible
manner. the first IB_UCM_MAX_DEVICES keep the same major/minor device
numbers they've always had.
If there are more than IB_UCM_MAX_DEVICES, then we
As shown when 'let c_space_errors=1' is set in vim.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/ucm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/core/ucm.c b/drivers/infiniband/core/ucm.c
index 1203ca4..7bf0a82 100644
--- a/driver
A small change to reduce the size of ib_device to 1112 bytes
(from 1128).
Signed-off-by: Alex Chiang
---
include/rdma/ib_verbs.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 09509ed..a585e0f 100644
--- a/incl
This change is not useful by itself, but sets us up for a future change
that allows us to support more than IB_UCM_MAX_DEVICES.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/ucm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/core/ucm.c
Clean errors as shown when 'let c_space_errors=1' is set in vim.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/user_mad.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/infiniband/core/user_mad.c
b/drivers/infiniband/core/us
This change is not useful by itself, but sets us up for a future
change that allows us to dynamically allocate device numbers in case
we have more than IB_UCM_MAX_DEVICES in the system.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/ucm.c | 12 +++-
1 files changed, 7 insertio
Some large systems may support more than IB_UMAD_MAX_PORTS
(currently 64).
This change allows us to support more ports in a backwards-compatible
manner. The first IB_UMAD_MAX_PORTS keep the same major/minor device
numbers they've always had.
If there are more than IB_UMAD_MAX_PORTS, we then dynam
This change is not useful by itself, but sets us up for a future
change that allows us to dynamically allocate device numbers
in case we have more than IB_UMAD_MAX_PORTS in the system.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/user_mad.c | 15 +--
1 files changed, 9 i
This change is not useful by itself, but sets us up for a future change
that allows us to support more than IB_UMAD_MAX_PORTS in a system.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/user_mad.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/inf
Clean up the errors as shown when 'let c_space_errors=1' is set in vim.
Signed-off-by: Alex Chiang
---
drivers/infiniband/core/uverbs_main.c | 68 +
1 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_main.c
b/driver
Instead of storing pointers to cdev and sm_cdev, embed the full
structures instead.
This change allows us to use the container_of() macro in ib_umad_open()
and ib_umad_sm_open() in a future patch.
This change increases the size of struct ib_umad_port to 320 bytes
from 128.
Signed-off-by: Alex Ch
dev_table's raison d'etre was to associate an inode back to a
struct ib_uverbs_device.
However, now that we've converted ib_uverbs_device to contain
an embedded cdev (instead of a *cdev), we can use the container_of()
macro and cast back to the containing device.
There's no longer any need for de
Instead of storing a pointer to a cdev, embed the entire struct cdev.
This change allows us to use the container_of() macro in
ib_uverbs_open() in a future patch.
This change increases the size of struct ib_uverbs_device to
168 bytes across 3 cachelines from 80 bytes in 2 cachelines.
However, we
This is v2 of a patch series that increases the maximum number of
IB HCAs supported per system.
The original mail thread is here:
http://lkml.org/lkml/2010/1/29/346
One note, I decided to "copy/paste" since factoring out the overflow
code in the three drivers seemed like overkill. If so d
On Tue, Feb 02, 2010 at 03:11:26PM +0200, Yevgeny Kliteynik wrote:
> >If no inline version is defined then the compiler just emits a normal
> >function call, if an inline version is defined then the compiler might
> >use it.
>
> Thanks for the idea.
> I read some documentation about it, and it doe
Andy,
What is the kernel version you are using ? Is the Xen patch you
are referring to an out of tree patch ? And from an OFED perspective,
which OFED versions would be impacted ?
Regards,
Ram
On Mon, Feb 1, 2010 at 7:51 PM, Andy Grover wrote:
> Actually the build error occurred on kernels with
On Feb 2, 2010, at 16:54 , Hal Rosenstock wrote:
> On Tue, Feb 2, 2010 at 5:44 AM, Vladimir Sokolovsky
>> [snip]
>> Masked Fetch and Add (MFetchAdd)
>> The MFetchAdd Atomic operation extends the functionality of the standard IB
>> FetchAdd by
>> allowing the user to split the target into multiple
On Feb 2, 2010, at 16:14 , yogeshwar sonawane wrote:
> Hi all,
>
> Following question can be of naïve nature. Kindly, help me to clarify
> the points.
> Thanks in Advance.
>
> [snip].
>
> It will be helpful if some information is shared as how mvapich2
> handles the situation regarding above po
On Tue, Feb 2, 2010 at 5:44 AM, Vladimir Sokolovsky
wrote:
> Sean Hefty wrote:
>>>
>>> This patchset adds support for the following enhanced atomic operations:
>>> - Masked atomic compare and swap
>>> - Masked atomic fetch and add
>>
>> Can you explain these in more detail? How exactly is a mask
Hi all,
Following question can be of naïve nature. Kindly, help me to clarify
the points.
Thanks in Advance.
Consider an application on top of uverbs / udapl library and wants to
use only rdma write operations.
While using RDMA write operations, one has to indicate the responder
side(receiving si
In this case the GID in the data details is the MGID and
not the source gid. So the SM gid should be taken as the source gid.
There was also an error in comparing the subnet prefix and guid due to
host/network order mismatch.
Signed-off-by: Eli Dorfman
---
opensm/opensm/osm_inform.c | 19
Hi Sasha,
Fixing a bug in cl_ptr_vector_find_from_end(), discovered
by compiler's warning:
cl_ptr_vector.c: In function 'cl_ptr_vector_find_from_end':
cl_ptr_vector.c:305: warning: operation on 'i' may be undefined
Signed-off-by: Yevgeny Kliteynik
---
opensm/complib/cl_ptr_vector.c |3 ++-
Sasha,
There are couple of problematic castings in complib/cl_passivelock.h:
(cl_status_t) pthread_rwlock_*()
Turns out that compiler doesn't like casting directly from
int to enum, probably because int can be negative:
cl_passivelock.h:199: warning: cast from function call of type 'int' to
no
On 01/Feb/10 18:01, Yevgeny Kliteynik wrote:
Sasha,
There are couple of problematic castings in complib/cl_passivelock.h:
(cl_status_t) pthread_rwlock_*()
Turns out that compiler doesn't like casting directly from
int to enum, probably because int can be negative:
cl_passivelock.h:199: warnin
On 01/Feb/10 20:46, Jason Gunthorpe wrote:
On Mon, Feb 01, 2010 at 03:05:13PM +0200, Yevgeny Kliteynik wrote:
In general, here's the problem:
We have cl_file.h and cl_file_osd.h.
cl_file.h has include directive for cl_file_osd.h
cl_file.h has the following definition of function:
int f
Sean Hefty wrote:
This patchset adds support for the following enhanced atomic operations:
- Masked atomic compare and swap
- Masked atomic fetch and add
Can you explain these in more detail? How exactly is a mask used? Are there
any restrictions on the format of the mask? How is the mask ca
42 matches
Mail list logo
