The common DAPL codebase shared between Windows and Linux has
diverged. Resync to get back to common code that builds on both
operating systems.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
dapl/common/dapl_adapter_util.h |2 +-
dapl/common/dapl_debug.c|2 +-
dapl/common
Changes to dtest to support building on Windows.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
test/dirs |2 +
test/dtest/SOURCES | 34 -
test/dtest/dirs |1 +
test/dtest/dtest.c
From: Stan Smith stan.sm...@intel.com
Merge SVN IBAL provider code back into the main git tree.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Actual codng changes were made by Stan. I'm just submitting the patch
to update the DAPL git repository.
dapl/dirs |2
From: Stan Smith stan.sm...@intel.com
Update the dapl.git tree with the latest SVN version of the
ibal-scm provider.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Actual codng changes were made by Stan. I'm just submitting the patch
to update the DAPL git repository.
dapl/ibal-scm
Forwarding to general list and copying Sasha.
Hello,
The Windows OpenSM vendor AL struct 'osm_vendor_t' (defined in
opensm\user\include\vendor\osm_vendor_al.h) is missing
the entry 'ca_names[UMAD_MAX_DEVICES][UMAD_CA_NAME_LEN]'.
saquery.c expects to find ca_names in osm_vendor_t.
A couple of
4) saquery.c is the only diags pgms (so far) which uses OpenSM MAD interfaces;
the rest use libibmad.
Looking briefly at the saquery code, I don't understand the benefit to using the
opensm vendor interfaces, versus using libibmad or even libibumad directly, and
switching to libibumad looks
I don't remember the exact details but at the time saquery was first written,
ibmad/ibumad did not have all the functionality I needed and the OpenSM vendor
library did. That may no longer be the case and if not then I would support
converting to using those other libraries.
libibumad does
@@ -595,21 +595,21 @@ typedef struct ib_vendor_call {
#define MAD_DEF_RETRIES3
#define MAD_DEF_TIMEOUT_MS 1000
-enum {
+typedef enum {
IB_DEST_LID,
IB_DEST_DRPATH,
IB_DEST_GUID,
IB_DEST_DRSLID,
-};
+} mad_dest_t;
-enum {
+typedef enum {
cma_acquire_dev -- cma_set_qkey/ps=IPOIB -- ib_sa_get_mcmember_rec where the
latter returns EADDRNOTAVAIL since when the port went down the core multicast
code
Why is ib_sa_get_mcmember_rec being called? Or is this issue separate from what
udaddy is showing?
I assume there must be a way to
- an rdma-cm based app wants to determine if the route for a multicast
group leads to IPoIB interface/device based on the outcome of
rdma_bind_addr etc
I'm not quite following this yet. Are you wanting a list of IP addresses that
map to RDMA devices?
- for HA scheme, an app want to resolve the
Is my understanding of the mechanisms correct? Since locking and unlocking of
data receiving buffers is a standard use case in most transport strategies, I
wanted to ask if there's a more elegant way to manage this using the Infiniband
architecture? Like for example delaying the sender side work
Rick Frank who brought this to my attention, also handed me this patch
which is claimed to workaround this issue, its badly formatted and I
couldn't really understand what it does. I hoped to be able and reproduce
this with rping or ucmatose, but neither allow me to specify a -I address
to the
Assuming this is an rdma-cm capable device in a 'bad' state, the user
space application can wait for asyn ibv events (PORT_ACTIVE) from the
device. Once the device is active again it can retry the rdma_create_qp
or rdma_join_mc.
Will this work? Even once the port goes active, what the
@@ -2167,6 +2170,12 @@ static int cma_sidr_rep_handler(struct i
event.status = ib_event-param.sidr_rep_rcvd.status;
break;
}
+ ret = cma_set_qkey(id_priv);
+ if (ret) {
+ event.event =
It might be better to catch errors earlier, but there is the risk that the
flow might change somehow, and losing the (now obvious) logical connection
between retrieving the qkey and actually using it.
I can go with that. I don't have a strong preference. Have you tested the
patch and verified
yos...@voltaire.com
Acked-by: Sean Hefty sean.he...@intel.com
---
Roland, any objection to queuing this for 2.6.30?
drivers/infiniband/core/cma.c | 41 +++--
1 file changed, 27 insertions(+), 14 deletions(-)
Index: b/drivers/infiniband/core/cma.c
So, why is it necessary for a ULP like RDS to implement its own flow
control? It looks like IB's flow control should result in no RNR
retries, yet without protocol-level FC, we see RNR retries.
If you're using a shared receive queue, end to end flow control is disabled.
Also, see 9.7.7.2.5 C9-162
I'm reading C9-162 and still not seeing why (according to the spec
anyways) there should ever be RNR retries on a connection. I would think
the receiving HCA would not credit its last WQE to the sender, and thus
retries should never happen?
The whole point of this feature is to eliminate RNR
ucmatose doesn't do anything with the address provided with the -b param on its
--active-- side, where this problem takes place.
It passes the address into rdma_resolve_addr() as the source address, which
results in binding to that address.
- Sean
___
Assuming WinOF already has libibumad implementation with preserved API
would it be reasonable to switch from vendor-ibal to vendor-ibumad in
WinOF?
WinOF does have a libibumad implementation, plus libibmad ports between the two
platforms. The saquery code needs structure definitions for the
I don't see that my original post ever went out.
Ulp\libibmad\include\infiniband\mad.h
Added MAD_EXPORT for xdump smp_query_via needed by ibtracert ibroute.
Changes to libibmad need to go through the management.git tree. The mirror in
SVN will be replaced with all upstream code.
Signed off
Changes to libibmad need to go through the management.git tree. The
mirror in SVN will be replaced with all upstream code.
Yes I understand this.
The note was to inform you that changes need to be pushed back to the git tree.
I am asking that all changes be submitted through to the main git
sas...@voltaire.com
---
On 15:55 Mon 09 Feb , Sean Hefty wrote:
Changing saquery didn't
look that hard to me, but it did look like it would modify a fair portion of
the
code.
Cannot resist... :)
Excellent! - thanks Sasha! It even reduced the codebase too.
- Sean
Did you had the chance to look into that?
Not yet - but should be able to look into it by the end of the week. From what
Jason said, it sounds like ip_dev_find() doesn't behave like I was expecting.
- Sean
___
general mailing list
With RDS-level flow control enabled, RDS attempts to set rnr_counter to
0 on an already connected QP by transitioning through SQD state. SQD is
not supported on ConnectX, and so we either need do it the right way or
make other plans.
Can this be set to 0 when connecting?
- Sean
It seems that even when the rdma-cm consumer binds to a specific
address,
the rdma-cm address resolution code follows the order of the
devices/rules
in routing table. So the user can't really dictate an outgoing interface
based on the src address provided to
I noticed the following in ibdiag_common.h:
#define DEBUG if (ibdebug || ibverbose) IBWARN
#define VERBOSE if (ibdebug || ibverbose 1) IBWARN
This allows for else statements to mismatch when defined.
- Sean
___
general mailing list
Allow sminfo to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Would there be any objection to including
From: Stan Smith stan.sm...@intel.com
ibtracert and ibroute need xdump and smp_query_via exported
from the library. Add MAD_EXPORT to the calls for Windows support.
Signed-off-by: Stan Smith stan.sm...@intel.com
Signed-off-by: Sean Hefty sean.he...@intel.com
---
libibmad/include/infiniband
I wasn't sure if you actually run the whole test or just let rdma_bind
to be called and see the above. Anyway, if you send me a patch with
the prints you've added, I can repeat it in my setup and we'll see.
I let ucmatose run successfully. It's kind of a hassel for me to generate a
patch for
diff --git a/infiniband-diags/src/ibdiag_common.c b/infiniband-
diags/src/ibdiag_common.c
index bda1efa..154e00c 100644
--- a/infiniband-diags/src/ibdiag_common.c
+++ b/infiniband-diags/src/ibdiag_common.c
@@ -43,15 +43,14 @@
#include stdlib.h
#include stdarg.h
#include sys/types.h
-#include
Modify the openib_scm provider to support both OFED and WinOF releases.
This takes advantage of having a libibverbs compatibility library.*
Signed-off-by: Sean Hefty sean.he...@intel.com
---
* If only there were a sockets compatility layer... gurgle
This is only build tested for windows, but does
+#include ibdiag_osd.h
I think it'll be easier to just put this include in ibdiag_common.h...
What about to add files inttypes.h and unistd.h in winof tree? It could
be wrapper similars to ibdiag_osd.h.
That could be done. The files would just be empty. As a thought, if you think
of the
Would there be any objection to including the windows source files (.c and
.h)
in the mgmt tree?
Which files? Basically I prefer to not have unrelated things in my tree,
but let's see specific needs.
So far, I have windows/ibdiag_osd.h, ibdiag_windows.c, and
windows/cl_nodenamemap.h.
My goal
What about to add files inttypes.h and unistd.h in winof tree? It could
be wrapper similars to ibdiag_osd.h.
One advantage of using your approach is that the source files end up only
including those headers that it needs. Moving everything into ibdiag_osd.h
means that the source files pick up
Isn't cl_nodenamemap.h part of complib?
It's not available in windows. (Yes, sadly, even the OS abstraction code
doesn't share a common codebase between the two platforms...) I'm not even sure
nodenamemap is really at the same level of abstraction as other complib items,
but I didn't want to
static const struct ibdiag_opt *opts_map[256];
and later:
memset(opts_map, 0, sizeof(opts_map));
With the above:
warnings in directory c:\mshefty\scm\winof\branches\winverbs\tools\infiniband-di
ags\src\sminfo
static const struct ibdiag_opt *opts_map[256];
and later:
memset(opts_map, 0, sizeof(opts_map));
And on second thought... can we just drop the memset completely?
___
general mailing list
general@lists.openfabrics.org
to the WinOF tree that touch areas outside of
the tools/infiniband-diags directly separate to the ofw mail list.
Signed-off-by: Sean Hefty sean.he...@intel.com
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin
Allow sminfo to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Note: all patches are also available
Allow vendstat to build and run on both Linux and Windows. Window
build files are maintained in the WinOF repository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/vendstat.c |2
Allow ibaddr to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/ibaddr.c |2
Allow perfquery to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/perfquery.c
Allow ibportstate to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/ibportstate.c
Allow ibstat to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Patch is also attached. Given the lengths
Allow smpdump to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/smpdump.c |8
Allow smpquery to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/smpquery.c |8
Allow ibping to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
For portability, use complib to obtain time stamps.
Signed-off-by: Sean Hefty sean.he
signal(SIGINT, report);
signal(SIGTERM, report);
Btw - I worked around adding cdecl before main by disabling the warning. Since
main must be cdecl by default, the compiler fixes it, but spits out a warning.
For some reason unknown to me, the warning only occurs when building 32-bit
type all void *ibmad_port and void *srcport with struct ibmad_port *
Create new mad_rpc_portid(struct ibmad_port *srcport) function
which mirrors madrpc_portid(void)
If you're planning on having someone use the new functions, they need to have
MAD_EXPORT added in front of them.
+ srcport = mad_rpc_open_port(ibd_ca, ibd_ca_port, mgmt_classes, 3);
+ if (!srcport)
+ IBERROR(Failed to open '%s' port '%d', ibd_ca, ibd_ca_port);
+
+ mad_rpc_close_port(srcport);
exit(0);
need MAD_EXPORT
___
- if (ib_resolve_portid_str(portid, argv[0], ibd_dest_type, ibd_sm_id)
0)
+ if (ib_resolve_portid_str_via(portid, argv[0], ibd_dest_type,
+ ibd_sm_id, srcport) 0)
needs MAD_EXPORT
- if (ib_resolve_self(selfportid,
- return 0;
+ goto Exit;
}
desc = smp-data;
@@ -301,5 +301,8 @@ int main(int argc, char *argv[])
putchar('\n');
if (smp-status)
fprintf(stdout, SMP status: 0x%x\n, ntohs(smp-status));
+
+Exit:
nit: can we use all lowercase
MAD_EXPORT int madrpc_portid(void);
-MAD_EXPORT int madrpc_set_retries(int retries);
-MAD_EXPORT int madrpc_set_timeout(int timeout);
I thought initially we weren't going to remove APIs but move over to
the new ones ? A subsequent step would be to deprecate the old APIs
and then eventually
#include infiniband/umad.h
#include infiniband/mad.h
-#include infiniband/complib/cl_nodenamemap.h
+#include complib/cl_nodenamemap.h
Is it needed? Rest tools use similar path with leading 'infiniband'.
That directory path doesn't exist in Windows. I think this makes sense.
Complib is a
Guess it is about report() function. Why to not make everything cdecl
(by using compiler/linker flag or some super-#pragma in config.h or so)?
The WDK build environment uses stdcall by default. Visual Studio uses cdecl. I
have not yet figured out how to override the WDK using stdcall. Simply
Allow smpquery to build and run on both Linux and Windows. Window
build files are maintained in the WinOF respository. These changes
allow dropping the infiniband-diags into the WinOF build environment.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
changes from v1: declared variables
This series adds support to all remaining IB diagnostics utilities,
except saquery.
Signed-off-by: Sean Hefty sean.he...@intel.com
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
Mainly fixing datatypes to avoid type mismatches.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Also attaching patch in case my mailer wraps the lines.
infiniband-diags/src/grouping.c | 28 ++--
infiniband-diags/src/ibnetdiscover.c |8
2 files
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/ibroute.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/infiniband-diags/src/ibroute.c b/infiniband-diags/src/ibroute.c
index 144d1b2..d1049ad 100644
--- a/infiniband-diags/src/ibroute.c
+++ b
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/ibtracert.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/infiniband-diags/src/ibtracert.c b/infiniband-diags/src/ibtracert.c
index ea5662b..db3b906 100644
--- a/infiniband-diags/src
Use char* pointers to obtain offsets, in place of void*.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/ibsysstat.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/infiniband-diags/src/ibsysstat.c b/infiniband-diags/src/ibsysstat.c
index
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/ibsendtrap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/infiniband-diags/src/ibsendtrap.c
b/infiniband-diags/src/ibsendtrap.c
index ba6aa8b..ba6f86a 100644
--- a/infiniband-diags/src
Fix some typecasts and variable argument function macro definitions
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/mcm_rereg_test.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/infiniband-diags/src/mcm_rereg_test.c
b
Add typecasts and modify include path.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Update from v1: need casts from int to uint16. One of the include files in
the winof tree disables certain build warnings for the callers convenience...
infiniband-diags/src/ibsendtrap.c |6 +++---
1
saquery calls getpass, and according to the man page:
'This function is obsolete. Do not use it.'
Can we remove this call? What is your preference for replacing it? (Use scanf?
take the SM Key as a command line argument?)
___
general mailing list
There was a thread on this back in June 2008:
http://lists.openfabrics.org/pipermail/general/2008-June/051057.html
Sasha wrote:
glibc info page doesn't indicate this. Also I did some
googling and looked at glibc code itself - found nothing suspicious yet.
Finally it is how password handled in
A lot of type casting with include fix-ups. Luckily, because
the macro CHECK_AND_SET_VAL() was added, I could add type casts
into the macro and avoid sprinkling even more throughout the code.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/saquery.c | 80
handle_outgoing_dr_smp() can queue a struct ib_mad_local_private *local
on the mad_agent_priv-local_work work queue with
local-mad_priv == NULL if device-process_mad() returns
IB_MAD_RESULT_SUCCESS | IB_MAD_RESULT_REPLY and
(!ib_response_mad(mad_priv-mad.mad) ||
...@qlogic.com
Good catch.
Acked-by: Sean Hefty sean.he...@intel.com
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib
+MAD_EXPORT uint8_t *port_performance_xmt_sl_query(void *rcvbuf, ib_portid_t *
dest,
+ int port, unsigned timeout);
+MAD_EXPORT uint8_t *port_performance_rcv_sl_query(void *rcvbuf, ib_portid_t *
dest,
+ int
I'll give your 2 patches a try. Is there a way that you can enable type
mismatch warnings? If so, that would probably show the same issues.
- Sean
___
general mailing list
general@lists.openfabrics.org
Both of your patches (ibnetdiscover and ibroute) build on winof. I replaced my
2 patches with yours, updated to the latest codebase, and pushed everything:
git://git.openfabrics.org/~shefty/ib-mgmt.git master
Were there changes to the other patches that you wanted (including saquery,
which
Sean: For this purpose casting to (char *) is somewhat sketchy, it
should be (uint8_t *).. char should only ever be used for strings due
to possible troubles with environments using 16 bit chars for wide
character support.
I'm not aware of any environments that define char as anything other than
@@ -1027,7 +1034,7 @@ static int query_path_records(const struct query_cmd
*q, bind_handle_t h,
CHECK_AND_SET_VAL(p-dlid, 16, 0, pr.dlid, PR, DLID);
CHECK_AND_SET_VAL(p-hop_limit, 32, -1, pr.hop_flow_raw, PR, HOPLIMIT);
CHECK_AND_SET_VAL(p-flow_label, 8, 0, flow, PR, FLOWLABEL);
Signed-off-by: Sean Hefty sean.he...@intel.com
---
changes from v1: change (char *) casts to (uint8_t *)
infiniband-diags/src/ibsysstat.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/infiniband-diags/src/ibsysstat.c b/infiniband-diags/src/ibsysstat.c
index
port_num is incorrectly set instead of block_num
Signed-off-by: Sean Hefty sean.he...@intel.com
---
I will resubmit the changes for saquery to support winof. I must have done
something wrong with my testing on that patch on linux, since I'm seeing
build warnings now.
infiniband-diags/src
Signed-off-by: Sean Hefty sean.he...@intel.com
---
Ok - that was quicker than I thought it would be... this patch depends on
saquery: set correct pkey table field.
changes from v1:
- use (uint8_t *) casts over (char *) casts
- change initialization of zero_gid to use memset
- modify
There is a potential race in ib_register_mad_agent() where the struct
ib_mad_agent_private is not fully initialized before it is added
to the list of agents per IB port. This means the ib_mad_agent_private
could be seen before the refcount, spin locks, and linked lists
are initialized. The fix is
Sasha,
I'd like to see about doing 'something' with nodenamemap. Currently, it's part
of complib, but the interfaces and operation are not similar to other complib
type abstractions.
From what I can tell, nodenamemap performs two abstractions. At a lower level,
it implements functionality
portnum index should go from 0 to numports - 1. This fixes an
issue on WinOF where a bogus last port is displayed.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
infiniband-diags/src/ibstat.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/infiniband-diags/src
I am trying to resolve IPv6 addresses (that is, obtaining the MAC
address of the interface bearing the IP addresses). I am using
rdma_resolve_ip() defined in core/addr.c but I don't get consistent
results.
I get something like this:
fe80::202:c9ff:fe00:1341 dev eth1 FAILED
where I would expect
-for (portnum = 0; portnum = ca.numports; portnum++)
+for (portnum = 0; portnum ca.numports; portnum++)
port_dump(ca.ports[portnum], 0);
As expected on linux it shows only first port of two ports CA.
Correct - port_dump checks for NULL ports and returns. This patch does
Basically yes. But we need to find some acceptable solution first which
will be better than how it is implemented now.
One possibility is to link the calls directly. This is the same as calls in
ibdiag_common.c. Functions like ibdiag_process_opts() are used in more places
than cl_nodenamemap,
Do you mean via a static library? Since the calls are used in 2 packages
opensm and infiniband-diags, you will have to have a library somewhere to
preserve building the packages separately; as RedHat and we do.
ibdiags can build and use it like ibdiag_common.c. (Add to libcommon, which
gets
Would you reconsider moving the tcp/rdma port unification changes up
into librdmacm? The benefit is that this will resolve the issue in a
manner that can flow into the distros and not affect the linux kernel.
So librdmacm could, if configured to support this, just allocate and
bind a user socket
We clearly don't want to introduce OpenSM - infiniband-diags dependency
- OpenSM now is distributable as separate tarball.
I'm not suggesting adding a dependency. I'm saying:
1. complib should be completely independent of Infiniband management on Linux.
Having it tightly coupled with the Linux
The idea was to make sure that any formatting changes to the config file would
be consistent between opensm and the diags. So far this has not happened.
However, IMHO I think it would be a step backward to have the code in 2
places.
I'm not sure we need to maintain duplicate code. I view that
Shall I post a patch for comments?
I think that would be the best way forward.
I've been trying to run through different use case scenarios in my head to see
if there is any security or other issue with this approach. From the kernel's
perspective, it seems like this adds some sort of trust
As for enabling this always on librdmacm, this can't work - since it will break
IB user space app that attempts to open two listeners:
I thought about that, but didn't know whether it was in use. I agree that
existing apps shouldn't break. (I was thinking more along the lines of adding a
new
Have you ever considered to push the madeye module (below)
into the kernel to ease with fabric debugging? I have tested
it now against Linus tree and it works fine.
I hadn't really thought about it, but I don't have any objection to someone
submitting it. There may be a better way of doing this
+#if 1
+ mad_rpc_close_port(srcport);
+#else
umad_unregister(port, agent);
umad_close_port(port);
umad_done();
+#endif
Why use #if 1 here? Why not just replace the umad calls with
mad_rpc_close_port?
Just consistency with what's been done in other places in that
Or maybe map PS_TCP port space to the be the unified space, and have a
new PS_RDMA or PS_IB port space that doesn't?
Hmm... I like this concept if a userspace work-around is needed.
___
general mailing list
general@lists.openfabrics.org
There has been enough interface changes to warrant a new version.
If we're bumping the version anyway, is what's there now for retries/timeouts
the best thing longer term? (I haven't tracked each change in detail, so I
don't know.)
- Sean
___
Someone made the decision to want to be able to switch back and forth
earlier. This should be directed to them. It's certainly easy to
eliminate the old code.
I'm wasn't suggesting that you fix the existing code, just not add to it.
If someone wants to be able to switch back and forth, it makes
Yes, exposing snooping capabilities to user space and writing a
user space app that does snooping sounds reasonable - what would
it take to expose this capability to user-space - will it fine
smoothly into the ib_umad and libibumad design/structure?
libibumad needs a way for the user to indicate
It's not a matter of relying on exit for open fds but rather the
allocated memory under the covers of mad_rpc_open_port so no longer
can one rely on just exit and this needs to be made explicit.
The OS should reclaim any allocated memory not freed by the app when it exits.
Is this your concern?
this knowingly breaks the windows build...
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
So what do you suggest?
Changing the WinOF build environment is something that could be brought up in
Sonoma, if there will be enough representatives there. Alternatively, WinOF
schedules regular con-calls.
Ira replied that he has no problems with it.
I remember Ira stating that he couldn't
I do have urgent time-sensitive traffic, and non-urgent traffic.
The urgent traffic and the non-urgent traffic is generated from different
hosts.
I would like to differentiate them by using different SL, then configure QoS to
give maximum priority to the urgent time-sensitive
traffic, and minimum
601 - 700 of 793 matches
Mail list logo
