On Fri, Oct 23, 2009 at 1:13 AM, Vu Pham wrote:
>
> [ ... ]
>
> Here is the updated patch which implement the device_loss_timeout for each
> target instead of module parameter. It also reflects changes from previous
> feedbacks. Please review
>
>
>
> Introducing device_loss_timeout per target gr
Per RFC 4391 rules for P_Key portion of MGIDs needing to be
full member and valid P_Key
Signed-off-by: Hal Rosenstock
---
diff --git a/opensm/opensm/osm_sa_mcmember_record.c
b/opensm/opensm/osm_sa_mcmember_record.c
index dd01eed..a185238 100644
--- a/opensm/opensm/osm_sa_mcmember_record.c
+++
On 17:33 Thu 22 Oct , Yevgeny Kliteynik wrote:
> Hi Sasha,
>
> There's a static function in the up/down routing, called
> "updn_clear_root_hops". This function is supposed to clear
> the hops to all targets but root switches.
> So the more correct name for this function would be
> "updn_clear_
Hi Ira,
On 10:35 Wed 07 Oct , Ira Weiny wrote:
>
> Perhaps you missed this patch the first time around.
Right, I missed this masked inside this email message.
And yes, it would be better to send a patches as separate emails. And of
course you can still use In-Replay-To: email header line to
On Thu, 2009-10-22 at 20:24 -0400, Vu Pham wrote:
> David Dillow wrote:
> > On Thu, 2009-10-22 at 20:04 -0400, Vu Pham wrote:
> >> Yes and you can not disable intirely. I'm still looking at
> >> benefits/advantages to disable it entirely
> >
> > To me, the advantage is I have a perfectly viable ba
David Dillow wrote:
On Thu, 2009-10-22 at 20:04 -0400, Vu Pham wrote:
David Dillow wrote:
Yes and you can not disable intirely. I'm still looking at
benefits/advantages to disable it entirely
To me, the advantage is I have a perfectly viable backup path to the
storage, and can imm
On Thu, 2009-10-22 at 20:04 -0400, Vu Pham wrote:
> David Dillow wrote:
>
> Yes and you can not disable intirely. I'm still looking at
> benefits/advantages to disable it entirely
To me, the advantage is I have a perfectly viable backup path to the
storage, and can immediately start issuing c
David Dillow wrote:
On Thu, 2009-10-22 at 19:34 -0400, David Dillow wrote:
On Thu, 2009-10-22 at 19:33 -0400, David Dillow wrote:
On Thu, 2009-10-22 at 19:13 -0400, Vu Pham wrote:
Jason Gunthorpe wrote:
On Thu, Oct 15, 2009 at 03:25:15PM -0400, David Dillow wrote:
On Thu, 2009-10-22 at 19:34 -0400, David Dillow wrote:
> On Thu, 2009-10-22 at 19:33 -0400, David Dillow wrote:
> > On Thu, 2009-10-22 at 19:13 -0400, Vu Pham wrote:
> > > Jason Gunthorpe wrote:
> > > > On Thu, Oct 15, 2009 at 03:25:15PM -0400, David Dillow wrote:
> > > >> I use multipath with ALUA
On Thu, 2009-10-22 at 19:33 -0400, David Dillow wrote:
> On Thu, 2009-10-22 at 19:13 -0400, Vu Pham wrote:
> > Jason Gunthorpe wrote:
> > > On Thu, Oct 15, 2009 at 03:25:15PM -0400, David Dillow wrote:
> > >> I use multipath with ALUA, and I don't mind if the link flaps a bit. 60
> > >> seconds is
On Thu, 2009-10-22 at 19:13 -0400, Vu Pham wrote:
> Jason Gunthorpe wrote:
> > On Thu, Oct 15, 2009 at 03:25:15PM -0400, David Dillow wrote:
> >> I use multipath with ALUA, and I don't mind if the link flaps a bit. 60
> >> seconds is near my SCSI timeout of 77 seconds, so it doesn't buy me
> >> muc
Bart Van Assche wrote:
+static void srp_event_handler(struct ib_event_handler *handler,
+ struct ib_event *event)
+{
+ struct srp_device *srp_dev =
+ ib_get_client_data(event->device, &srp_client);
+ struct srp_host *host, *tmp_host;
+ st
Jason Gunthorpe wrote:
On Thu, Oct 15, 2009 at 03:25:15PM -0400, David Dillow wrote:
On Thu, 2009-10-15 at 09:23 -0700, Vu Pham wrote:
David Dillow wrote:
And if I want to disable this completely?
Unless these patches are bad and affect the stability of the driver, w
Roland Dreier wrote:
> > > - wait_for_completion(&target->done);
> >
> > How do you avoid leaking connection on module unload etc? Don't we have
> > to wait for the disconnect to finish somewhere?
> >
> > - R.
> >
> Are you talking about cm_id?
> I think that we wait because
Sending this to the EWG openfabrics list,
since this seems to be an OFED build/installation issue
rather than a general code problem.
One thing that you might try is to instead of copying the
entire build directory and re-runing ./install.pl -c ofed.conf
on each system, instead, after building on
>For ipv6 I ran what I described previously. What I do need to do is add
>the option to rping to specify a source address and run it with various
>address. Any help you can give defining what exactly needs to be tested
>would be appreciated.
You can also test with ucmatose to verify ipv4 still w
On Wed, 2009-10-21 at 17:08 -0600, Jason Gunthorpe wrote:
> This looks exactly like what I was thinking of - have you tested this?
Yes I did do some testing, but that brings up a good question. I am not
sure I know what all should be tested? I am running rping with
different destination addre
Export rdma_set_ib_paths to user space to allow applications to
manually set the IB path used for connections. This allows
alternative ways for a user space application or library to obtain
path record information, including retrieving path information
from cached data, avoiding direct interaction
>I really tried to follow the thread between you and Jason with quite
>little success, and I am going to give it more tries... in parallel,
>could you help me understand what is the --drive/reasoning-- from your
>perspective to add AF_IB / PS_IB here?
These are the things done today in the kernel
On Thu, Oct 22, 2009 at 11:31:07AM -0700, Sean Hefty wrote:
> The REP does not contain a port GUID, so what exactly were you trying to say
> here?
Sorry, typo, it was too late. I ment REQ.
The point was, that you don't know what port the QP will be bound to
until you get the REQ (ie the RDMA CM u
On Thu, Oct 22, 2009 at 11:28:11AM -0700, Sean Hefty wrote:
> I don't like the idea of the kernel silently ignoring the alternate path.
> Returning an error seems like a better idea.
Then provide a way for userspace to know WTF to do. Without a
negotiation process this is now an 'impossible to us
>Why would it need to? The REQ contains all the port information
>necessary, the active side doesn't get to pick the port, it just gets
>to approve it.
I'm not following you at all now. You said:
This is actually something of a mandatory notion to implement the
full generality of the IB CM proto
>> if (number of paths > 1)
>> return -ENOSYS;
>
>This is really no different than what you had at first.
The main difference is returning ENOSYS to indicate that only one path is
acceptable.
>My idea was to have the kernel search the array for the entries it
>needs/supports. First one found
I was referred to this list by the general mailing list on OFED.
Emailing from my personal address since Lotus Notes insists that
anything it sends has to contain some portion of HTML.
This problem was observed on Red Hat Enterprise Linux 5 update 3. I
searched the list but did not see anything i
On Thu, Oct 22, 2009 at 10:59:37AM -0700, Sean Hefty wrote:
> >> You can redirect (REJ) a REQ to a different port, but you can't accept
> >> (REP)
> >a
> >> connection on a different port.
> >
> >Do you have a compliance statment for that? :)
>
> The REP doesn't carry port (i.e. GID) information.
On Thu, Oct 22, 2009 at 10:52:13AM -0700, Sean Hefty wrote:
> >> +static int ucma_set_ib_path(struct ucma_context *ctx,
> >> + struct ib_path_rec_data *path_data, size_t optlen)
> >> +{
> >> + struct ib_sa_path_rec sa_path;
> >> + struct rdma_cm_event event;
> >> + int ret;
Per RFC 4391 rules for P_Key portion of MGIDs needing to be
full member and valid P_Key
Signed-off-by: Hal Rosenstock
---
diff --git a/opensm/opensm/osm_sa_mcmember_record.c
b/opensm/opensm/osm_sa_mcmember_record.c
index dd01eed..a185238 100644
--- a/opensm/opensm/osm_sa_mcmember_record.c
+++
>> You can redirect (REJ) a REQ to a different port, but you can't accept (REP)
>a
>> connection on a different port.
>
>Do you have a compliance statment for that? :)
The REP doesn't carry port (i.e. GID) information.
>Spec says:
>
> The initiator is responsible for proposing the Port Addresses
Signed-off-by: Hal Rosenstock
---
diff --git a/opensm/include/opensm/osm_base.h b/opensm/include/opensm/osm_base.h
index 06223ce..34646cd 100644
--- a/opensm/include/opensm/osm_base.h
+++ b/opensm/include/opensm/osm_base.h
@@ -906,6 +906,8 @@ typedef enum _osm_sm_signal {
#define OSM_VENDOR_ID_H
>> +static int ucma_set_ib_path(struct ucma_context *ctx,
>> +struct ib_path_rec_data *path_data, size_t optlen)
>> +{
>> +struct ib_sa_path_rec sa_path;
>> +struct rdma_cm_event event;
>> +int ret;
>> +
>> +if (optlen != sizeof(*path_data))
>> +r
On Thu, Oct 22, 2009 at 01:10:09AM -0700, Sean Hefty wrote:
> +static int ucma_set_ib_path(struct ucma_context *ctx,
> + struct ib_path_rec_data *path_data, size_t optlen)
> +{
> + struct ib_sa_path_rec sa_path;
> + struct rdma_cm_event event;
> + int ret;
> +
>
On Wed, Oct 21, 2009 at 11:49:52PM -0700, Sean Hefty wrote:
> > This is actually something of a mandatory notion to implement the
> > full generality of the IB CM protocol which allows the CM REP to
> > contain a port GUID of another port on the same node (multi-port
> > APM is an IB featur
On Thu, Oct 22, 2009 at 10:08:20AM -0500, stuarts wrote:
> Confirmed. I have multicast again!
>
> Shall I open a bug, or has one already been done?
Please open a bug, Tziporet said Vlad would handle it..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body
On Thu, Oct 22, 2009 at 05:41:53PM +0200, Or Gerlitz wrote:
> If from other reasons, people want the rdma-cm to support AF_IB and/or
> PS_IB, we can do that as well, but why force doing that behind the cover
> each time ACM is used?!
My view is that ultimately ACM has at best a niche applicatio
On Thu, Oct 22, 2009 at 9:50 AM, Sasha Khapyorsky wrote:
> On 08:56 Thu 22 Oct , Hal Rosenstock wrote:
>> >
>> > Why do you need this?
>>
>> It is useful in some clusters where the default behavior is
>> insufficient
>
> I would suppose that by itself this may indicate some external issues
> l
Sean Hefty wrote:
okay, I just wanted to make sure that the whole thing (ACM + modified librdmacm
+ modifed rdma-cm) is applicable AND inter-operable for AF_INET / PS_TCP
applications
I do not intend to have any changes that break anything
my question went beyond whether things are going to be
Hi Sasha,
There's a static function in the up/down routing, called
"updn_clear_root_hops". This function is supposed to clear
the hops to all targets but root switches.
So the more correct name for this function would be
"updn_clear_non_root_hops".
Signed-off-by: Yevgeny Kliteynik
---
opensm/op
Sean Hefty wrote:
rdma_join_multicast re-initializes id_priv->cond rather than mc->cond. Fix
this. Bug reported by Nir Naaman
any idea what's the impact of this bug?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel
On Oct 21, 2009, at 5:08 PM, Jason Gunthorpe wrote:
On Wed, Oct 21, 2009 at 04:43:53PM -0500, stuarts wrote:
This is better than the current stuff since it preserves the intent of
the ip_ib_mc_map patches, and it adjusts the dmi_addr directly so ip
maddr reports the correct address to ai
On 08:50 Wed 21 Oct , Hal Rosenstock wrote:
>
> Also, cosmetic change to OSM_LOG message
Please don't mix.
I used "Unicast Cache" (with upper case starting letters) as for a name.
>
> Signed-off-by: Hal Rosenstock
Applied with changes. Thanks.
Sasha
--
To unsubscribe from this list: sen
On 08:56 Thu 22 Oct , Hal Rosenstock wrote:
> >
> > Why do you need this?
>
> It is useful in some clusters where the default behavior is
> insufficient
I would suppose that by itself this may indicate some external issues
like bad connectivity (cabling) or similar and some investigation woul
This define controls an array in the OpenSM umad vendor layer. Moving
this define to the vendor layer aids in Windows porting. See thread
which "ends" with:
http://lists.openfabrics.org/pipermail/ofw/2009-October/005819.html
Signed-off-by: Hal Rosenstock
---
Changes since v1:
Added patch descrip
On 08:49 Thu 22 Oct , Hal Rosenstock wrote:
> >> /s* OpenSM: Vendor UMAD/osm_ca_info_t
> >> * NAME
> >> * osm_ca_info_t
> >> @@ -154,7 +156,7 @@ typedef struct _osm_vendor {
> >> osm_ca_info_t *p_ca_info;
> >> uint32_t timeout;
> >> int max_retries;
> >> - osm_bin
On 08:49 Thu 22 Oct , Hal Rosenstock wrote:
>
> I thought the subject was sufficient and seems to be included in the
> commits. Is that true ?
Subject is just *one* line patch summary and not patch description (as
you trying to use it).
> What are you looking for here that is not
> being do
On Thu, Oct 22, 2009 at 8:24 AM, Sasha Khapyorsky wrote:
> On 14:33 Mon 19 Oct , Hal Rosenstock wrote:
>>
>
> Why do you need this?
It is useful in some clusters where the default behavior is
insufficient and control over the number of retries helps and there is
no vendor API support for this
Hi Sasha,
On Thu, Oct 22, 2009 at 8:21 AM, Sasha Khapyorsky wrote:
> Hi Hal,
>
> Could you add commit message to your patches (this and another)?
I thought the subject was sufficient and seems to be included in the
commits. Is that true ? What are you looking for here that is not
being done ?
>
On 09:35 Tue 20 Oct , Hal Rosenstock wrote:
>
> Remove some unneeded osm_ prefixes`
> Also, some other cosmetic formatting changes
>
> Signed-off-by: Hal Rosenstock
Applied. Thanks.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to m
On 14:33 Mon 19 Oct , Hal Rosenstock wrote:
>
Why do you need this?
And why did you choose to use environment variable and not command
line/config option? I think that it is less obvious.
Sasha
> Signed-off-by: Hal Rosenstock
> ---
> diff --git a/opensm/libvendor/osm_vendor_ibumad.c
> b/
Hi Hal,
Could you add commit message to your patches (this and another)?
On 11:38 Mon 19 Oct , Hal Rosenstock wrote:
>
> Signed-off-by: Hal Rosenstock
> ---
> diff --git a/opensm/include/vendor/osm_vendor_ibumad.h
> b/opensm/include/vendor/osm_vendor_ibumad.h
> index e346a2e..f3a48e5 10064
On 09:03 Mon 19 Oct , Hal Rosenstock wrote:
>
> Signed-off-by: Hal Rosenstock
Applied. Thanks.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
On 09:02 Mon 19 Oct , Hal Rosenstock wrote:
>
> Signed-off-by: Hal Rosenstock
Applied. Thanks.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
On 09:00 Mon 19 Oct , Hal Rosenstock wrote:
>
> Signed-off-by: Hal Rosenstock
Applied. Thanks.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
This eliminates compile warning (with >= gcc-4.4.0 and -O2 -Wall flags):
warning: dereferencing pointer ‘p_mc_res’ does break strict-aliasing rules
resulted by assignment (and later pointer use) like:
ib_sa_mad_t res_sa_mad;
ib_member_rec_t *p_mc_res;
p_mc_res = ib_sa_m
On 11:03 Fri 16 Oct , Hal Rosenstock wrote:
>
> Signed-off-by: Hal Rosenstock
Applied. Thanks.
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
Kill variable p_recvd_rec which duplicates p_mc_res. Remove a lot of
repeated re-initializations.
Signed-off-by: Sasha Khapyorsky
---
opensm/osmtest/osmt_multicast.c | 151 +++
1 files changed, 43 insertions(+), 108 deletions(-)
diff --git a/opensm/osmtest/o
Add the fact that connect_roots option is valid in ftree
in the opensm usage and in the manual.
Signed-off-by: Yevgeny Kliteynik
---
opensm/man/opensm.8.in |4 ++--
opensm/opensm/main.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/opensm/man/opensm.8.in b/op
Implementation of the connect_roots option in fat tree.
Actually, it will not only connect all the roots, but
also all the other switches that are above leaf switch
level.
Signed-off-by: Yevgeny Kliteynik
---
opensm/opensm/osm_ucast_ftree.c | 82 +++
1 fil
Jason Gunthorpe wrote:
Correct. We need someone to pick up the above patch for the
backports. I don't know who that is (someone please speak up?)
Vlad will take it
Please open a bug in bugzilla too
Tziporet
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the bo
Export rdma_set_ib_paths to user space to allow applications to
manually set the IB path used for connections. This allows
alternative ways for a user space application or library to obtain
path record information, including retrieving path information
from cached data, avoiding direct interaction
59 matches
Mail list logo
