Re: [GIT PULL] ib_srpt: Initial SRP Target merge for v3.2-rc1

[Bart Van Assche]

On Sat, Nov 5, 2011 at 7:04 PM, Nicholas A. Bellinger
<nab@xxxxxxxxxxxxxxx> wrote:
> On Sat, 2011-11-05 at 08:37 +0100, Bart Van Assche wrote:
>> On Fri, Nov 4, 2011 at 9:10 PM, Nicholas A. Bellinger
>> <nab@xxxxxxxxxxxxxxx> wrote:
>> > This is the PULL request for an initial merge of the ib_srpt driver
>> > using mainline target infrastructure into v3.2-rc1.
>>
>> In case anyone is interested, the most important unaddressed comments
>> for this version of ib_srpt are:
>> - There are still too many module parameters. This makes ib_srpt
>> harder to use than necessary because several of these parameters can
>> only be set at module load time.
>
> Can you be more specific here..?  I went through the module parameters
> and made the ones that where used in a per-port specific context into
> configfs attributes as Roland recommended, but it seems like you are
> saying that more should be made into attributes.  Which ones..?

Several read-only kernel module parameters remain. That's fine in
out-of-tree code since it will be compiled as a kernel module only.
But anyone who tries to build with CONFIG_INFINIBAND_SRPT=y will
notice that it's impossible to change the value of these read-only
kernel module parameters.

>> - The last WQE event can arrive before the queue pair is reset,
>> resulting in a hanging session and blocking future logins
>> (http://www.mail-archive.com/linux-rdma@xxxxxxxxxxxxxxx/msg09678.html).
>
> Yep, was going to get this resolved post merge along with my patch now
> in lio-core.git to address active I/O shutdown with ib_srpt.

Your "active I/O shutdown" patch does not address the "last WQE" issue.

>> - The "ib_srpt: Convert srp_max_rdma_size into per port configfs
>> attribute" contradicts the I/O controller concept. This is a bug.
>> (http://www.mail-archive.com/linux-rdma@xxxxxxxxxxxxxxx/msg09677.html).
>
> As mentioned in the thread, I deferred to Roland's input on that one.
> So you're saying this should be made back into a module parameter now,
> or what..?

I see two possible ways forward:
- Convert the per-port max_rdma_size configfs variable into a
per-module configfs variable.
- Remove the max_rdma_size variable from configfs entirely and compute
the max_rdma_size from the HCA properties in struct ib_device_attr.

Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/