>How about user taking this into account and not arming the CQ /
>not polling it until the established event?
The CQ could be in use by other QPs.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openi
>OFED is tracking 2.6.18 so to get things there they need to be submitted to
>Roland's for-2.6.18 tree.
I downloaded Linus' latest tree today, and will submit a patch tomorrow.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://ope
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: design for communication established affiliated asynchronous
> event handling
>
> >I suggest the following design: the CMA would replace the event handler
> >provided with the qp_init_attr struct with a callback of its own and
> >keep t
Quoting r. [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Subject: [openib-general] [Bug 160] OFED1.0: ib_modify_qp() of RC QP fails
> with -EINVAL
>
> http://openib.org/bugzilla/show_bug.cgi?id=160
>
>
>
>
>
> --- Comment #1 from [EMAIL PROTECTED] 2006-06-28 15:52 ---
> Thanks for the in
"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote:
>
> Hi, Andrew -
>
> I have a pile of patches for the ipath driver that I'd like to get in
> during the "open season" window. Roland has his hands full with diapers
> and other sprog paraphernalia as of a few days ago, so I doubt he'll see
> this mess
Hi, Andrew -
I have a pile of patches for the ipath driver that I'd like to get in
during the "open season" window. Roland has his hands full with diapers
and other sprog paraphernalia as of a few days ago, so I doubt he'll see
this message soon, much less care about the patches.
Given Roland's
Roland Dreier wrote:
>>I suggest the following design: the CMA would replace the event handler
>>provided with the qp_init_attr struct with a callback of its own and
>>keep the original handler/context on a private structure.
>
>
> This is probably fine. There is one further situation where the
http://openib.org/bugzilla/show_bug.cgi?id=160
--- Comment #1 from [EMAIL PROTECTED] 2006-06-28 15:52 ---
Thanks for the info. I have committed the fix to SVN revision 8267. The OFED
release will need to be updated separately.
--- You are receiving this mail because: ---
http://openib.org/bugzilla/show_bug.cgi?id=160
Summary: OFED1.0: ib_modify_qp() of RC QP fails with -EINVAL
Product: OpenFabrics Linux
Version: gen2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority
At 10:51 AM 6/28/2006, Michael S. Tsirkin wrote:
>Yep. We could have an option to have the stack scale the requested values down
>to some legal set instead of failing an allocation. But we couldn't come up
>with a clean way to tell the stack e.g. what should it round down: the SGE or
>WR value.
[EMAIL PROTECTED] wrote on Wed, 28 Jun 2006 17:51 +0300:
> Yea, that's because the API only can report 1 max value. But when
> this was considered the concensus was its not worth extending the API
> because of the other issues you mention.
Maybe you should report min(max_recv_sge, max_send_sge) in
http://openib.org/bugzilla/show_bug.cgi?id=159
Summary: OFED1.0: Missing interfaces
Product: OpenFabrics Linux
Version: gen2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Compone
Hello, stable team!
The pull of the following fix was requested by Roland Dreier just a couple of
days before 2.6.17 came out, and so it seems it missed 2.6.17 by a narrow
margin:
http://lkml.org/lkml/2006/6/13/164
It is now upsteam:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.g
>
> Yep. We could have an option to have the stack scale the
> requested values down to some legal set instead of failing an
> allocation. But we couldn't come up with a clean way to tell
> the stack e.g. what should it round down: the SGE or WR
> value. Do you think selecting something arbit
Quoting r. Pete Wyckoff <[EMAIL PROTECTED]>:
> Subject: Re: max_send_sge < max_sge
>
> [EMAIL PROTECTED] wrote on Wed, 28 Jun 2006 01:38 +0300:
> > If this works for you, great. I was just trying to point out query device
> > can not guarantee that QP allocaton will always succeed even if you stay
Quoting r. Talpey, Thomas <[EMAIL PROTECTED]>:
> Subject: Re: max_send_sge < max_sge
>
> At 08:42 AM 6/28/2006, Michael S. Tsirkin wrote:
> >Quoting r. Talpey, Thomas <[EMAIL PROTECTED]>:
> >> Just some ideas. I feel your pain.
> >
> >Is there something that would make life easier for you?
>
> A
[EMAIL PROTECTED] wrote on Wed, 28 Jun 2006 01:38 +0300:
> If this works for you, great. I was just trying to point out query device can
> not guarantee that QP allocaton will always succeed even if you stay within
> limits it reports.
>
> For example, are you using a large number of WRs per QP as
At 08:42 AM 6/28/2006, Michael S. Tsirkin wrote:
>Quoting r. Talpey, Thomas <[EMAIL PROTECTED]>:
>> Just some ideas. I feel your pain.
>
>Is there something that would make life easier for you?
A work-request-based IBTA1.2/iWARP-compliant FMR implementation.
Please. :-)
Tom.
__
Quoting r. Talpey, Thomas <[EMAIL PROTECTED]>:
> Just some ideas. I feel your pain.
Is there something that would make life easier for you?
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-gene
Yep, you're confirming my comment that the sge size is dependent
on the memory registration strategy (and not the protocol itself).
Because you have a pool approach, you potentially have a lot of
discontiguous regions. Therefore, you need more sge's. (You could
have the same issue with large prereg
Title: Main Signature Signature
The attached patch fixes the description of iSER in Kconfig.
--
Erez
Zilber | 972-9-971-7689
Software
Engineer, Storage Team
Voltaire
– The Grid Backbone
www.voltaire.com
Index
21 matches
Mail list logo
