[ewg] ofa_1_5_kernel 20100616-0200 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git git_branch: ofed_kernel_1_5 Common build parameters: Passed: Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.26 Passed on i686 with linux-2.6.24 Passed on i686 with linux-2.6.22 Passed on i686 with linux-2.6.27 Passed on x86_64 with linux-2.6.16.60-0.54.5-smp Passed on x86_64 with linux-2.6.16.60-0.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-128.el5 Passed on x86_64 with linux-2.6.18-194.el5 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.18-93.el5 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.22 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.24 Passed on x86_64 with linux-2.6.25 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.27.19-5-smp Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on x86_64 with linux-2.6.9-67.ELsmp Passed on x86_64 with linux-2.6.9-89.ELsmp Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.23 Passed on ia64 with linux-2.6.21.1 Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.26 Passed on ia64 with linux-2.6.24 Passed on ia64 with linux-2.6.25 Passed on ppc64 with linux-2.6.18 Passed on ppc64 with linux-2.6.19 Failed: ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED-1.5.2 32bit packaging
On Tue, 15 Jun 2010 17:09:24 +0300
Vladimir Sokolovsky wrote:
> Hi Alexander,
> Please try OFED installation after applying the following patch to the
> install.pl script:
>
>
> diff --git a/install.pl b/install.pl
> index 89ca93c..54f3b0f 100755
> --- a/install.pl
> +++ b/install.pl
> @@ -3481,7 +3481,7 @@ sub install_rpm_32
> }
>
> $cmd = "rpm -iv $rpminstall_flags";
> -if ($distro eq "SuSE" and $dist_rpm_rel gt 15.2) {
> +if ($distro eq "SuSE") {
> $cmd .= " --force";
> }
> $cmd .= " $package";
Hi Vlad,
this worked fine on SLES11SP1, will this be the final fix or could this break
other (older) SuSE releases?
Anyway, thanks for looking into this!
Regards,
Alex
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED-1.5.2 32bit packaging
Alexander Schmidt wrote:
> On Tue, 15 Jun 2010 17:09:24 +0300
> Vladimir Sokolovsky wrote:
>> Hi Alexander,
>> Please try OFED installation after applying the following patch to the
>> install.pl script:
>>
>>
>> diff --git a/install.pl b/install.pl
>> index 89ca93c..54f3b0f 100755
>> --- a/install.pl
>> +++ b/install.pl
>> @@ -3481,7 +3481,7 @@ sub install_rpm_32
>> }
>>
>> $cmd = "rpm -iv $rpminstall_flags";
>> -if ($distro eq "SuSE" and $dist_rpm_rel gt 15.2) {
>> +if ($distro eq "SuSE") {
>> $cmd .= " --force";
>> }
>> $cmd .= " $package";
>
>
> Hi Vlad,
>
> this worked fine on SLES11SP1, will this be the final fix or could this break
> other (older) SuSE releases?
>
> Anyway, thanks for looking into this!
>
> Regards,
> Alex
>
Hi,
This will be the final fix.
Actually, it is a workaround.
The correct fix is to use SLES convention for RPM names (name-32bit) but I have
no time work on this.
Regards,
Vladimir
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Roland Dreier wrote: > > I tested it before on the Roland tree ( iboe branch ) and it fails, > > because it writen in the way suitable for OFED. If adapt the patch to > > the Roland tree, then appling Mellanox OFED patches will fail, because > > it changes the same functions in the code. > > Here is one example: > > Look at __mlx4_ib_modify_qp at the Roland tree - there is no RAW_ETY > > support. But in the OFED version of the same function this support is > > present. > > RAW_ETH patch modify this function and looking for RAW_ETY word and > > without this RAW_ETH Mellanox patch will fail. > > Don't take this too personally -- I picked a semi-random email in this > thread to reply to; this is pretty broadly targeted. > > > > What the hell is the thinking behind introducing IB_QPT_RAW_ETH? You're > inserting an enum value before IB_QPT_RAW_ETY, so any old userspace > passing in IB_QPT_RAW_ETY will silently get different behavior depending > on the kernel version. And you're creating two constands that differ in > a single letter (IB_QPT_RAW_ETY vs. IB_QPT_RAW_ETH). How are you going > to explain that to users? How is anyone ever going to get it right? > For that matter, what exactly does IB_QPT_RAW_ETH mean? > > This all seems to be a symptom of how broken our development process > is. Yes, unfortunately I can't spend as much time reviewing and > applying patches as I might like, and I apologize for that. But if we > have all the RDMA developers piling up shit in their little area and > then sending it on to be merged as soon as it kind of works, without > thinking about design or maintainability and without ever doing any > review, then I'm always going to have an expanding review backlog. > > And then we have OFED compounding problems -- "Oh that's a nice pile of > shit you've built there. We better ship it to users while it's still > steaming." How about if OFED developers take a little time to think > things through? > > > > In other words, can someone explain the plan for this raw QP stuff to me? > > - R. > It doesn't even look like this patch and the mlx4 patch were ever posted to linux-rdma. Only to the EWG list. Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. We should all follow this "upstream first" process IMO. Steve. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED-1.5.2 32bit packaging
On 6/16/2010 4:31 PM, Vladimir Sokolovsky wrote: > Hi, > This will be the final fix. > Actually, it is a workaround. > The correct fix is to use SLES convention for RPM names (name-32bit) but I > have no time work on this. > > > Alex Do you have time for this? Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Hi Roland, > What the hell is the thinking behind introducing IB_QPT_RAW_ETH? You're > inserting an enum value before IB_QPT_RAW_ETY, so any old userspace > passing in IB_QPT_RAW_ETY will silently get different behavior depending > on the kernel version. And you're creating two constands that differ in > a single letter (IB_QPT_RAW_ETY vs. IB_QPT_RAW_ETH). How are you going > to explain that to users? How is anyone ever going to get it right? > For that matter, what exactly does IB_QPT_RAW_ETH mean? > There is no qp type IBV_QPT_RAW_ETY in user space (at least not in the definitions coming with libibverbs). In fact, libibverbs that comes with OFED defines (in verbs.h) a qp type called IBV_QPT_RAW_ETT which equals to 7. The patch that is under discussion here adds a new qp type IB_QPT_RAW_ETH and equals it to 7 to match the definition in user space. This indeed changes the value of IB_QPT_RAW_ETY to 8 but I don't see who can be affected since 1. No user space program that uses IB_QPT_RAW_ETY exists 2. kernel is compiled as one piece of code. > This all seems to be a symptom of how broken our development process > is. Yes, unfortunately I can't spend as much time reviewing and > applying patches as I might like, and I apologize for that. But if we > have all the RDMA developers piling up shit in their little area and > then sending it on to be merged as soon as it kind of works, without > thinking about design or maintainability and without ever doing any > review, then I'm always going to have an expanding review backlog. > I want very much to push the RAW_ETH patches to upstream and we didn't intend to skip this stage. However, 1. It seems that upstream kernel still can't use ConnectX ETH ports. Is it right? 2. From practical (commercial) reasons it was important to us that the RAW_ETH patches will be in OFED. AFAIK, OFED recommends that patches will be reviewed and added first in upstream kernel but exceptions are allowed. Anyway, we didn't think that a review is not necessary, we just used the OFED group for that matter. > And then we have OFED compounding problems -- "Oh that's a nice pile of > shit you've built there. We better ship it to users while it's still > steaming." How about if OFED developers take a little time to think > things through? > > > > In other words, can someone explain the plan for this raw QP stuff to me? I hope I understand what needs to be explained but in short, we want a QP type that takes the data in post_send() and puts it on the wire as is without adding headers or footers. This allows the user of this kind of QP to build an entire Ethernet packet and send it to an Ethernet switch port. UD/RC QP with RoCEE is no good because we want to be compliant with simple ETH devices (e.g. remote server with standard 10G NIC) Infiniband RAW packets is no good (if I understand the spec correctly) because it adds LRH and is not suitable for fabrics with Ethernet switch This is why RAW_ETH was invented. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
> > > It doesn't even look like this patch and the mlx4 patch were ever posted > to linux-rdma. Only to the EWG list. > Not 100% correct. See thread from April 30. Patches to core, libibverbs and NES driver were presented there. > Granted our dev process may not be documented, but I always assumed the > general idea was to get changes accepted upstream, then pull into ofed. > OFED is just a mechanism to make top-of-tree linux work on distro > kernels. There are some exceptions, but this stuff shouldn't be an > exception. > > We should all follow this "upstream first" process IMO. > ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Moni Shoua wrote: > > >> It doesn't even look like this patch and the mlx4 patch were ever posted >> to linux-rdma. Only to the EWG list. >> >> > Not 100% correct. See thread from April 30. > Patches to core, libibverbs and NES driver were presented there. > > I'll go look, but I thought the NES stuff was for RAW_ETY qp types. Not RAW_ETH... >> Granted our dev process may not be documented, but I always assumed the >> general idea was to get changes accepted upstream, then pull into ofed. >> OFED is just a mechanism to make top-of-tree linux work on distro >> kernels. There are some exceptions, but this stuff shouldn't be an >> exception. >> >> We should all follow this "upstream first" process IMO. >> >> > > > -- > 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.html > ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
> >> It doesn't even look like this patch and the mlx4 patch were ever posted > >> to linux-rdma. Only to the EWG list. > >> > >> > > Not 100% correct. See thread from April 30. > > Patches to core, libibverbs and NES driver were presented there. > > > > > > I'll go look, but I thought the NES stuff was for RAW_ETY qp types. Not > RAW_ETH... There was a problem with the original patch series from Mirek and it didn't show up in patchwork. Subsequently there's been bug fixes including the defines. I think it would be easier if the whole thing is cleaned up and resubmitted. Resolving the define name would be great as I got very confused the first time I saw it and I still don't understand it fully. Chien ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
On Wed, Jun 16, 2010 at 09:09:59AM -0500, Steve Wise wrote: > Granted our dev process may not be documented, but I always assumed the > general idea was to get changes accepted upstream, then pull into ofed. > OFED is just a mechanism to make top-of-tree linux work on distro > kernels. There are some exceptions, but this stuff shouldn't be an > exception. That is what many people wish for, me included, but it is not at all what generally happens :( In my observation the typical flow is: - A patch is written, it may or may not be sent to the list - 'business drivers' get it slammed into OFED right away - A patch is finally sent for proper review - It is not merged, there are comments.. - Interest in doing anything is lost because it is already in OFED and that is all that matters, right? - People complain. For instance, the iWarp thingy we were just discussing fits this process rather well. Jason ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Jason Gunthorpe wrote: > On Wed, Jun 16, 2010 at 09:09:59AM -0500, Steve Wise wrote: > > >> Granted our dev process may not be documented, but I always assumed the >> general idea was to get changes accepted upstream, then pull into ofed. >> OFED is just a mechanism to make top-of-tree linux work on distro >> kernels. There are some exceptions, but this stuff shouldn't be an >> exception. >> > > That is what many people wish for, me included, but it is not at all > what generally happens :( > > In my observation the typical flow is: > - A patch is written, it may or may not be sent to the list > - 'business drivers' get it slammed into OFED right away > - A patch is finally sent for proper review > - It is not merged, there are comments.. > - Interest in doing anything is lost because it is already in >OFED and that is all that matters, right? > - People complain. > > For instance, the iWarp thingy we were just discussing fits this > process rather well. > > You're wrong. I started that iWARP change in 2007 on LKLM. I proposed a few ideas and show the pros/cons of each. And it was NAKed 100% by mister miller.It was then included in OFED as a last resort only because I couldn't get any help with trying to add this upstream in any form. I even spent a few weeks developing a way to administor "iwarp only" ipaddresses, but Roland didn't like that scheme for various reasons. So please don't mention that particular patch as a "bad process" unless you want to argue with me some more about it. Also, the chelsio iWARP driver has 100% been upstream first, then ofed. Some of us are indeed trying to do the right thing. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] ofa_kernel openibd script
This patch builds upon my previously submitted patch for improving the default
handling of the node_desc.
With this patch, the openibd script will set the description of each HCA in the
system to the value "@: HCA-##" where "##" is replaced with a unique id number
for that HCA and the "@" symbol is automatically replaced by the HCA whenever
the HCA's node description is queried. For example:
r...@bart:~# cat /sys/class/infiniband/mthca0/node_desc
@: HCA-1
[r...@panic ~]# smpquery ND 6
Node Description: bart: HCA-1
Again, this patch is only effective when combined with my previously submitted
node_desc patch.
Signed-Off-By: Michael Heinz
-
diff --git a/ofed_scripts/openibd b/ofed_scripts/openibd
index fa65611..447e1a8 100755
--- a/ofed_scripts/openibd
+++ b/ofed_scripts/openibd
@@ -898,8 +898,8 @@ if [ -d \${IBSYSDIR} ]; then
for hca in \${IBSYSDIR}/*
do
if [ -e \${hca}/node_desc ]; then
-logger -i "Set node_desc for \$(basename \$hca): \$(hostname -s)
HCA-\${hca_id}"
-echo -n "\$(hostname -s) HCA-\${hca_id}" >> \${hca}/node_desc
+logger -i "Set node_desc for HCA-\${hca_id}"
+echo -n "@: HCA-\${hca_id}" >> \${hca}/node_desc
fi
let hca_id++
done
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
On Wed, Jun 16, 2010 at 12:12:06PM -0500, Steve Wise wrote: >>> Granted our dev process may not be documented, but I always assumed >>> the general idea was to get changes accepted upstream, then pull into >>> ofed. OFED is just a mechanism to make top-of-tree linux work on >>> distro kernels. There are some exceptions, but this stuff shouldn't >>> be an exception. >> That is what many people wish for, me included, but it is not at all >> what generally happens :( >> >> In my observation the typical flow is: >> - A patch is written, it may or may not be sent to the list >> - 'business drivers' get it slammed into OFED right away >> - A patch is finally sent for proper review >> - It is not merged, there are comments.. >> - Interest in doing anything is lost because it is already in >>OFED and that is all that matters, right? >> - People complain. >> >> For instance, the iWarp thingy we were just discussing fits this >> process rather well. > You're wrong. I started that iWARP change in 2007 on LKLM. I proposed > a few ideas and show the pros/cons of each. And it was NAKed 100% by > mister miller.It was then included in OFED as a last resort only > because I couldn't get any help with trying to add this upstream in any > form. I even spent a few weeks developing a way to administor "iwarp > only" ipaddresses, but Roland didn't like that scheme for various > reasons. So please don't mention that particular patch as a "bad > process" unless you want to argue with me some more about it. Uhm, what you just described does fit my process outline: #1 - Patch written, sent to LKML. Check. #3 - Patch sent for proper review - in 2007. Check. #4 - Not merged. NAK by DM. Check. #2 - 'business drivers' force it into OFED - 'last resort' ie, iWarp cards can't be used without some fix. Check. #5 - Interest is lost. Yep, this was done in 2007, and it was idle till now. Check. #6 - People Complain. Hmm. Yep. Check. Don't think I'm being critical toward only you, or singling out that little iWarp patch. But it really isn't special, or different, or an exception. Pick nearly any patch in OFED and someone will rush to its defense with a 'we tried to follow the process and it failed, so we did it anyway' argument. I also didn't say this is the only way that RDMA development goes, lots and lots of stuff goes into mainline first, from everyone. Jason ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Jason Gunthorpe wrote: > On Wed, Jun 16, 2010 at 12:12:06PM -0500, Steve Wise wrote: > > Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. > > >>> That is what many people wish for, me included, but it is not at all >>> what generally happens :( >>> >>> In my observation the typical flow is: >>> - A patch is written, it may or may not be sent to the list >>> - 'business drivers' get it slammed into OFED right away >>> - A patch is finally sent for proper review >>> - It is not merged, there are comments.. >>> - Interest in doing anything is lost because it is already in >>>OFED and that is all that matters, right? >>> - People complain. >>> >>> For instance, the iWarp thingy we were just discussing fits this >>> process rather well. >>> > > >> You're wrong. I started that iWARP change in 2007 on LKLM. I proposed >> a few ideas and show the pros/cons of each. And it was NAKed 100% by >> mister miller.It was then included in OFED as a last resort only >> because I couldn't get any help with trying to add this upstream in any >> form. I even spent a few weeks developing a way to administor "iwarp >> only" ipaddresses, but Roland didn't like that scheme for various >> reasons. So please don't mention that particular patch as a "bad >> process" unless you want to argue with me some more about it. >> > > Uhm, what you just described does fit my process outline: > > #1 - Patch written, sent to LKML. Check. > #3 - Patch sent for proper review - in 2007. Check. > #4 - Not merged. NAK by DM. Check. > #2 - 'business drivers' force it into OFED - 'last resort' ie, iWarp > cards can't be used without some fix. Check. > #5 - Interest is lost. Yep, this was done in 2007, and it was idle > till now. Check. > #6 - People Complain. Hmm. Yep. Check. > > Note the ordering is different. IE I tried very hard to get the "right" solution designed and agreed-upon upstream. But failed. That's my bad.I did, however help with the iWARP core code including neighbour update net events which did go in upstream before ofed. > Don't think I'm being critical toward only you, or singling out that > little iWarp patch. But it really isn't special, or different, or an > exception. Pick nearly any patch in OFED and someone will rush to its > defense with a 'we tried to follow the process and it failed, so we > did it anyway' argument. > > I also didn't say this is the only way that RDMA development goes, > lots and lots of stuff goes into mainline first, from everyone. > > Jason > OFED maintainers should be more rigid, perhaps, with requiring that changes be accepted upstream first. One observation is that there is no "OFED RDMA maintainer", aka a Roland Dreier, for the OFED code. So each driver maintainer pretty much has free reign to do the right thing or the wrong thing... Steve. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
