> > +/*
> > + * ipath_vma_nopage - handle a VMA page fault.
> > + */
> > +static struct page *ipath_vma_nopage(struct vm_area_struct *vma,
> > + unsigned long address, int *type)
> > +{
> > + struct ipath_mmap_info *ip = vma->vm_private_data;
> > + unsigned l
> > struct ib_uverbs_resize_cq_resp {
> >__u32 cqe;
> > + __u32 reserved;
> > + __u64 driver_data[0];
> > };
>
> I don't see any changes related to this in uverbs_cmd.c, and you don't
> bump the ABI version. So as far as I can tell, ib_uverbs_resize_cq()
> will silently corrupt the st
> > int ibv_cmd_resize_cq(struct ibv_cq *cq, int cqe,
> > -struct ibv_resize_cq *cmd, size_t cmd_size);
> > +struct ibv_resize_cq *cmd, size_t cmd_size,
> > +struct ibv_resize_cq_resp *resp, size_t resp_size);
>
> We can't make this change withou
> Ralph Campbell wrote:
>> The following patches update libibverbs, libmthca, libipathverbs,
>> and the kernel ib_core, ib_mthca, ib_ehca, and ib_ipath modules in
>> order to improve performance on QLogic InfiniPath HCAs.
>
> (With probably not being enough into the details of what you are
> changi
> ralphc> We had a power failure here so I'm not able to reproduce
> ralphc> the assembly code at the moment. What I remember from
> ralphc> looking at the code is that the code for
> ralphc> ipath_read_kreg32() was present in i2c_wait_for_writes()
&g
> ralphc> I don't have a lot to add to this other than I looked at
> ralphc> the assembly code output for -Os and -O3 and both looked
> ralphc> OK. I put the mb() in to be sure the writes were complete
> ralphc> and I found this to work by
> On Mon, 2006-05-15 at 08:57 -0700, Roland Dreier wrote:
>> > static void i2c_wait_for_writes(struct ipath_devdata *dd)
>> > {
>> > + mb();
>> > (void)ipath_read_kreg32(dd, dd->ipath_kregs->kr_scratch);
>> > }
>>
>> This needs a comment explaining why it's needed. A memory barrier
>> be
> Hello Ralph,
>
>
> Thanks for sharing the info.
>
>> Then I built svn/gen2/trunk/src/userspace/mpi/mvapich-gen2.
>> I was able to get osu_latency & osu_bw to run using:
>> mpirun_rsh -np 2 -debug -hostfile ./mf ~/mvapich1/bin/osu_latency
>> but when I run it without -debug, I get a "Connection re
> Hello Ralph,
>
>
> Thanks for sharing the info.
>
>> Then I built svn/gen2/trunk/src/userspace/mpi/mvapich-gen2.
>> I was able to get osu_latency & osu_bw to run using:
>> mpirun_rsh -np 2 -debug -hostfile ./mf ~/mvapich1/bin/osu_latency
>> but when I run it without -debug, I get a "Connection re
ify that no new entries have been
added. I haven't verified that this fixes my problem,
just visual inspection based on the standard as I was reading
the code.
> ralphc> There is a race in IPoIB where it rearms the CQ by calling
> ralphc> ib_req_notify_cq() followed by ib_poll_
There is a race in IPoIB where it rearms the CQ by calling
ib_req_notify_cq() followed by ib_poll_cq(). The loop
can call ib_poll_cq() multiple times if new packets arrive
but then fail to rearm the CQ properly.
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Index: openib/src/linux-kernel/inf
>
> On Fri, 17 Mar 2006, Bryan O'Sullivan wrote:
>
>> > In our own testing, we were unable to use the SRQ support via the
>> ipath
>> > driver. Perhaps someone from Pathscale could comment on the stability
>> of
>> > SRQ support?
>>
>> Our SRQ code should be stable; we've no customer-reported bugs
I was browsing through the libibverbs code and found a minor memory
leak. Here is the fix.
Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
Index: openib/src/userspace/libibverbs/src/init.c
===
--- openib/src/userspace/libibverbs/s
Please note that the patch I sent out is more for comment.
I would like to test it and think about it some more before
committing to it. I may have a simpler solution but I
have to think about it first.
Ralph Campbell
___
openib-general mailing list
op
14 matches
Mail list logo
