[ofa-general] Blue sexy pill - $0.{_2SYMBCHAR}
Blue sexy pill - $0.{_2SYMBCHAR}Have a look at our site
___
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
[ofa-general] Now you can get it before anyone.
Bacheelor, MasteerMBA, and Doctoraate diplomas available in the field of your choice that's right, you can even become a Doctor and receive all the benefits that comes with it! Our Diplomas/Certificates are recognised in most countries No required examination, tests, classes, books, or interviews. ** No one is turned down ** Confidentiality assured CALL US 24 HOURS A DAY, 7 DAYS A WEEK For US: 1-801-504-2132 Outside US: +1-801-504-2132 Just leave your NAME amp; PHONE NO. (with CountryCode) in the voicemail our staff will get back to you in next few days ___ 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
[ofa-general] RNIC resource limits
Hello,
I have asked this question about RNIC resource limits before:
snip
Could you give me some insight in what the limits of the Chelsio RNIC
are? (Max MRs, QPs, PDs etc)
Many thanks and kind regards,
Philip
snip
Try running ibv_devinfo -v to see driver/hw limits.
However, how are you limited? Are you getting failures registering
memory? Did you try setting your ulimit -l to unlimited or at least as
large as the memory region you want to register?
Steve.
Steve, thanks for the answer!
When running 'ibv_devinfo -v' on my Chelsio RNIC (T3) with OFED 1.3 (FW
5.0)
I get the following:
[EMAIL PROTECTED] ~]# ibv_devinfo -v
hca_id: cxgb3_0
fw_ver: 0.0.0
node_guid: 0007:4301:33f7:
sys_image_guid: 0007:4301:33f7:
vendor_id: 0x1425
vendor_part_id: 49
hw_ver: 0x0
board_id: 1425.31
phys_port_cnt: 2
max_mr_size:0x
page_size_cap: 0x0
max_qp: 32736
max_qp_wr: 16777215
device_cap_flags: 0x00038000
max_sge:4
max_sge_rd: 1
max_cq: 32767
max_cqe:16777215
max_mr: 32768
max_pd: 32767
max_qp_rd_atom: 8
max_ee_rd_atom: 0
max_res_rd_atom:0
max_qp_init_rd_atom:8
max_ee_init_rd_atom:0
atomic_cap: ATOMIC_NONE (0)
max_ee: 0
max_rdd:0
max_mw: 0
max_raw_ipv6_qp:0
max_raw_ethy_qp:0
max_mcast_grp: 0
max_mcast_qp_attach:0
max_total_mcast_qp_attach: 0
max_ah: 0
max_fmr:0
max_srq:0
max_pkeys: 0
local_ca_ack_delay: 0
port: 1
state: PORT_ACTIVE (4)
max_mtu:4096 (5)
active_mtu: invalid MTU (225)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
max_msg_sz: 0x
port_cap_flags: 0x009f
max_vl_num: invalid value (255)
bad_pkey_cntr: 0x213
qkey_viol_cntr: 0x0
sm_sl: 0
pkey_tbl_len: 1
gid_tbl_len:1
subnet_timeout: 146
init_type_reply:39
active_width: 4X (2)
active_speed: 5.0 Gbps (2)
phys_state: invalid physical state (0)
port: 2
state: PORT_ACTIVE (4)
max_mtu:4096 (5)
active_mtu: invalid MTU (225)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
max_msg_sz: 0x
port_cap_flags: 0x009f
max_vl_num: invalid value (255)
bad_pkey_cntr: 0x213
qkey_viol_cntr: 0x0
sm_sl: 0
pkey_tbl_len: 1
gid_tbl_len:1
subnet_timeout: 146
init_type_reply:39
active_width: 4X (2)
active_speed: 5.0 Gbps (2)
phys_state: invalid physical state (0)
When creating a QP, I need to specify some capacity information:
struct ibv_qp_cap {
uint32_tmax_send_wr;
uint32_tmax_recv_wr;
uint32_tmax_send_sge;
uint32_tmax_recv_sge;
uint32_tmax_inline_data;
};
According to the above listing, I should be able to use:
16777215
[ofa-general] [PATCH][MINOR] opensm/osm_sa_mcmember_record.c: Minor logic change in __get_new_mlid
opensm/osm_sa_mcmember_record.c: Minor logic change in __get_new_mlid
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
diff --git a/opensm/opensm/osm_sa_mcmember_record.c
b/opensm/opensm/osm_sa_mcmember_record.c
index c982f40..3cfd5f7 100644
--- a/opensm/opensm/osm_sa_mcmember_record.c
+++ b/opensm/opensm/osm_sa_mcmember_record.c
@@ -181,10 +181,9 @@ __get_new_mlid(IN osm_sa_t * sa, IN ib_net16_t
requested_mlid)
/* track all used mlids in the array (by mlid index) */
used_mlids_array = (uint8_t *) malloc(sizeof(uint8_t) * max_num_mlids);
- if (used_mlids_array)
- memset(used_mlids_array, 0, sizeof(uint8_t) * max_num_mlids);
if (!used_mlids_array)
return 0;
+ memset(used_mlids_array, 0, sizeof(uint8_t) * max_num_mlids);
/* scan all available multicast groups in the DB and fill in the table
*/
while (p_mgrp != (osm_mgrp_t *) cl_qmap_end(p_subn-mgrp_mlid_tbl)) {
___
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
[ofa-general] [PATCH][MINOR] opensm/osm_ucast_ftree.c: Eliminate unnecessary check in __osm_ftree_sw_tbl_element_create
opensm/osm_ucast_ftree.c: Eliminate unnecessary check in __osm_ftree_sw_tbl_element_create Signed-off-by: Hal Rosenstock [EMAIL PROTECTED] diff --git a/opensm/opensm/osm_ucast_ftree.c b/opensm/opensm/osm_ucast_ftree.c index e7104e5..caf231c 100644 --- a/opensm/opensm/osm_ucast_ftree.c +++ b/opensm/opensm/osm_ucast_ftree.c @@ -349,8 +349,7 @@ static ftree_sw_tbl_element_t *__osm_ftree_sw_tbl_element_create(IN ftree_sw_t * return NULL; memset(p_element, 0, sizeof(ftree_sw_tbl_element_t)); - if (p_element) - p_element-p_sw = p_sw; + p_element-p_sw = p_sw; return p_element; } ___ 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
[ofa-general] [PATCH] opensm/osm_pkey.c: Eliminate potential NULL pointer dereference
opensm/osm_pkey.c: Eliminate potential NULL pointer dereference
Also, a comment reformat
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
diff --git a/opensm/opensm/osm_pkey.c b/opensm/opensm/osm_pkey.c
index 9b43669..c3b8394 100644
--- a/opensm/opensm/osm_pkey.c
+++ b/opensm/opensm/osm_pkey.c
@@ -151,8 +151,9 @@ osm_pkey_tbl_set(IN osm_pkey_tbl_t * p_pkey_tbl,
if (!p_pkey_block) {
p_pkey_block =
(ib_pkey_table_t *) malloc(sizeof(ib_pkey_table_t));
- if (p_pkey_block)
- memset(p_pkey_block, 0, sizeof(ib_pkey_table_t));
+ if (!p_pkey_block)
+ return (IB_ERROR);
+ memset(p_pkey_block, 0, sizeof(ib_pkey_table_t));
cl_ptr_vector_set(p_pkey_tbl-blocks, block, p_pkey_block);
}
@@ -163,8 +164,8 @@ osm_pkey_tbl_set(IN osm_pkey_tbl_t * p_pkey_tbl,
NOTE: as the spec does not require uniqueness of PKeys in
tables there is no other way but to refresh the entire keys map.
- Moreover, if the same key exists but with full membership it should
have
- precedence on the key with limited membership !
+ Moreover, if the same key exists but with full membership it should
+ have precedence on the key with limited membership !
*/
cl_map_remove_all(p_pkey_tbl-keys);
___
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
[ofa-general] Blue sexy pill - $0.{_2SYMBCHAR}
Blue sexy pill - $0.{_2SYMBCHAR}Click the link
___
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
[ofa-general] [PATCH] opensm/osm_port.c: Eliminate potential NULL pointer dereferences
opensm/osm_port.c: Eliminate potential NULL pointer dereferences
Also, comment format change
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
diff --git a/opensm/opensm/osm_port.c b/opensm/opensm/osm_port.c
index 3398d04..d66e6be 100644
--- a/opensm/opensm/osm_port.c
+++ b/opensm/opensm/osm_port.c
@@ -127,8 +127,9 @@ osm_physp_init(IN osm_physp_t * const p_physp,
cl_ptr_vector_init(p_physp-slvl_by_port, num_slvl, 1);
for (i = 0; i num_slvl; i++) {
p_slvl = (ib_slvl_table_t *) malloc(sizeof(ib_slvl_table_t));
- if (p_slvl)
- memset(p_slvl, 0, sizeof(ib_slvl_table_t));
+ if (!p_slvl)
+ break;
+ memset(p_slvl, 0, sizeof(ib_slvl_table_t));
cl_ptr_vector_set(p_physp-slvl_by_port, i, p_slvl);
}
@@ -594,6 +595,10 @@ osm_physp_replace_dr_path_with_alternate_dr_path(IN
osm_log_t * p_log,
boolean_t next_list_is_full = TRUE, reached_dest = FALSE;
uint8_t num_ports, port_num;
+ p_nextPortsList = (cl_list_t *) malloc(sizeof(cl_list_t));
+ if (!p_nextPortsList)
+ return;
+
/*
initialize the map of all port participating in current dr path
not including first and last switches
@@ -609,7 +614,6 @@ osm_physp_replace_dr_path_with_alternate_dr_path(IN
osm_log_t * p_log,
BFS from OSM port until we find the target physp but avoid
going through mapped ports
*/
- p_nextPortsList = (cl_list_t *) malloc(sizeof(cl_list_t));
cl_list_construct(p_nextPortsList);
cl_list_init(p_nextPortsList, 10);
@@ -638,12 +642,16 @@ osm_physp_replace_dr_path_with_alternate_dr_path(IN
osm_log_t * p_log,
next_list_is_full = FALSE;
p_currPortsList = p_nextPortsList;
p_nextPortsList = (cl_list_t *) malloc(sizeof(cl_list_t));
+ if (!p_nextPortsList) {
+ p_nextPortsList = p_currPortsList;
+ goto Exit;
+ }
cl_list_construct(p_nextPortsList);
cl_list_init(p_nextPortsList, 10);
p_physp = (osm_physp_t *) cl_list_remove_head(p_currPortsList);
while (p_physp != NULL) {
- /* If we are in a switch - need to go out through all
the other
- physical ports of the switch */
+ /* If we are in a switch - need to go out through all
+ the other physical ports of the switch */
num_ports = osm_node_get_num_physp(p_physp-p_node);
for (port_num = 1; port_num num_ports; port_num++) {
___
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
Re: [ofa-general] RNIC resource limits
[EMAIL PROTECTED] ~]# ibv_devinfo -v
hca_id: cxgb3_0
fw_ver: 0.0.0
node_guid: 0007:4301:33f7:
sys_image_guid: 0007:4301:33f7:
vendor_id: 0x1425
vendor_part_id: 49
hw_ver: 0x0
board_id: 1425.31
phys_port_cnt: 2
max_mr_size:0x
page_size_cap: 0x0
max_qp: 32736
max_qp_wr: 16777215
device_cap_flags: 0x00038000
max_sge:4
max_sge_rd: 1
max_cq: 32767
max_cqe:16777215
max_mr: 32768
max_pd: 32767
max_qp_rd_atom: 8
max_ee_rd_atom: 0
max_res_rd_atom:0
max_qp_init_rd_atom:8
max_ee_init_rd_atom:0
atomic_cap: ATOMIC_NONE (0)
max_ee: 0
max_rdd:0
max_mw: 0
max_raw_ipv6_qp:0
max_raw_ethy_qp:0
max_mcast_grp: 0
max_mcast_qp_attach:0
max_total_mcast_qp_attach: 0
max_ah: 0
max_fmr:0
max_srq:0
max_pkeys: 0
local_ca_ack_delay: 0
port: 1
state: PORT_ACTIVE (4)
max_mtu:4096 (5)
active_mtu: invalid MTU (225)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
max_msg_sz: 0x
port_cap_flags: 0x009f
max_vl_num: invalid value (255)
bad_pkey_cntr: 0x213
qkey_viol_cntr: 0x0
sm_sl: 0
pkey_tbl_len: 1
gid_tbl_len:1
subnet_timeout: 146
init_type_reply:39
active_width: 4X (2)
active_speed: 5.0 Gbps (2)
phys_state: invalid physical state (0)
port: 2
state: PORT_ACTIVE (4)
max_mtu:4096 (5)
active_mtu: invalid MTU (225)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
max_msg_sz: 0x
port_cap_flags: 0x009f
max_vl_num: invalid value (255)
bad_pkey_cntr: 0x213
qkey_viol_cntr: 0x0
sm_sl: 0
pkey_tbl_len: 1
gid_tbl_len:1
subnet_timeout: 146
init_type_reply:39
active_width: 4X (2)
active_speed: 5.0 Gbps (2)
phys_state: invalid physical state (0)
When creating a QP, I need to specify some capacity information:
struct ibv_qp_cap {
uint32_tmax_send_wr;
uint32_tmax_recv_wr;
uint32_tmax_send_sge;
uint32_tmax_recv_sge;
uint32_tmax_inline_data;
};
According to the above listing, I should be able to use:
16777215WRs(max_qp_wr: 16777215) [is this per qp
or total?]
4SGEs (max_sge: 4)
It does not say anything about the max_inline_data.
max inline supported is 64.
I have tried to create a QP with as many resources as possible and found
the following:
max_send_wrcannot exceed 16384
max_recv_wrcannot exceed 1023
max_send_sgecannot exceed 4294967295 (maximum a uint32_t can hold)
max_recv_sgecannot exceed 4294967295 (maximum a uint32_t can hold)
max_inline_datacannot exceed 64
The limits described in the device attributes are
[ofa-general] device attributes
Roland/All, Should the device attributes (for instance max_send_wr) be the max supported by the HW or the max supported by the OS or something else? For instance: Chelsio's HW can handle very large work queues, but since Linux limits the size of contiguous dma coherent memory allocations, the actual limits are much smaller. Which should I be using for the device attributes? Also, the chelsio device uses a single work queue to implement the SQ and RQ abstractions. So the max SQ depth depends on the RQ depth and vice versa. This leads to device max attributes that aren't that useful. I'm wondering what application writes should glean from these attributes... Steve ___ 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
Re: [ofa-general] device attributes
On Wed, 2008-06-04 at 09:28 -0500, Steve Wise wrote: Roland/All, Should the device attributes (for instance max_send_wr) be the max supported by the HW or the max supported by the OS or something else? Something else. For instance: Chelsio's HW can handle very large work queues, but since Linux limits the size of contiguous dma coherent memory allocations, the actual limits are much smaller. Basing the limit on an OS resource seems arbitrary and dangerous. Applications using advertised adapter resource limits will unnecessarily consume the maximum. Which should I be using for the device attributes? Arbitrary knee jerk == 512. However, surveying the current app usage as well as the other manufacturers advertised limits will make it less arbitrary. Also, the chelsio device uses a single work queue to implement the SQ and RQ abstractions. So the max SQ depth depends on the RQ depth and vice versa. This leads to device max attributes that aren't that useful. So the real limit is the HW WQ max and therefore max SQ = HW WQ max - RQ max? Setting RQ and SQ to 512 solves this problem. I'm wondering what application writes should glean from these attributes... I guess you mean application writer? Here's what I suggest: - Set the RQ and SQ max to some reasonable default limit (e.g. 512). - Add an escape hatch by providing module options to override the default max. Tom Steve ___ 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 ___ 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
Re: [ofa-general] device attributes
Here's what I suggest: - Set the RQ and SQ max to some reasonable default limit (e.g. 512). - Add an escape hatch by providing module options to override the default max. Or don't actually enforce the 512 max. IE set the attrs to what we think apps should use or max out at, but allow larger ones if the OS can handle it. Stevo. ___ 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
***SPAM*** Re: [ofa-general] RNIC resource limits
Hi.
Philip Frey1 wrote:
Hello,
I have asked this question about RNIC resource limits before:
snip
Could you give me some insight in what the limits of the Chelsio RNIC
are? (Max MRs, QPs, PDs etc)
Many thanks and kind regards,
Philip
snip
Try running ibv_devinfo -v to see driver/hw limits.
However, how are you limited? Are you getting failures registering
memory? Did you try setting your ulimit -l to unlimited or at least as
large as the memory region you want to register?
Steve.
Steve, thanks for the answer!
When running 'ibv_devinfo -v' on my Chelsio RNIC (T3) with OFED 1.3
(FW 5.0)
I get the following:
[EMAIL PROTECTED] ~]# ibv_devinfo -v
hca_id: cxgb3_0
fw_ver: 0.0.0
node_guid: 0007:4301:33f7:
sys_image_guid: 0007:4301:33f7:
vendor_id: 0x1425
vendor_part_id: 49
hw_ver: 0x0
board_id: 1425.31
phys_port_cnt: 2
max_mr_size:0x
page_size_cap: 0x0
max_qp: 32736
max_qp_wr: 16777215
device_cap_flags: 0x00038000
max_sge:4
max_sge_rd: 1
max_cq: 32767
max_cqe:16777215
max_mr: 32768
max_pd: 32767
max_qp_rd_atom: 8
max_ee_rd_atom: 0
max_res_rd_atom:0
max_qp_init_rd_atom:8
max_ee_init_rd_atom:0
atomic_cap: ATOMIC_NONE (0)
max_ee: 0
max_rdd:0
max_mw: 0
max_raw_ipv6_qp:0
max_raw_ethy_qp:0
max_mcast_grp: 0
max_mcast_qp_attach:0
max_total_mcast_qp_attach: 0
max_ah: 0
max_fmr:0
max_srq:0
max_pkeys: 0
local_ca_ack_delay: 0
port: 1
state: PORT_ACTIVE (4)
max_mtu:4096 (5)
active_mtu: invalid MTU (225)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
max_msg_sz: 0x
port_cap_flags: 0x009f
max_vl_num: invalid value (255)
bad_pkey_cntr: 0x213
qkey_viol_cntr: 0x0
sm_sl: 0
pkey_tbl_len: 1
gid_tbl_len:1
subnet_timeout: 146
init_type_reply:39
active_width: 4X (2)
active_speed: 5.0 Gbps (2)
phys_state: invalid physical state
(0)
port: 2
state: PORT_ACTIVE (4)
max_mtu:4096 (5)
active_mtu: invalid MTU (225)
sm_lid: 0
port_lid: 0
port_lmc: 0x00
max_msg_sz: 0x
port_cap_flags: 0x009f
max_vl_num: invalid value (255)
bad_pkey_cntr: 0x213
qkey_viol_cntr: 0x0
sm_sl: 0
pkey_tbl_len: 1
gid_tbl_len:1
subnet_timeout: 146
init_type_reply:39
active_width: 4X (2)
active_speed: 5.0 Gbps (2)
phys_state: invalid physical state
(0)
When creating a QP, I need to specify some capacity information:
struct ibv_qp_cap {
uint32_tmax_send_wr;
uint32_tmax_recv_wr;
uint32_tmax_send_sge;
uint32_tmax_recv_sge;
uint32_tmax_inline_data;
};
According to the above listing, I should be
[ofa-general] Blue sexy pill - $0.81
Blue sexy pill - $0.81Click the link ___ 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
[ofa-general] Re: device attributes
Should the device attributes (for instance max_send_wr) be the max supported by the HW or the max supported by the OS or something else? I think they should be what the consumer can expect to work -- ie the upper limits on the current system, whether those limits are imposed by the HW, driver, or whatever. For instance: Chelsio's HW can handle very large work queues, but since Linux limits the size of contiguous dma coherent memory allocations, the actual limits are much smaller. Which should I be using for the device attributes? The smaller limit I think. Also, the chelsio device uses a single work queue to implement the SQ and RQ abstractions. So the max SQ depth depends on the RQ depth and vice versa. This leads to device max attributes that aren't that useful. Not nice... I guess you could return half of the work queue depth for each max since that is guaranteed to work? I'm wondering what application writes should glean from these attributes... I think the limits are pointless unless they give something that an application can actually request. Some of the limits are pretty useless, eg max # of CQs, since another app may have already used up all the CQs. - R. ___ 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
Re: [ofa-general] Re: [PATCH v3 08/13] QLogic VNIC: sysfs interface implementation for the driver
Or so the theory goes. Unfortunately, you need all that information before you can create the connection. The configfs guys have thought about that, but not implemented yet: [Committable Items] NOTE: Committable items are currently unimplemented. The netconsole code in-tree has a separate enabled attribute that serves the purpose of committing something. Seems good enough for SRP to use to me... the rename to commit idea seems cute but I don't see that it buys much beyond this. ___ 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
Re: [ofa-general][PATCH v2 1/2]mlx4: Multiple completion vectors support
I resent the two patches that handle multiple completion vectors last week. What is the status for these patches? Are there further changes that need to be done, or will these patches be applied? I guess the patches look mostly OK, but are there any results that give motivation for applying this? I'm not asking about multicore systems need multiple EQs so we should do this level of vagueness, but we have application and/or ULP X that shows improvement Z using this. Also any thoughts on how an app/ULP can sanely choose which vector to use? - R. ___ 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
[ofa-general] Re: [PATCH] IB/ipoib: increase ring sizes
Increase IPoIB ring sizes to twice the original size to act as a shock observer for high traffic picks. Looks fine but I would like to include a little more motivation in the changelog. What type of workload benefits from this change? ___ 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
Re: [ofa-general][PATCH 8/12 v1] mlx4: Dynamic port configuration
+static int mlx4_change_port_types(struct mlx4_dev *dev,
+ enum mlx4_port_type *port_types)
+{
+int i;
+int err = 0;
+int change = 0;
+int port;
+
+for (i = 0; i MLX4_MAX_PORTS; i++) {
+if (port_types[i] != dev-caps.port_type[i + 1]) {
+change = 1;
+dev-caps.port_type[i + 1] = port_types[i];
+}
+}
+if (change) {
+mlx4_unregister_device(dev);
+for (port = 1; port = dev-caps.num_ports; port++) {
+mlx4_CLOSE_PORT(dev, port);
+err = mlx4_SET_PORT(dev, port);
+if (err) {
+mlx4_err(dev, Failed to set port %d,
+ aborting\n, port);
+return err;
+}
+}
+err = mlx4_register_device(dev);
+}
+return err;
+}
If I read the code correctly, there is no locking around this, so
multiple processes could race and cause all sorts of problems. And also
you do the assignment
+dev-caps.port_type[i + 1] = port_types[i];
before unregistering the device -- so there is a window where
caps.port_type has the wrong data -- not sure if this is a real issue.
+static ssize_t show_port_type(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+struct pci_dev *pdev = to_pci_dev(dev);
+struct mlx4_dev *mdev = pci_get_drvdata(pdev);
+int i;
+
+sprintf(buf, Current port types:\n);
+for (i = 1; i = MLX4_MAX_PORTS; i++) {
+sprintf(buf, %sPort%d: %s\n, buf, i,
+(mdev-caps.port_type[i] == MLX4_PORT_TYPE_IB)?
+ib: eth);
+}
+return strlen(buf);
+}
This violates the one-value-per-file rule for sysfs if I am reading the
code correctly.
- R.
___
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
Re: [ofa-general] Re: [PATCH v3 08/13] QLogic VNIC: sysfs interface implementation for the driver
On Wed, Jun 04, 2008 at 09:10:26PM -0700, Roland Dreier wrote: Or so the theory goes. Unfortunately, you need all that information before you can create the connection. The configfs guys have thought about that, but not implemented yet: [Committable Items] NOTE: Committable items are currently unimplemented. The netconsole code in-tree has a separate enabled attribute that serves the purpose of committing something. Seems good enough for SRP to use to me... the rename to commit idea seems cute but I don't see that it buys much beyond this. But... But... I've got nothing. I mentioned the enable attribute as a possible way to do it, though it is counter to the configfs's documented preference. But it's there, it works perfectly well, and the configfs guys have had over 2 years to implement their alternate commit feature. That said, given that SRP's been using sysfs since it went in, is there a reason to move to configfs other than it's the new preferred way to do it? Given the desire to not break ABI's -- and IIRC sysfs was declared to be under that unbrella -- wouldn't we have to at least carry both interfaces for a while, assuming we can even get rid of the sysfs one? Carrying both adds a bit of a interesting twist -- targets added using the sysfs add-target wouldn't show up under configfs. It may not be a real problem, but it could be a bit of a surprise to an admin. I'm not opposed to configfs, but the more I think about it, it doesn't seem to bring much to the table for the SRP initiator other more code and data structure size. -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office ___ 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
