From sfr at canb.auug.org.au  Thu Nov 19 16:03:42 2009
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 20 Nov 2009 11:03:42 +1100
Subject: [ofa-general] linux-next: infiniband tree build failure
Message-ID: <20091120110342.5128b8f8.sfr@canb.auug.org.au>

Hi all,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

ERROR: ".__ipv6_addr_type" [drivers/infiniband/core/rdma_cm.ko] undefined!

I have used the version of the infiniband tree from next-20091119 for
today.
-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20091120/456e36a2/attachment.sig>

From rdreier at cisco.com  Thu Nov 19 16:19:29 2009
From: rdreier at cisco.com (Roland Dreier)
Date: Thu, 19 Nov 2009 16:19:29 -0800
Subject: [ofa-general] Re: linux-next: infiniband tree build failure
In-Reply-To: <20091120110342.5128b8f8.sfr@canb.auug.org.au> (Stephen
	Rothwell's message of "Fri, 20 Nov 2009 11:03:42 +1100")
References: <20091120110342.5128b8f8.sfr@canb.auug.org.au>
Message-ID: <ada1vju6oa6.fsf@roland-alpha.cisco.com>


 > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
 > 
 > ERROR: ".__ipv6_addr_type" [drivers/infiniband/core/rdma_cm.ko] undefined!
 > 
 > I have used the version of the infiniband tree from next-20091119 for
 > today.

Sorry, will track it down.  Sean this probably came from your patches,
any idea off the top of your head?


From sfr at canb.auug.org.au  Thu Nov 19 16:34:09 2009
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 20 Nov 2009 11:34:09 +1100
Subject: [ofa-general] Re: linux-next: infiniband tree build failure
In-Reply-To: <ada1vju6oa6.fsf@roland-alpha.cisco.com>
References: <20091120110342.5128b8f8.sfr@canb.auug.org.au>
	<ada1vju6oa6.fsf@roland-alpha.cisco.com>
Message-ID: <20091120113409.1dcdc2b4.sfr@canb.auug.org.au>

Hi Roland, Sean,

On Thu, 19 Nov 2009 16:19:29 -0800 Roland Dreier <rdreier at cisco.com> wrote:
>
> 
>  > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>  > 
>  > ERROR: ".__ipv6_addr_type" [drivers/infiniband/core/rdma_cm.ko] undefined!
>  > 
>  > I have used the version of the infiniband tree from next-20091119 for
>  > today.
> 
> Sorry, will track it down.  Sean this probably came from your patches,
> any idea off the top of your head?

Big hint:  IPV6 is not enabled in this config.

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20091120/6c74d119/attachment.sig>

From rdreier at cisco.com  Thu Nov 19 16:43:07 2009
From: rdreier at cisco.com (Roland Dreier)
Date: Thu, 19 Nov 2009 16:43:07 -0800
Subject: [ofa-general] Re: linux-next: infiniband tree build failure
In-Reply-To: <6307584467EB4D168602C43E0B185157@amr.corp.intel.com> (Sean
	Hefty's message of "Thu, 19 Nov 2009 16:30:55 -0800")
References: <20091120110342.5128b8f8.sfr@canb.auug.org.au>
	<ada1vju6oa6.fsf@roland-alpha.cisco.com>
	<6307584467EB4D168602C43E0B185157@amr.corp.intel.com>
Message-ID: <adaskca58mc.fsf@roland-alpha.cisco.com>


 > Off the top of my head, I'll guess that maybe we need to add something like

 > #if defined(CONFIG_IPv6) || defined(CONFIG_IPV6_MODULE)

Yes, makes sense, I'll throw that in.

 - R.


From rdreier at cisco.com  Thu Nov 19 16:45:58 2009
From: rdreier at cisco.com (Roland Dreier)
Date: Thu, 19 Nov 2009 16:45:58 -0800
Subject: [ofa-general] Re: linux-next: infiniband tree build failure
In-Reply-To: <6307584467EB4D168602C43E0B185157@amr.corp.intel.com> (Sean
	Hefty's message of "Thu, 19 Nov 2009 16:30:55 -0800")
References: <20091120110342.5128b8f8.sfr@canb.auug.org.au>
	<ada1vju6oa6.fsf@roland-alpha.cisco.com>
	<6307584467EB4D168602C43E0B185157@amr.corp.intel.com>
Message-ID: <adaocmy58hl.fsf@roland-alpha.cisco.com>

OK, so I threw this into the ipv6 patch, I think it's right:

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 71e616a..fbdd731 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2083,6 +2083,7 @@ static int cma_get_port(struct rdma_id_private *id_priv)
 static int cma_check_linklocal(struct rdma_dev_addr *dev_addr,
 			       struct sockaddr *addr)
 {
+#if defined(CONFIG_IPv6) || defined(CONFIG_IPV6_MODULE)
 	struct sockaddr_in6 *sin6;
 
 	if (addr->sa_family != AF_INET6)
@@ -2094,6 +2095,7 @@ static int cma_check_linklocal(struct rdma_dev_addr *dev_addr,
 			return -EINVAL;
 
 	dev_addr->bound_dev_if = sin6->sin6_scope_id;
+#endif
 	return 0;
 }
 


From celine.bourde at bull.net  Mon Nov 23 00:15:48 2009
From: celine.bourde at bull.net (=?ISO-8859-1?Q?C=E9line_Bourde?=)
Date: Mon, 23 Nov 2009 09:15:48 +0100
Subject: [ofa-general] qos on service-id
Message-ID: <4B0A44B4.9060803@bull.net>

Hi,

I'm trying to configure qos-policy.donc file for service-id use.
I've tried basic RDMA_PS_TCP service-id level with service id 0x0106

[]# cat /etc/opensm/qos-policy.conf
qos-levels
       qos-level
       name: DEFAULT
       sl: 0
       end-qos-level
       qos-level
           name: TCP
           sl: 4
       end-qos-level
         qos-level
            name: MPI
            sl: 5
        end-qos-level
end-qos-levels

qos-ulps
   default                       : 0 # default SL
   any, service-id 0x0000000001060000- 0x000000000106FFFF : 4
end-qos-ulps

I add this rule in my configuration and check by mapping
sl 4 on a vl with a weight of 0

# QoS default options
qos_max_vls 8
qos_high_limit 1
qos_vlarb_high 0:1,1:0,2:0,3:0,4:0
qos_vlarb_low 0:1,1:2,2:4,3:8,4:0,5:32
qos_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15

I've launched qperf on the server side
and listen on client:

j=100; for i in $(seq 0 $j) ; do /usr/bin/qperf -ri mlx4_0:1 -li mlx4_0:1
10.12.1.4 -sl 4 -lp 20004 rc_bw; done;
rc_bw:
   bw  =  0 bytes/sec
rc_bw:
   bw  =  0 bytes/sec

j=100; for i in $(seq 0 $j) ; do /usr/bin/qperf -ri mlx4_0:1 -li mlx4_0:1
10.12.1.4 -sl 5 -lp 20005 rc_bw; done;
rc_bw:
   bw  =  3.37 GB/sec
rc_bw:
   bw  =  3.37 GB/sec

Qperf gives me results I expected due to qos-level configuration part, 
but no
expected results using qperf tcp_bw, bandwith is not
filtered/blocked by sl weight.

# j=100; for i in $(seq 0 $j) ; do /usr/bin/qperf 10.12.1.4 tcp_bw; done;
tcp_bw:
   bw  =  923 MB/sec
tcp_bw:
   bw  =  935 MB/sec

j=100; for i in $(seq 0 $j) ; do /usr/bin/qperf -ri mlx4_0:1 -li mlx4_0:1
10.12.1.4 -sl 5 -lp 20005 rc_bw; done;
rc_bw:
   bw  =  2.23 GB/sec
rc_bw:
   bw  =  2.24 GB/sec
rc_bw:
   bw  =  2.21 GB/sec

Could you help me to understanding service-id mechanism or give me a 
relevant
test to test TCP service id level ?

Thanks.

Céline Bourde.