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: > > From: "Steve Wise" <swise@xxxxxxxxxxxxxxxxxxxxx> > > Date: Thu, 27 Feb 2014 11:11:49 -0600 > > > > >> > > >> > -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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
