On Tue, 2010-08-03 at 13:33 +0200, Bart Van Assche wrote: > On Mon, Aug 2, 2010 at 11:23 PM, David Dillow <d...@thedillows.org> wrote: > > > > On Mon, 2010-08-02 at 17:32 +0200, Bart Van Assche wrote: > > > [ ... ] > > > > > > @@ -1051,7 +1052,7 @@ static struct srp_iu *__srp_get_tx_iu(struct > > > srp_target_port *target, > > > > > > srp_send_completion(target->send_cq, target); > > > > > > - if (target->tx_head - target->tx_tail >= SRP_SQ_SIZE) > > > + if (target->tx_head - target->tx_tail >= SRP_REQ_SQ_SIZE) > > > return NULL; > > > > I'm not keen on the name SRP_REQ_SQ_SIZE. I had used SRP_SQ_FULL here > > and SRP_MAX_CREDIT elsewhere to be more descriptive of their use, but > > I'm not sold on those names either. Anyone have better ideas? > > SRP_REQ_SQ_SIZE is the number of elements of the send queue reserved > for sending requests (SRP_CMD, SRP_TSK_MGMT and in the future maybe > SRP_I_LOGOUT), and SRP_RSP_SQ_SIZE is the number of elements on the > send queue reserved for sending responses (SRP_CRED_RSP and in the > future also SRP_AER_RSP). So the names you suggested do not reflect > what these constants are used for.
My thinking was SRP_SQ_FULL was a better indication of the use when checking if there were buffers left, but I've already admitted I'm not too happy with my name, either. :) I used SRP_MAX_CREDIT for .can_queue, to reflect that we were limiting the credits/outstanding requests we would use. Perhaps it is superfluous, but I felt it helped clarify the intent. I just really do not like the aesthetics of SRP_REQ_SQ_SIZE. I don't have any better suggestions, so I'll drop it until/unless I can come up with a better idea. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
