On Thu, May 14, 2020 at 08:50:43AM +0800, Ming Lei wrote: > On Wed, May 13, 2020 at 05:27:53AM -0700, Christoph Hellwig wrote: > > On Wed, May 13, 2020 at 05:54:37PM +0800, Ming Lei wrote: > > > .commit_rqs() is supposed to handle partial dispatch when driver may not > > > see .last of flag passed to .queue_rq(). > > > > > > We have added .commit_rqs() in case of partial dispatch and all consumers > > > of bd->last have implemented .commit_rqs() callback, so it is perfect to > > > pass real .last flag of the request list to .queue_rq() instead of faking > > > it by trying to allocate driver tag for next request in the batching list. > > > > The current case still seems like a nice optimization to avoid an extra > > indirect function call. So if you want to get rid of it I think it at > > least needs a better rationale. > > You mean marking .last by trying to allocate for next request can > replace .commit_rqs()? No, it can't because .commit_rqs() can be > called no matter .last is set or not, both two are independent. > > Removing it can avoid to pre-allocate one extra driver tag, and > improve driver tag's utilization. What I said is that the current scheme works, and the new one will need an additional indirect function call in various scenarios. The commit log doesn't really "sell" that change very well. Your new explanation is much better, as would be saying it helps you with the hanges in this series.
