On Tue, Apr 30, 2013 at 11:08:19PM +0300, Or Gerlitz wrote:
> Jason Gunthorpe wrote:
>
> For the TSS case, I'd say just allocate normal QPs and provide
> something like ibv_override_ud_src_qpn(). This is very general and
> broadly useful for any application using UD QPs.
>
> I've los
Jason Gunthorpe wrote:
> 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
Jason Gunthorpe wrote:
> For the TSS case, I'd say just allocate normal QPs and provide
> something like ibv_override_ud_src_qpn(). This is very general and
> broadly useful for any application using UD QPs.
I've lost you, how you suggest to implement ibv_override_ud_src_qpn(), is
that for futu
On Tue, Apr 30, 2013 at 12:04:25PM +0300, Shlomo Pongratz wrote:
> >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_
On 4/29/2013 11:36 PM, Jason Gunthorpe wrote:
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
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 r
On Fri, Apr 26, 2013 at 12:40 AM, Jason Gunthorpe wrote:
> As Sean said earlier, please think about a single QP, multiple RQ/SQ
> style API - that seems much more general to me and also could
> reasonably be defined for other transport types.
I find it to have too much of an abstraction for kerne
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-sy
On Fri, Apr 26, 2013 at 12:40 AM, Jason Gunthorpe
> Also, I feel what happens inside the kernel is more flexable API
> wise, so dropping the uverbs component may also be something you want to look
> at.
We didn't submit any uverbs exporting of these verbs on this series. I
am OK if the series i
On Thu, Apr 25, 2013 at 11:56:16PM +0300, Or Gerlitz wrote:
> > 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
I'd have to read it agai
Jason Gunthorpe wrote:
> On Thu, Apr 25, 2013 at 08:26:45PM +, 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 t
On Thu, Apr 25, 2013 at 08:26:45PM +, 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
> > 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
On Wed, Apr 24, 2013 at 02:24:45AM +, 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.
> On Mon, Apr 22, 2013 at 7:46 PM, Or Gerlitz wrote:
> > Sean, Tzahi -- I understand now that there have been few talkings @
> > the OFA meeting re this patch set. So what's the way to move forward,
> > any concrete feedback that needs to be addressed here? This series is
> > hanging since May 20
On Mon, Apr 22, 2013 at 7:46 PM, Or Gerlitz wrote:
> Sean, Tzahi -- I understand now that there have been few talkings @
> the OFA meeting re this patch set. So what's the way to move forward,
> any concrete feedback that needs to be addressed here? This series is
> hanging since May 2012 and I'd
On Mon, Apr 15, 2013 at 4:21 PM, Or Gerlitz wrote:
> Actually these comments and questions on the series come just a week
> before the annual OFA gathering, personally, I will not be there nor
> Shlomo who is the author of the patches, but Tzahi Oved from Mellanox
> who lead the architecture for t
Weiny, Ira wrote:
>> ow...@vger.kernel.org] On Behalf Of Or Gerlitz
>> RSS child QPs are plain UD or RAW Packet QPs that only have consecutive
>> QPNs which is common requirement of HW for configuring the RSS parent
>> which in networking is called the RSS indirection or dispatching QP. You
>> c
Tzahi Oved
> Subject: Re: [PATCH V4 for-next 1/5] IB/core: Add RSS and TSS QP groups
>
> On Thu, Apr 11, 2013 at 5:45 PM, Hefty, Sean wrote:
> [...]
> >> but lets get there after hopefully agreeing what is RSS QP group.
>
> > So far, this is what I think it is:
>
On Thu, Apr 11, 2013 at 5:45 PM, Hefty, Sean wrote:
[...]
>> but lets get there after hopefully agreeing what is RSS QP group.
> So far, this is what I think it is:
> - a collection of related receive queues
> - each queue is configured somewhat separately - i.e. sized, CQ, sge size,
> etc.
> -
> > I have no issue with RSS/TSS. But the 'qp group' interface to using this
> seems kludgy.
>
> lets try to be more specific
>
> > On a node, this is multiple send/receive queues grouped together to form a
> larger
> > construct. On the wire, this is a single QP - maybe? I'm still not clear
Or Gerlitz wrote:
Hefty, Sean wrote:
>> I have no issue with RSS/TSS. But the 'qp group' interface to using this
>> seems
>> kludgy.
> lets try to be more specific
>
>> On a node, this is multiple send/receive queues grouped together to form a
>> larger
>> construct. On the wire, this is a s
> This patch introduces the concept of RSS and TSS QP groups which
> allows for implementing them by low level drivers and using it
> by IPoIB and later also by user space ULPs.
>
> A QP group is a set of QPs consists of a parent QP and two disjoint sets
> of RSS and TSS QPs. The creation of a QP g
23 matches
Mail list logo
