On Mon, Apr 29, 2013 at 10:52:21PM +0300, Or Gerlitz wrote:
> On Fri, Apr 26, 2013 at 12:40 AM, Jason Gunthorpe wrote:
> > But I don't follow why the send QPNs have to be sequential for
> > IPoIB. It looks like this is being motivated by RSS and RSS QPNs are
> > just being reused for TSS?
> 
> Go read "It turns out that there are IPoIB drivers used by some
> operating-systems
> and/or Hypervisors in a para-virtualization (PV) scheme which extract the
> source QPN from the CQ WC associated with an incoming packets in order
> to.." and what follows in the change-log of patch 4/5
> http://marc.info/?l=linux-rdma&m=136412901621797&w=2

This is what I said in the first place, the RFC is premised on the
src.QPN to be set properly, you can't just mess with it, because stuff
needs it.

I think you should have split this patch up, there is lots going on
here.

- Add proper TSS that doesn't change the wire protocol
- Add fake TSS that does change the wire protocol, and
  properly document those changes so other people can
  follow/implement them
- Add RSS

And.. 'tss_qpn_mask_sz' seems unnecessarily limiting, using
 WC.srcQPN + ipoib_header.tss_qpn_offset == real QPN
 (ie use a signed offset, not a mask)
Seems much better than
 Wc.srcQPN & ~((1<<(ipoib_header.tss_qpn_mask_sz >> 12))-1) == real QPN
 (Did I even get that right?)

Specifically it means the requirements for alignment and
contiguous-ness are gone. This means you can implement it without
using the QP groups API and it will work immediately with every HCA
out there. I think if we are going to actually mess with the wire
protocol this sort of broad applicability is important.

As for the other two questions: seems reasonable to me. Without a
consensus among HW vendors how to do this it makes sense to move ahead
*in the kernel* with a minimal API. Userspace is a different question
of course..

Jason
--
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

Reply via email to