[ewg] Re: [ofa-general] Bonding and hw_csum
On Wed, 2008-01-30 at 19:35 -0800, Shirley Ma wrote: Hello Tziporet, the hw checksum patch was removed from OFED 1.3 Tziporet Could youp please specify which patch has been removed? I still can see a list of patches under RC3. here they are: ipoib_0010_Add-high-dma-support-to-ipoib.patch ipoib_0020_Add-s-g-support-for-IPOIB.patch ipoib_0030_hw_csum.patch ipoib_0040_checksum-offload.patch ipoib_0050_Add-LSO-support.patch ipoib_0060_ethtool-support.patch ipoib_0070_modiy_cq_params.patch ipoib_0080_broadcast_null.patch ipoib_0110_set_default_cq_patams.patch ipoib_0030_hw_csum.patch has been removed ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] add missing change-log for the connected mode Grat ARP patch
Or Gerlitz wrote: --- kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch.orig 2008-01-31 13:33:13.0 +0200 +++ kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch 2008-01-31 13:33:35.0 +0200 @@ -1,3 +1,18 @@ +commit e1df2907fe4ef6809ad8c849882f6dc7cb6ed7a3 +Author: Moni Shoua [EMAIL PROTECTED] +Date: Tue Jan 29 12:44:32 2008 +0200 + +IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode + +move a little up the code that checks for a situation where the remote GID stored in the ipoib_neigh is +different than the one present in the neighbour (handle Gratuitous ARP) or that a bonding fail over has +happened but the neighbour still has a pointer to an ipoib_neigh created not by the current slave. This +will cause the driver to apply the check also for connected mode neighbours. +This patch was tested against upstream kernel and ofed_kernel. + +Signed-off-by: Or Gerlitz [EMAIL PROTECTED] +Signed-off-by: Moni Shoua [EMAIL PROTECTED] + Index: ofa_kernel-1.3/drivers/infiniband/ulp/ipoib/ipoib_main.c === --- ofa_kernel-1.3.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2008-01-29 08:55:33.0 -0500 Signed-off-by: Or Gerlitz [EMAIL PROTECTED] ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg Applied, Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] [ANNOUCE] dapl 2.0.5 release
Arlin Davis wrote: Arlin Davis wrote: There is new release for dapl 2.0 available on the OFA download page and in my git tree. Changes to allow both v1 and v2 development packages to be installed on the same system. v2 libdat.so has been renamed to libdat2.so. md5sum: 010459e421a5c194438d58b1ccf1c6d0 dapl-2.0.5.tar.gz Vlad, please pull new v2 release into OFED 1.3 RC3 and install the following packages: Note: please make sure dapl-1.2.4-devel is added to list. Vlad, I noticed that the daily build added dapl-2.0.5 but did not add dapl-1.2.4-devel to install script. Please add for next build. A missing libdat.so will break most v1 uDAPL consumers. Thanks, -arlin ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg Hi Arlin, I am not sure that I will be available to do this till OFED-1.3-rc4. If you can send me the patch to install.pl script I will apply this to my git tree. git://git.openfabrics.org/~vlad/ofed_1_3_scripts master Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Bonding and hw_csum
On Wed, 2008-01-30 at 18:42 +0200, Tziporet Koren wrote: Or Gerlitz wrote: This is interesting report, however, since currently the hw checksum patch in not being submitted to the mainline kernel and it is also about to be removed from ofed 1.3 (Tziporet, can you update on that?), I am not going to look into that. Or. the hw checksum patch was removed from OFED 1.3 I just saw some patches on the mailing list concerning csum offloading. Are these applied in RC3? Or are they going to be introduced in the daily build of tomorrow? Is it correct to state that these patches replace the hw_csum parameter by offloading the csum computation to the mthca? This would mean that the results should be similar also. Does the new offload patch depend on the type of hca being used? According to lspci, we have the InfiniBand: Mellanox Technologies MT25208 InfiniHost III Ex (rev a0) card. Do these patches work on a sles 10 sp1 installed on x3755 and x3655 machines of IBM that have this card inserted? Is bonding going to work with this type of offloading? Kind Regards Koen Tziporet ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general *** Disclaimer *** Vlaamse Radio- en Televisieomroep Auguste Reyerslaan 52, 1043 Brussel nv van publiek recht BTW BE 0244.142.664 RPR Brussel http://www.vrt.be/disclaimer ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
Woodruff, Robert J wrote: I hate to keep slipping this, but I think it is important to get what RedHat needs into OFED 1.3, so I am not apposed to this. I think however that perhaps after 1.3, we should discuss our process a bit to try to get a little better at making our original release dates. I think we are getting hit with feature creep, allowing some pretty major changes after the feature freeze date, late in the release cycle. I agree - we must do a better work in OFED 1.4 Main thing is that all companies will think in advance on the new features they want to drive and not come with features in the last minute. I also think that we do need to be a little more careful and selective about what features go into OFED, as it is suppose to be an enterprise release rather than an experimental code release. This is true but from first OFED version we decided that not all components must be in production level and that we allow components that are in experimental state as long as they do not harm the stability of the full package We may revisit this decision. I think we should have a session on OFED target and expectations in Sonoma For the kernel code, I think that this means keeping things a little closer to the kernel.org kernel features and if something is not upstream, then press for getting it upstream (or at least queued for upsteam) rather than allowing big patches into OFED that have not had a good review. The way we are working now, if it is getting into OFED, people are less aggressive at getting things upstream. Perhaps we can have a discussion about this at the Sonoma workshop. I agree we should have such a discussion at Sonoma Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
On Wed, 2008-01-30 at 17:10 -0800, Woodruff, Robert J wrote: Tziporet wrote, * Delay 1.3 release in a week * Do RC4 next week - Feb 6 * Add RC5 on Feb 18 - this will be the GOLD version * GA release on Feb 25 All - please reply if this is acceptable I hate to keep slipping this, but I think it is important to get what RedHat needs into OFED 1.3, so I am not apposed to this. I think however that perhaps after 1.3, we should discuss our process a bit to try to get a little better at making our original release dates. I think we are getting hit with feature creep, allowing some pretty major changes after the feature freeze date, late in the release cycle. I also think that we do need to be a little more careful and selective about what features go into OFED, as it is suppose to be an enterprise release rather than an experimental code release. For the kernel code, I think that this means keeping things a little closer to the kernel.org kernel features and if something is not upstream, then press for getting it upstream (or at least queued for upsteam) rather than allowing big patches into OFED that have not had a good review. The way we are working now, if it is getting into OFED, people are less aggressive at getting things upstream. Perhaps we can have a discussion about this at the Sonoma workshop. In addition, we should talk about how to integrate patches being queued in upper stream but not in OFED, like IPoIB noSRQ. There is always a window between OFED release and kernel release, a window between Distro release and OFED release. Some customers are targeted OFED release, some customers are targeted OFED release. Then how to handle these windows to meet different customers' requirements could be something t to be discussed at Sonoma workshop as well. Thanks Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
In addition, we should talk about how to integrate patches being queued in upper stream but not in OFED, like IPoIB noSRQ. There is always a window between OFED release and kernel release, a window between Distro release and OFED release. Some customers are targeted OFED release, some customers are targeted OFED release. Then how to handle these windows to meet different customers' requirements could be something t to be discussed at Sonoma workshop as well. Oops, a typo, I meant some customers are targeted Distro releases. From customer support point view, it's always better to have OFED releases in Distros. Thanks Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] Bonding and hw_csum
Hello Eli, ipoib_0030_hw_csum.patch has been removed Would removing this patch cause any errors on applying the rest of patches? If not, I will remove it for our testing as well. Thanks Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH ofed-1.3] Load iw_cxgb3 as part of ofed init.
Vlad, can you please review this? Is there anything else needed to get
iw_cxgb3 to be loaded at init time? I tested the patched openibd and
it seems to work fine.
If this looks good to you, please pull this patch for ofed-1.3 from:
git://www.openfabrics.org/~swise/ofed-1.3 ofed_kernel
This change is long overdue...
Thanks,
Steve.
--
Load iw_cxgb3 as part of ofed init.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
ofed_scripts/ofa_kernel.spec |6 ++
ofed_scripts/openibd | 19 +++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/ofed_scripts/ofa_kernel.spec b/ofed_scripts/ofa_kernel.spec
index 6184cfc..954dd0c 100755
--- a/ofed_scripts/ofa_kernel.spec
+++ b/ofed_scripts/ofa_kernel.spec
@@ -488,6 +488,12 @@ fi
echo MLX4_LOAD=yes %{IB_CONF_DIR}/openib.conf
%endif
+%if %{build_cxgb3}
+ echo %{IB_CONF_DIR}/openib.conf
+ echo # Load CXGB3 modules %{IB_CONF_DIR}/openib.conf
+ echo CXGB3_LOAD=yes %{IB_CONF_DIR}/openib.conf
+%endif
+
%if %{build_ipoib}
echo %{IB_CONF_DIR}/openib.conf
echo # Load IPoIB %{IB_CONF_DIR}/openib.conf
diff --git a/ofed_scripts/openibd b/ofed_scripts/openibd
index 2553881..700c8ef 100755
--- a/ofed_scripts/openibd
+++ b/ofed_scripts/openibd
@@ -273,13 +273,13 @@ fi
GEN1_UNLOAD_MODULES=ib_srp_target scsi_target ib_srp kdapltest_module
ib_kdapl ib_sdp ib_useraccess ib_useraccess_cm ib_cm ib_dapl_srv ib_ip2pr
ib_ipoib ib_tavor mod_thh mod_rhh ib_dm_client ib_sa_client ib_client_query
ib_poll ib_mad ib_core ib_services
-UNLOAD_MODULES=ib_mthca mlx4_enet mlx4_ib mlx4_core ib_ipath ipath_core
ib_ehca
+UNLOAD_MODULES=ib_mthca mlx4_enet mlx4_ib mlx4_core ib_ipath ipath_core
ib_ehca iw_cxgb3
UNLOAD_MODULES=$UNLOAD_MODULES ib_ipoib ib_madeye ib_rds
UNLOAD_MODULES=$UNLOAD_MODULES rds ib_ucm kdapl ib_srp_target scsi_target
ib_srpt ib_srp qlgc_vnic ib_iser ib_sdp
UNLOAD_MODULES=$UNLOAD_MODULES rdma_ucm rdma_cm ib_addr ib_cm ib_local_sa
findex
UNLOAD_MODULES=$UNLOAD_MODULES ib_sa ib_uverbs ib_umad ib_mad ib_core
-STATUS_MODULES=rdma_ucm ib_rds rds ib_srpt ib_srp qlgc_vnic ib_sdp rdma_cm
ib_addr ib_local_sa findex ib_ipoib ib_ehca ib_ipath ipath_core mlx4_core
mlx4_ib ib_mthca ib_uverbs ib_umad ib_ucm ib_sa ib_cm ib_mad ib_core
+STATUS_MODULES=rdma_ucm ib_rds rds ib_srpt ib_srp qlgc_vnic ib_sdp rdma_cm
ib_addr ib_local_sa findex ib_ipoib ib_ehca ib_ipath ipath_core mlx4_core
mlx4_ib ib_mthca ib_uverbs ib_umad ib_ucm ib_sa ib_cm ib_mad ib_core iw_cxgb3
ipoib_ha_pidfile=/var/run/ipoib_ha.pid
srp_daemon_pidfile=/var/run/srp_daemon.pid
@@ -800,6 +800,17 @@ start()
RC=$[ $RC + $my_rc ]
fi
+# Load iw_cxgb3 driver
+if [ X${CXGB3_LOAD} == Xyes ]; then
+fix_location_codes
+/sbin/modprobe iw_cxgb3 /dev/null 21
+my_rc=$?
+if [ $my_rc -ne 0 ]; then
+echo_failure $Loading cxgb3 driver:
+fi
+RC=$[ $RC + $my_rc ]
+fi
+
# Add node description to sysfs
IBSYSDIR=/sys/class/infiniband
if [ -d ${IBSYSDIR} ]; then
@@ -1101,7 +1112,7 @@ unload()
if is_module $mod; then
case $mod in
- ib_mthca | mlx4_ib | ib_ipath | ib_ehca)
+ ib_mthca | mlx4_ib | ib_ipath | ib_ehca | iw_cxgb3)
rm_mod $mod
sleep 2
;;
@@ -1273,7 +1284,7 @@ status()
{
local RC=0
- if is_module ib_mthca || is_module mlx4_core || is_module ib_ipath ||
is_module ib_ehca; then
+ if is_module ib_mthca || is_module mlx4_core || is_module ib_ipath ||
is_module ib_ehca || is_module iw_cxgb3; then
echo
echo HCA driver loaded
echo
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] cancel inline default for Hermon
perftest: cancel inline default for Hermon to optimize BW performance in send
and write
Signed-off-by: Oren Meron [EMAIL PROTECTED]
--- a/send_bw.c
+++ b/send_bw.c
@@ -922,6 +922,7 @@ int main(int argc, char *argv[])
struct pingpong_dest my_dest;
struct pingpong_dest*rem_dest;
struct user_parameters user_param;
+ struct ibv_device_attr device_attribute;
char*ib_devname = NULL;
int port = 18515;
int ib_port = 1;
@@ -929,6 +930,8 @@ int main(int argc, char *argv[])
int sockfd;
int i = 0;
int size_max_pow = 24;
+ int inline_given_in_cmd = 0;
+ struct ibv_context *context;
/* init default values to user's parameters */
memset(user_param, 0, sizeof(struct user_parameters));
user_param.mtu = 0;
@@ -937,7 +940,7 @@ int main(int argc, char *argv[])
user_param.servername = NULL;
user_param.use_event = 0;
user_param.duplex = 0;
-user_param.inline_size = MAX_INLINE;
+ user_param.inline_size = MAX_INLINE;
/* Parameter parsing. */
while (1) {
int c;
@@ -1022,6 +1025,7 @@ int main(int argc, char *argv[])
case 'I':
user_param.inline_size = strtol(optarg, NULL, 0);
+ inline_given_in_cmd =1;
if (user_param.inline_size MAX_INLINE) {
usage(argv[0]);
return 7;
@@ -1069,7 +1073,6 @@ int main(int argc, char *argv[])
else
printf(Send BW Test\n);
- printf(Inline data is used up to %d bytes message\n,
user_param.inline_size);
if (user_param.connection_type == RC)
printf(Connection type : RC\n);
else if (user_param.connection_type == UC)
@@ -1109,6 +1112,16 @@ int main(int argc, char *argv[])
}
}
+ context = ibv_open_device(ib_dev);
+ if (ibv_query_device(context, device_attribute)) {
+ fprintf(stderr, Failed to query device props);
+ return 1;
+ }
+ if ((device_attribute.vendor_part_id == 25418)
(!inline_given_in_cmd)) {
+ user_param.inline_size = 1;
+ }
+ printf(Inline data is used up to %d bytes message\n,
user_param.inline_size);
+
ctx = pp_init_ctx(ib_dev, size, user_param.tx_depth,
user_param.rx_depth,
ib_port, user_param);
if (!ctx)
diff --git a/write_bw.c b/write_bw.c
index 83a8af4..7c518aa 100644 (file)
--- a/write_bw.c
+++ b/write_bw.c
@@ -666,6 +666,7 @@ int main(int argc, char *argv[])
struct pingpong_dest *my_dest;
struct pingpong_dest**rem_dest;
struct user_parameters user_param;
+ struct ibv_device_attr device_attribute;
char*ib_devname = NULL;
int port = 18515;
int ib_port = 1;
@@ -674,6 +675,8 @@ int main(int argc, char *argv[])
int duplex = 0;
int i = 0;
int noPeak = 0;/*noPeak == 0: regular peak-bw
calculation done*/
+ int inline_given_in_cmd = 0;
+ struct ibv_context *context;
/* init default values to user's parameters */
memset(user_param, 0, sizeof(struct user_parameters));
@@ -767,6 +770,7 @@ int main(int argc, char *argv[])
case 'I':
user_param.inline_size = strtol(optarg, NULL, 0);
+ inline_given_in_cmd =1;
if (user_param.inline_size MAX_INLINE) {
usage(argv[0]);
return 7;
@@ -810,7 +814,6 @@ int main(int argc, char *argv[])
printf(RDMA_Write BW Test\n);
}
- printf(Inline data is used up to %d bytes message\n,
user_param.inline_size);
printf(Number of qp's running %d\n,user_param.numofqps);
if (user_param.connection_type==RC) {
printf(Connection type : RC\n);
@@ -853,6 +856,16 @@ int main(int argc, char *argv[])
}
}
+ context = ibv_open_device(ib_dev);
+ if (ibv_query_device(context, device_attribute)) {
+ fprintf(stderr, Failed to query device props);
+ return 1;
+ }
+ if ((device_attribute.vendor_part_id == 25418)
(!inline_given_in_cmd)) {
+ user_param.inline_size = 1;
+ }
+ printf(Inline data is used up to %d bytes message\n,
user_param.inline_size);
+
ctx = pp_init_ctx(ib_dev, size, user_param.tx_depth, ib_port,
user_param);
if (!ctx)
Re: [ewg] Re: non SRQ patch for OFED 1.3
Pradeep, We tries to apply this patch for OFED 1.3 and its breaks some of the backports. Please use the makedist script on the ofa server (there is an explanation in the developers Wiki) and fix this so we can try to apply it Vlad will help you later today too Thanks, Tziporet Thanks Tziporet/Vlad for helping this into OFED-1.3. Sean suggested to compare noSRQ and SRQ performance in a smaller cluster environment long time ago. That's an interesting suggestion. We are planning to compare it in OFED-1.3. Thanks Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
Yes this is better, I have no particular objections to these changes and appreciate your efforts to hold the line on the OFED 1.3 schedule. Thanks, Bob Tziporet Koren wrote: The main reason is not the bugs but the features supported by IBM - CM support for non SRQ and 4K MTU I see that these are important for IBM (see other mails) Another thing we can do in order not to delay the release is insert the changes tomorrow (immediately after RC3 is out) and do RC4 next week (instead of 2 weeks between every RC), and RC5 the week after. In this way we will have enough time for testing and if we find some bug we can fix then in RC5 Is this better? Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[Fwd: [ewg] [PATCH ofed-1.3] Load iw_cxgb3 as part of ofed init.]
Can this fix make ofed-1.3?
Its a trivial change and allows iw_cxgb3 to get loaded like the other
rdma modules...
Steve.
Original Message
Subject: [ewg] [PATCH ofed-1.3] Load iw_cxgb3 as part of ofed init.
Date: Thu, 31 Jan 2008 09:21:18 -0600
From: Steve Wise [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: ewg@lists.openfabrics.org
Vlad, can you please review this? Is there anything else needed to get
iw_cxgb3 to be loaded at init time? I tested the patched openibd and
it seems to work fine.
If this looks good to you, please pull this patch for ofed-1.3 from:
git://www.openfabrics.org/~swise/ofed-1.3 ofed_kernel
This change is long overdue...
Thanks,
Steve.
--
Load iw_cxgb3 as part of ofed init.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
ofed_scripts/ofa_kernel.spec |6 ++
ofed_scripts/openibd | 19 +++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/ofed_scripts/ofa_kernel.spec b/ofed_scripts/ofa_kernel.spec
index 6184cfc..954dd0c 100755
--- a/ofed_scripts/ofa_kernel.spec
+++ b/ofed_scripts/ofa_kernel.spec
@@ -488,6 +488,12 @@ fi
echo MLX4_LOAD=yes %{IB_CONF_DIR}/openib.conf
%endif
+%if %{build_cxgb3}
+ echo %{IB_CONF_DIR}/openib.conf
+ echo # Load CXGB3 modules %{IB_CONF_DIR}/openib.conf
+ echo CXGB3_LOAD=yes %{IB_CONF_DIR}/openib.conf
+%endif
+
%if %{build_ipoib}
echo %{IB_CONF_DIR}/openib.conf
echo # Load IPoIB %{IB_CONF_DIR}/openib.conf
diff --git a/ofed_scripts/openibd b/ofed_scripts/openibd
index 2553881..700c8ef 100755
--- a/ofed_scripts/openibd
+++ b/ofed_scripts/openibd
@@ -273,13 +273,13 @@ fi
GEN1_UNLOAD_MODULES=ib_srp_target scsi_target ib_srp kdapltest_module
ib_kdapl ib_sdp ib_useraccess ib_useraccess_cm ib_cm ib_dapl_srv
ib_ip2pr ib_ipoib ib_tavor mod_thh mod_rhh ib_dm_client ib_sa_client
ib_client_query ib_poll ib_mad ib_core ib_services
-UNLOAD_MODULES=ib_mthca mlx4_enet mlx4_ib mlx4_core ib_ipath
ipath_core ib_ehca
+UNLOAD_MODULES=ib_mthca mlx4_enet mlx4_ib mlx4_core ib_ipath
ipath_core ib_ehca iw_cxgb3
UNLOAD_MODULES=$UNLOAD_MODULES ib_ipoib ib_madeye ib_rds
UNLOAD_MODULES=$UNLOAD_MODULES rds ib_ucm kdapl ib_srp_target
scsi_target ib_srpt ib_srp qlgc_vnic ib_iser ib_sdp
UNLOAD_MODULES=$UNLOAD_MODULES rdma_ucm rdma_cm ib_addr ib_cm
ib_local_sa findex
UNLOAD_MODULES=$UNLOAD_MODULES ib_sa ib_uverbs ib_umad ib_mad ib_core
-STATUS_MODULES=rdma_ucm ib_rds rds ib_srpt ib_srp qlgc_vnic ib_sdp
rdma_cm ib_addr ib_local_sa findex ib_ipoib ib_ehca ib_ipath ipath_core
mlx4_core mlx4_ib ib_mthca ib_uverbs ib_umad ib_ucm ib_sa ib_cm ib_mad
ib_core
+STATUS_MODULES=rdma_ucm ib_rds rds ib_srpt ib_srp qlgc_vnic ib_sdp
rdma_cm ib_addr ib_local_sa findex ib_ipoib ib_ehca ib_ipath ipath_core
mlx4_core mlx4_ib ib_mthca ib_uverbs ib_umad ib_ucm ib_sa ib_cm ib_mad
ib_core iw_cxgb3
ipoib_ha_pidfile=/var/run/ipoib_ha.pid
srp_daemon_pidfile=/var/run/srp_daemon.pid
@@ -800,6 +800,17 @@ start()
RC=$[ $RC + $my_rc ]
fi
+# Load iw_cxgb3 driver
+if [ X${CXGB3_LOAD} == Xyes ]; then
+fix_location_codes
+/sbin/modprobe iw_cxgb3 /dev/null 21
+my_rc=$?
+if [ $my_rc -ne 0 ]; then
+echo_failure $Loading cxgb3 driver:
+fi
+RC=$[ $RC + $my_rc ]
+fi
+
# Add node description to sysfs
IBSYSDIR=/sys/class/infiniband
if [ -d ${IBSYSDIR} ]; then
@@ -1101,7 +1112,7 @@ unload()
if is_module $mod; then
case $mod in
- ib_mthca | mlx4_ib | ib_ipath | ib_ehca)
+ ib_mthca | mlx4_ib | ib_ipath | ib_ehca | iw_cxgb3)
rm_mod $mod
sleep 2
;;
@@ -1273,7 +1284,7 @@ status()
{
local RC=0
- if is_module ib_mthca || is_module mlx4_core || is_module
ib_ipath || is_module ib_ehca; then
+ if is_module ib_mthca || is_module mlx4_core || is_module
ib_ipath || is_module ib_ehca || is_module iw_cxgb3; then
echo
echo HCA driver loaded
echo
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness
Thanks for everyone here. I appreciate your comments and effort. The big challenge for us is how to sync features/blockers with OFED release Distros release. Most of our customers prefer Distros release so they can get same level of support as other pieces. If OFED could work with Distros release, then it will be less problems for both end users and Distros. That's just my personal opinion. We are here to support any issues being found in OFED release cycle on time regarding these patches. Thanks again! Shirley ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
At 09:16 PM 1/30/2008, Chet Mehta wrote: Robert, In response to your question.. A more general question I would like to ask the group is how many people use OFED from the RH or SUSE distros as is, as compared with using OFED releases from other sources like the IB vendors, or building their own from openfabrics.org? We use RH distros, but to this point, the OFED support provided in RH distros has lagged behind the latest releases available from openfabrics.org. This is not to fault Red Hat, but OFED is still changing too rapidly, with minor point releases and bug fixes, for a distro to keep up. I think many of us hope that someday that will not be the case, but appears to be true for the foreseeable future. Right now, our mode of operation is to remove whatever IB support comes in the distro and replace it, so it does not help us to delay OFED 1.3 to get a particular bug fix in a distro. We have found that there are some vendors who dictate that they will only support a Distro EX: RHXXX. Then if you layer the latest OFED on top, then the support is nullified. Or to get any bug fixes or support you have to uninstall the what you did and repeat the bug/error. SO I think it is very important to keep the Distros very close the latest OFED stack. I believe the question that should be asked is 'How many IB customers would like to use the OFED distribution if provided by the distro? The answer at least for the customer set we deal with is pretty much unanimous. The fact is that customers are already dealing with a distro for their base OS so obtaining the interconnect code support from the same sources is highly desirable. When OpenIB was new (in 2004/5) and common IB code was still in its infancy, the customer set was tolerant of 'build your own' or vendor provided distribution mechanism. However if IB is to become a ubiquitous interconnect, we in OFA have to strive to tailor our deliverables to meet distro requirements. Until we do that, IB will have difficultly gaining broader market acceptance. Just my perspective. :Chet. ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general * Correspondence * This email contains no programmatic content that requires independent ADC review ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary onRC3readiness
In all fairness, the kernel portion of all of this, and the process of getting things into Linus' kernel, has *always* been a case of staging things in Roland's tree and then merging upstream. So, at least for the kernel, that's mostly true as OFED is pretty close to Roland's tree generally speaking. As for the user space packages though, you guys *are* the upstream. There's no one to merge upstream to and very little oversight by anyone. So, it's entirely up to all of you just how much your package seems to be a feature of the day change-athon versus a solid, stable program. I don't believe that this is the model actually in use. OFED has accepted kernel features that have not been submitted for upstream inclusion, or, in some cases, that were, but were rejected. (For examples, see local SA, SA event subscription, XRC, SDP, and some of the previous incarnations of IPoIB CM.) There are thousands of lines of code difference between OFED and the kernel upon which it's based. (To be clear, I'm not objecting to any changes, just the sheer volume.) The OFED releases of the userspace libraries are not identical to those provided by the maintainers. (See libibverbs.) Whose version of libibverbs does RedHat plan on using? How do you manage the differences between OFED and Roland's libibverbs libraries? And I'm really not trying to come across harsh here, but if the distros are willing to pull the OFED code, why should OFA bother trying to merge anything upstream? - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3 readiness
Conversely, there are some vendors who will *not* support OFED from a distro, but only a version they supply and control. The customers I work with are more sensitive to performance, as well as quick turnaround for bug fixes, so having the latest releases, and being able to update them quickly is critical. I agree that for other customers, a more slowly changing supported stack is suitable. These may also be the same customers more likely to use 10GE. I agree more discussion and adjustment is needed for OFED to be able to balance the needs of the spectrum of users, from the latest kernel.org users, IB vendor based users and distro based users. Bob Parks Fields wrote: At 09:16 PM 1/30/2008, Chet Mehta wrote: Robert, In response to your question.. A more general question I would like to ask the group is how many people use OFED from the RH or SUSE distros as is, as compared with using OFED releases from other sources like the IB vendors, or building their own from openfabrics.org? We use RH distros, but to this point, the OFED support provided in RH distros has lagged behind the latest releases available from openfabrics.org. This is not to fault Red Hat, but OFED is still changing too rapidly, with minor point releases and bug fixes, for a distro to keep up. I think many of us hope that someday that will not be the case, but appears to be true for the foreseeable future. Right now, our mode of operation is to remove whatever IB support comes in the distro and replace it, so it does not help us to delay OFED 1.3 to get a particular bug fix in a distro. We have found that there are some vendors who dictate that they will only support a Distro EX: RHXXX. Then if you layer the latest OFED on top, then the support is nullified. Or to get any bug fixes or support you have to uninstall the what you did and repeat the bug/error. SO I think it is very important to keep the Distros very close the latest OFED stack. I believe the question that should be asked is 'How many IB customers would like to use the OFED distribution if provided by the distro? The answer at least for the customer set we deal with is pretty much unanimous. The fact is that customers are already dealing with a distro for their base OS so obtaining the interconnect code support from the same sources is highly desirable. When OpenIB was new (in 2004/5) and common IB code was still in its infancy, the customer set was tolerant of 'build your own' or vendor provided distribution mechanism. However if IB is to become a ubiquitous interconnect, we in OFA have to strive to tailor our deliverables to meet distro requirements. Until we do that, IB will have difficultly gaining broader market acceptance. Just my perspective. :Chet. ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general * Correspondence * This email contains no programmatic content that requires independent ADC review ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary onRC3readiness
On Thu, 2008-01-31 at 10:07 -0800, Sean Hefty wrote: In all fairness, the kernel portion of all of this, and the process of getting things into Linus' kernel, has *always* been a case of staging things in Roland's tree and then merging upstream. So, at least for the kernel, that's mostly true as OFED is pretty close to Roland's tree generally speaking. As for the user space packages though, you guys *are* the upstream. There's no one to merge upstream to and very little oversight by anyone. So, it's entirely up to all of you just how much your package seems to be a feature of the day change-athon versus a solid, stable program. I don't believe that this is the model actually in use. OFED has accepted kernel features that have not been submitted for upstream inclusion, or, in some cases, that were, but were rejected. (For examples, see local SA, SA event subscription, XRC, SDP, and some of the previous incarnations of IPoIB CM.) There are thousands of lines of code difference between OFED and the kernel upon which it's based. (To be clear, I'm not objecting to any changes, just the sheer volume.) The OFED releases of the userspace libraries are not identical to those provided by the maintainers. (See libibverbs.) Whose version of libibverbs does RedHat plan on using? How do you manage the differences between OFED and Roland's libibverbs libraries? And I'm really not trying to come across harsh here, but if the distros are willing to pull the OFED code, why should OFA bother trying to merge anything upstream? I pull *some* OFED code. I don't pull it all. There are things in OFED I won't accept until they've gone upstream. Hence, RDS is not in our offering. We made the mistake of taking SDP long ago and we'll carry that forward, but we generally look for things to be upstream before pulling them from OFED at this point (or at least have been submitted upstream and is being worked towards acceptance). In terms of user space, given a choice between a released tarball or the custom OFED tarball, I choose the released tarball. So, I currently have Roland's libibverbs, libmthca, and libmlx4. -- Doug Ledford [EMAIL PROTECTED] GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: This is a digitally signed message part ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] OFED Jan 28 meeting summary onRC3readiness
On Thu, Jan 31, 2008 at 01:30:23PM -0500, Doug Ledford wrote: And I'm really not trying to come across harsh here, but if the distros are willing to pull the OFED code, why should OFA bother trying to merge anything upstream? I pull *some* OFED code. I don't pull it all. There are things in OFED I won't accept until they've gone upstream. Hence, RDS is not in our offering. We made the mistake of taking SDP long ago and we'll carry What about XRC? -- Gleb. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] cancel inline default for Hermon
On 1/31/08, Oren Meron [EMAIL PROTECTED] wrote: perftest: cancel inline default for Hermon to optimize BW performance in send and write Can you please explain what was the problem and what is the fix? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] OFED Jan 28 meeting summaryonRC3readiness
It's currently in, although that isn't written in stone either. Individual changes to existing components, like xrc, can slip past me easier than whole unsubmitted subsystems like RDS. I think for RedHat it would end up being in the kernel, but Roland's userspace library doesn't support it, so it ends up being unused code. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] Re: [ofa-general] [ANNOUCE] dapl 2.0.5 release [PATCH] install.pl
Hi Arlin,
I am not sure that I will be available to do this till OFED-1.3-rc4.
If you can send me the patch to install.pl script I will apply this to
my git tree.
git://git.openfabrics.org/~vlad/ofed_1_3_scripts master
Change install script to include v1 dapl-devel package.
Signed-off by: Arlin Davis [EMAIL PROTECTED]
diff --git a/install.pl b/install.pl
index 9be3013..354e896 100755
--- a/install.pl
+++ b/install.pl
@@ -295,7 +295,7 @@ my @user_packages = (libibverbs, libibverbs-devel,
libibverbs-devel-static
librdmacm, librdmacm-utils, librdmacm-devel,
librdmacm-debuginfo,
libsdp, libsdp-devel, libsdp-debuginfo,
opensm, opensm-libs, opensm-devel,
opensm-debuginfo, opensm-static,
- dapl-v1, dapl-v2, dapl-devel, dapl-devel-static,
dapl-utils,
dapl-debuginfo,
+ dapl-v1, dapl-v1-devel, dapl-v2, dapl-devel,
dapl-devel-static,
dapl-utils, dapl-debuginfo,
perftest, mstflint, tvflash,
qlvnictools, sdpnetstat, srptools, rds-tools,
ibutils, infiniband-diags, qperf, qperf-debuginfo,
@@ -309,7 +309,7 @@ my @basic_user_packages = (libibverbs,
libibverbs-utils, libmthca, libmlx
my @hpc_kernel_packages = (kernel-ib, ib-bonding);
my @hpc_kernel_modules = (@basic_kernel_modules);
my @hpc_user_packages = (@basic_user_packages, librdmacm,
-librdmacm-utils, dapl-v1, dapl-v2, dapl-devel,
dapl-devel-static,
dapl-utils,
+librdmacm-utils, dapl-v1, dapl-v1-devel,
dapl-v2, dapl-devel,
dapl-devel-static, dapl-utils,
infiniband-diags, ibutils, qperf, @mpi_packages);
# all_packages is required to save ordered (following dependencies) list of
@@ -932,6 +932,13 @@ my %packages_info = (
dist_req_inst = [], ofa_req_build = [libibverbs,
libibverbs-devel, librdmacm,
librdmacm-devel],
ofa_req_inst = [libibverbs, librdmacm],
install32 = 1, exception = 0, configure_options = '' },
+'dapl-v1-devel' =
+{ name = dapl-devel, parent = dapl-v1,
+selected = 0, installed = 0, rpm_exist = 0, rpm_exist32 = 0,
+available = 1, mode = user, dist_req_build = [],
+dist_req_inst = [], ofa_req_build =
[libibverbs,libibverbs-devel, librdmacm,
librdmacm-devel],
+ofa_req_inst = [dapl-v1],
+install32 = 1, exception = 0, configure_options = '' },
'dapl-v2' =
{ name = dapl, parent = dapl-v2,
selected = 0, installed = 0, rpm_exist = 0, rpm_exist32 = 0,
@@ -3120,7 +3127,7 @@ sub install_rpm_32
my $release = $main_packages{$packages_info{$name}{'parent'}}{'release'};
if ( $name =~ m/dapl-v/ ) {
-$name = dapl;
+$name = $packages_info{$name}{'name'};
}
$package = $RPMS/$name-$version-$release.$target_cpu32.rpm;
@@ -3181,7 +3188,7 @@ sub install_rpm
if ( $name =~ m/dapl-v/ ) {
$tmp_name = $name;
-$name = dapl;
+$name = $packages_info{$name}{'name'};
}
if ($name eq $packages_info{'open-iscsi-generic'}{'name'}) {
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
