On Wed, 2011-10-19 at 20:09 +0200, Bart Van Assche wrote: > On Wed, Oct 19, 2011 at 7:38 PM, Nicholas A. Bellinger > <n...@linux-iscsi.org> wrote: > > Btw, Roland asked me to take a look at the current set of module > > parameters for ib_srpt, and see which could be removed and/or converted > > to per SPR target endpoint configfs attributes.. So on that note, a few > > questions for you on a couple of the module parameters: > > > > *) use_port_guid_in_session_name: This appears to be a legacy compat > > item, can this be safetly removed for mainline..? > > As far as I know some people are still using this parameter.
Sure, but I think the question is if it's worth getting rid of for mainline if it's something that the mainline code will not be using. AFAICT it's still something we will never end up using with mainline target infrastructure, right..? > > > *) srpt_service_guid: Should this really have global scope..? > > I'm afraid that having different values of this parameter for > different HCAs would break failing over between HCAs. > Ok, leaving srpt_service_guid as a single global module parameter. > > Aside from those, i'm currently having a look to see which of the module > > parameters are not used in the initial srpt_add_one() setup path, and > > that using per SRP target endpoint configfs attributes would make sense. > > My opinion is that the parameters used in srpt_add_one() also should > be converted from module parameters into something that is > configurable dynamically. Sure, but the question is: Where can these parameters be set dynamically if srpt_add_one() is called directly from modprobe..? > ib_srpt users have already been asking to > make e.g. srp_max_req_size configurable dynamically. It should be > doable to reallocate the receive ring when there are no active > sessions. > Mmmm, I think I understand what you mean here, but will need to dig into the code some more to make sure. I'll try moving as much of these as possible into per SRP target endpoint attributes, and will let you know if I get stuck on any specific parameter. Thanks, --nab -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
