Jason Gunthorpe <[email protected]> wrote: > On Thu, Apr 25, 2013 at 08:26:45PM +0000, Hefty, Sean wrote: > > 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.. AFAIK the IPoIB specification doesn't mandate the QPN of the sender > 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. INDEED, but this must be supported by the HW. The patch set is already supporting the case of HW the knows to do that forcing, quoting ---> IB_DEVICE_UD_TSS which is set to indicate that the device supports "HW TSS" which means that the HW is capable of over-riding the source UD QPN present in sent IB datagram header (DTH) with the parent's QPN <--- where over such HW the on-the-wire IPoIB header isn't touched. BUT for the sake of improving performance and being competitive with tons of Linux Ethernet drivers that support TSS/MQ we still need IPoIB to support MQ/TSS before such HW is introduced, and as such the chosen solution was to use reserved fields of the wire header. How about we discuss RSS 1st? for RSS no wire change is introduced, lets see if/how we can come to an agreement how the RSS related verbs should look like and we'll take it from there to TSS. Or. -- 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
