[openib-general] Getting the code and locking user space memory regions

2005-03-07 Thread Timur Tabi
Hi, A long time ago, the openib driver used a hack to call sys_mlock() to lock down a user space memory region. This was because get_user_pages() wasn't completely locking the region like it was supposed to. I haven't paid much attention to the openib stuff since then, but now I want to know w

Re: [openib-general] Re: [RFC] userspace CM/verbs QP

2005-03-07 Thread Libor Michalek
On Mon, Mar 07, 2005 at 01:26:19PM -0800, Sean Hefty wrote: > Libor Michalek wrote: > > Sean, I'm not sure there's an easy way to perform a port source GID > > to device lookup, did you have something specific in mind for the > > lookup? Unless there's an easy way to do this, I was going to go ahea

Re: [openib-general] Re: [RFC] userspace CM/verbs QP

2005-03-07 Thread Sean Hefty
Libor Michalek wrote: Sean, I'm not sure there's an easy way to perform a port source GID to device lookup, did you have something specific in mind for the lookup? Unless there's an easy way to do this, I was going to go ahead with #1... There's a device_list maintained in device.c that's used when

Re: [PATCH] might_sleep on con_lock (was Re: [openib-general] SDP_CONN_LOCK)

2005-03-07 Thread Libor Michalek
On Sun, Mar 06, 2005 at 12:38:40PM +0200, Michael S. Tsirkin wrote: > Quoting r. Libor Michalek <[EMAIL PROTECTED]>: > > Subject: Re: [openib-general] SDP_CONN_LOCK > > > > They do implement exclusive access to the socket, but they implement > > > > exclusive access from both process and irq cont

Re: [openib-general] Re: [RFC] userspace CM/verbs QP

2005-03-07 Thread Libor Michalek
On Mon, Mar 07, 2005 at 11:14:07AM -0800, Sean Hefty wrote: > Roland Dreier wrote: > > 1. Don't worry about checking. There's nothing too evil a CM user > > can do with a QP beyond getting another QP to connect to it, since > > the CM user can't modify a QP unless it legitimately owns it.

[openib-general] Re: [PATCH][SDP] Make sdp compile on 2.6.11

2005-03-07 Thread Libor Michalek
On Wed, Mar 02, 2005 at 10:11:34AM -0800, Tom Duffy wrote: > Now that 2.6.11 is out, need to make sdp compile with 2.6.11. > Thanks Tom, applied and commited. -Libor ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/li

Re: [openib-general] Re: [RFC] userspace CM/verbs QP

2005-03-07 Thread Sean Hefty
Roland Dreier wrote: 1. Don't worry about checking. There's nothing too evil a CM user can do with a QP beyond getting another QP to connect to it, since the CM user can't modify a QP unless it legitimately owns it. And an evil user can always guess the QPN instead of the QP handle a

Re: [openib-general] IB Address Translation service

2005-03-07 Thread Michael Krause
Just to make this clear: - There are only two QP that are defined with specific intention - QP0 and QP1.  All other QP may vary throughout the entire QP space.  - All ULP built on top of IB must assume that the QP are variant and must discover these through various protocol such as the service

Re: [openib-general] mthca drvier on PPC platform

2005-03-07 Thread Roland Dreier
Shirley> I am starting to test mthca driver on PPC64. I want to Shirley> know whether someone has tested mthca on any PPC platform? Yes, I have used it successfully on IBM p630 and JS20 systems. - Roland ___ openib-general mailing list openib-g

[openib-general] userspace verbs UD support

2005-03-07 Thread Roland Dreier
I've just committed support for UD address handles to libibverbs and libmthca on the roland-uverbs branch. This makes it possible to use UD from userspace. libibverbs/examples has a new ud-pingpong.c demo program that shows how this works. There are no new changes to the kernel uverbs support on

[openib-general] mthca drvier on PPC platform

2005-03-07 Thread Shirley Ma
I am starting to test mthca driver on PPC64. I want to know whether someone has tested mthca on any PPC platform? Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone(Fax): (503) 578-7638 ___ openib-general

[openib-general] Re: mthca query_device does not fill in struct ib_device_attr

2005-03-07 Thread Hal Rosenstock
On Mon, 2005-03-07 at 11:55, Roland Dreier wrote: > OK, it won't be hard to fill out those entries. What application is > using this info? uDAPL (and kDAPL) use these device attributes currently. -- Hal ___ openib-general mailing list openib-general@o

[openib-general] Re: mthca query_device does not fill in struct ib_device_attr

2005-03-07 Thread Roland Dreier
Hal> Certainly the following ones: OK, it won't be hard to fill out those entries. What application is using this info? - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscrib

[openib-general] Re: mthca query_device does not fill in struct ib_device_attr

2005-03-07 Thread Hal Rosenstock
On Mon, 2005-03-07 at 11:32, Roland Dreier wrote: > Hal> It appears that mthca_provider.c::mthca_query_device does not > Hal> fill in many of the device attributes in struct > Hal> ib_device_attr. When can the remainder of these be completed? > > Any time... which ones are needed now?

[openib-general] Re: mthca query_device does not fill in struct ib_device_attr

2005-03-07 Thread Roland Dreier
Hal> It appears that mthca_provider.c::mthca_query_device does not Hal> fill in many of the device attributes in struct Hal> ib_device_attr. When can the remainder of these be completed? Any time... which ones are needed now? - R. ___ open

[openib-general] mthca query_device does not fill in struct ib_device_attr

2005-03-07 Thread Hal Rosenstock
Hi Roland, It appears that mthca_provider.c::mthca_query_device does not fill in many of the device attributes in struct ib_device_attr. When can the remainder of these be completed ? Thanks. -- Hal ___ openib-general mailing list openib-general@openib

[openib-general] Re: rev 1954 - new flint uploaded

2005-03-07 Thread Michael S. Tsirkin
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>: > Subject: rev 1954 - new flint uploaded > > With revision 1954 I have uploaded new flint code, > synched with current mellanox code. I made some last minute fixes and uploaded rev 1957. Enjoy! > There are lots of changes, since this adds suppor