On Mon, Apr 03, 2006 at 02:59:03PM +0300, Or Gerlitz wrote:
> Haven't heard from you re the patch you have supplied me which removes
> at least this SCSI IOCTL issuing a non SG SCSI command. As i wrote you i
> have patched 2.6.16 and tested it, works great. Is it queued for 2.6.17?
It's in scsi-
hi i have started working over infiniband network in my work i am using openib stack which is available along with RHEL4 update 3 and i tried my benchmark to test the performance the figures are not convincing (max 260Mbps at 10Mb data rate) can anybody send me the typical performance
Hi,
Thanks for pointing me to the latest firmware/boot loader.
After I uninstalled the Ammasso Software, I was able to succesfully update
and load the firmware and also the module. It worked fine on one machine
but on another machine, when I try to bring the eth2 interface up, the
machine hangs.
皆さん、どんなエッチを楽しんでいますか？
今、話題で人気なのがやっぱり即アポ即エッチにムンムンなフェロモンを放つ『人妻』。
そんな人妻とちょっと大人の秘密の出会いを…
でもどうやって！？と思ったり感じたりしてませんか？
彼女たちの本気(マジ)にエロイ実態を大公開♪
そしてそんなサポートをしてくれる『２丁目の奥様』のご紹介、そして出逢いパーティーのお知らせです！！
http://okusama.ock-gatu.com/2cco
出逢い┓┏┓┏┓.*・°☆.。.:*・°☆.。.:*・°☆.。.:*・°☆
確立♪┻┗┛┗％…┓┏━┓┏…┓┏━┓┏…┓┏━┓
┃直┃┃ア┃┃
OK, I applied the original patch here, along with this on top of it:
IPoIB: Use spin_lock_irq() instead of spin_lock_irqsave()
We know ipoib_flush_paths() is called from plain process context with
interrupts enabled, since it does wait_for_completion(). So there's
no need to
On Thu, Apr 06, 2006 at 07:16:25PM -0700, Manpreet Singh wrote:
> Doug,
>
> Thanks for the updated rpms. Just curious as to what svn revision of openib
> you used for the rpms.
>
> Do the IB tools (if compiled separately) have to be from the same svn
> revision?
Usually, they don't have to be id
On Fri, Apr 07, 2006 at 12:30:04AM +0300, Michael S. Tsirkin wrote:
> Quoting r. Doug Ledford <[EMAIL PROTECTED]>:
> > Just to make that point
> > clear, I've removed the old RPMs from my site and put up a new set of kernel
> > rpms based on the 1.0 release branch code (userspace rpms will be a lit
Doug,
Thanks for the updated rpms. Just curious as to what svn revision of openib you used for the rpms.
Do the IB tools (if compiled separately) have to be from the same svn revision?
Thanks,
Manpreet.
On 4/6/06, Doug Ledford <[EMAIL PROTECTED]> wrote:
On Wed, Apr 05, 2006 at 07:04:29PM -0700,
A quick followup. I have just build/configure and propagated the
mvapich-gen2 installation on two EM64T nodes as root. mvapich-gen2 runs
fine with MPD_RING option. Here are the commands I had used. Hope they
could help.
1) prepare your mpd passwd/conf files: /root/.mpdpasswd and
/root/.mpd.co
Dear Home O w n e r ,
Your credit doesn't matter to us !
If you O W N real e s t a t e and want l M M E D l A T E c a s h to s p e n d ANY way you
like, or simply wish to L O W E R your monthly p a y m e n t s by a third or more,
here are the deals we have T O
Hi, Don,
Good to know that you are able to run mvapich with mpirun_rsh. We can
now focus on MPD problem. We never had attempted to run MPD_RING option
as root user. Just curious, were you able to mvapich2-gen2 with
MPD_RING? They are more or less similar code. So could you try the
following t
>> Maybe we should give up the ghost and stop trying to support IB switches?
>
>IMHO, the main reason to have the IB stack on a switch is to support
>ipoib for in band management with a stable and well tested code base.
>My company is looking closely at doing this in our switches and I'd be
>surpri
On Thu, Apr 06, 2006 at 12:51:23PM -0700, Roland Dreier wrote:
> Maybe we should give up the ghost and stop trying to support IB switches?
IMHO, the main reason to have the IB stack on a switch is to support
ipoib for in band management with a stable and well tested code base.
My company is looki
Sean Hefty wrote:
+static inline int
+rdma_resolve_ip(struct sockaddr *src_addr, struct sockaddr *dst_addr,
+ struct rdma_dev_addr *addr, int timeout_ms,
+ void (*callback)(int status, struct sockaddr *src_addr,
+struct rdma_dev_addr *ad
Weikuan
I previously reported that I was having
problems running any MPI jobs between a pair of EM64T machines with RHEL4,
Update 3 with the OpenIB modules, (kernel versions 2.6.9-34.ELsmp)
and the "mvapich-gen2" code from the OpenIB svn tree.
I was having two problems:
When I tried to run
V A L t U M 1, 22 $ C t A L t S 3, 74 $ V t A G R A 3, 36 $
get more information - http://toaep990.paitemidde.com___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, pl
Hi Hal and others,
I find that, there are no standard header files
exists at userspace which can define structure for PORT_INFO, NODE_INFO and
other elements like Path Records, Service record etc.
So every individual has to define his own header
files to define the data structures for these
> Steve, can you test this version and see if it works for your iWARP device.
>
I think the patch is good.
I ran dapltest/regress.sh over the chelsio iwarp device using this new
patch instead of my original patch, and things seem as stable as they
were before (i'm fighting some intermittent con
Hello!
Just wanted to let everyone know Jiuxing has populated a mercurial
tree (very kindly hosted by XenSource) with his code at the following site:
http://xenbits.xensource.com/ext/xen-smartio.hg
This contains the current source code for a xen infiniband frontend
and backend driver. The sou
Hello!
Just wanted to let everyone know Jiuxing has populated a mercurial
tree (very kindly hosted by XenSource) with his code at the following site:
http://xenbits.xensource.com/ext/xen-smartio.hg
This contains the current source code for a xen infiniband frontend
and backend driver. The sou
>> Only one MAD request per group is active at any time, regardless if the MAD
>is
>> for a join or leave.
>
>One request per group or (per group and join state) ?
Per group - with a group identified by an MGID. The intent is to ensure that
the state of the group is not driven in different direct
Quoting r. Eli Cohen <[EMAIL PROTECTED]>:
> Subject: [PATCH] ipoib_flush_paths
>
> ib_sa_cancel_query must be called with priv->lock held since
> a completion might arrive and set path->query to NULL
>
> Signed-off-by: Eli Cohen <[EMAIL PROTECTED]>
>
Roland, with all the noise about module unlo
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: librdmacm/ucma
>
> Michael S. Tsirkin wrote:
> >I just propose killing old ABI support in librdmacm - CMA is sufficiently
> >new for that.
>
> I'm fine doing that. The ABI versions can be reset to 1.
Yes, let's do that,
--
MST
On Thu, 2006-04-06 at 17:56, Sean Hefty wrote:
> >There's also code in opensm/osm_sa_mcmember_record.c that you can
> >peruse.
>
> Thanks - that's helpful.
>
> >> The code uses a promotion/demotion mechanism based on a reference count of
> >> membership types. The restriction is that only a sing
Michael S. Tsirkin wrote:
OK, this means we must add struct module * pointer to ib_create_cm_id
and rdma_create_cm_id as well.
Could one of you guys build and commit such a patch for these modules?
I'm not in the lab.
I will create the patches for these.
- Sean
___
Hal> Is it more than the MCMemberRecord RID ? I suppose this keeps
Hal> things simpler anyhow.
Not really. MCMemberRecord RID identifies a single member of a group,
so it needs both MGID and port GID. This means that a group is
identified by just the MGID.
- R.
Michael S. Tsirkin wrote:
I just propose killing old ABI support in librdmacm - CMA is sufficiently
new for that.
I'm fine doing that. The ABI versions can be reset to 1.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib
>There's also code in opensm/osm_sa_mcmember_record.c that you can
>peruse.
Thanks - that's helpful.
>> The code uses a promotion/demotion mechanism based on a reference count of
>> membership types. The restriction is that only a single request per group is
>> active at a time.
>
>Meaning only
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Note that ib_cm and rdma_cm technically have the same issue, since cm_id's can
> be destroyed by returning non-zero from a callback. I.e. a user of those
> interfaces isn't forced to call anything when unloading.
OK, this means we must add struct modul
On Thu, 2006-04-06 at 17:21, Sean Hefty wrote:
> >> I don't think it's needed. MGID and PortGID together form the record
> >> identifier for multicast groups.
> >
> >I see your point so perhaps it is not needed. For IPoIB, that clearly
> >works as the PKey is embedded in the MGID. I didn't think t
On Thu, 2006-04-06 at 17:17, Roland Dreier wrote:
> Hal> I see your point so perhaps it is not needed. For IPoIB, that
> Hal> clearly works as the PKey is embedded in the MGID. I didn't
> Hal> think that was the case with generalized IB multicast.
>
> A multicast group is uniquely iden
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: Re: librdmacm/ucma
>
> >Put another way - why do you already have backward compatibility hacks
> >in lirdmacm? There wasn't any released version of cma, was there?
>
> Because the behavior of the ABI changed. The CMA was released to openi
>Put another way - why do you already have backward compatibility hacks
>in lirdmacm? There wasn't any released version of cma, was there?
Because the behavior of the ABI changed. The CMA was released to openib, but
has not yet been merged upstream. What is the issue here? The CMA ABI now
behav
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: Re: librdmacm/ucma
>
> Michael S. Tsirkin wrote:
> >In normal usage I expect we must not break the ABI, but should rather
> >extend it - without breaking userspace. How do you extend the ABI?
> >not by bumping the ABI revision? How does use
James and Steve,
Here is revised patch that was tested (free and debug build versions) with
dtest, dapltest, and
Intel MPI test suites. The rdma_destroy_id will block until we acknowledge the
event so there was no
need to add our own wait objects for synchronization. This will never be called
f
Quoting r. Doug Ledford <[EMAIL PROTECTED]>:
> Just to make that point
> clear, I've removed the old RPMs from my site and put up a new set of kernel
> rpms based on the 1.0 release branch code (userspace rpms will be a little
> later).
Doug, is this
https://openib.org/svn/gen2/branches/1.0/src/li
On Thu, 2006-04-06 at 17:01, Sean Hefty wrote:
> >1. My main initial comment is that I think that cmp_rec needs to be more
> >complicated that the matching which is there. The selectors include
> >things like greater than, less than, and largest available in addition
> >to equal to which is what is
Michael S. Tsirkin wrote:
In normal usage I expect we must not break the ABI, but should rather
extend it - without breaking userspace. How do you extend the ABI?
not by bumping the ABI revision? How does userspace find out
whether kernel supports new features?
If the ABI didn't break, can't us
>> I don't think it's needed. MGID and PortGID together form the record
>> identifier for multicast groups.
>
>I see your point so perhaps it is not needed. For IPoIB, that clearly
>works as the PKey is embedded in the MGID. I didn't think that was the
>case with generalized IB multicast.
It does
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] Re: librdmacm/ucma
>
> Michael S. Tsirkin wrote:
> >The library now has
> >min = 1 max = 2
> >this means that any ABI update in kernel will break userspace.
>
> Isn't that what it means to break the ABI?
In normal usage I
Hal> I see your point so perhaps it is not needed. For IPoIB, that
Hal> clearly works as the PKey is embedded in the MGID. I didn't
Hal> think that was the case with generalized IB multicast.
A multicast group is uniquely identified by MGID. There can't be two
different groups with th
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] ipoib_flush_paths
>
> Michael> Actually, it turned out to be the simplest solution - and
> Michael> quite elegant since there's no room for mistakes: if
> Michael> query is going to be running this means module is sti
On Thu, 2006-04-06 at 16:58, Roland Dreier wrote:
> Hal> Why did the PKey component get removed from the leave ?
>
> I don't think it's needed. MGID and PortGID together form the record
> identifier for multicast groups.
I see your point so perhaps it is not needed. For IPoIB, that clearly
w
On Wed, 5 Apr 2006, Steve Wise wrote:
> James,
>
> Running a 4 thread, 8 ep/thread dapltest (the last test in regress.sh),
> I was intermittently seeing a seg fault in dapltest. This is running
> over the chelsio rnic using the iwarp branch. After debugging I found
> out that dapltest was fre
>1. My main initial comment is that I think that cmp_rec needs to be more
>complicated that the matching which is there. The selectors include
>things like greater than, less than, and largest available in addition
>to equal to which is what is supported there now. I'm not sure whether
>any of this
Hal> Why did the PKey component get removed from the leave ?
I don't think it's needed. MGID and PortGID together form the record
identifier for multicast groups.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mai
On Thu, 2006-04-06 at 14:13, Sean Hefty wrote:
Another question:
> +static int send_leave(struct mcast_group *group, u8 leave_state)
> +{
> + struct mcast_port *port = group->port;
> + struct ib_sa_mcmember_rec rec;
> + int ret;
> +
> + rec = group->rec;
> + rec.join_state = l
Michael S. Tsirkin wrote:
The library now has
min = 1 max = 2
this means that any ABI update in kernel will break userspace.
Isn't that what it means to break the ABI?
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman
On Thu, 2006-04-06 at 14:13, Sean Hefty wrote:
> Add kernel support that tracks joining and leaving multicast groups.
> The SA tracks join/leave operations on a per port basis. In order
> to support multiple users of the same multicast group, we need to
> track join / leave requests locally.
On i
Hal> I would prefer not to. SMI changes for switches have been
Hal> provided but not integrated as yet. Enhanced switch port 0
Hal> would need this (at a minimum).
OK, then this code needs to do the usual "port 0 if it's a switch,
otherwise ports 1...num ports"
- R.
_
Sean> Here's a similar patch for ib_addr.
Looks good to me.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: librdmacm/ucma
>
> >- dependency on libsysfs
> > I propose we don't get into this again. I know we have it in ibverbs
> > but let's avoid for new code.
> >
> >- negative error codes
> > I think this is kernel practice, in userspace we
>
Sean/Roland:
I may be the only one using the openib stack for a switch. I don't need the
module in question at this point, but I request the group to consider
putting all changes for a switch (as well) while adding new functionality.
This way, if and when I get to a point of needing the function
On Thu, 2006-04-06 at 14:01 -0400, Karthikeyan Vaidyanathan wrote:
> Hi,
>
> I was trying to follow the discussion on getting the iWARP branch to work
> with Ammasso NICs and tried the following steps:
>
> /include/rdma -->
>/gen2/branches/iwarp/src/linux-kernel/infiniband/include/rdma
>
> /
Roland Dreier wrote:
> +static void queue_join(struct mcast_member *member)
> +{
> + struct mcast_group *group = member->group;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&group->lock, flags);
> + list_add(&member->list, &group->pending_list);
> + if (group->state == MCAST_IDLE) {
On Thu, 2006-04-06 at 16:16, Sean Hefty wrote:
> Roland Dreier wrote:
> > > +dev = kmalloc(sizeof *dev + device->phys_port_cnt * sizeof
> > *port,
> > > + GFP_KERNEL);
> > > +if (!dev)
> > > +return;
> > > +
> > > +for (i = 1; i <=
Roland Dreier wrote:
> + dev = kmalloc(sizeof *dev + device->phys_port_cnt * sizeof *port,
> + GFP_KERNEL);
> + if (!dev)
> + return;
> +
> + for (i = 1; i <= device->phys_port_cnt; i++) {
Seems like this is implicitly assuming that the IB device is a CA.
Maybe we sh
On Thu, 2006-04-06 at 15:51, Roland Dreier wrote:
> > + dev = kmalloc(sizeof *dev + device->phys_port_cnt * sizeof *port,
> > +GFP_KERNEL);
> > + if (!dev)
> > + return;
> > +
> > + for (i = 1; i <= device->phys_port_cnt; i++) {
>
> Seems like this is implicitly a
Roland Dreier wrote:
and so on. Can you separate that into another patch, so that it's
easier to review the real changes here?
Sure.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
Roland Dreier wrote:
Looks fine but can you redo this on top of the module unload race fix
once we agree on that? I expect the race fix to go into 2.6.17 and
this API change to go into 2.6.18, so the API change needs to apply on
top of the race fix.
Yes - I'll redo this on top of the API fix.
Here's a similar patch for ib_addr.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: core/addr.c
===
--- core/addr.c (revision 6307)
+++ core/addr.c (working copy)
@@ -73,6 +73,7 @@ struct addr_req {
struct sockaddr
Looks fine but can you redo this on top of the module unload race fix
once we agree on that? I expect the race fix to go into 2.6.17 and
this API change to go into 2.6.18, so the API change needs to apply on
top of the race fix.
- R.
___
openib-general
There is a fair amount of simple reformatting here like
> -comp_mask =
> -IB_SA_MCMEMBER_REC_MGID |
> -IB_SA_MCMEMBER_REC_PORT_GID |
> -IB_SA_MCMEMBER_REC_PKEY |
> -IB_SA_MCMEMBER_REC_JOIN_STATE;
> +comp_mask = IB_SA
> +static void queue_join(struct mcast_member *member)
> +{
> +struct mcast_group *group = member->group;
> +unsigned long flags;
> +
> +spin_lock_irqsave(&group->lock, flags);
> +list_add(&member->list, &group->pending_list);
> +if (group->state == MCAST_IDLE) {
> +
> +dev = kmalloc(sizeof *dev + device->phys_port_cnt * sizeof *port,
> + GFP_KERNEL);
> +if (!dev)
> +return;
> +
> +for (i = 1; i <= device->phys_port_cnt; i++) {
Seems like this is implicitly assuming that the IB device is a CA.
Maybe we should giv
Eli> ensure reverse order of creation or else might cause errors
Eli> if debugfs is used.
Not sure I follow this. What error could occur?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-
Convert IPoIB to use the new ib_multicast interfaces in place of direct
SA query calls.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Testing was limited to bringing up ipoib and verifying that it worked.
If I can get some guidance on some additional testing, I can do that.
Code review would
Same comments as the sa_query patch apply here:
- __module_get() has a race, use try_module_get() instead
- let's hide the THIS_MODULE inside an inline wrapper so
consumers of the API don't change and don't have to think about
this at all.
Other than that it seems good.
- R.
Michael> Actually, it turned out to be the simplest solution - and
Michael> quite elegant since there's no room for mistakes: if
Michael> query is going to be running this means module is still
Michael> loaded so we can take a reference to it without races.
Yes, this is suprisingly
On Thu, 2006-04-06 at 11:11 -0700, Roland Dreier wrote:
> I don't think doing this:
Thanks for spotting that. Fixed.
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Add kernel support that tracks joining and leaving multicast groups.
The SA tracks join/leave operations on a per port basis. In order
to support multiple users of the same multicast group, we need to
track join / leave requests locally.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
This pa
I don't think doing this:
#ifdef IB_NODE_CA
dev->node_type = IB_NODE_CA;
#else
dev->node_type = RDMA_NODE_IB_CA;
#endif
bought you anything. IB_NODE_CA is an enum, not a macro.
- R.
___
openib-general mailing list
openib-general@openi
Yes it
should.
Ishai
From: Woodruff, Robert J
[mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006
1:31 AMTo: Ishai Rabinovitz;
[EMAIL PROTECTED]Subject: RE: [openfabrics-ewg] Changes in
SM for the new SRP daemon
Shouldn't this discussion be on openib-general
?
From: [EMAIL PROT
Hi,
I was trying to follow the discussion on getting the iWARP branch to work
with Ammasso NICs and tried the following steps:
/include/rdma -->
/gen2/branches/iwarp/src/linux-kernel/infiniband/include/rdma
/drivers/infiniband -->
/gen2/branches/iwarp/src/linux-kernel/infiniband
and recom
Currently, the SA query interface does not permit retrying requests
automatically. Expose this capability to take advantage of underlying
MAD layer API, which provides it basically for free because of RMPP.
Without automatic retries pushed down into the SA query module, retries are
assigned new T
James Lentini wrote:
On Tue, 4 Apr 2006, Steve Wise wrote:
What happens if a consumer attempts to free the EP from a callback?
There are no direct consumer callbacks in usermode are there? consumers
call dat_evd_wait() or whatever and get scheduled. Not like kernel
mode... Or am
On Wed, Apr 05, 2006 at 07:04:29PM -0700, Manpreet Singh wrote:
> Hi,
>
> I am observing the following with redhat kernel rpm at:
> http://people.redhat.com/dledford/Infiniband , which uses openib version
> 3965. This is on an RHEL4 install.
>
> When the system is rebooted, ib_core, ib_mad and ib
Bryan,
I have also failure on:
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
Kernel: 2.6.9-34.ELsmp
Architecture: x86_64
gcc
-Wp,-MD,/var/tmp/IBED/tmp/openib/openib/src/linux-kernel/infiniband/hw/ipath/.ipath_cq.o.d
-nostdinc -iwithprefix include -D__KERNEL__
-I/var/tmp/IBED/tm
On Tue, 4 Apr 2006, Steve Wise wrote:
> > What happens if a consumer attempts to free the EP from a callback?
>
> There are no direct consumer callbacks in usermode are there? consumers
> call dat_evd_wait() or whatever and get scheduled. Not like kernel
> mode... Or am I confused?
You're
>> Actually, it turned out to be the simplest solution - and quite
>> elegant since there's no room for mistakes: if query is going to be running
>> this means module is still loaded so we can take a reference to it
>> without races.
>
>And Here's the patch to ib_addr. Sean, Roland, please comment.
On Thu, 2006-04-06 at 19:48 +0300, Vladimir Sokolovsky wrote:
> I have the following compilation failure:
This should be fixed now.
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Hi Bryan,
I have the following compilation failure:
OS: Novell Linux Desktop 10 (x86_64)
VERSION = 10
RELEASE = 9
Kernel: 2.6.16-rc5-git9-2-smp
Architecture: x86_64
gcc
-Wp,-MD,/var/tmp/IBED/tmp/openib/openib/src/linux-kernel/infiniband/hw/ipath/.ipath_verbs.o.d
-nostdinc -isystem /usr/lib6
On Thu, 2006-04-06 at 09:57, Tziporet Koren wrote:
> Bryan O'Sullivan wrote:
> > Unfortunately, the coordination of this with the 1.0 process has thus
> > far not been very effective, so I am spending a lot of time manually
> > filtering diffs to see what has changed between the first EWG software
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] ipoib_flush_paths
>
> The best solution might be just to say, hey, module unloading has races.
Ugh. Please, consider my patch instead.
It solves these races in 35 LOC, including SA, ADDR and updating all ULPs.
--
MST
The best solution might be just to say, hey, module unloading has races.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/op
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Actually, it turned out to be the simplest solution - and quite
> elegant since there's no room for mistakes: if query is going to be running
> this means module is still loaded so we can take a reference to it
> without races.
And Here's the pa
On Wed, 5 Apr 2006, Steve Wise wrote:
> Ignore this patch. max_sge_rd is not the correct attribute...
You're right. I've fixed it on the trunk and 1.0 branch in revision
6289 with this:
Index: openib_cma/dapl_ib_util.c
===
--- op
On Wed, 5 Apr 2006, Steve Wise wrote:
>
> Set the IA attribute max_iov_segments_per_rdma_read and the EP attribute
> max_rdma_read_iov based on the openib max_sge_rd device attribute.
Committed in the trunk and 1.0 branch in revision 6287.
___
openib
Quoting r. Fabian Tillier <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] Re: RE: Re: [PATCH] ipoib_flush_paths
>
> On 4/6/06, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > Quoting r. Muli Ben-Yehuda <[EMAIL PROTECTED]>:
> > > Subject: Re: [openib-general] Re: RE: Re: [PATCH] ipoib_flush_
On 4/6/06, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting r. Muli Ben-Yehuda <[EMAIL PROTECTED]>:
> > Subject: Re: [openib-general] Re: RE: Re: [PATCH] ipoib_flush_paths
> >
> > On Thu, Apr 06, 2006 at 04:38:33PM +0300, Michael S. Tsirkin wrote:
> >
> > > No, since we are keeping a callbac
On 4/6/06, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting r. Fabian Tillier <[EMAIL PROTECTED]>:
> > Subject: Re: RE: Re: [PATCH] ipoib_flush_paths
> >
> > On 4/6/06, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > > Quoting r. Fabian Tillier <[EMAIL PROTECTED]>:
> > > > Can't you pass i
Quoting r. Fabian Tillier <[EMAIL PROTECTED]>:
> Subject: Re: RE: Re: [PATCH] ipoib_flush_paths
>
> On 4/5/06, Sean Hefty <[EMAIL PROTECTED]> wrote:
> > >Can't you pass in a reference to the client module for registration,
> > >and then take a reference from the context of each request that is
> >
Quoting r. Muli Ben-Yehuda <[EMAIL PROTECTED]>:
> Subject: Re: Re: RE: Re: [PATCH] ipoib_flush_paths
>
> On Thu, Apr 06, 2006 at 05:04:07PM +0300, Michael S. Tsirkin wrote:
>
> > struct query {
> > void (*callback)();
> > struct module *owner;
> > }
> >
> > Then it is always safe to do
>
On Thu, 2006-04-06 at 09:57, Tziporet Koren wrote:
> Bryan O'Sullivan wrote:
> > Unfortunately, the coordination of this with the 1.0 process has thus
> > far not been very effective, so I am spending a lot of time manually
> > filtering diffs to see what has changed between the first EWG software
On Thu, Apr 06, 2006 at 05:04:07PM +0300, Michael S. Tsirkin wrote:
> struct query {
> void (*callback)();
> struct module *owner;
> }
>
> Then it is always safe to do
>
> __get_module(query->owner);
> query->callback();
> put_module(query->owner);
Ok, that makes s
On Wed, 5 Apr 2006, Vladimir Sokolovsky wrote:
> Can you add dapl tests to EXTRA_DIST list in the dapl/Makefile.am?
Can you send me a patch with exactly what you want?
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman
Quoting r. Fabian Tillier <[EMAIL PROTECTED]>:
> Subject: Re: RE: Re: [PATCH] ipoib_flush_paths
>
> On 4/6/06, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > Quoting r. Fabian Tillier <[EMAIL PROTECTED]>:
> > > Can't you pass in a reference to the client module for registration,
> > > and then
On 4/6/06, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting r. Fabian Tillier <[EMAIL PROTECTED]>:
> > Can't you pass in a reference to the client module for registration,
> > and then take a reference from the context of each request that is
> > released after the callback unwinds? I thoug
Quoting r. Muli Ben-Yehuda <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] Re: RE: Re: [PATCH] ipoib_flush_paths
>
> On Thu, Apr 06, 2006 at 04:38:33PM +0300, Michael S. Tsirkin wrote:
>
> > No, since we are keeping a callback pointer into that module.
>
> Sorry if I'm being dense but I don
On 4/5/06, Sean Hefty <[EMAIL PROTECTED]> wrote:
> >Can't you pass in a reference to the client module for registration,
> >and then take a reference from the context of each request that is
> >released after the callback unwinds? I thought Linux had module
> >reference functions...
>
> Yes - this
1 - 100 of 134 matches
Mail list logo
