Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: Re: RFC: e2e credits
>
> On Sat, 2006-03-25 at 11:59, Michael S. Tsirkin wrote:
> > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > However we have this, towards the end of page 355.
> > > >
> > > >
> > > >
> > > > "Even a res
On Sat, 2006-03-25 at 11:59, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > However we have this, towards the end of page 355.
> > >
> > >
> > >
> > > "Even a responder which does generate end-to-end credits may choose to
> > > send
> > > the 'invalid' code
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > However we have this, towards the end of page 355.
> >
> >
> >
> > "Even a responder which does generate end-to-end credits may choose to send
> > the 'invalid' code in the AETH"
> >
> >
> >
> > This seems to imply that HCA (which mus
On Fri, 2006-03-24 at 07:08, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> >
> > I did some spec reading to find this and found the following which I
> > think makes the current requirement clear:
> >
> > p.347 line 37 states "HCA receive queues must generate end-to
At 03:31 AM 3/24/2006, Hal Rosenstock wrote:
On Thu, 2006-03-23 at 12:34,
Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > > > > > > >Sean, just to wrap it
up, the API at the verbs layer will look
> > > > > > > > > >like the below, and then
ULPs just put the valu
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
>
> I did some spec reading to find this and found the following which I
> think makes the current requirement clear:
>
> p.347 line 37 states "HCA receive queues must generate end-to-end
> credits (except for QPs associated with a SRQ), but TCA rece
On Thu, 2006-03-23 at 12:34, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > > > > > > >Sean, just to wrap it up, the API at the verbs layer will
> > > > > > > > > >look
> > > > > > > > > >like the below, and then ULPs just put the value they want in
> > > > > >
On Thu, 23 Mar 2006, Michael S. Tsirkin wrote:
mst> Guys, please review the verbs.h extension below - I'll be
mst> submitting a patch including CM update and mthca implementation
mst> next week. Anyone has a problem with this?
mst>
mst> Index: openib/drivers/infiniband/include/rdma/ib_user_ve
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > > > > > >Sean, just to wrap it up, the API at the verbs layer will look
> > > > > > > > >like the below, and then ULPs just put the value they want in
> > > > > > > > >the CM and CM will pass it in to low level.
So this is our question, right?
On Thu, 2006-03-23 at 12:09, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > Subject: Re: RFC: e2e credits
> >
> > On Thu, 2006-03-23 at 11:41, Michael S. Tsirkin wrote:
> > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > Subject: Re: RFC: e2e credits
> > >
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: Re: RFC: e2e credits
>
> On Thu, 2006-03-23 at 11:41, Michael S. Tsirkin wrote:
> > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > Subject: Re: RFC: e2e credits
> > >
> > > On Thu, 2006-03-23 at 11:13, Michael S. Tsirkin wrote:
> > >
On Thu, 2006-03-23 at 11:41, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > Subject: Re: RFC: e2e credits
> >
> > On Thu, 2006-03-23 at 11:13, Michael S. Tsirkin wrote:
> > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > > >Sean, just to wrap it up, the API
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: Re: RFC: e2e credits
>
> On Thu, 2006-03-23 at 11:13, Michael S. Tsirkin wrote:
> > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > >Sean, just to wrap it up, the API at the verbs layer will look like the
> > > > >below, and then ULP
On Thu, 2006-03-23 at 11:13, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > >Sean, just to wrap it up, the API at the verbs layer will look like the
> > > >below, and then ULPs just put the value they want in the CM and CM will
> > > >pass it in to low level.
> > >
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > >Sean, just to wrap it up, the API at the verbs layer will look like the
> > >below, and then ULPs just put the value they want in the CM and CM will
> > >pass it in to low level.
> >
> > I'm fine with this, but I do think that it's a minor spec
>
On Wed, 2006-03-22 at 18:26, Sean Hefty wrote:
> >Sean, just to wrap it up, the API at the verbs layer will look like the
> >below,
> >and then ULPs just put the value they want in the CM and CM will pass
> >it in to low level.
>
> I'm fine with this, but I do think that it's a minor spec
> viol
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RFC: e2e credits
>
> >Sean, just to wrap it up, the API at the verbs layer will look like the
> >below,
> >and then ULPs just put the value they want in the CM and CM will pass
> >it in to low level.
>
> I'm fine with this, but I do think tha
>> So, how about we add a flag to ib_qp_init_attr?
>> Something like
>> responder_invalid_credits
>>
>> Which will, for RC QPs, cause the responder to always
>> generate invalid credits, effectively disabling hardware E2E
>> flow control for this receive queue. ULPs will turn this on
>> if t
[EMAIL PROTECTED] wrote:
> Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
>> Hello!
>> As was recently discussed on this list, infiniband implements an
>> optional hardware end to end credits mechanism, with credits encoded
>> in the AETH field in an ACK packet.
>>
>> The result is that an app
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Hello!
> As was recently discussed on this list, infiniband implements
> an optional hardware end to end credits mechanism, with credits
> encoded in the AETH field in an ACK packet.
>
> The result is that an application might see performance de
20 matches
Mail list logo
