On Tue, Mar 04, 2014 at 23:22:46 +0000, Ben Hutchings wrote:

On Thu, 2014-02-27 at 13:05 -0500, David Miller wrote:

quoted

From: "Steve Wise" <redacted>
Date: Thu, 27 Feb 2014 11:11:49 -0600

quoted

quoted

quoted

-static int allow_db_fc_on_t5;
-module_param(allow_db_fc_on_t5, int, 0644);
-MODULE_PARM_DESC(allow_db_fc_on_t5,
-           "Allow DB Flow Control on T5 (default = 0)");
-
-static int allow_db_coalescing_on_t5;
-module_param(allow_db_coalescing_on_t5, int, 0644);
-MODULE_PARM_DESC(allow_db_coalescing_on_t5,
-           "Allow DB Coalescing on T5 (default = 0)");

Module parameters are a user facing interface.

You cannot just delete, or change the semantics of, the ones you feel
like doing so to.

I see your point on user facing interfaces.   These module params were
added initially to allow tweaking the db drop recovery for T5 devices in
the thought that we might need it.  It turns out T5 doesn't suffer from
this issue.  These params default to 0 anyway, and I doubt anyone has
changed them.  Disabling the hw db coalescing feature proved problematic
and it turned out to even make the issue worse, so I removed it totally
at the recommendation from the HW engineers, and put in place the new
design which better rate controls things under heavy load.

You have to keep the old ones around.

Setting an unknown module parameter now results in a warning (since
3.11), so removing a parameter isn't so disruptive as it used to be.

Obviously this is removing a feature, but as the feature sounds like it
was only marginally useful I think it's a perfectly valid change.

Ben.

Thanks Ben for letting us know that things have changed post 3.11 kernel.

Hi David,
Would you be OK if we remove the unused module_param now when we re-submit the series ?


Thanks,
-Hari.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html