Re: [RFC] FC pass thru - Rev V

[Boaz Harrosh <bharrosh@panasas.com>]

FUJITA Tomonori wrote:
> On Wed, 11 Feb 2009 18:55:00 +0200
> Boaz Harrosh <bharrosh@panasas.com> wrote:
> 
>>> It's about a bidi request. We already have tons of loops, memory
>>> allocations, etc in the path. Do you think that adding one more loop
>>> leads to a notable performance regression?
>>>
>>> Well, if you say that it's hacky then I would agree. But your patch
>>> using ~0 is hacky too.
>> It is an hack if used by an outside user, because it assumes knowledge
>> of block-internals. It is much less of an hack if done by block-internals
>> which knows for sure that this has no side effects.
>>
>> But I agree that this is not clean. The clean solution is to add an extra
>> parameter to blk_end_request() and change all callers.
> 
> I don't agree.
> 
> 
>> Or even cleaner is to add a new request->residual member and leave
>> request->data_len be in peace. Then change the few users that care
>> about residual, and one caller that sets it. I'll prepare a patch.
> 
> Yeah, it's clean but I'm not sure Jens would accept such patch since
> fattening request struct leads to a notable performance regression.

OK, then give up, a proper comment next to blk_end_bidi_request()
that says:
"... can be used with any requests, in case of uni-requests the
second length will be ignored"

Actual FC code changes is:
-	blk_end_request(req, err, req_len);
+	blk_end_bidi_request(req, err, req_len, rsp_len);

That is not so hard to understand. There are much more complicated
things in kernel then that simple thing.

Boaz