Nothing in the current patches is non-standard.
That's a bit hard to say without knowing what the standard is :)
But maybe you do know.
--
MST
___
general mailing list
general@lists.openfabrics.org
I think the problem is that cma_remove_id_dev overrides the current state,
losing state information in the process. Why do we need CMA_DEVICE_REMOVAL
at all? Everything seems to work fine just by forwarding
RDMA_CM_EVENT_DEVICE_REMOVAL
to user, without touching state.
I need to read back over the
Quoting Sean Hefty [EMAIL PROTECTED]:
Subject: RE: [ofa-general] hotplug event handle question
I think the problem is that cma_remove_id_dev overrides the current state,
losing state information in the process. Why do we need CMA_DEVICE_REMOVAL
at all? Everything seems to work fine just by
Quoting Sean Hefty [EMAIL PROTECTED]:
Subject: RE: [ofa-general] Re: [RFC] [PATCH 0/3] 2.6.22 or 23
ib:addpathrecord cache
That's a bit hard to say without knowing what the standard is :)
But maybe you do know.
The cache does PathRecord GetTable queries and InformInfo/Notice
At the very least we need to repeat the check:
if (!cma_comp(id_priv, CMA_DESTROYING))
return 0;
here to avoid calling the user after they've tried to destroy their id from
another callback. See comment above.
OK. Would that be enough?
Off the top of my head, I don't
Sure. But how that will interact with whatever extensions are going into
1.2.1 is hard for me to guess.
I agree. My point is that the cache should be spec compliant now, with support
for any potential extensions in 1.2.1 coming later. Even once 1.2.1 is released
SAs will need time to
Just take a look at this one!
Sea.rch for: CHVCCurrent: $0.69 1 Day Target price: $1.5Market: bullish.
All signs show that this one is going to Explode!!
The hottest news are released for CHVC, openib-general, call to broker.
___
general
This email was generated automatically, please do not reply
Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod
--with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod
--with-addr_trans-mod --with-rds-mod --with-cxgb3-mod
Passed:
Passed on i686 with
On Thu, 2007-04-26 at 02:16, Michael S. Tsirkin wrote:
Quoting Sean Hefty [EMAIL PROTECTED]:
Subject: RE: [ofa-general] Re: [RFC] [PATCH 0/3] 2.6.22 or 23
ib:addpathrecord cache
That's a bit hard to say without knowing what the standard is :)
But maybe you do know.
The cache
On 4/25/07, Roland Dreier [EMAIL PROTECTED] wrote:
Also is it worth taking the semaphore in the mthca reset function?
Why not? PRM says we should - the point of this is protecting against
someone
accidentally touching flash while device is reset,
which will result is hangs, system errors
Hi Yevgeny,
On Thu, 2007-04-26 at 03:27, Yevgeny Kliteynik wrote:
Hi Hal,
This patch fixes two similar memory leaks in fat-tree routing.
Please apply to ofed_1_2 and to master
Signed-off-by: Yevgeny Kliteynik [EMAIL PROTECTED]
Thanks. Applied (to both master and ofed_1_2).
-- Hal
On 4/25/07, Roland Dreier [EMAIL PROTECTED] wrote:
If you want to tackle more of the cache elimination plan we discussed
that would be great though.
One more issue I looked into that in my opinion needs to be discussed
is that we do not have an easy api that should provide us with the
whole
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/25/07, Roland Dreier [EMAIL PROTECTED] wrote:
If you want to tackle more of the cache elimination plan we discussed
that would be great though.
One more issue I looked into that in my opinion needs to
On 4/26/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/25/07, Roland Dreier [EMAIL PROTECTED] wrote:
If you want to tackle more of the cache elimination plan we discussed
that would be great though.
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/26/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/25/07, Roland Dreier [EMAIL PROTECTED] wrote:
If you want to
On 4/26/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/26/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/25/07, Roland
FYI. I posted a question on git mailing list, asking about
best ways to manage ofed repository.
http://article.gmane.org/gmane.comp.version-control.git/45519
The conclusion so far seems to be that what we are doing (keeping patches
under version control) is basically the right way to do it:
Michael S. Tsirkin wrote:
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/25/07, Roland Dreier [EMAIL PROTECTED] wrote:
If you want to tackle more of the cache elimination plan we discussed
that would be great though.
One more issue I looked into that in my
OpenSM/ib_types.h: Rename IB_NOTICE_* macros for Producer Type field in
Notice attribute
Update Notice Producer Type macros names
Signed-off-by: Ira K. Weiny [EMAIL PROTECTED]
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
diff --git a/osm/include/iba/ib_types.h b/osm/include/iba/ib_types.h
On Thu, 2007-04-26 at 10:36, Yevgeny Kliteynik wrote:
Hal Rosenstock wrote:
OpenSM/ib_types.h: Rename IB_NOTICE_* macros for Producer Type field in
Notice attribute
Update Notice Producer Type macros names
Looks fine (and also makes sense).
This is for master only, right?
Right.
--
On Thu, 2007-04-26 at 01:02, Michael S. Tsirkin wrote:
There also some few commands (ib*.pl) that are using a file
/tmp/ibnetdiscover.topology. I suggest /var/cache/ibnetdiscover.topology
I'm not sure about this one. I need to think about this more.
Not sure about the best
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/26/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/26/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Moni
Off the top of my head, I don't think so. Since the state is staying the same,
we now have the potential of another thread invoking a callback to the same id.
For example, the ib_cm could callback with a connect or reject event, which
gets
propagated to the user. The user will now see two
Folks:
I just upgraded my system to RHEL5 and tried to install ofed_1.2-rc2.tgz
(dated 18-April) and am getting errors. I picked the basic install+defaults for
All selections.
uname -a prints:
Linux ib-interop1host 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64
x86_64 x86_64
I don't think this sequence should occur. My IP links have MTU of 9k and I
have set the ib0 links to the same MTU. This sequence of 17k size packet
every eighth packet seems to match my retransmit sequence as captured by
tcpdump on the IP end of an iperf. The MSS in the IP header is 8960 so
Quoting Hal Rosenstock [EMAIL PROTECTED]:
Subject: Re: [RFC] IB management changes proposal
On Thu, 2007-04-26 at 01:02, Michael S. Tsirkin wrote:
There also some few commands (ib*.pl) that are using a file
/tmp/ibnetdiscover.topology. I suggest
Michael S. Tsirkin wrote:
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: Re: [ewg] Re: pkey change handling patch
Michael S. Tsirkin wrote:
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re: pkey change handling patch
On 4/25/07, Roland Dreier [EMAIL PROTECTED] wrote:
If you want to tackle
Quoting Bryan Lawver [EMAIL PROTECTED]:
Subject: Re: IPoIB forwarding
I don't think this sequence should occur. My IP links have MTU of 9k and I
have set the ib0 links to the same MTU.
Not sure about this: IPoIB has different encapsulation header size.
Maybe make IPoIB MTU bigger?
This
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: Re: [ewg] Re: pkey change handling patch
Michael S. Tsirkin wrote:
Quoting Yosef Etigin [EMAIL PROTECTED]:
Subject: Re: [ewg] Re: pkey change handling patch
Michael S. Tsirkin wrote:
Quoting Moni Levy [EMAIL PROTECTED]:
Subject: Re:
http://kerneltrap.org/node/8103
--
MST
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Colleagues,
Monday at 4:00pm at Sonoma workshop we will have a discussion on how to
proceed on sockets over RDMA.
All are welcome.
Thanks,
Arkady
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance Inc. phone: 781-768-5395
1601 Trapelo Rd. - Suite
Please note that you should *only* ever stick the SDP family value
in the socket(3) call. All addresses for connect, bind etc
are AF_INET, since SDP uses IP addresses for everything.
Sounds like something trying to be just a little bit pregnant.
Thankfully, I'm only munging the getaddrinfo()
Here's a short summary of what my plans for 2.6.22 are. For
reference, everything is in my git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
Please let me know if you have any thoughts on these plans, or if
there is something that you feel is missing from this
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This is the first batch of merges for 2.6.22 --
On Thu, 2007-04-26 at 10:46 -0400, Hal Rosenstock wrote:
On Thu, 2007-04-26 at 01:02, Michael S. Tsirkin wrote:
There also some few commands (ib*.pl) that are using a file
/tmp/ibnetdiscover.topology. I suggest
/var/cache/ibnetdiscover.topology
I'm not sure about this one. I
Let's do it over query_pkey/query_port for now.
Long term providers will just optimize these I think.
How ? Caching at device driver level ?
Yes... for the most part, it should be much easier to do within the
driver. For example mthca, mlx4 and ipath at least know exactly when
the
Hal Rosenstock wrote:
Hi John,
One can run 2 OpenSMs on different CA/ports on a single machine.
Yes, in fact this is exactly what we have been doing. Although we
have been running OpenSM by hand to achieve this.
The main things in doing this is setting them up to use different
directories.
On Thu, 2007-04-26 at 15:23, John Partridge wrote:
Hal Rosenstock wrote:
Hi John,
One can run 2 OpenSMs on different CA/ports on a single machine.
Yes, in fact this is exactly what we have been doing. Although we
have been running OpenSM by hand to achieve this.
The main things in
Hey Roland,
Here are some bug fixes to the iw_cxgb3 driver that I'd like merged for
2.6.22. The 1st patch has been posted before, but I didn't see it in
your for-2.6.22 branch, so I'm posting it again.
Jeff,
The last patch updates the cxgb3 required firmware version. It is
included in
Fix TERM codes.
Fix TERMINATE layer, type, and ecode values based on
conformance testing.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_qp.c | 69 ++---
1 files changed, 38 insertions(+), 31 deletions(-)
diff --git
Fail qp creation if the requested max_inline is too large.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/cxio_wr.h |1 +
drivers/infiniband/hw/cxgb3/iwch_provider.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Initialize cpu_idx field in cpl_close_listserv_req message.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_cm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
Support for new abort logic.
The HW now posts 2 ABORT_RPL and/or PEER_ABORT_REQ messages. We need
to handle them by silenty dropping the 1st but mark that we're ready
for the final message. This plugs some close races between the uP and HW.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
Update required firmware revision to 4.0.0.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/net/cxgb3/version.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h
index 042e27e..b112317 100644
---
Hal Rosenstock wrote:
OK, I will feed back any changes to opensmd and the /etc/opensm.conf
files. Who should these go to ?
Vlad (and me; I'd at least like to see them).
OK will do thanks for your help
John
--
John Partridge
Silicon Graphics Inc
Tel: 651-683-3428
Vnet: 233-3428
E-Mail:
After some digging around on the net figured out that the error actually meant
no c program would compile when supplied with the same arguments as found on
the error line in config.log.
In my case it happens to be:
gcc -m32 -g -O2 -L/usr/lib -I../libibverbs/include -L. conftest.c 5
the -m32
I've updated these patches based on the feedback received so far:
* Added definition for missing trap 259.
* Replaced miscdevice usage with module parameters.
* Add module parameter to control SA event registration.
There is still one issue wrt the API that I'd like to get more opinions on.
Hi List,
I was wondering whether there is an example of using APM with Openfabrics. I
do not
see an example in the examples directory. With the OFED 1.2 rc2 too, i have
not seen
such an example.
Mellanox VAPI used to have support for completion events with different APM
states.
However, with
Mellanox VAPI used to have support for completion events with
different APM states. However, with Openfabrics, i see that the
support for MIGRATED - ARMED event is not there (verbs.h include
file). is there any specific reason for the same?
I don't know what you're referring to. Of
Suresh Shelvapille wrote:
After some digging around on the net figured out that the error actually meant
no c program would compile when supplied with the same arguments as found on
the error line in config.log.
In my case it happens to be:
gcc -m32 -g -O2 -L/usr/lib -I../libibverbs/include
Roland,
Thanks for your mail.
On 4/26/07, Roland Dreier [EMAIL PROTECTED] wrote:
Mellanox VAPI used to have support for completion events with
different APM states. However, with Openfabrics, i see that the
support for MIGRATED - ARMED event is not there (verbs.h include
file). is there
I was wondering whether there is an example of using APM with
Openfabrics. I do not
see an example in the examples directory. With the OFED 1.2 rc2 too, i
have not seen
such an example.
I have a kernel ib_cm test program (cmpost) that I've used to test APM. It's
available from:
Abhinav However, VAPI has an event which specifies the successful
Abhinav transition of MIGRATED - ARMED (I know very well, that
Abhinav it is done through modify_qp). But just the success of
Abhinav modify_qp does not explicitly tell the time at which the
Abhinav transition
So, while playing around with my new netperf SDP_RR test I've noticed that a
single-byte _RR test over SDP has a much higher transactions per second (ie
lower latency) than over TCP over the same HCA, but the CPU utilization is
_very_ much higher and the service demand (cpu per transaction) as
On Thu, 26 Apr 2007 19:08:25 +0300
Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Hal Rosenstock [EMAIL PROTECTED]:
Subject: Re: [RFC] IB management changes proposal
On Thu, 2007-04-26 at 01:02, Michael S. Tsirkin wrote:
There also some few commands (ib*.pl) that are using a
On Thu, 26 Apr 2007 19:47:04 -0700
Roland Dreier [EMAIL PROTECTED] wrote:
I'm sorry, I'm not familiar with the code.
I was just saying that using /tmp/ibnetdiscover.topology is clearly
a security risk since /tmp is world-writeable. Isn't it?
However, I think the risk is pretty
Update required firmware revision to 4.0.0.
Hmm... should we fold this into the earlier patch, which actually
needs this new FW? Or at least merge this patch first?
Also, is it cool with everyone to require a new FW, even for users who
might not be using (or even building) the RDMA driver?
On Thu, 26 Apr 2007 19:47:04 -0700
Roland Dreier [EMAIL PROTECTED] wrote:
I'm sorry, I'm not familiar with the code.
I was just saying that using /tmp/ibnetdiscover.topology is clearly
a security risk since /tmp is world-writeable. Isn't it?
However, I think the risk is pretty
Quoting Rick Jones [EMAIL PROTECTED]:
Subject: why is CPU util/service demand so much higher with SDP than TCP?
So, while playing around with my new netperf SDP_RR test I've noticed that
a single-byte _RR test over SDP has a much higher transactions per second
(ie lower latency) than over
59 matches
Mail list logo
