On Thu, 2006-07-13 at 17:18 -0700, Roland Dreier wrote:
> Arjan> it does get harder if this is needed for your IB device to
> Arjan> do more work, so that your swap device on your IB can take
> Arjan> more IO's to free up ram..
>
> That's the classic problem, but it's more a matter of
two Qs refers to openib kernel stack found in Redhat distribution (RHEL4 update
3)
(redhat kernel version: 2.4.18-14 #1):
1. if ib_poll_cq(cq, 1, &wc) returns zero, does wc contain a valid entry?
[just for reference what happend in gen1 stack
following code is from gen1 code where if similar
On Thu, 13 Jul 2006 18:18:35 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Having the caller hold a chunk of memory in a stack variable was the
> > trick I came up with to get around that.
>
> Yes, that certainly works.
Problem is, I think, you'll need to preallocate IDR_FREE_MAX items. A
Hi Sasha,
I agree. Your check is best.
Thanks.
Pat
Sorry if this is a duplicate I got a bounce earlier today.
>>> Sasha Khapyorsky <[EMAIL PROTECTED]> 07/12/06 6:45 PM >>>
Hi Pat,
On 15:14 Tue 11 Jul , Patrick Mullaney wrote:
> This will avoid an invalid warning about service level valu
On Thu, 13 Jul 2006 18:08:17 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> > Good point, a try-again loop would work. Do we really need the caller to
> > maintain a cache? I suspect something like
> >
> > drat:
> >if (idr_pre_get(GFP_KERNEL) == ENOMEM)
> >give_up();
>
> Good point, a try-again loop would work. Do we really need the caller to
> maintain a cache? I suspect something like
>
> drat:
> if (idr_pre_get(GFP_KERNEL) == ENOMEM)
> give_up();
> spin_lock();
> ret = idr_get_new();
> spin_unlock();
> if (ret
Steve Wise wrote:
> All,
>
> I added a quick "how to" on the wiki for the Chelsio T3 rnic...
>
> Steve.
>
>
>
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, ple
Arjan> it does get harder if this is needed for your IB device to
Arjan> do more work, so that your swap device on your IB can take
Arjan> more IO's to free up ram..
That's the classic problem, but it's more a matter of the consumer
using GFP_NOIO in the right places.
- R.
_
Steve Wise wrote:
> All,
>
> I added a quick "how to" on the wiki for the Chelsio T3 rnic...
>
> Steve.
>
>
>
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, ple
The following patch adds calls to the userspace RDMA CM to return its list
of RDMA devices. The calls are similar to ibv_get_device_list() /
ibv_free_device_list().
Currently, RDMA device contexts are handed to the user only after they
create an rdma_cm_id and bind it to a local device. By expos
Remove libsysfs usage from librdmacm.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---Index: configure.in
===
--- configure.in(revision 8215)
+++ configure.in(working copy)
@@ -25,8 +25,6 @@ AC_CHECK_SIZEOF(long)
dnl
All,
I added a quick "how to" on the wiki for the Chelsio T3 rnic...
Steve.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/o
On Thu, 13 Jul 2006 14:03:21 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> > I suspect it'll get really ugly. It's a container library which needs to
> > allocate memory when items are added, like the radix-tree. Either it needs
> > to assume GFP_ATOMIC, which is bad and can easily fail or
On Thu, 2006-07-13 at 14:03 -0700, Roland Dreier wrote:
> > I suspect it'll get really ugly. It's a container library which needs to
> > allocate memory when items are added, like the radix-tree. Either it needs
> > to assume GFP_ATOMIC, which is bad and can easily fail or it does weird
> > t
> I suspect it'll get really ugly. It's a container library which needs to
> allocate memory when items are added, like the radix-tree. Either it needs
> to assume GFP_ATOMIC, which is bad and can easily fail or it does weird
> things like radix_tree_preload().
Actually I don't think it has
On Thu, 13 Jul 2006 08:42:47 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> > Sigh. It was always a mistake (of the kernel programming 101 type) to put
> > any locking at all in the idr code. At some stage we need to weed it all
> > out and move it to callers.
> >
> > Your fix is yet mor
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: OFED 1.1 release - schedule and features
>
> > So if the link which ib0 maps to is DOWN you move the ib0 IPv4 address
> > to another device whose link is UP (eg ib1) and you somehow have ib1
> > send a gratuitous ARP?
>
> I think the
> It appears to me that if for some reason IPoIB rerequests a path that
> has already been resolved, it has filled in values for fields in the
> request which are not to be honored by the SA as their component mask
> bits are not on. While the SA responds properly to this since it ignores
> an
> So if the link which ib0 maps to is DOWN you move the ib0 IPv4 address
> to another device whose link is UP (eg ib1) and you somehow have ib1
> send a gratuitous ARP?
I think there may be a problem in the way IPoIB deals with gratuitous
ARPs. Because if a neighbour structure is updated by th
> BTW - we will need your help regarding SRP daemon changes that were
> implemented by Ishai for OFED 1.0 but have not make it then.
Hmm, I haven't seen any SRP daemon stuff that looked suitable yet. Is
there going to be an updated version sent out soon?
- R.
After some period of time(say about 20-30 seconds).
Right now, I am trying to rebuild the libraries with
latest code from iwarp branch.
Ravi
-Original Message-
From: Steve Wise [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 12:10 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; op
Steve Wise wrote:
> I guess this isn't surprising since rping doesn't work for you either.
> Something fundamental is screwed up on your user side methinks...
True..
Ravinandan why don't you do one thing. If you are running on an x86 platform,
send me (private mail) the rping binary, and all the
By the way, does this failure happen immediately or after some period of
time?
On Thu, 2006-07-13 at 13:27 -0500, Steve Wise wrote:
> I guess this isn't surprising since rping doesn't work for you either.
> Something fundamental is screwed up on your user side methinks...
>
> CM event 8 == RDMA_
On Mon, Jun 19, 2006 at 11:11:12AM -0400, Bill Wichser wrote:
>Running the openib stack from Redhat on a 2.6.9-34.ELsmp kernel, dual
>Xeon. Running with openmpi v1.0.2 compiled w/gcc.
>
>While we still have the problem with btl_openib_endpoint.c returning 0
>byte(s) for max inline data, and rea
I guess this isn't surprising since rping doesn't work for you either.
Something fundamental is screwed up on your user side methinks...
CM event 8 == RDMA_CM_EVENT_REJECTED which means either the server side
wasn't listening on the appropriate TCP port, or the server process did
an rdma_reject().
With the --cma option, I don't see the error about running SM.
But there's no connection established.
openfab2:/tmp/ib/src/userspace/perftest # ./rdma_lat --cma
pp_server_connect_cma starting server
openfab:/tmp/ib/src/userspace/perftest # ./rdma_lat --cma 17.2.2.102
pp_client_connect_cma startin
Sean Hefty wrote:
> I see two reasonable solutions here. One is to provide an enumeration of RDMA
> IP addresses. The second is to use the existing methods to enumerate all IP
> addresses, then provide a check to determine if an IP address is usable as an
> RDMA address. The current code does th
>Yes - I'm actually talking about a separate issue here. It looks like
>using the RDMA CM for multicast is going to require using it for all of
>my connection management, so I'm looking at what that entails.
>Currently I'm using only ibverbs and Open MPI's runtime environment layer.
The RDMA CM i
Thanks to all for the pointers and suggestions.
It will probably take me a while to follow up on these
and make another proposal.
On Thu, 2006-07-13 at 09:02 -0700, Roland Dreier wrote:
> > > A cleaner solution would be to make the dma_ API really use the device
> > > it's passed anyway, and all
Sean Hefty wrote:
>>I'm concerned about how rdma_cm abstracts HCAs. It looks like I can use
>>the src_addr argument to rdma_resolve_addr() to select which IP
>>address/HCA (assuming one IP per HCA), but how can I enumerate the
>>available HCAs?
>
>
> The HCA / RDMA device abstraction is there fo
> > A cleaner solution would be to make the dma_ API really use the device
> > it's passed anyway, and allow drivers to override the standard PCI
> > stuff nicely. But that would be major surgery, I guess.
> Clean but expensive, you should not force the rest of the kernel
> to eat the cost o
Andrew, could you please drop the following in -mm and on to Linus?
--
Avoid bogus out of memory errors: fix sa_query to actually pass gfp_mask
supplied by the user to idr_pre_get.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Acked-by: "Sean Hefty" <[EMAIL PROTECTED]>
Acked-by: "Roland
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] validate MADs issued from userspace for spec compliance
> C13-18.1.1
>
> Michael S. Tsirkin wrote:
> > This will be 2.6.18 material, right?
>
> I've committed this to svn. Assuming that further testing goes without a
> hitch, you
> Sigh. It was always a mistake (of the kernel programming 101 type) to put
> any locking at all in the idr code. At some stage we need to weed it all
> out and move it to callers.
>
> Your fix is yet more fallout from that mistake.
Agreed. Consider me on the hook to fix this up in a bett
Quoting r. Bernhard Fischer <[EMAIL PROTECTED]>:
> Is using the linux-kernel/infiniband driver from svn still the proper
> thing to do?
It depends on what you want to do I guess :)
> Does ipoib from svn build for the current kernel?
> hm.. Could it be that the current git repo is not supported bu
On Thu, Jul 13, 2006 at 05:32:07PM +0200, Bernhard Fischer wrote:
>On Thu, Jul 13, 2006 at 05:15:18PM +0300, Michael S. Tsirkin wrote:
>>Quoting r. Bernhard Fischer <[EMAIL PROTECTED]>:
>>> Subject: [patch] update uverbs_event_get_sb() to new get_sb_pseudo()
>>>
>>> Hi,
>>>
>>> get_sb_pseudo was
Andrew, could you please drop the following into -mm and on to Linus?
---
ib_fmr_pool_map_phys gets the virtual address by pointer but never writes there,
and users (e.g. srp) seem to assume this and ignore the value returned. This
patch cleans up the API to get the VA by value, and updates all u
On Thu, Jul 13, 2006 at 05:15:18PM +0300, Michael S. Tsirkin wrote:
>Quoting r. Bernhard Fischer <[EMAIL PROTECTED]>:
>> Subject: [patch] update uverbs_event_get_sb() to new get_sb_pseudo()
>>
>> Hi,
>>
>> get_sb_pseudo was changed but uverbs was not updated.
>
>svn only supports latest kernel.or
At 03:49 PM 7/12/2006, Fabian Tillier wrote:
Hi Mike,
On 7/12/06, Michael Krause <[EMAIL PROTECTED]> wrote:
At 09:48 AM 7/12/2006, Jeff Broughton wrote:
Modifying the sockets API is
just defining yet another RDMA API, and we have
so many already
I disagree. This effort has distilled the API
On Wed, 2006-07-12 at 21:45, Hal Rosenstock wrote:
[snip...]
> > I don't know if this is an HCA firmware issues, switch issue, or openSM
> > issue.
> > I don't think it's related to my changes or osmtest at this point.
>
> I'll see if I can reproduce this tomorrow.
I've followed your scenario
Hi Roland,
It appears to me that if for some reason IPoIB rerequests a path that
has already been resolved, it has filled in values for fields in the
request which are not to be honored by the SA as their component mask
bits are not on. While the SA responds properly to this since it ignores
anyth
Moshe Kazir wrote:
> I'm trying to use OFED 1.0 on sles9 SP3 PPC64 .
>
> OFED 1.0 requires sysfsutils to be installed .
>
> I tried to compile & install sysfsutils-1.2.0-4.src.rpm
>
> But found that it conflicts with udev--021-36 rpm
>
> Anyone knows to work around this problem ?
>
> Also,
>
>
Quoting r. Bernhard Fischer <[EMAIL PROTECTED]>:
> Subject: [patch] update uverbs_event_get_sb() to new get_sb_pseudo()
>
> Hi,
>
> get_sb_pseudo was changed but uverbs was not updated.
svn only supports latest kernel.org release.
>
> PS: should nowadays the in-kernel impl be used instead of t
Are you trying to run this over iwarp? It doesn't need an SM...
For the perftests rdma_lat and rdma_bw in the iwarp branch, use the
--cma flag.
Steve.
On Wed, 2006-07-12 at 16:39 -0700, Ravinandan Arakali wrote:
> Also, I am trying to run some of the iwarp bandwidth/latency tests
> (available
I'm trying to use OFED 1.0 on sles9 SP3 PPC64 .
OFED 1.0 requires sysfsutils to be installed .
I tried to compile & install sysfsutils-1.2.0-4.src.rpm
But found that it conflicts with udev--021-36 rpm
Anyone knows to work around this problem ?
Also,
OFED 1.0 is svn rev 8031 while patche
Hi,
get_sb_pseudo was changed but uverbs was not updated.
PS: should nowadays the in-kernel impl be used instead of the one in
svn?
Signed-off-by: Bernhard Fischer <[EMAIL PROTECTED]>
Index: uverbs_main.c
===
--- uverbs_main.c
On Thu, 2006-07-13 at 07:52, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > In file included from cl_memory.c:55:
> > > ./../include/complib/cl_memtrack.h:99: warning: `cl_mem_tracker_t' is
> > > deprecated (declared at ./../include/complib/cl_memtrack.h:82)
> > >
On Thu, 2006-07-13 at 06:48, Dotan Barak wrote:
> On Thursday 13 July 2006 13:25, Hal Rosenstock wrote:
> > > ./../include/complib/cl_memtrack.h:99: warning: `cl_mem_tracker_t' is
> > > deprecated (declared at ./../include/complib/cl_memtrack.h:82)
> > > cl_memory.c:74: warning: `cl_mem_tracker_t'
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > In file included from cl_memory.c:55:
> > ./../include/complib/cl_memtrack.h:99: warning: `cl_mem_tracker_t' is
> > deprecated (declared at ./../include/complib/cl_memtrack.h:82)
> > cl_memory.c:74: warning: `cl_mem_tracker_t' is deprecated (decla
On Thu, 2006-07-13 at 03:58, Dotan Barak wrote:
> Hi.
>
> I noticed that there are warnings during the compilation of the gen2 driver.
>
> machine props:
> *
> Host Architecture : x86_64
> Linux Distribution: Red Hat Enterprise Linux AS
On Thursday 13 July 2006 13:25, Hal Rosenstock wrote:
> > ./../include/complib/cl_memtrack.h:99: warning: `cl_mem_tracker_t' is
> > deprecated (declared at ./../include/complib/cl_memtrack.h:82)
> > cl_memory.c:74: warning: `cl_mem_tracker_t' is deprecated (declared at
> > ./../include/complib/cl
Tziporet Koren wrote:
> Roland Dreier wrote:
> Since the technical details were not in this mail some features seems a
>> > * IPoIB
>> > - Bonding - for high availability
>> that have had no work done (in public at least) yet to be integrated.
>> If 1.1 is going to go to code
Roland Dreier wrote:
> To me this schedule seems too short to expect real new features like
>
Since the technical details were not in this mail some features seems a
lot of changes while they are not (to be explained).
> > - HCA fatal - full flow support
>
We just want to use the cu
Michael S. Tsirkin wrote:
> Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
>> We have a fix for iSER's Kconfig and i wonder if its fine to send it now
>> also.
> Where? Was this iSER Kconfig patch posted on openib? lkml? I can't find
> anything
> in the archives ...
Since i was thinking its not 2.
Dhabaleswar Panda wrote:
> Tziporet,
>
>
>> - Based on 0.97 (we will not move to 0.98 since we tested it and
>> found it is less stable then 0.97)
>>
>
> Could you please indicate which version of 0.9.8 you tested and what
> are the exact problems you have faced.
>
We are running
Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] IB/ipoib: remove broken link from Kconfig and
> documentation
>
> Roland - is this 2.6.18 (bugfixes) material?
Looks safe enough :)
> We have a fix for iSER's Kconfig and i wonder if its fine to send it now also.
Where? Was this
Hi, Roland!
Here's a small mthca patch from Dotan Barak.
---
mthca: fix limit event range check for memfree.
Signed-off-by: Dotan Barak <[EMAIL PROTECTED]>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: openib/drivers/infiniband/hw/mthca/mthca_srq.c
===
Hi.
I noticed that there are warnings during the compilation of the gen2 driver.
machine props:
*
Host Architecture : x86_64
Linux Distribution: Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
Kernel Version: 2.6.9-22.ELsmp
M
Roland - is this 2.6.18 (bugfixes) material?
We have a fix for iSER's Kconfig and i wonder if its fine to send it now also.
Or.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe
remove references to the IPoIB IETF working group as it has been closed.
Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/ulp/ipoib/Kconfig
b/drivers/infiniband/ulp/ipoib/Kconfig
index 13d6d01..d74653d 100644
--- a/drivers/infiniband/ulp/ipoib/Kconfig
+++ b/drivers/i
David Miller wrote:
> If you need device level DMA mapping semantics, create them for your
> device type. This is what USB does, btw.
Ralph,
two other examples where drivers provide some sort of address lookup are:
- drivers/ieee1394/dma.[hc]
AFAIK this deals with housekeeping of ringbuffers
61 matches
Mail list logo
