[PATCH opensm] osm_console_io.c: Handle another write-strings issue
From: Ira Weiny ira.we...@intel.com
hosts_ctl declaration is:
int hosts_ctl(daemon, client_name, client_addr, client_user);
char *daemon;
char *client_name;
char *client_addr;
char *client_user;
This should have been part of previous commit
664494a8157684f2f277fb457556a7c27feae0af
Fix issues causing const warnings for strings
Signed-off-by: Ira Weiny ira.we...@intel.com
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
diff --git a/opensm/osm_console_io.c b/opensm/osm_console_io.c
index 167562c..18bd5ef 100644
--- a/opensm/osm_console_io.c
+++ b/opensm/osm_console_io.c
@@ -164,8 +164,8 @@ int is_authorized(osm_console_t * p_oct)
{
/* allowed to use the console? */
p_oct-authorized = !is_remote(p_oct-client_type) ||
- hosts_ctl(OSM_DAEMON_NAME, p_oct-client_hn, p_oct-client_ip,
- STRING_UNKNOWN);
+ hosts_ctl((char *)OSM_DAEMON_NAME, p_oct-client_hn,
p_oct-client_ip,
+ (char *)STRING_UNKNOWN);
return p_oct-authorized;
}
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH opensm] osm_lid_mgr.c: fix duplicate LID assignment after SM port down
From: Alex Netes ale...@mellanox.com
We must discard previous guid2lid db if this is the first master sweep and
reassign_lids option is TRUE.
If we came out of standby and honor_guid2lid_file option is TRUE, we must
restore guid2lid db. Otherwise if honor_guid2lid_file option is FALSE we must
discard previous guid2lid db.
Signed-off-by: Alex Netes ale...@mellanox.com
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
opensm/osm_lid_mgr.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/opensm/osm_lid_mgr.c b/opensm/osm_lid_mgr.c
index f92084a..4289424 100644
--- a/opensm/osm_lid_mgr.c
+++ b/opensm/osm_lid_mgr.c
@@ -302,11 +302,17 @@ static int lid_mgr_init_sweep(IN osm_lid_mgr_t * p_mgr)
lmc_mask = ~((1 p_mgr-p_subn-opt.lmc) - 1);
- /* if we came out of standby we need to discard any previous guid2lid
- info we might have.
- Do this only if the honor_guid2lid_file option is FALSE. If not, then
- need to honor this file. */
- if (p_mgr-p_subn-coming_out_of_standby == TRUE) {
+ /* We must discard previous guid2lid db if this is the first master
+* sweep and reassign_lids option is TRUE.
+* If we came out of standby and honor_guid2lid_file option is TRUE, we
+* must restore guid2lid db. Otherwise if honor_guid2lid_file option is
+* FALSE we must discard previous guid2lid db.
+*/
+ if (p_mgr-p_subn-first_time_master_sweep == TRUE
+ p_mgr-p_subn-opt.reassign_lids == TRUE) {
+ osm_db_clear(p_mgr-p_g2l);
+ memset(p_mgr-used_lids, 0, sizeof(p_mgr-used_lids));
+ } else if (p_mgr-p_subn-coming_out_of_standby == TRUE) {
osm_db_clear(p_mgr-p_g2l);
memset(p_mgr-used_lids, 0, sizeof(p_mgr-used_lids));
if (p_mgr-p_subn-opt.honor_guid2lid_file == FALSE)
--
1.7.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V4 for-next 1/5] IB/core: Add RSS and TSS QP groups
I have no issue with RSS/TSS. But the 'qp group' interface to using this seems kludgy. lets try to be more specific On a node, this is multiple send/receive queues grouped together to form a larger construct. On the wire, this is a single QP - maybe? I'm still not clear on that. From what's written, all the send queues appear as a single QPN. The receive queues appear as different QPNs. Starting with RSS QP groups: its a group made of one parent QP and N RSS child QPs. On the wire everything is sent to the RSS parent QP, however, when the HW receives a packet for which this QP/QPN is the destination, it applies a hash function on the packet header and subject to the hash result dispatches the packet to one of the N child QPs. I'm not trying to be facetious here, but a QP is a 'pair' of queues - one send, one receive. The construct that you're talking about is a collection of send and/or receive queues, all addressed using the same transport level value. I don't see where or why there's a parent-child relationship between queues, either from the perspective of the user or the remote endpoint. The transport level address happens to be called a QPN, but that's just a misnomer. The design applies for IB UD QPs and Raw Ethernet Packet QP types, under IB the QPN of the parent is on the wire, under Eth, there are no QPNs on the wire, but that HW has some steering rule which makes certain packets to be steered to that RSS parent, and the RSS parent in turn further does dispatching decision (hashing) to determine which of the child RSS QPs will actually receive that packet. The current implementation only applies to UD QPs, but I don't see why the concept can't apply to UC or RC. In my mind, a QP is really a special case of the RSS/TSS construct. With IPoIB, the remote side is provided with the RSS parent QPN as part of the IPoIB HW address provided in the ARP reply payload, so packets are sent to that QPN. With RAW Packet Eth QPs, the remote side isn't aware to QPNs at all, all goes through a steering rule who is directing to the RSS parent. You can send packets over RSS packet QP but not receive packets. So for RSS, the remote side isn't aware to that QP group @ all. Makes sense? As for TSS QP groups, basically generally speaking, the only case that really matters are applications/drivers that care for the source QPN of a packet. but lets get there after hopefully agreeing what is RSS QP group. So far, this is what I think it is: - a collection of related receive queues - each queue is configured somewhat separately - i.e. sized, CQ, sge size, etc. - receives are posted to the queues separately - the queues are allocated together This is where it gets confusing. They're allocated together, but through separate API calls. I'm not sure if they share states or not. Can all of them but one go into the error state and still receive data? Do packets get routed to whichever queue actually works, or do packets sometimes get dropped, but sometimes don't, depending on some local rules which have been programmed into the HCA? Can the queues really be destroyed independently? Is it even necessary to treat the receive queues as being independent? What happens if they're allocated, destroyed, and modified as a single entity? We don't treat send and receive queues that belong as part of a single queue 'pair' as having completely separate states. - Sean -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mellanox/RoCE - VLAN support
Hi all, we are doing a project on IBM x-blades using Mellanox/RoCE. I have some difficulties to get RoCE based VLANs to run. We are currently on Linux 3.8. No OFED material involved. While non-VLAN devices work ok, i experience the following on VLAN devs - a GID for the VLAN is created and we use the proper index for gid source addr. - a ping on the VLAN-device runs ok - rdma/roce traffic fails in that the sender overruns the send retry count. In terms of Mellanox driver level, what gives us Linux 3.8? Are we at most current driver level? And do we have to take special setup for VLAN, i.e. special MLX4 module parms, or special qp parameters to get this going? Any help on this is very much appreciated. Kind regards Klaus Wacker IBM Systems Technology Group, Systems Software Development SW Linux on System z Dev Service Phone: +49-7031-16-3779 IBM Deutschland E-Mail: kdwac...@de.ibm.com Schoenaicher Str. 220 71032 Boeblingen Germany IBM Deutschland Research Development GmbH / Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: iwarp and inline data
Intel NE020 supports send with inline data as well. -Original Message- From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Steve Wise Sent: Thursday, April 11, 2013 1:11 PM To: Hefty, Sean Cc: linux-rdma (linux-rdma@vger.kernel.org) Subject: Re: iwarp and inline data On 4/11/2013 12:31 PM, Hefty, Sean wrote: Does anyone know if the current iwarp adapters support inline sends? -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Chelsio's do. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 for-next 1/5] IB/core: Add RSS and TSS QP groups
On Thu, Apr 11, 2013 at 5:45 PM, Hefty, Sean sean.he...@intel.com wrote: [...] but lets get there after hopefully agreeing what is RSS QP group. So far, this is what I think it is: - a collection of related receive queues - each queue is configured somewhat separately - i.e. sized, CQ, sge size, etc. - receives are posted to the queues separately - the queues are allocated together This is where it gets confusing. They're allocated together, but through separate API calls. I'm not sure if they share states or not. Can all of them but one go into the error state and still receive data? Do packets get routed to whichever queue actually works, or do packets sometimes get dropped, but sometimes don't, depending on some local rules which have been programmed into the HCA? Can the queues really be destroyed independently? We only require (== implemented that) for the verbs level to mandate for the RSS parent not to be destroyed before ANY of the RSS childs is destroyed and be placed to action only after ALL RSS childs are created. The queues (RSS childs can be destroyed independently after the parent is destroyed, yes. RSS child QPs are plain UD or RAW Packet QPs that only have consecutive QPNs which is common requirement of HW for configuring the RSS parent which in networking is called the RSS indirection or dispatching QP. You can send and receive on them. If an RSS child goes to the error state it will not receive data. Packets are routed to RSS childs only per the hash function output, not per the state of that child. This design doesn't allow for an app to do DoS attack on the HW either if they try that out or just have a bug, but does require them to think out their code (design/review/test) - fair enough. RSS exists in almost any Ethernet NIC you take from the shelf, and works in the manner I explained here, e.g if one of the Ethernet RSS child queues isn't functional packets hashed to it will not be received Is it even necessary to treat the receive queues as being independent? What happens if they're allocated, destroyed, and modified as a single entity? [...] can you elaborate/explain the question a little more? Or. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mellanox/RoCE - VLAN support
Klaus Wacker klaus.wac...@de.ibm.com wrote: Hi all, we are doing a project on IBM x-blades using Mellanox/RoCE. I have some difficulties to get RoCE based VLANs to run. We are currently on Linux 3.8. No OFED material involved. While non-VLAN devices work ok, i experience the following on VLAN devs - a GID for the VLAN is created and we use the proper index for gid source addr. - a ping on the VLAN-device runs ok - rdma/roce traffic fails in that the sender overruns the send retry count. Do you have any evidence that the packets are actually crossing the switch? the way we debug RoCE connectivity issues is configuring port mirroring on the switch and capture the mirrored packets on the host where packets are mirrored, and feed them to wireshark (the official/latest versions support parsing of RoCE/IB packets), on that host you can also observe L2 mac/vlan header of the packets to see if it matches what you expected. But even before that, I would check the switch counters to see the packets aren't dropped. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
