Re: [PATCH 1/1] IB/iser: re-adjust number of max_cqe and send_wr to hw supported number.
On 10/27/2014 7:01 AM, Minh Duc Tran wrote I like to follow up with all IB/iser changes and developments for 3.19. Please keep me updated with these changes if they are not going to be in the RDMA mailing list. We keep it all on the mailing list. Stay tuned... ;) Can you try the patch attached with my bits modified? Thanks, Sagi Your modification to the patch looks good and ran as expected. OK, so we will include it in our fixes for 3.18-rc2. Thanks Minh! Sagi. -- 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
Re: [PATCH V2 for-next 0/9] Peer-Direct support
On 10/23/2014 8:29 PM, Roland Dreier wrote: On Thu, Oct 23, 2014 at 5:02 AM, Yishai Hadas wrote: The API defined for Peer-Direct is described in this cover letter. The required implementation for a hardware device to expose memory buffers over Peer-Direct is also detailed in this letter. I don't see how I can justify merging this (for now at least), given that there are no actual users of all this (fairly complex) new code, besides a sample that doesn't actually do anything useful. Is there any actual consumer that might go upstream someday that we can at least review now? Intel people pointed that CCL Direct for Intel Xeon Phi uses this API. See http://www.spinics.net/lists/linux-rdma/msg21605.html . We are checking with Intel whether the relevant stuff can be shared for some early review. Additional use case for this Infrastructure can be the ability to do remote RDMA by exposing the UAR pages of the Mellanox HCAs and other NICs as peer direct memory. For this functionality to work, the only missing component in the kernel side is allowing registration of UAR pages. Relatively simple extension of mlx4_ib/mlx5_ib to be a peer direct client can add this missing component, in a nice, well integrated way. This will allow application to perform remote posting of work requests. This can be useful, for example in a gateway application. The application exposes QPs to remote machine inside the cluster. The remote machines can post work requests directly into the gateway machine using RDMA. This way, the gateway machine does not need any software involvement in the data path, improving the gateway machine scalability. This makes the usage of peer-direct almost completely transparent to the individual hardware drivers. The only changes required in the low level IB hardware drivers is supporting an interface for immediate invalidation of registered memory regions. Why do we need immediate invalidation of memory regions? We have listed the need for immediate invalidation in previous e-mails, specifically at: https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg21375.html To summarize, some of the hardware devices must block all accesses to the memory registered immediately in some use cases. This is needed to maintain correctness and forward progress, for example if the hardware must switch tasks to progress. To support these hardware devices, we implemented a callback to support invalidation. This allows the peer memory client to be sure that the memory will not be accessed by the hardware, and simplify their software design. -- 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
Re: [PATCH v2 02/12] blk-mq: Add blk_mq_unique_tag()
> "Bart" == Bart Van Assche writes: Bart> The queuecommand() callback functions in SCSI low-level drivers Bart> need to know which hardware context has been selected by the block Bart> layer. Since this information is not available in the request Bart> structure, and since passing the hctx pointer directly to the Bart> queuecommand callback function would require modification of all Bart> SCSI LLDs, add a function to the block layer that allows to query Bart> the hardware context index. I agree with consolidating the two functions. Otherwise OK. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering -- 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
Re: [PATCH v2 03/12] scsi-mq: Add support for multiple hardware queues
> "Bart" == Bart Van Assche writes: Bart> Allow a SCSI LLD to declare how many hardware queues it supports Bart> by setting Scsi_Host.nr_hw_queues before calling scsi_add_host(). Bart> Note: it is assumed that each hardware queue has a queue depth of Bart> shost-> can_queue. In other words, the total queue depth per host Bart> is (number of hardware queues) * (shost->can_queue). I suggest you emphasize that assumption in the header file. Also: What about the host template? Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering -- 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
Re: [PATCH v2 04/12] scsi_tcq.h: Add support for multiple hardware queues
> "Bart" == Bart Van Assche writes: Bart> Modify scsi_find_tag() and scsi_host_find_tag() such that these Bart> fuctions can translate a tag generated by blk_mq_unique_tag(). Looks good to me. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering -- 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
