| Message ID | 545240E7.5030206@acm.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
I've applied patches 1-3 to the core-for-3.19 branch. Various srp patches, including the first one fail to apply for me. Can you regenerate them against the drivers-for-3.19 branch? Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/04/14 15:14, Christoph Hellwig wrote: > I've applied patches 1-3 to the core-for-3.19 branch. Various srp > patches, including the first one fail to apply for me. Can you > regenerate them against the drivers-for-3.19 branch? Thanks! Hello Christoph, That's strange. I have compared the patches that are already in your tree with the patches I had posted myself with a diff tool. These patches look identical to what I had posted except for one CC tag that has been left out. If I try to apply the three patches that have not yet been included in your tree (9/11..11/11) on top the drivers-for-3.19 branch then these patches apply fine. Anyway, I have rebased my tree on top of your drivers-for-3.19 branch, added a few other patches (including one block layer patch that has not yet been posted) and retested the SRP initiator driver against the traditional SCSI core and also against the scsi-mq core. The result can be found here: https://github.com/bvanassche/linux/commits/srp-multiple-hwq-v4. Can you please retry to apply patches 9/11..11/11 apply on top of the drivers-for-3.19 branch ? Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 05, 2014 at 01:37:14PM +0100, Bart Van Assche wrote: > That's strange. I have compared the patches that are already in your tree > with the patches I had posted myself with a diff tool. These patches look > identical to what I had posted except for one CC tag that has been left out. > If I try to apply the three patches that have not yet been included in your > tree (9/11..11/11) on top the drivers-for-3.19 branch then these patches > apply fine. Anyway, I have rebased my tree on top of your drivers-for-3.19 > branch, added a few other patches (including one block layer patch that has > not yet been posted) and retested the SRP initiator driver against the > traditional SCSI core and also against the scsi-mq core. The result can be > found here: https://github.com/bvanassche/linux/commits/srp-multiple-hwq-v4. > Can you please retry to apply patches 9/11..11/11 apply on top of the > drivers-for-3.19 branch ? I've pulled in the three remaining patches from the series from that tree. If you want me to pull in the remaining trivial srp patch as well please give me a Reviewed-by: and I'll also pull it in. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/05/14 19:54, Christoph Hellwig wrote: > On Wed, Nov 05, 2014 at 01:37:14PM +0100, Bart Van Assche wrote: >> That's strange. I have compared the patches that are already in your tree >> with the patches I had posted myself with a diff tool. These patches look >> identical to what I had posted except for one CC tag that has been left out. >> If I try to apply the three patches that have not yet been included in your >> tree (9/11..11/11) on top the drivers-for-3.19 branch then these patches >> apply fine. Anyway, I have rebased my tree on top of your drivers-for-3.19 >> branch, added a few other patches (including one block layer patch that has >> not yet been posted) and retested the SRP initiator driver against the >> traditional SCSI core and also against the scsi-mq core. The result can be >> found here: https://github.com/bvanassche/linux/commits/srp-multiple-hwq-v4. >> Can you please retry to apply patches 9/11..11/11 apply on top of the >> drivers-for-3.19 branch ? > > I've pulled in the three remaining patches from the series from that > tree. If you want me to pull in the remaining trivial srp patch as well > please give me a Reviewed-by: and I'll also pull it in. Thanks ! Regarding the remaining SRP patch: Roland has already been asked to pull that patch (see also http://thread.gmane.org/gmane.linux.drivers.rdma/22018). Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c index 8317175..728b9a4 100644 --- a/block/blk-mq-tag.c +++ b/block/blk-mq-tag.c @@ -584,6 +584,34 @@ int blk_mq_tag_update_depth(struct blk_mq_tags *tags, unsigned int tdepth) return 0; } +/** + * blk_mq_unique_tag() - return a tag that is unique queue-wide + * @rq: request for which to compute a unique tag + * + * The tag field in struct request is unique per hardware queue but not over + * all hardware queues. Hence this function that returns a tag with the + * hardware context index in the upper bits and the per hardware queue tag in + * the lower bits. + * + * Note: When called for a request that is queued on a non-multiqueue request + * queue, the hardware context index is set to zero. + */ +u32 blk_mq_unique_tag(struct request *rq) +{ + struct request_queue *q = rq->q; + struct blk_mq_hw_ctx *hctx; + int hwq = 0; + + if (q->mq_ops) { + hctx = q->mq_ops->map_queue(q, rq->mq_ctx->cpu); + hwq = hctx->queue_num; + } + + return (hwq << BLK_MQ_UNIQUE_TAG_BITS) | + (rq->tag & BLK_MQ_UNIQUE_TAG_MASK); +} +EXPORT_SYMBOL(blk_mq_unique_tag); + ssize_t blk_mq_tag_sysfs_show(struct blk_mq_tags *tags, char *page) { char *orig_page = page; diff --git a/block/blk-mq.c b/block/blk-mq.c index 68929ba..b5896d4 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2024,6 +2024,8 @@ static int blk_mq_alloc_rq_maps(struct blk_mq_tag_set *set) */ int blk_mq_alloc_tag_set(struct blk_mq_tag_set *set) { + BUILD_BUG_ON(BLK_MQ_MAX_DEPTH > 1 << BLK_MQ_UNIQUE_TAG_BITS); + if (!set->nr_hw_queues) return -EINVAL; if (!set->queue_depth) diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h index c9be158..15f7034a 100644 --- a/include/linux/blk-mq.h +++ b/include/linux/blk-mq.h @@ -167,6 +167,23 @@ struct request *blk_mq_alloc_request(struct request_queue *q, int rw, gfp_t gfp, bool reserved); struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags, unsigned int tag); +enum { + BLK_MQ_UNIQUE_TAG_BITS = 16, + BLK_MQ_UNIQUE_TAG_MASK = (1 << BLK_MQ_UNIQUE_TAG_BITS) - 1, +}; + +u32 blk_mq_unique_tag(struct request *rq); + +static inline u16 blk_mq_unique_tag_to_hwq(u32 unique_tag) +{ + return unique_tag >> BLK_MQ_UNIQUE_TAG_BITS; +} + +static inline u16 blk_mq_unique_tag_to_tag(u32 unique_tag) +{ + return unique_tag & BLK_MQ_UNIQUE_TAG_MASK; +} + struct blk_mq_hw_ctx *blk_mq_map_queue(struct request_queue *, const int ctx_index); struct blk_mq_hw_ctx *blk_mq_alloc_single_hw_queue(struct blk_mq_tag_set *, unsigned int, int);