On Mon, Jan 18, 2010 at 12:29 PM, Eli Cohen <[email protected]> wrote: > > On Sun, Jan 17, 2010 at 9:08 PM, Bart Van Assche > <[email protected]> wrote: > > Once I noticed that the SRP initiator triggers two IB interrupts per I/O > > (more > > precise, per srp_queuecommand() call) I started looking at reducing the > > number > > of IB interrupts. The patch below didn't help. Does this mean that the patch > > below isn't complete or is this because of the hw driver used during the > > test > > (mlx4) ? > > When you say that the patch did not help, do you mean that it did not > reduce the rate of interrupts?
Yes. > I also think that you have a race here > since the head and tail operations are not protected (I don't know the > SRP driver I think locking should be done here). The race was already present in the original SRP driver: tx_tail is not consistently protected by target->scsi_host->host_lock. As far as my analysis of the tx_tail access patterns is correct this race doesn't hurt in the original SRP driver. But you are right, I should carefully analyze whether this race is acceptable. > It would be better if > you'd choose a value that is a fraction of the queue size to request a > completion so that you don't get to a situation where your queue is > full and you the sender is waiting for it to be cleared. Also, you did > not touch the completion handler. Seems to me you should increment the > tail for each completion by the number of completions you skipped. > Failing to do so will keep cause the completion to be requested each > post after the first time it skipped queue len completions. Thanks -- will have a look at this. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
