FUJITA Tomonori wrote: > On Wed, 11 Feb 2009 18:55:00 +0200 > Boaz Harrosh <bharrosh@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
