| Message ID | 1438243595-32288-6-git-send-email-sagig@mellanox.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, Jul 30, 2015 at 11:06 AM, Sagi Grimberg <sagig@mellanox.com> wrote: > We don't update those anywhere in the code and they > seem pretty useless (no one seem to care about those). > > qp_tx_queue_full: We never should get this why? > fmr_map_not_avail: We can never get to this why? if for some reason fmr pool thread which does unmapping on the background is slowed/delayed? or the device firmware/hardware is in troubles? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 7/30/2015 1:20 PM, Or Gerlitz wrote: > On Thu, Jul 30, 2015 at 11:06 AM, Sagi Grimberg <sagig@mellanox.com> wrote: >> We don't update those anywhere in the code and they >> seem pretty useless (no one seem to care about those). >> >> qp_tx_queue_full: We never should get this > > why? We reserve slots in our queue-pair based on the maximum inflight IOs. And we lower the user's cmds_max to our queue-pair size. So we never get there - also the code never touches this counter. > >> fmr_map_not_avail: We can never get to this > > why? if for some reason fmr pool thread which does unmapping on the > background is slowed/delayed? or the > device firmware/hardware is in troubles? For FMRs we allocate x2 FMRs to absorb the background unmapping. Besides, We don't increment this in any place in the code... I don't see a point in keeping parameters that are not maintained. Actually I never noticed they were there... a quick git searched didn't show any usage of those ever. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c b/drivers/infiniband/ulp/iser/iscsi_iser.c index 859d9d9..92b1020 100644 --- a/drivers/infiniband/ulp/iser/iscsi_iser.c +++ b/drivers/infiniband/ulp/iser/iscsi_iser.c @@ -750,15 +750,9 @@ iscsi_iser_conn_get_stats(struct iscsi_cls_conn *cls_conn, struct iscsi_stats *s stats->r2t_pdus = conn->r2t_pdus_cnt; /* always 0 */ stats->tmfcmd_pdus = conn->tmfcmd_pdus_cnt; stats->tmfrsp_pdus = conn->tmfrsp_pdus_cnt; - stats->custom_length = 4; - strcpy(stats->custom[0].desc, "qp_tx_queue_full"); - stats->custom[0].value = 0; /* TB iser_conn->qp_tx_queue_full; */ - strcpy(stats->custom[1].desc, "fmr_map_not_avail"); - stats->custom[1].value = 0; /* TB iser_conn->fmr_map_not_avail */; - strcpy(stats->custom[2].desc, "eh_abort_cnt"); - stats->custom[2].value = conn->eh_abort_cnt; - strcpy(stats->custom[3].desc, "fmr_unalign_cnt"); - stats->custom[3].value = conn->fmr_unalign_cnt; + stats->custom_length = 1; + strcpy(stats->custom[0].desc, "fmr_unalign_cnt"); + stats->custom[0].value = conn->fmr_unalign_cnt; } static int iscsi_iser_get_ep_param(struct iscsi_endpoint *ep,
We don't update those anywhere in the code and they seem pretty useless (no one seem to care about those). qp_tx_queue_full: We never should get this fmr_map_not_avail: We can never get to this eh_abort_cnt: We don't monitor aborts Go ahead and remove them. Signed-off-by: Sagi Grimberg <sagig@mellanox.com> --- drivers/infiniband/ulp/iser/iscsi_iser.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)