On Thu, Apr 25, 2013 at 08:26:45PM +0000, Hefty, Sean wrote: > > > Conceptually, RSS/TSS are a set of send/receive work queues all > > > belonging to the same transport level address. There's no > > > parent-child relationship or needed pairing of send and receive > > > queues together in order to form a group. > > > > This view makes sense to me as well. Can someone also confirm that > > using TSS doesn't affect the on-the-wire packets vs the non-TSS cases? > > I heard a few comments that sounded like TSS users get a per-queue QPN > > in the outgoing packet rather than a single QPN for the group, which > > would be pretty ugly. > > After speaking with Tzahi, my understanding is that the receive work > queues all receive on the same QPN, but the send work queues use > different QPNs. The on-wire packets are affected, specifically the > ipoib header. This is why the send QPNs must be sequential, so that > a mask can be applied at the receiving side to determine a single > source QPN.
Ah, this seems contrary to the IPoIB specification? Someone should probably talk about how sending from the wrong QPN is acceptable.. As I said, that is ugly. 'TSS' that changes the on-the-wire packet is not TSS. It is just ganging QPs together. Allocating sequential TSS QPNs is an awful hack, what we really need is a way to force a UD QP's outgoing QPN. Jason -- 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
