Any further comments on this?
Doug -- does it look ok to you?
> On Dec 7, 2015, at 5:27 AM, Haggai Eran wrote:
>
> On 12/04/2015 01:09 AM, Jeff Squyres wrote:
>> The default value of 8 is too small to read
>> /sys/class/infiniband/usnic_x/node_type, which contains &q
therefore increases the buffer size to 16, which is long
enough to read the usNIC node_type value.
Signed-off-by: Jeff Squyres
Signed-off-by: Xuyang Wang
---
src/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/init.c b/src/init.c
index dbdd795..ef78871 100644
--- a/src/in
al BSD/GPL-licensed.
Signed-off-by: Jeff Squyres
---
drivers/infiniband/hw/usnic/usnic.h | 21 ++---
drivers/infiniband/hw/usnic/usnic_abi.h | 21 ++---
drivers/infiniband/hw/usnic/usnic_common_pkt_hdr.h | 21 ++---
drivers/
ch get into upstream distro libibverbs
releases. Once that happens, we can start planning the end of the horrible
hackarounds we had to put into place (e.g., in Open MPI) to suppress the
misleading libibverbs output.
Thanks!
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information g
Ping.
This is just a periodic query to see if there has been any progress on
accepting this patch into libibverbs.
> On Jun 3, 2015, at 12:50 PM, Doug Ledford wrote:
>
> On Mon, 2015-06-01 at 22:02 +0000, Jeff Squyres (jsquyres) wrote:
>> On May 22, 2015, at 9:44 AM, Doug
ere on list).
Ping.
This is just a periodic query to see if there has been any progress on
accepting this patch into libibverbs.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: s
-r--r-- 1 dledford ofed 406548 May 5 2014 libibverbs-1.1.8.tar.gz
-rw-r--r--. 1 dledford ofed 384656 Apr 24 2007 libibverbs-1.1.tar.gz
-rw-r--r-- 1 dledford ofed 3957 May 7 2014 README.html
-rw-r--r--. 1 dledford ofed 60 Mar 12 2008 WEB_README
-
--
Jeff Squyres
jsquy.
On May 9, 2015, at 8:04 AM, Yann Droneaud wrote:
>
> Le vendredi 08 mai 2015 à 11:21 -0700, Jeff Squyres a écrit :
>> Signed-off-by: Jeff Squyres
>
> This is a little short for an explanation: what was the issue with the
> error messages ?
Cisco has stopped shipping
Signed-off-by: Jeff Squyres
---
src/init.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/src/init.c b/src/init.c
index d0e4b1c..9c21768 100644
--- a/src/init.c
+++ b/src/init.c
@@ -557,19 +557,5 @@ HIDDEN int ibverbs_init(struct ibv_device ***list)
}
out
Bump. This is V2 of the patch, which removes the ABI issue: libibverbs
directly calls the command in the kernel (without going through the provider
plugin).
On Aug 21, 2013, at 5:22 PM, Jeff Squyres wrote:
> Per lengthy discussion on the linux-rdma list, add a new verb to get
> max da
uv_query_port_max_datagram() directly invoke
uv_cmd_query_port_max_datagram().
Signed-off-by: Jeff Squyres
---
Makefile.am | 3 +-
examples/devinfo.c | 7 +
include/infiniband/driver.h | 4 +++
include/infiniband/kern-abi.h| 17 +++-
in
;t see any mention of it in libibverbs.git.
> Is it necessary to call into a provider library, versus simply dropping into
> the kernel?
I don't think I have much of an opinion here, other than: it would seem weird
to not call the provider library, given that all other verbs do that
On Aug 19, 2013, at 6:36 PM, "Hefty, Sean" wrote:
> This breaks the libibverbs ABI. You can't modify ibv_context_ops because it
> changes struct ibv_context.
Any suggestions on how one adds a new driver call without breaking ABI?
--
Jeff Squyres
jsquy...@cisco.co
> command is not supported. In that case, you can handle things like Jason
> suggested.
Gotcha. I'll adjust the patch.
Any other feedback?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
equires bumping the ABI version to 7, no?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord..
e only failure for this call should be due to a bad port
> number..
Sure, can do.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
query" was used (vs. "get") because it invokes a command (vs. a
struct lookup)
If the community likes this approach, I'll send the corresponding
kernel patch.
Signed-off-by: Jeff Squyres
---
Makefile.am | 3 +-
examples/devinfo.c | 7 +
inc
struct lookup)
If the community likes this approach, I'll send the corresponding
kernel patch.
Signed-off-by: Jeff Squyres
---
Makefile.am | 3 +-
examples/devinfo.c | 7 +
include/infiniband/driver.h | 4 +++
include/infiniband/kern-abi.h
the prior posts on this thread
that describes the MTU issue and why we still need a solution.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linu
On Jul 23, 2013, at 9:26 AM, Jeff Squyres (jsquyres) wrote:
>> .. and UD is the least abstracted transport, so existing apps won't
>> support Jeff's new NIC anyhow, MTU is the least of their problems.
>>
>> Existing apps with existing transports see the
4th bump...
On Jul 10, 2013, at 4:32 PM, Jeff Squyres wrote:
> If the send size is less than the cap.max_inline_data reported by the
> qp, use the IBV_SEND_INLINE flag. This now only shows the example of
> using ibv_query_qp(), it also reduces the latency time shown by the
> pingp
ew NIC anyhow, MTU is the least of their problems.
>
> Existing apps with existing transports see the same old values.
...so how do we move forward?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To
Bump bump bump.
I know this isn't a huge / important patch, but it is a small thing that does
decrease the latency reported by these example programs.
On Jul 10, 2013, at 4:32 PM, Jeff Squyres wrote:
> If the send size is less than the cap.max_inline_data reported by the
>
Bump bump.
On Jul 10, 2013, at 4:32 PM, Jeff Squyres wrote:
> If the send size is less than the cap.max_inline_data reported by the
> qp, use the IBV_SEND_INLINE flag. This now only shows the example of
> using ibv_query_qp(), it also reduces the latency time shown by the
> pingp
ong, but it doesn't matter much.
We need it for UD for our upcoming device, however, because the MTU is the only
way to get the max message size.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsub
tu;
>
> In most cases, we only have 8 bits available to/from the kernel. (There are
> at least 16 bits of reserved space in these structures.)
Hmm. 16 bits is probably enough for the MTU values, but still, changing
kern-abi.h will be problematic from an ABI perspective. Do people care abo
e the Doug/Jason position:
- MTU really needs to be a plain integer (not an enum)
- forcing application source change/adaptation is the safest way to move forward
- doing it this way preserves ABI, so existing binaries are safe
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal informat
Bump.
On Jul 10, 2013, at 4:32 PM, Jeff Squyres wrote:
> If the send size is less than the cap.max_inline_data reported by the
> qp, use the IBV_SEND_INLINE flag. This now only shows the example of
> using ibv_query_qp(), it also reduces the latency time shown by the
> pingpong p
Bump.
On Jul 10, 2013, at 8:14 AM, Jeff Squyres (jsquyres) wrote:
> On Jul 8, 2013, at 1:26 PM, Jason Gunthorpe
> wrote:
>
>> Jeff's patch doesn't break old binaries, old binaries, running with
>> normal IB MTUs work fine. The structure layouts all stay the sa
If the send size is less than the cap.max_inline_data reported by the
qp, use the IBV_SEND_INLINE flag. This now only shows the example of
using ibv_query_qp(), it also reduces the latency time shown by the
pingpong programs when the sends can be inlined.
Signed-off-by: Jeff Squyres
s in 0.02 seconds = 15.74 usec/iter
-
Still works fine.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
N�r��yb�X��ǧv�^�){.n�+{��ٚ�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
source code and ABI changes, which
resulted in this patch.
I personally don't care which way this goes; I just want the ability to have
non-enum MTU values.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
Bump.
On Jul 2, 2013, at 8:31 AM, Jeff Squyres wrote:
> (Previous patch did not include updates for the man pages)
>
> Keep IBV_MTU_* enums values as they are, but pass MTU values around as
> a struct containing a single int.
>
> Per lengthy discusson on the linux-rdm
can
continue to use the enum values, they will need to be updated to use
the struct. Newer applications are encouraged to use arbitrary int
values, not the MTU enums (e.g., 1024, 1500, 9000).
Signed-off-by: Jeff Squyres
---
Makefile.am| 3 +-
examples/devinfo.c | 20
to use the struct. Newer applications are
encouraged to use arbitrary int values, not the MTU enums (e.g., 1024,
1500, 9000).
(if people like the idea of this patch, I will send the corresponding
kernel patch)
Signed-off-by: Jeff Squyres
---
Makefile.am| 3 ++-
examples
touched. This is trivially done by wrapping it in a struct:
>
> struct ibv_mtu_t {int __mtu;};
Sure, I can work up a patch that does this.
Do others agree? Roland?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/
routines such
> as this.
This is in the devinfo.c program (which is single-threaded), not in the library
itself.
But regardless, this whole function went away in V2 of the patch.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doi
band/libibverbs.git/tree/include/infiniband/verbs.h#n379
respectively.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a
idea of this patch, I will send the corresponding
kernel patch)
Signed-off-by: Jeff Squyres
---
Makefile.am| 3 ++-
examples/devinfo.c | 20 +++---
examples/pingpong.c| 12 -
examples/pingpong.h| 1 -
examples/rc_pingpong.c
it is in the spirit of the other
enum-to-int/int-to-enum function pair naming conventions:
int ibv_rate_to_mult(enum ibv_rate rate);
enum ibv_rate mult_to_ibv_rate(int mult);
int ibv_rate_to_mbps(enum ibv_rate rate);
enum ibv_rate mbps_to_ibv_rate(int mbps);
--
Jeff Squyres
jsquy...@cisco.c
idea of this patch, I will send the corresponding
kernel patch)
Signed-off-by: Jeff Squyres
---
examples/devinfo.c | 11 +--
examples/pingpong.c| 12
examples/pingpong.h| 1 -
examples/rc_pingpong.c | 8
examples/srq_pingpong.c
n-RDMA apps - but
> especially when combined with ODP it is useful in some places.
I have no doubt that ODP solves problems for someone. It just doesn't seem to
solve the very-long-standing MPI issues with verbs and registration caches.
--
Jeff Squyres
jsquy...@cisco.com
For corpora
ication provides the buffer*, not MPI.
Hence, we're stuck with what buffers the user passes in.
This is the root of the whole "MPI has a registration cache" issue.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_busines
r example.
*That's* what makes this whole concept weird.
It seems like this is a perfect kernel space concept, but is quite foreign to
userspace developers.
> A practical example of using this would be to avoid the need to send
> scatter buffer pointers to the remote. The remote writ
you said you could (preemptively) register
some small regions (that assumedly don't yet exist in your virtual memory
address space) and use them as memory pools. But given that userspace doesn't
control its virtual address ranges, I'm not sure how that's useful.
--
Jeff
nt that by registering non-existent
memory, that's the kernel's problem
I guess I'm arguing that registering non-existent memory is not the Right Thing.
Regardless of what solution is devised for registered memory management
(ummunotify, ODP, or something else), a non-blocking v
On Jun 6, 2013, at 4:33 PM, Jeff Squyres (jsquyres) wrote:
> I don't think this covers other memory regions, like those added via mmap,
> right?
We talked about this at the MPI Forum this week; it doesn't seem like ODP fixes
any MPI problems.
1. MPI still has to have a mem
_sbrk_save = sbrk();
ibv_reg_mr(..., 0, mpi_sbrk_save, ...);
...
}
MPI_Send(buffer, ...) {
if (mpi_sbrk_save != sbrk())
mpi_sbrk_save = sbrk();
ibv_rereg_mr(..., 0, mpi_sbrk_save, ...);
...
}
I don't think this covers other memory regions, like those added via mmap,
right?
--
Jeff Squy
ve to register buffers piecemeal, a non-blocking registration
verb would be quite helpful.
> Also bear in mind that all RDMA access protections will be disabled if
> you register the entire process VM, the remote(s) can scribble/read
> everything..
No problem for MPI/HPC... :-)
--
J
me patches...
That's why I asked at the beginning of this thread. He didn't provide any
details about what still needs to be done, though. :-)
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
ack of that specially. That seems more complex
> than just always returning 3. 3 is guarenteed compatible with all
> users.
>
> Old users will test directly against 3.
> New users will call ibv_from_mtu which tests against 3 as well.
Ok.
I'll take a to-do to work up
dle of incorporating this functionality from the original ummunotify
standalone kernel module into libibverbs and ibcore.
I started this thread asking the status of that branch.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_busines
libray can return that.
> - Make a ibv_from/to_mtu inline function to translate from bytes to
> the encoded MTU value.
> - Switch ibv_mtu from a enum to a typedef int ibv_mtu
That also breaks ABI, doesn't it?
> Jason
--
Jeff Squyres
jsquy...@cisco.com
For corporate lega
libibverbs 2.0, where it would be palatable to have an ABI
break?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the bo
ver issue may go away (that's why I started
this thread asking about register(0 .. 2^64)). But without that, unless I'm
missing something, I don't think it solves the MPI-must-catch-free-sbrk-etc.
issues...? And therefore, having some kind of ummunotify-like functionality as
a ver
vious drawback is that this will break ABI; applications will
need to be recompiled.
(if this approach/patch is acceptable, I will submit a corresponding
patch for the kernel side)
Signed-off-by: Jeff Squyres
---
examples/devinfo.c | 18 +-
examples/pingpong.c
like ummunotify yet?
Why don't we have non-blocking memory registration yet?
...etc.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rd
>>
> We have a mechanism to prefetch the pages needed for a large message
> upon the first page fault, which can also help amortizing the cost of
> the page fault for larger messages.
Ok, thanks.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://w
er an RNR NAK.
Is this correct?
He was very concerned about what the size of the TLB on the HCA, and therefore
what the actual run-time behavior would be for sending around large messages
via MPI -- i.e., would RDMA'ing 1GB messages now incur this
HCA-must-reload-its-TLB-and-therefore-i
entire
memory space (i.e., NULL to 2^64) and then never worry about registered memory?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma&q
IIRC?), and the MPI community universally hated it.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord..
?
The limitation of a max of 2 concurrent page faults seems fairly significant.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
ed to be done at this point)
Has anything been done on the userspace side?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the b
ernel and libibverbs.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More
disagree with these patches -- can they get applied to
libibverbs?
On Apr 22, 2013, at 1:41 PM, Jeff Squyres wrote:
> Added some entries to config/.gitignore for newer versions of the GNU
> Autotools. Also renamed configure.in -> configure.ac to accomodate
> newer GNU Autotools
>
&
in libibverbs.
It would be good to make this value a non-enum-int, too.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
Because I have no control over that. :-)
>> On Apr 25, 2013, at 11:38 AM, Jeff Squyres (jsquyres)
>> wrote:
>>
>>> Bump.
>>>
>>> On Apr 22, 2013, at 1:41 PM, Jeff Squyres wrote:
>>>
>>>> The old sequence of Autotools commands liste
Bump bump. :-)
On Apr 25, 2013, at 11:38 AM, Jeff Squyres (jsquyres)
wrote:
> Bump.
>
> On Apr 22, 2013, at 1:41 PM, Jeff Squyres wrote:
>
>> The old sequence of Autotools commands listed in autogen.sh is no
>> longer correct. Instead, just use the single "
Bump.
On Apr 22, 2013, at 1:41 PM, Jeff Squyres wrote:
> The old sequence of Autotools commands listed in autogen.sh is no
> longer correct. Instead, just use the single "autoreconf" command,
> which will invoke all the Right Autotools commands in the correct
> order.
&g
; it might be worthwhile
to bump libibverbs to 2.x, and then intentionally change the MTU field names in
ibv_port_attr and ibv_qp_attr so that apps using those fields will fail to
compile with libibverbs 2.x (and therefore forcibly realize they need to adapt
to the new int MTU values)
--
Je
The old sequence of Autotools commands listed in autogen.sh is no
longer correct. Instead, just use the single "autoreconf" command,
which will invoke all the Right Autotools commands in the correct
order.
Signed-off-by: Jeff Squyres
---
autogen.sh | 6 +-
1 file changed, 1 inser
e.in" in future
versions of Autoconf).
Signed-off-by: Jeff Squyres
---
.gitignore | 6 +
configure.ac | 74
configure.in | 74
3 files changed, 80 insertions(+),
On Apr 19, 2013, at 8:19 PM, "Hefty, Sean" wrote:
> It may help if you identify the library this patch is against. :)
3rd time sending will be the charm... :-)
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_busin
Bump.
Any thoughts on these two patches? They're pretty trivial, enable use with
modern versions of Autotools, and now feature the proper Signed-off-by line.
On Apr 13, 2013, at 8:15 AM, Jeff Squyres wrote:
> The old sequence of Autotools commands listed in autogen.sh is no
> lon
On Apr 12, 2013, at 11:40 AM, Jeff Squyres (jsquyres)
wrote:
>> As an aside I like the use of RDMA_MTU_* for these values. Again to
>> distinguish them from the IBTA values. But I know that is poor form.
>
> So what's the right way to move forward on this? Is it
e.in" in future
versions of Autoconf).
Signed-off-by: Jeff Squyres
---
.gitignore | 6 +
configure.ac | 74
configure.in | 74
3 files changed, 80 insertions(+),
The old sequence of Autotools commands listed in autogen.sh is no
longer correct. Instead, just use the single "autoreconf" command,
which will invoke all the Right Autotools commands in the correct
order.
Signed-off-by: Jeff Squyres
---
autogen.sh | 6 +-
1 file changed, 1 inser
IB_MTU_256 = 1,
IB_MTU_512 = 2,
IB_MTU_1024 = 3,
IB_MTU_2048 = 4,
IB_MTU_4096 = 5,
RDMA_MTU_1500 = 1500,
RDMA_MTU_9000 = 9000
};
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_busin
x
message size is on RoCE, because the max message size attribute on port refers
to RC, not UD.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "un
RDMA_MTU_9000 = 9000
};
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.k
Roland --
If there are no objections, can this patch (and patch 4 of this set:
https://patchwork.kernel.org/patch/2387321/) be committed? Neither should not
have any real impact other than the modernization of the libibverbs build
system.
On Apr 3, 2013, at 9:06 AM, Jeff Squyres wrote
s that there does not seem to be any other way to
get the max UD message size without knowing the actual MTU (are we incorrect
about that?). Hence, using the IB-defined values is not really sufficient.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com
ger design issue there. I'll go reply separately on that thread.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the bod
Per my previous email, forgive my top reply...
RDMA_NODE_VENDOR would be great, actually. Should I work up a patch for that?
Sent from my phone. No type good.
On Apr 4, 2013, at 10:32 AM, "Hefty, Sean" wrote:
>> The reason we're asking for these IBV_*_USNIC enums now -- before we've
>> submit
type good.
On Apr 4, 2013, at 5:27 PM, "Or Gerlitz" wrote:
> Jeff Squyres (jsquyres) wrote:
>
>> Sure. For a little background, the 2nd-generation Cisco VIC has been
>> available
>> since last year (IIRC): http://www.cisco.com/en/US/products/ps10277
>&g
.max_msg_size is sufficient for their RC QPs.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to major
e a little
time before we can submit good patches for these. The main driving factor for
submitting these new enums is so that they can be included in RHEL 6.5.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
pstream.
But they (rightfully) won't accept patches to IB core and libibverbs until
they've been vetted by the community. Hence, even though our driver is slowly
working its way through QA and not available yet, we wanted to submit these new
enums upstream for community approval so t
Per off-list conversation with Roland, add some new enums for the
Cisco Ethernet Virtual NIC (it's not an RNIC/iWARP device, so it
doesn't fit in the same category as RDMA_NODE_RNIC / RDMA_TRANSPORT_IWARP).
"USNIC" = "Userspace NIC".
---
drivers/infiniband/core/verbs.c | 3 +++
include/rdma/ib_v
Allow specification of common Ethernet MTUs.
---
include/rdma/ib_addr.h | 6 +-
include/rdma/ib_verbs.h | 8 ++--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/rdma/ib_addr.h b/include/rdma/ib_addr.h
index 9996539..1f6fbbc 100644
--- a/include/rdma/ib_addr.h
+++
Added some entries to config/.gitignore for newer versions of the GNU
Autotools. Also renamed configure.in -> configure.ac to accomodate
newer GNU Autotools
(http://lists.gnu.org/archive/html/autotools-announce/2012-11/msg0.html
announced the intent to drop support for "configure.in" in futur
Allow specification of common Ethernet MTUs.
---
examples/devinfo.c | 2 ++
examples/pingpong.c| 2 ++
include/infiniband/verbs.h | 6 --
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/examples/devinfo.c b/examples/devinfo.c
index 98a6b4b..6700882 100644
--- a/
The old sequence of Autotools commands listed in autogen.sh is no
longer correct. Instead, just use the single "autoreconf" command,
which will invoke all the Right Autotools commands in the correct
order.
---
autogen.sh | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/au
Per off-list conversation with Roland, add some new enums for the
Cisco Ethernet Virtual NIC (it's not an RNIC/iWARP device, so it
doesn't fit in the same category as RDMA_NODE_RNIC / RDMA_TRANSPORT_IWARP).
"USNIC" = "Userspace NIC".
---
examples/devinfo.c | 1 +
include/infiniband/verbs
and 9000 MTUs.
2. Minor modernization of the GNU Autotools usage in libibverbs.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
On Jul 21, 2011, at 8:47 AM, Jack Morgenstein wrote:
> [snip]
> When the last user of an XRC domain exits cleanly (or crashes), the domain
> should be destroyed.
> In this case, with Sean's design, the tgt qp's for the XRC domain should also
> be destroyed.
Sounds p
pens if the MPI job crashes and does not properly deallocate the XRC
domain / tgt qp?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma&q
and
>> --with-rdma=gen2 CFLAGS='-DOFED_VERBS -D_ENABLE_XRC_
>>
>> It didn't appear that mvapichs ever used XRC
>>
> You are correct, mvapich does not use XRC.
> openMPI uses XRC, so hopefully you can use openMPI to test out your XRC stuff.
>
; node escher exiting without calling "finalize". This may
> have caused other processes in the application to be
> terminated by signals sent by mpirun (as reported here).
> ------
>
>
--
Jeff Squyres
kernel page that contains a
> generation counter that is incremented each time an event is
> generated. This allows userspace to have a fast path that checks
> that no events have occurred without a system call.
>
> Thanks to Jason Gunthorpe obsidianresearch.com>
1 - 100 of 126 matches
Mail list logo
