IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017
Subsystems (4)
cover IB/hfi1, core, rdmavt: Driver fixes for 10/2/2017
Hi Doug,
There are a couple fixes in here that would have been nice to get into the RC cycle, including one marked stable. However I think you will find them to be too many LOC for an rc-4 submission so I have sent them in one series for-next. Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not really that important to the end user.
There are some clean ups in here from Don from the 16B changes. One takes care of some sparse warnings and the other two are from a WARN_ON_ONCE that needed special cased for OPA.
Patches can can also be found in my GitHub repo at:
https://github.com/ddalessa/kernel/tree/for-4.15
---
Don Hiatt (3):
IB/core: Use __be32 for LIDs in opa_is_extended_lid IB/core: Do not warn on lid conversions for OPA IB/hfi1: Do not warn on lid conversions for OPA
Jakub Byczkowski (1):
IB/hfi1: Add parsing for platform configuration format version 4
Michael J. Ruhl (1):
IB/hfi1: Fix incorrect available receive user context count
Mike Marciniszyn (1):
IB/hfi1: Fix output trace issues from 16B change
Sebastian Sanchez (2):
IB/hfi1: Prevent LNI out of sync by resetting host interface version IB/rdmavt: Correct issues with read-mostly and send size cache lines
drivers/infiniband/core/user_mad.c | 11 +++ drivers/infiniband/hw/hfi1/chip.c | 112 +++++++++++++++++++---------- drivers/infiniband/hw/hfi1/chip.h | 1 drivers/infiniband/hw/hfi1/firmware.c | 87 ++++++++++++++++++----- drivers/infiniband/hw/hfi1/hfi.h | 3 + drivers/infiniband/hw/hfi1/mad.c | 7 +- drivers/infiniband/hw/hfi1/sysfs.c | 2 - drivers/infiniband/hw/hfi1/trace_ibhdrs.h | 5 + drivers/infiniband/hw/hfi1/vnic_main.c | 7 +- include/rdma/opa_addr.h | 6 +- include/rdma/rdmavt_qp.h | 6 +- 11 files changed, 177 insertions(+), 70 deletions(-)
A message that is not in the archive (sent off-list or not yet received): 20171002180204.31117.12254.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org
PATCH 1/8 IB/hfi1: Add parsing for platform configuration format version 4
From: Jakub Byczkowski <[email protected]>
Platform configuration format version 4, that didn't use the file size field, is not parsed by the host driver. Only version 5 is supported. Add logic in parsing procedure to determine what format is being used and allow to read data from version 4 files.
--- drivers/infiniband/hw/hfi1/firmware.c | 24 ++++++++++++++++++++++-- 1 files changed, 22 insertions(+), 2 deletions(-)
drivers/infiniband/hw/hfi1/firmware.c +22 -2
@@ -113,6 +113,12 @@ struct css_header {#define MU_SIZE 8#define EXPONENT_SIZE 4 +/* size of platform configuration partition */ +#define MAX_PLATFORM_CONFIG_FILE_SIZE 4096 + +/* size of file of plaform configuration encoded in format version 4 */ +#define PLATFORM_CONFIG_FORMAT_4_FILE_SIZE 528 +/* the file itself */ struct firmware_file {struct css_header css_header;
@@ -1774,7 +1780,20 @@ int parse_platform_config(struct hfi1_devdata *dd)/* Field is file size in DWORDs */ file_length = (*ptr) *4 ; - ptr++; + +/* +* Length can't be larger than partition size. Assume platform +* config format version 4 is being used. Interpret the file size +* field as header instead by not moving the pointer. +*/ +if (file_length >MAX_PLATFORM_CONFIG_FILE_SIZE ) { +dd_dev_info (dd, +"%s:File length out of bounds, using alternative format\n" , + __func__); + file_length =PLATFORM_CONFIG_FORMAT_4_FILE_SIZE ; + }else { + ptr++; + }if (file_length > dd->platform_config.size) { dd_dev_info(dd, "%s:File claims to be larger than read size\n",
@@ -1789,7 +1808,8 @@ int parse_platform_config(struct hfi1_devdata *dd)/* * In both cases where we proceed, using the self-reported file length -* is the safer option +* is the safer option. In case of old format a predefined value is +* being used. */ while (ptr < (u32 *)(dd->platform_config.data + file_length)) { header1 = *ptr;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 2/8 IB/hfi1: Fix output trace issues from 16B change
In reply to a message not in the archiveFrom: Mike Marciniszyn <[email protected]>
The 16B changes to the output side of the header trace introduced two issues:
1. An uninitialized field "l4" for 9B packets
This field needs to be given a value of 0 for 9B packets to insure a correct 9B trace.
The fix adds a new define to insure that there is a dummy default for 9B packets to insure the correct string is decoded.
2. Use of entry vs. __entry in field references
--- drivers/infiniband/hw/hfi1/hfi.h | 1 + drivers/infiniband/hw/hfi1/trace_ibhdrs.h | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/infiniband/hw/hfi1/hfi.h +1 -0
@@ -390,6 +390,7 @@ struct hfi1_packet {/* * OPA 16B L2/L4 Encodings */ +#define OPA_16B_L4_9B 0x00#define OPA_16B_L2_TYPE 0x02#define OPA_16B_L4_IB_LOCAL 0x09#define OPA_16B_L4_IB_GLOBAL 0x0A
drivers/infiniband/hw/hfi1/trace_ibhdrs.h +3 -2
@@ -334,7 +334,7 @@ void hfi1_trace_parse_16b_hdr(struct hfi1_16b_header *hdr, &__entry->dlid, &__entry->slid); -if (entry->l4 ==OPA_16B_L4_IB_LOCAL ) +if (__entry->l4 ==OPA_16B_L4_IB_LOCAL ) ohdr = &opah->opah.u.oth;else ohdr = &opah->opah.u.l.oth;
@@ -348,6 +348,7 @@ void hfi1_trace_parse_16b_hdr(struct hfi1_16b_header *hdr, &__entry->psn, &__entry->qpn); }else { + __entry->l4 =OPA_16B_L4_9B ; hfi1_trace_parse_9b_hdr(&opah->ibh, sc5, &__entry->lnh, &__entry->lver,
@@ -356,7 +357,7 @@ void hfi1_trace_parse_16b_hdr(struct hfi1_16b_header *hdr, &__entry->len, &__entry->dlid, &__entry->slid); -if (entry->lnh ==HFI1_LRH_BTH ) +if (__entry->lnh ==HFI1_LRH_BTH ) ohdr = &opah->ibh.u.oth;else ohdr = &opah->ibh.u.l.oth;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 4/8 IB/hfi1: Prevent LNI out of sync by resetting host interface version
In reply to a message not in the archiveFrom: Sebastian Sanchez <[email protected]>
When the link is disabled and re-enabled, the host version bit is not set again, so the firmware behaves as though it’s interacting with an old driver. This causes LNI to get out of sync. The host version bit needs to be set at load_8051_firmware() and _dc_start(). Currently, it's only set at load_8051_firmware().
Create a common function to set the bit with the intent to make the code more maintainable in the future, set the host version bit at _dc_start() and modify the 8051 command API to prevent a deadlock as _dc_start() is already holding the dc8051 lock.
--- drivers/infiniband/hw/hfi1/chip.c | 77 +++++++++++++++++++++++---------- drivers/infiniband/hw/hfi1/chip.h | 1 drivers/infiniband/hw/hfi1/firmware.c | 63 ++++++++++++++++++++------- 3 files changed, 101 insertions(+), 40 deletions(-)
drivers/infiniband/hw/hfi1/chip.c +53 -24
@@ -6520,12 +6520,11 @@ static void _dc_start(struct hfi1_devdata *dd)if (!dd->dc_shutdown)return ; -/* Take the 8051 out of reset */ -write_csr (dd,DC_DC8051_CFG_RST ,0ull ); -/* Wait until 8051 is ready */ -if (wait_fm_ready (dd,TIMEOUT_8051_START )) -dd_dev_err (dd,"%s: timeout starting 8051 firmware\n" , - __func__); +/* +* Take the 8051 out of reset, wait until 8051 is ready, and set host +* version bit. +*/ +release_and_wait_ready_8051_firmware (dd);/* Take away reset for LCB and RX FPE (set in lcb_shutdown). */ write_csr (dd,DCC_CFG_RESET ,0x10 );
@@ -8595,30 +8594,23 @@ int write_lcb_csr(struct hfi1_devdata *dd, u32 addr, u64 data) }/* +* If the 8051 is in reset mode (dd->dc_shutdown == 1), this function +* will still continue executing. +* * Returns: * < 0 = Linux error, not able to get access * > 0 = 8051 command RETURN_CODE */ -static int do_8051_command ( -struct hfi1_devdata *dd, -u32 type, -u64 in_data, -u64 *out_data) +static int _do_8051_command (struct hfi1_devdata *dd,u32 type,u64 in_data, +u64 *out_data) {u64 reg, completed;int return_code;unsigned long timeout; +lockdep_assert_held (&dd->dc8051_lock);hfi1_cdbg (DC8051 ,"type %d, data 0x%012llx" , type, in_data); -mutex_lock (&dd->dc8051_lock); - -/* We can't send any commands to the 8051 if it's in reset */ -if (dd->dc_shutdown) { - return_code = -ENODEV ; - goto fail; - } -/* * If an 8051 host command timed out previously, then the 8051 is * stuck.
@@ -8719,6 +8711,29 @@ static int do_8051_command(write_csr (dd,DC_DC8051_CFG_HOST_CMD_0 ,0 ); fail: +return return_code; +} + +/* +* Returns: +* < 0 = Linux error, not able to get access +* > 0 = 8051 command RETURN_CODE +*/ +static int do_8051_command (struct hfi1_devdata *dd,u32 type,u64 in_data, +u64 *out_data) +{ +int return_code; + +mutex_lock (&dd->dc8051_lock); +/* We can't send any commands to the 8051 if it's in reset */ +if (dd->dc_shutdown) { + return_code = -ENODEV ; + goto fail; + } + + return_code =_do_8051_command (dd, type, in_data, out_data); + +fail:mutex_unlock (&dd->dc8051_lock);return return_code; }
@@ -8728,16 +8743,17 @@ static int set_physical_link_state(struct hfi1_devdata *dd, u64 state)return do_8051_command (dd,HCMD_CHANGE_PHY_STATE , state,NULL ); } -int load_8051_config (struct hfi1_devdata *dd,u8 field_id, -u8 lane_id,u32 config_data) +int _load_8051_config (struct hfi1_devdata *dd,u8 field_id, +u8 lane_id,u32 config_data) {u64 data;int ret; +lockdep_assert_held (&dd->dc8051_lock); data = (u64 )field_id <<LOAD_DATA_FIELD_ID_SHIFT | (u64 )lane_id <<LOAD_DATA_LANE_ID_SHIFT | (u64 )config_data <<LOAD_DATA_DATA_SHIFT ; - ret =do_8051_command (dd,HCMD_LOAD_CONFIG_DATA , data,NULL ); + ret =_do_8051_command (dd,HCMD_LOAD_CONFIG_DATA , data,NULL );if (ret !=HCMD_SUCCESS ) { dd_dev_err(dd, "load 8051 config: field id %d, lane %d, err %d\n",
@@ -8746,6 +8762,18 @@ int load_8051_config(struct hfi1_devdata *dd, u8 field_id,return ret; } +int load_8051_config (struct hfi1_devdata *dd,u8 field_id, +u8 lane_id,u32 config_data) +{ +int return_code; + +mutex_lock (&dd->dc8051_lock); + return_code =_load_8051_config (dd, field_id, lane_id, config_data); +mutex_unlock (&dd->dc8051_lock); + +return return_code; +} +/* * Read the 8051 firmware "registers". Use the RAM directly. Always * set the result, even on error.
@@ -8861,13 +8889,14 @@ int write_host_interface_version(struct hfi1_devdata *dd, u8 version)u32 frame;u32 mask; +lockdep_assert_held (&dd->dc8051_lock); mask = (HOST_INTERFACE_VERSION_MASK <<HOST_INTERFACE_VERSION_SHIFT );read_8051_config (dd,RESERVED_REGISTERS ,GENERAL_CONFIG , &frame);/* Clear, then set field */ frame &= ~mask; frame |= ((u32 )version <<HOST_INTERFACE_VERSION_SHIFT ); -return load_8051_config (dd,RESERVED_REGISTERS ,GENERAL_CONFIG , - frame); +return _load_8051_config (dd,RESERVED_REGISTERS ,GENERAL_CONFIG , + frame); } void read_misc_status(struct hfi1_devdata *dd, u8 *ver_major, u8 *ver_minor,
drivers/infiniband/hw/hfi1/chip.h +1 -0
@@ -710,6 +710,7 @@ void read_misc_status(struct hfi1_devdata *dd, u8 *ver_major, u8 *ver_minor, u8 *ver_patch);int write_host_interface_version (struct hfi1_devdata *dd,u8 version);void read_guid (struct hfi1_devdata *dd); +int release_and_wait_ready_8051_firmware (struct hfi1_devdata *dd);int wait_fm_ready (struct hfi1_devdata *dd,u32 mstimeout);void set_link_down_reason (struct hfi1_pportdata *ppd,u8 lcl_reason,u8 neigh_reason,u8 rem_reason);
drivers/infiniband/hw/hfi1/firmware.c +47 -16
84 lines not on this page · raw message
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 5/8 IB/core: Use __be32 for LIDs in opa_is_extended_lid
In reply to a message not in the archiveFrom: Don Hiatt <[email protected]>
The LIDs passed to opa_extended_lid are in __be32 format, change function signature accordingly.
This fixes the following sparse warnings:
drivers/infiniband/core/cm.c:1181:60: warning: incorrect type in
argument 1 (different ba
drivers/infiniband/core/cm.c:1182:60: warning: incorrect type in
argument 2 (different ba
drivers/infiniband/core/cm.c:1242:68: warning: incorrect type in
argument 1 (different ba
drivers/infiniband/core/cm.c:1243:68: warning: incorrect type in
argument 2 (different ba
drivers/infiniband/core/cm.c:2922:66: warning: incorrect type in
argument 1 (different ba
drivers/infiniband/core/cm.c:2923:66: warning: incorrect type in
argument 2 (different ba
include/rdma/opa_addr.h:102:14: warning: cast to restricted __be32
--- include/rdma/opa_addr.h | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
include/rdma/opa_addr.h +3 -3
@@ -97,15 +97,15 @@ static inline u32 opa_get_lid_from_gid(const union ib_gid *gid)* @dlid: The DLID * @slid: The SLID */ -static inline bool opa_is_extended_lid (u32 dlid,u32 slid) +static inline bool opa_is_extended_lid (__be32 dlid,__be32 slid) {if ((be32_to_cpu (dlid) >=be16_to_cpu (IB_MULTICAST_LID_BASE )) || (be32_to_cpu (slid) >=be16_to_cpu (IB_MULTICAST_LID_BASE )))return true; -else -return false; + +return false; }/* Get multicast lid base */
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171002180431.31117.33069.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org
Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid
Quoted 33 lines · Dennis Dalessandro
From: Don Hiatt <[email protected]>
The LIDs passed to
opa_extended_lidare in__be32format, change function signature accordingly.This fixes the following sparse warnings:
drivers/infiniband/core/cm.c:1181:60: warning: incorrect type in
argument 1 (different ba
drivers/infiniband/core/cm.c:1182:60: warning: incorrect type in
argument 2 (different ba
drivers/infiniband/core/cm.c:1242:68: warning: incorrect type in
argument 1 (different ba
drivers/infiniband/core/cm.c:1243:68: warning: incorrect type in
argument 2 (different ba
drivers/infiniband/core/cm.c:2922:66: warning: incorrect type in
argument 1 (different ba
drivers/infiniband/core/cm.c:2923:66: warning: incorrect type in
argument 2 (different ba
include/rdma/opa_addr.h:102:14: warning: cast to restricted__be32Fixes e92aa00a5189 ("IB/CM: Add OPA Path record support to CM")Reviewed-by Mike Marciniszyn <[email protected]>Signed-off-by Don Hiatt <[email protected]>Signed-off-by Dennis Dalessandro <[email protected]>--- include/rdma/opa_addr.h | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)include/rdma/opa_addr.h +0
-0
include/rdma/opa_addr.h static inline u32 opa_get_lid_from_gid(const union ib_gid *gid) · line 105
Quoted 10 lines
include/rdma/opa_addr.h +1
-1@@ -97,15 +97,15 @@ static inline u32 opa_get_lid_from_gid(const union ib_gid *gid)* @dlid: The DLID * @slid: The SLID */ -static inline bool opa_is_extended_lid (u32 dlid,u32 slid) +static inline bool opa_is_extended_lid (__be32 dlid,__be32 slid) {if ((be32_to_cpu (dlid) >=be16_to_cpu (IB_MULTICAST_LID_BASE )) || (be32_to_cpu (slid) >=be16_to_cpu (IB_MULTICAST_LID_BASE )))
You can drop be32_to_cpu and be16_to_cpu now.
The dlid is __be32 and IB_MULTICAST_LID_BASE is __be16. The direct comparison will work.
Quoted 13 lines
include/rdma/opa_addr.h +2
-3return true; - else - return false; + +return false; }/* Get multicast lid base */ --To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171003061657.GA13648-U/[email protected]
Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid
Quoted 11 lines · Leon Romanovsky
include/rdma/opa_addr.h static inline u32 opa_get_lid_from_gid(const union ib_gid *gid) · line 105
Quoted 7 lines
include/rdma/opa_addr.h +1
-1-static inline bool opa_is_extended_lid (u32 dlid,u32 slid) +static inline bool opa_is_extended_lid (__be32 dlid,__be32 slid) {if ((be32_to_cpu (dlid) >=be16_to_cpu (IB_MULTICAST_LID_BASE )) || (be32_to_cpu (slid) >=be16_to_cpu (IB_MULTICAST_LID_BASE )))You can drop
be32_to_cpuandbe16_to_cpunow.
The dlid is__be32andIB_MULTICAST_LID_BASEis__be16. The direct comparison will work.
It won't order properly for >=, the swap is still needed...
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171003160059.GB30753-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org
Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid
Quoted 14 lines · Jason Gunthorpe
Quoted 11 lines · Leon Romanovsky
include/rdma/opa_addr.h static inline u32 opa_get_lid_from_gid(const union ib_gid *gid) · line 105
Quoted 7 lines
include/rdma/opa_addr.h +1
-1-static inline bool opa_is_extended_lid (u32 dlid,u32 slid) +static inline bool opa_is_extended_lid (__be32 dlid,__be32 slid) {if ((be32_to_cpu (dlid) >=be16_to_cpu (IB_MULTICAST_LID_BASE )) || (be32_to_cpu (slid) >=be16_to_cpu (IB_MULTICAST_LID_BASE )))You can drop
be32_to_cpuandbe16_to_cpunow.
The dlid is__be32andIB_MULTICAST_LID_BASEis__be16. The direct comparison will work.
Quoted 1 line
It won't order properly for >=, the swap is still needed...
Jason,
Do you have reference for that?
I tried to find any information about comparison of values from one endianess on machine with another endianess and didn't find anything relevant.
Thanks
Quoted 6 lines
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171003170140.GD25829-U/[email protected]
RE: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Review
Quoted 4 lines
(quoted diff) +0
-0if ((be32_to_cpu(dlid) >= be16_to_cpu(IB_MULTICAST_LID_BASE)) || (be32_to_cpu(slid) >= be16_to_cpu(IB_MULTICAST_LID_BASE)))You can drop
be32_to_cpuandbe16_to_cpunow.
The dlid is__be32andIB_MULTICAST_LID_BASEis__be16. The direct comparison will work.
Quoted 8 lines
Quoted 1 line
It won't order properly for >=, the swap is still needed...
Jason,
Do you have reference for that?I tried to find any information about comparison of values from one endianess on machine with another endianess and didn't find anything relevant.
The bytes are out of order, so the comparisons won't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 1828884A29C6694DAF28B7E6B8A82373AB19A6C6-P5GAC/[email protected]
Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid
Quoted 11 lines · Sean
Quoted 11 lines
Quoted 10 lines
Quoted 8 lines
Review
Quoted 4 lines
(quoted diff) +0
-0if ((be32_to_cpu(dlid) >= be16_to_cpu(IB_MULTICAST_LID_BASE)) || (be32_to_cpu(slid) >= be16_to_cpu(IB_MULTICAST_LID_BASE)))You can drop
be32_to_cpuandbe16_to_cpunow.
The dlid is__be32andIB_MULTICAST_LID_BASEis__be16. The direct comparison will work.It won't order properly for >=, the swap is still needed...
Quoted 8 lines
Quoted 6 lines
Jason,
Do you have reference for that?I tried to find any information about comparison of values from one endianess on machine with another endianess and didn't find anything relevant.
The bytes are out of order, so the comparisons won't work.
I understand it for the "manual" comparison (C-like arrays), but does it apply for the compiler-aware comparison? Both these variables are marked as __be32 for the compiler.
Thanks
A message that is not in the archive (sent off-list or not yet received): 20171003180735.GE25829-U/[email protected]
Re: [PATCH for-next 5/8] IB/core: Use __be32 for LIDs in opa_is_extended_lid
Quoted 19 lines · Leon Romanovsky
Quoted 18 lines · Sean
Quoted 17 lines
Quoted 10 lines
Quoted 8 lines
Review
Quoted 4 lines
(quoted diff) +0
-0if ((be32_to_cpu(dlid) >= be16_to_cpu(IB_MULTICAST_LID_BASE)) || (be32_to_cpu(slid) >= be16_to_cpu(IB_MULTICAST_LID_BASE)))You can drop
be32_to_cpuandbe16_to_cpunow.
The dlid is__be32andIB_MULTICAST_LID_BASEis__be16. The direct comparison will work.It won't order properly for >=, the swap is still needed...
Jason,
Do you have reference for that?I tried to find any information about comparison of values from one endianess on machine with another endianess and didn't find anything relevant.
Quoted 5 lines
Quoted 1 line
The bytes are out of order, so the comparisons won't work.
I understand it for the "manual" comparison (C-like arrays), but does it apply for the compiler-aware comparison? Both these variables are marked as
__be32for the compiler.
OK, I finally found time to test my question and you and Jason are right. Thank you for your time.
For curious readers, the snippet below, tested on x86:
drivers/infiniband/hw/mlx5/main.c +9 -0
@@ -4754,6 +4754,15 @@ static int __init mlx5_ib_init(void) {int err; +uint32_t u1 =0x2233 ; +uint32_t u2 =0x4411 ; + +__be32 b1 =cpu_to_be32 (u1); +__be32 b2 =cpu_to_be32 (u2); + +printk (KERN_ERR "test: u1 %s u1\n" , (u1 < u2 ) ?"<" :">" ); +printk (KERN_ERR "test: b1 %s b1\n" , (b1 < b2 ) ?"<" :">" ); +mlx5_ib_odp_init (); err =mlx5_register_interface (&mlx5_ib_interface);
and the result:
[ 6.566979] test: u1 < u1 [ 6.567147] test: b1 > b1
Thanks
Quoted 2 lines
Thanks
PATCH 6/8 IB/rdmavt: Correct issues with read-mostly and send size cache lines
In reply to a message not in the archiveFrom: Sebastian Sanchez <[email protected]>
The s_ahgpsn was incorrectly placed in the read-mostly section of the QP and the s_curr_size and s_hdrwords are oversized. The misplaced s_ahgpsn will cause the read-mostly cachelines to thrash.
Place s_ahgpsn in the send side cache lines and correctly size and s_hdrwords and s_cur_size to keep the send side cachelines at the same size.
--- drivers/infiniband/hw/hfi1/chip.c | 4 ++-- include/rdma/rdmavt_qp.h | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-)
drivers/infiniband/hw/hfi1/chip.c +2 -2
@@ -8743,8 +8743,8 @@ static int set_physical_link_state(struct hfi1_devdata *dd, u64 state)return do_8051_command (dd,HCMD_CHANGE_PHY_STATE , state,NULL ); } -int _load_8051_config (struct hfi1_devdata *dd,u8 field_id, -u8 lane_id,u32 config_data) +static int _load_8051_config (struct hfi1_devdata *dd,u8 field_id, +u8 lane_id,u32 config_data) {u64 data;int ret;
include/rdma/rdmavt_qp.h +3 -3
@@ -282,7 +282,6 @@ struct rvt_qp {u32 remote_qpn;u32 qkey;/* QKEY for this QP (for UD or RD) */ u32 s_size;/* send work queue size */ -u32 s_ahgpsn;/* set to the psn in the copy of the header */ u16 pmtu;/* decoded from path_mtu */ u8 log_pmtu;/* shift for pmtu */
@@ -344,7 +343,6 @@ struct rvt_qp {struct rvt_swqe *s_wqe;struct rvt_sge_state s_sge;/* current send request data */ struct rvt_mregion *s_rdma_mr; -u32 s_cur_size;/* size of send packet in bytes */ u32 s_len;/* total length of s_sge */ u32 s_rdma_read_len;/* total length of s_rdma_read_sge */ u32 s_last_psn;/* last response PSN processed */
@@ -358,8 +356,10 @@ struct rvt_qp {u32 s_acked;/* last un-ACK'ed entry */ u32 s_last;/* last completed entry */ u32 s_lsn;/* limit sequence number (credit) */ -u16 s_hdrwords;/* size of s_hdr in 32 bit words */ +u32 s_ahgpsn;/* set to the psn in the copy of the header */ +u16 s_cur_size;/* size of send packet in bytes */ u16 s_rdma_ack_cnt; +u8 s_hdrwords;/* size of s_hdr in 32 bit words */ s8 s_ahgidx;u8 s_state;/* opcode of last packet sent */ u8 s_ack_state;/* opcode of packet to ACK */
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 7/8 IB/core: Do not warn on lid conversions for OPA
In reply to a message not in the archiveFrom: Don Hiatt <[email protected]>
On OPA devices the user_mad recv_handler can receive 32Bit LIDs (e.g. OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits of the LID as this information is obtained elsewhere. Do not issue a warning when calling ib_lid_be16() in this case by masking out the upper 16Bits.
[75667.310846] ------------[ cut here ]------------ [75667.316447] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 recv_handler+0x15a/0x170 [ib_umad] [75667.327640] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core] [75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1 [75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015 [75667.429555] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [75667.436360] task: ffff88084a718000 task.stack: ffffc9000a424000 [75667.443549] RIP: 0010:recv_handler+0x15a/0x170 [ib_umad] [75667.450090] RSP: 0018:ffffc9000a427ce8 EFLAGS: 00010286 [75667.456508] RAX: 00000000ffffffff RBX: ffff88085159ce80 RCX: 0000000000000000 [75667.465094] RDX: ffff88085a47b068 RSI: 0000000000000000 RDI: ffff88085159cf00 [75667.473668] RBP: ffffc9000a427d38 R08: 000000000001efc0 R09: ffff88085159ce80 [75667.482228] R10: ffff88085f007480 R11: ffff88084acf20e8 R12: ffff88085a47b020 [75667.490824] R13: ffff881056842e10 R14: ffff881056840200 R15: ffff88104c8d0800 [75667.499390] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000 [75667.509028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75667.516080] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0 [75667.524664] Call Trace: [75667.528044] ? find_mad_agent+0x7c/0x1b0 [ib_core] [75667.534031] ? ib_mark_mad_done+0x73/0xa0 [ib_core] [75667.540142] ib_mad_recv_done+0x423/0x9b0 [ib_core] [75667.546215] __ib_process_cq+0x5d/0xb0 [ib_core] [75667.552007] ib_cq_poll_work+0x20/0x60 [ib_core] [75667.557766] process_one_work+0x149/0x360 [75667.562844] worker_thread+0x4d/0x3c0 [75667.567529] kthread+0x109/0x140 [75667.571713] ? rescuer_thread+0x380/0x380 [75667.576775] ? kthread_park+0x60/0x60 [75667.581447] ret_from_fork+0x25/0x30 [75667.586014] Code: 43 4a 0f b6 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 c0 0f c8 89 43 5c e9 79 ff ff ff e8 16 4e fa e0 <0f> ff e9 42 ff ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 [75667.608323] ---[ end trace cf26df27c9597264 ]---
--- drivers/infiniband/core/user_mad.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-)
drivers/infiniband/core/user_mad.c +10 -1
@@ -229,7 +229,16 @@ static void recv_handler(struct ib_mad_agent *agent, packet->mad.hdr.status =0 ; packet->mad.hdr.length =hdr_size (file) + mad_recv_wc->mad_len; packet->mad.hdr.qpn =cpu_to_be32 (mad_recv_wc->wc->src_qp); - packet->mad.hdr.lid =ib_lid_be16 (mad_recv_wc->wc->slid); +/* +* On OPA devices it is okay to lose the upper 16 bits of LID as this +* information is obtained elsewhere. Mask off the upper 16 bits. +*/ +if (agent->device->port_immutable[agent->port_num].core_cap_flags & +RDMA_CORE_PORT_INTEL_OPA ) + packet->mad.hdr.lid =ib_lid_be16 (0xFFFF & + mad_recv_wc->wc->slid); +else + packet->mad.hdr.lid =ib_lid_be16 (mad_recv_wc->wc->slid); packet->mad.hdr.sl = mad_recv_wc->wc->sl; packet->mad.hdr.path_bits = mad_recv_wc->wc->dlid_path_bits; packet->mad.hdr.pkey_index = mad_recv_wc->wc->pkey_index;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171002180446.31117.56786.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org
Leon Romanovsky
Reviewed-byRe: [PATCH for-next 7/8] IB/core: Do not warn on lid conversions for OPA
Quoted 40 lines · Dennis Dalessandro
From: Don Hiatt <[email protected]>
On OPA devices the
user_madrecv_handlercan receive 32Bit LIDs (e.g.OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits of the LID as this information is obtained elsewhere. Do not issue a warning when callingib_lid_be16()in this case by masking out the upper 16Bits.[75667.310846] ------------[ cut here ]------------ [75667.316447] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 recv_handler+0x15a/0x170 [ib_umad] [75667.327640] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core] [75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1 [75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015 [75667.429555] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [75667.436360] task: ffff88084a718000 task.stack: ffffc9000a424000 [75667.443549] RIP: 0010:recv_handler+0x15a/0x170 [ib_umad] [75667.450090] RSP: 0018:ffffc9000a427ce8 EFLAGS: 00010286 [75667.456508] RAX: 00000000ffffffff RBX: ffff88085159ce80 RCX: 0000000000000000 [75667.465094] RDX: ffff88085a47b068 RSI: 0000000000000000 RDI: ffff88085159cf00 [75667.473668] RBP: ffffc9000a427d38 R08: 000000000001efc0 R09: ffff88085159ce80 [75667.482228] R10: ffff88085f007480 R11: ffff88084acf20e8 R12: ffff88085a47b020 [75667.490824] R13: ffff881056842e10 R14: ffff881056840200 R15: ffff88104c8d0800 [75667.499390] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000 [75667.509028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75667.516080] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0 [75667.524664] Call Trace: [75667.528044] ? find_mad_agent+0x7c/0x1b0 [ib_core] [75667.534031] ? ib_mark_mad_done+0x73/0xa0 [ib_core] [75667.540142] ib_mad_recv_done+0x423/0x9b0 [ib_core] [75667.546215] __ib_process_cq+0x5d/0xb0 [ib_core] [75667.552007] ib_cq_poll_work+0x20/0x60 [ib_core] [75667.557766] process_one_work+0x149/0x360 [75667.562844] worker_thread+0x4d/0x3c0 [75667.567529] kthread+0x109/0x140 [75667.571713] ? rescuer_thread+0x380/0x380 [75667.576775] ? kthread_park+0x60/0x60 [75667.581447] ret_from_fork+0x25/0x30 [75667.586014] Code: 43 4a 0f b6 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 c0 0f c8 89 43 5c e9 79 ff ff ff e8 16 4e fa e0 <0f> ff e9 42 ff ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 [75667.608323] ---[ end trace cf26df27c9597264 ]---
Quoted 7 lines
Fixes 62ede7779904 ("Add OPA extended LID support")Reviewed-by Mike Marciniszyn <[email protected]>Signed-off-by Don Hiatt <[email protected]>Signed-off-by Dennis Dalessandro <[email protected]>--- drivers/infiniband/core/user_mad.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-)
Thanks,
PATCH 8/8 IB/hfi1: Do not warn on lid conversions for OPA
In reply to a message not in the archiveFrom: Don Hiatt <[email protected]>
On OPA devices opa_local_smp_check will receive 32Bit LIDs when the LID is Extended. In such cases, it is okay to lose the upper 16 bits of the LID as this information is obtained elsewhere. Do not issue a warning when calling ib_lid_cpu16() in this case by masking out the upper 16Bits.
[75920.148985] ------------[ cut here ]------------ [75920.154651] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3788 hfi1_process_mad+0x1c1f/0x1c80 [hfi1] [75920.166192] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core] [75920.246331] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1 [75920.255907] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015 [75920.268158] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [75920.274934] task: ffff88084a718000 task.stack: ffffc9000a424000 [75920.282123] RIP: 0010:hfi1_process_mad+0x1c1f/0x1c80 [hfi1] [75920.288881] RSP: 0018:ffffc9000a427c38 EFLAGS: 00010206 [75920.295265] RAX: 0000000000010001 RBX: ffff8808361420e8 RCX: ffff880837811d80 [75920.303784] RDX: 0000000000000002 RSI: 0000000000007fff RDI: ffff880837811d80 [75920.312302] RBP: ffffc9000a427d38 R08: 0000000000000000 R09: ffff8808361420e8 [75920.320819] R10: ffff88083841f0e8 R11: ffffc9000a427da8 R12: 0000000000000001 [75920.329335] R13: ffff880837810000 R14: 0000000000000000 R15: ffff88084f1a4800 [75920.337849] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000 [75920.347450] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75920.354405] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0 [75920.362947] Call Trace: [75920.366257] ? ib_mad_recv_done+0x258/0x9b0 [ib_core] [75920.372457] ? ib_mad_recv_done+0x258/0x9b0 [ib_core] [75920.378652] ? __kmalloc+0x1df/0x210 [75920.383229] ib_mad_recv_done+0x305/0x9b0 [ib_core] [75920.389270] __ib_process_cq+0x5d/0xb0 [ib_core] [75920.395032] ib_cq_poll_work+0x20/0x60 [ib_core] [75920.400777] process_one_work+0x149/0x360 [75920.405836] worker_thread+0x4d/0x3c0 [75920.410505] kthread+0x109/0x140 [75920.414681] ? rescuer_thread+0x380/0x380 [75920.419731] ? kthread_park+0x60/0x60 [75920.424406] ret_from_fork+0x25/0x30 [75920.428972] Code: 4c 89 9d 58 ff ff ff 49 89 45 00 66 b8 00 02 49 89 45 08 e8 44 27 89 e0 4c 8b 9d 58 ff ff ff e9 d8 f6 ff ff 0f ff e9 55 e7 ff ff <0f> ff e9 3b e5 ff ff 0f ff 0f 1f 84 00 00 00 00 00 e9 4b e9 ff [75921.451269] ---[ end trace cf26df27c9597265 ]---
--- drivers/infiniband/hw/hfi1/mad.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
drivers/infiniband/hw/hfi1/mad.c +5 -2
@@ -4293,7 +4293,6 @@ static int opa_local_smp_check(struct hfi1_ibport *ibp, const struct ib_wc *in_wc) {struct hfi1_pportdata *ppd =ppd_from_ibp (ibp); -u16 slid =ib_lid_cpu16 (in_wc->slid);u16 pkey;if (in_wc->pkey_index >=ARRAY_SIZE (ppd->pkeys))
@@ -4320,7 +4319,11 @@ static int opa_local_smp_check(struct hfi1_ibport *ibp,*/ if (pkey ==LIM_MGMT_P_KEY || pkey ==FULL_MGMT_P_KEY )return 0 ; -ingress_pkey_table_fail (ppd, pkey, slid); +/* +* On OPA devices it is okay to lose the upper 16 bits of LID as this +* information is obtained elsewhere. Mask off the upper 16 bits. +*/ +ingress_pkey_table_fail (ppd, pkey,ib_lid_cpu16 (0xFFFF & in_wc->slid));return 1 ; }
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171002180453.31117.53379.stgit-9QXIwq+3FY+1XWohqUldA0EOCMrvLtNR@public.gmane.org
Leon Romanovsky
Reviewed-byRe: [PATCH for-next 8/8] IB/hfi1: Do not warn on lid conversions for OPA
Quoted 40 lines · Dennis Dalessandro
From: Don Hiatt <[email protected]>
On OPA devices
opa_local_smp_checkwill receive 32Bit LIDs when the LID is Extended. In such cases, it is okay to lose the upper 16 bits of the LID as this information is obtained elsewhere. Do not issue a warning when callingib_lid_cpu16()in this case by masking out the upper 16Bits.[75920.148985] ------------[ cut here ]------------ [75920.154651] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3788 hfi1_process_mad+0x1c1f/0x1c80 [hfi1] [75920.166192] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core] [75920.246331] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1 [75920.255907] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015 [75920.268158] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [75920.274934] task: ffff88084a718000 task.stack: ffffc9000a424000 [75920.282123] RIP: 0010:hfi1_process_mad+0x1c1f/0x1c80 [hfi1] [75920.288881] RSP: 0018:ffffc9000a427c38 EFLAGS: 00010206 [75920.295265] RAX: 0000000000010001 RBX: ffff8808361420e8 RCX: ffff880837811d80 [75920.303784] RDX: 0000000000000002 RSI: 0000000000007fff RDI: ffff880837811d80 [75920.312302] RBP: ffffc9000a427d38 R08: 0000000000000000 R09: ffff8808361420e8 [75920.320819] R10: ffff88083841f0e8 R11: ffffc9000a427da8 R12: 0000000000000001 [75920.329335] R13: ffff880837810000 R14: 0000000000000000 R15: ffff88084f1a4800 [75920.337849] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000 [75920.347450] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75920.354405] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0 [75920.362947] Call Trace: [75920.366257] ? ib_mad_recv_done+0x258/0x9b0 [ib_core] [75920.372457] ? ib_mad_recv_done+0x258/0x9b0 [ib_core] [75920.378652] ? __kmalloc+0x1df/0x210 [75920.383229] ib_mad_recv_done+0x305/0x9b0 [ib_core] [75920.389270] __ib_process_cq+0x5d/0xb0 [ib_core] [75920.395032] ib_cq_poll_work+0x20/0x60 [ib_core] [75920.400777] process_one_work+0x149/0x360 [75920.405836] worker_thread+0x4d/0x3c0 [75920.410505] kthread+0x109/0x140 [75920.414681] ? rescuer_thread+0x380/0x380 [75920.419731] ? kthread_park+0x60/0x60 [75920.424406] ret_from_fork+0x25/0x30 [75920.428972] Code: 4c 89 9d 58 ff ff ff 49 89 45 00 66 b8 00 02 49 89 45 08 e8 44 27 89 e0 4c 8b 9d 58 ff ff ff e9 d8 f6 ff ff 0f ff e9 55 e7 ff ff <0f> ff e9 3b e5 ff ff 0f ff 0f 1f 84 00 00 00 00 00 e9 4b e9 ff [75921.451269] ---[ end trace cf26df27c9597265 ]---
Quoted 8 lines
Fixes 62ede7779904 ("Add OPA extended LID support")Reviewed-by Mike Marciniszyn <[email protected]>Signed-off-by Don Hiatt <[email protected]>Signed-off-by Dennis Dalessandro <[email protected]>--- drivers/infiniband/hw/hfi1/mad.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
Thanks,
Quoted 11 lines · Dennis Dalessandro
Hi Doug,
There are a couple fixes in here that would have been nice to get into the RC
cycle, including one marked stable. However I think you will find them to be
too many LOC for an rc-4 submission so I have sent them in one series for-next.
Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not really that
important to the end user.
Quoted 8 lines
There are some clean ups in here from Don from the 16B changes. One takes care
of some sparse warnings and the other two are from aWARN_ON_ONCEthat needed
special cased for OPA.Patches can can also be found in my GitHub repo at:
https://github.com/ddalessa/kernel/tree/for-4.15
Hi Denny,
I didn't process that you mixed for-rc and for-next stuff in a single thread before I had gone through and looked at the patches and processed them. So, this time they all went to for-next. In the future, you really need patches you want in for-rc separate from the patches intended for for-next.
Anyway, applied. And 2 and 5 are the only ones I would have been likely to take to for-rc right now, and 2 isn't that important to the end user as you say, so that just leaves 5, and it's sparse warnings, so we'll just leave things as they are.
Signature · 8 lines
Doug Ledford <[email protected]> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 21 lines · Doug Ledford
Quoted 11 lines · Dennis Dalessandro
Hi Doug,
There are a couple fixes in here that would have been nice to get into the RC
cycle, including one marked stable. However I think you will find them to be
too many LOC for an rc-4 submission so I have sent them in one series for-next.
Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not really that
important to the end user.Quoted 8 lines
There are some clean ups in here from Don from the 16B changes. One takes care
of some sparse warnings and the other two are from aWARN_ON_ONCEthat needed
special cased for OPA.Patches can can also be found in my GitHub repo at:
https://github.com/ddalessa/kernel/tree/for-4.15
Quoted 7 lines
Hi Denny,
I didn't process that you mixed for-rc and for-next stuff in a single thread before I had gone through and looked at the patches and processed them. So, this time they all went to for-next. In the future, you really need patches you want in for-rc separate from the patches intended for for-next.
Maybe I wasn't too clear, I didn't intend any of those to go for-rc. So yep for-next was the right target.
I would have liked to get the fixes into -rc but they were just too complex for this late in the game is all I meant.
-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 30 lines · Dennis Dalessandro
Quoted 21 lines · Doug Ledford
Quoted 11 lines · Dennis Dalessandro
Hi Doug,
There are a couple fixes in here that would have been nice to get into the RC
cycle, including one marked stable. However I think you will find them to be
too many LOC for an rc-4 submission so I have sent them in one series for-next.
Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not really that
important to the end user.Quoted 8 lines
There are some clean ups in here from Don from the 16B changes. One takes care
of some sparse warnings and the other two are from aWARN_ON_ONCEthat needed
special cased for OPA.Patches can can also be found in my GitHub repo at:
https://github.com/ddalessa/kernel/tree/for-4.15Quoted 7 lines
Hi Denny,
I didn't process that you mixed for-rc and for-next stuff in a single thread before I had gone through and looked at the patches and processed them. So, this time they all went to for-next. In the future, you really need patches you want in for-rc separate from the patches intended for for-next.
Quoted 5 lines
Maybe I wasn't too clear, I didn't intend any of those to go for-rc. So yep for-next was the right target.
I would have liked to get the fixes into -rc but they were just too complex for this late in the game is all I meant.
IMHO, the number of LOCs shouldn't be the gating factor for -rc, but the severity of fixes yes.
Thanks
Quoted 6 lines
-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 31 lines · Leon Romanovsky
Quoted 30 lines · Dennis Dalessandro
Quoted 28 lines · Doug Ledford
Quoted 11 lines · Dennis Dalessandro
Hi Doug,
There are a couple fixes in here that would have been nice to get into the RC
cycle, including one marked stable. However I think you will find them to be
too many LOC for an rc-4 submission so I have sent them in one series for-next.
Patches 2,3,4 and 5 are the fixes. Patch 2 is small but it's not really that
important to the end user.Quoted 8 lines
There are some clean ups in here from Don from the 16B changes. One takes care
of some sparse warnings and the other two are from aWARN_ON_ONCEthat needed
special cased for OPA.Patches can can also be found in my GitHub repo at:
https://github.com/ddalessa/kernel/tree/for-4.15Hi Denny,
I didn't process that you mixed for-rc and for-next stuff in a single thread before I had gone through and looked at the patches and processed them. So, this time they all went to for-next. In the future, you really need patches you want in for-rc separate from the patches intended for for-next.
Quoted 8 lines
Quoted 5 lines
Maybe I wasn't too clear, I didn't intend any of those to go for-rc. So yep for-next was the right target.
I would have liked to get the fixes into -rc but they were just too complex for this late in the game is all I meant.
IMHO, the number of LOCs shouldn't be the gating factor for -rc, but the severity of fixes yes.
Not the gating factor necessarily, but a factor that has to be be weighed against the severity of the bug being fixed. As we get into later -rc cycles the bar for risk vs reward gets raised, not that there should be a limit of X LOC for -rc whatever it's more of an overall assessment of the risk of causing more harm than good.
-Denny
A message that is not in the archive (sent off-list or not yet received): 8601bdaa-53cc-e41f-95e6-483af90848b7-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
Quoted 5 lines · Dennis Dalessandro
Quoted 4 lines · Leon Romanovsky
Quoted 3 lines · Dennis Dalessandro
Maybe I wasn't too clear, I didn't intend any of those to go for-rc. So yep
for-next was the right target.
Ok.
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
I would have liked to get the fixes into -rc but they were just too complex
for this late in the game is all I meant.
Understood.
Quoted 8 lines
Quoted 2 lines
IMHO, the number of LOCs shouldn't be the gating factor for -rc, but the severity of fixes yes.
Not the gating factor necessarily, but a factor that has to be be weighed against the severity of the bug being fixed. As we get into later -rc cycles the bar for risk vs reward gets raised, not that there should be a limit of X LOC for -rc whatever it's more of an overall assessment of the risk of causing more harm than good.
Exactly. And given the rc stage we are at now, and the complexity of the fixes, you made the right call.
Signature · 3 lines
Doug Ledford <[email protected]> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
PATCH 3/8 IB/hfi1: Fix incorrect available receive user context count
In reply to Dennis DalessandroFrom: Michael J. Ruhl <[email protected]>
The addition of the VNIC contexts to num_rcv_contexts changes the meaning of the sysfs value nctxts from available user contexts, to user contexts + reserved VNIC contexts.
User applications that use nctxts are now broken.
Update the calculation so that VNIC contexts are used only if there are hardware contexts available, and do not silently affect nctxts.
Update code to use the calculated VNIC context number.
Update the sysfs value nctxts to be available user contexts only.
--- drivers/infiniband/hw/hfi1/chip.c | 35 +++++++++++++++++++------------- drivers/infiniband/hw/hfi1/hfi.h | 2 ++ drivers/infiniband/hw/hfi1/sysfs.c | 2 +- drivers/infiniband/hw/hfi1/vnic_main.c | 7 +++++- 4 files changed, 29 insertions(+), 17 deletions(-)
drivers/infiniband/hw/hfi1/chip.c +21 -14
@@ -13076,7 +13076,7 @@ static int request_msix_irqs(struct hfi1_devdata *dd) first_sdma = last_general; last_sdma = first_sdma + dd->num_sdma; first_rx = last_sdma; - last_rx = first_rx + dd->n_krcv_queues +HFI1_NUM_VNIC_CTXT ; + last_rx = first_rx + dd->n_krcv_queues + dd->num_vnic_contexts;/* VNIC MSIx interrupts get mapped when VNIC contexts are created */ dd->first_dyn_msix_idx = first_rx + dd->n_krcv_queues;
@@ -13282,8 +13282,9 @@ static int set_up_interrupts(struct hfi1_devdata *dd)* slow source, SDMACleanupDone) * N interrupts - one per used SDMA engine * M interrupt - one per kernel receive context +* V interrupt - one for each VNIC context */ - total =1 + dd->num_sdma + dd->n_krcv_queues +HFI1_NUM_VNIC_CTXT ; + total =1 + dd->num_sdma + dd->n_krcv_queues + dd->num_vnic_contexts;/* ask for MSI-X interrupts */ request =request_msix (dd, total);
@@ -13344,10 +13345,12 @@ static int set_up_interrupts(struct hfi1_devdata *dd)* in array of contexts * freectxts - number of free user contexts * num_send_contexts - number of PIO send contexts being used +* num_vnic_contexts - number of contexts reserved for VNIC */ static int set_up_context_variables (struct hfi1_devdata *dd) {unsigned long num_kernel_contexts; +u16 num_vnic_contexts =HFI1_NUM_VNIC_CTXT ;int total_contexts;int ret;unsigned ngroups;
@@ -13381,6 +13384,14 @@ static int set_up_context_variables(struct hfi1_devdata *dd) num_kernel_contexts); num_kernel_contexts = dd->chip_send_contexts - num_vls -1 ; } + +/* Accommodate VNIC contexts if possible */ +if ((num_kernel_contexts + num_vnic_contexts) > dd->chip_rcv_contexts) { +dd_dev_err (dd,"No receive contexts available for VNIC\n" ); + num_vnic_contexts =0 ; + } + total_contexts = num_kernel_contexts + num_vnic_contexts; +/* * User contexts: * - default to 1 user context per real (non-HT) CPU core if
@@ -13390,19 +13401,16 @@ static int set_up_context_variables(struct hfi1_devdata *dd) num_user_contexts =cpumask_weight (&node_affinity.real_cpu_mask); - total_contexts = num_kernel_contexts + num_user_contexts; -/* * Adjust the counts given a global max. */ -if (total_contexts > dd->chip_rcv_contexts) { +if (total_contexts + num_user_contexts > dd->chip_rcv_contexts) {dd_dev_err (dd,"Reducing # user receive contexts to: %d, from %d\n" , - (int )(dd->chip_rcv_contexts - num_kernel_contexts), + (int )(dd->chip_rcv_contexts - total_contexts), (int )num_user_contexts); - num_user_contexts = dd->chip_rcv_contexts - num_kernel_contexts;/* recalculate */ - total_contexts = num_kernel_contexts + num_user_contexts; + num_user_contexts = dd->chip_rcv_contexts - total_contexts; }/* each user context requires an entry in the RMT */
@@ -13415,25 +13423,24 @@ static int set_up_context_variables(struct hfi1_devdata *dd) user_rmt_reduced);/* recalculate */ num_user_contexts = user_rmt_reduced; - total_contexts = num_kernel_contexts + num_user_contexts; } -/* Accommodate VNIC contexts */ -if ((total_contexts +HFI1_NUM_VNIC_CTXT ) <= dd->chip_rcv_contexts) - total_contexts +=HFI1_NUM_VNIC_CTXT ; + total_contexts += num_user_contexts;/* the first N are kernel contexts, the rest are user/vnic contexts */ dd->num_rcv_contexts = total_contexts; dd->n_krcv_queues = num_kernel_contexts; dd->first_dyn_alloc_ctxt = num_kernel_contexts; + dd->num_vnic_contexts = num_vnic_contexts; dd->num_user_contexts = num_user_contexts; dd->freectxts = num_user_contexts;dd_dev_info (dd, -"rcv contexts: chip %d, used %d (kernel %d, user %d)\n" , +"rcv contexts: chip %d, used %d (kernel %d, vnic %u, user %u)\n" , (int )dd->chip_rcv_contexts, (int )dd->num_rcv_contexts, (int )dd->n_krcv_queues, - (int )dd->num_rcv_contexts - dd->n_krcv_queues); + dd->num_vnic_contexts, + dd->num_user_contexts);/* * Receive array allocation:
drivers/infiniband/hw/hfi1/hfi.h +2 -0
@@ -1049,6 +1049,8 @@ struct hfi1_devdata {u64 z_send_schedule;u64 __percpu *send_schedule; +/* number of reserved contexts for VNIC usage */ +u16 num_vnic_contexts;/* number of receive contexts in use by the driver */ u32 num_rcv_contexts;/* number of pio send contexts in use by the driver */
drivers/infiniband/hw/hfi1/sysfs.c +1 -1
@@ -543,7 +543,7 @@ static ssize_t show_nctxts(struct device *device,* give a more accurate picture of total contexts available. */ return scnprintf (buf,PAGE_SIZE ,"%u\n" , -min (dd->num_rcv_contexts - dd->first_dyn_alloc_ctxt, +min (dd->num_user_contexts, (u32 )dd->sc_sizes[SC_USER ].count)); }
drivers/infiniband/hw/hfi1/vnic_main.c +5 -2
@@ -840,6 +840,9 @@ struct net_device *hfi1_vnic_alloc_rn(struct ib_device *device,struct rdma_netdev *rn;int i, size, rc; +if (!dd->num_vnic_contexts) +return ERR_PTR (-ENOMEM ); +if (!port_num || (port_num > dd->num_pports))return ERR_PTR (-EINVAL );
@@ -848,7 +851,7 @@ struct net_device *hfi1_vnic_alloc_rn(struct ib_device *device, size =sizeof (struct opa_vnic_rdma_netdev ) +sizeof (*vinfo); netdev =alloc_netdev_mqs (size, name, name_assign_type, setup, - dd->chip_sdma_engines,HFI1_NUM_VNIC_CTXT ); + dd->chip_sdma_engines, dd->num_vnic_contexts);if (!netdev)return ERR_PTR (-ENOMEM );
@@ -856,7 +859,7 @@ struct net_device *hfi1_vnic_alloc_rn(struct ib_device *device, vinfo =opa_vnic_dev_priv (netdev); vinfo->dd = dd; vinfo->num_tx_q = dd->chip_sdma_engines; - vinfo->num_rx_q =HFI1_NUM_VNIC_CTXT ; + vinfo->num_rx_q = dd->num_vnic_contexts; vinfo->netdev = netdev; rn->free_rdma_netdev = hfi1_vnic_free_rn; rn->set_id = hfi1_vnic_set_vesw_id;