[ewg] ofa_1_5_kernel 20100617-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.18 Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.24 Passed on i686 with linux-2.6.26 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-67.ELsmp Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on x86_64 with linux-2.6.9-89.ELsmp Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.18 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.24 Passed on ia64 with linux-2.6.26 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
[ewg] [PATCH] iWARP Multicast Acceleration description - nes_release_notes.txt update
docs/nes: Add description of iWARP Multicast Acceleration The document describes a usage model of the iWARP Multicast Acceleration Signed-off-by: Mirek Walukiewicz miroslaw.walukiew...@intel.com --- diff --git a/nes_release_notes.txt b/nes_release_notes.txt index 6386c54..b23abf3 100644 --- a/nes_release_notes.txt +++ b/nes_release_notes.txt @@ -269,5 +269,66 @@ Example mpirun command line: -mca btl_openib_flags 2 /usr/mpi/gcc/openmpi-1.4.1/tests/IMB-3.2/IMB-MPI1 +=== +iWARP Multicast Acceleration (IMA) +=== + +iWARP multicast acceleration bases on new defined QP +type IBV_QPT_RAW_ETH. Adding a IBV_QPT_RAW_ETH enables +a L2 traffic kernel bypass using user-space verbs API. + +The L2 RAW_ETH acceleration assumes that user application +transmits and receives a whole L2 frame including MAC/IP/UDP/TCP headers. + +ETH RAW QP usage: +first the application creates IBV_QPT_RAW_ETH QP with associated CQ,PD, +completion channels as it is performed for RDMA connection. + +Next step is enabling L2 MAC address RX filters for directing received +multicasts to the RAW_ETH QPs using ibv_attach_multicast() verb. + +From this point the application is ready to receive and transmit +multicast traffic. + +In multicast acceleration the user application passes to ibv_post_send() +whole IGMP frame including MAC header, IP header, UDP header and UDP payload. +It is a user responsibility to make IP fragmentaion when required payload +is larger than MTU. Every fragment is a separate L2 frame to transmit. +The ibv_poll_cq() provides an information about the status of transmit buffer. + +On receive path when ibv_poll_cq() provides an information +about received L2 packet, the Rx buffer (previously posted by ibv_post_recv() + contains a whole L2 frame including MAC header, IP header and UDP header. +It is a user application responsibility to check if received packet is +a valid UDP frame so the fragments must be checked and +checksums must be computed. + +IMA API description (NE020 specific) : +User application must create separate CQs for RX and TX path. +Only single sge on tranmit is supported. +User application must post at least 65 rx buffers to keep RX path working. + +IMA device: +IMA requires creation of the /dev/infiniband/nes_ud_sksq device to get + access to optimized IMA transmit path. The best method for creation +of that device is manual addition following line to +/etc/udev/rules.d/90-ib.rules file +after OFED distribution installation and rebooting machine. + +KERNEL==nes_ud_sksq, NAME=infiniband/%k, MODE=0644 + +As a result the 90-ib.rules should look like: + +KERNEL==umad*, NAME=infiniband/%k +KERNEL==issm*, NAME=infiniband/%k +KERNEL==ucm*, NAME=infiniband/%k, MODE=0666 +KERNEL==uverbs*, NAME=infiniband/%k, MODE=0666 +KERNEL==ucma, NAME=infiniband/%k, MODE=0666 +KERNEL==rdma_cm, NAME=infiniband/%k, MODE=0666 +KERNEL==nes_ud_sksq, NAME=infiniband/%k, MODE=0644 + +Keep in mind that setting an other that 644 mode of nes_ud_sksq device +can cause serious serious security issues, so it is not recommended to +change this mode for applications. NetEffect is a trademark of Intel Corporation in the U.S. and other countries. ___ 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 06/16/2010 02:35 PM, Steve Wise wrote: 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... Yep, no doubt that has an impact on things. It's for this very reason that our next operating system is not following OFED but instead is using upstream as its basis. That will be true from now on with our products. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature ___ 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 06/16/2010 01:12 PM, Steve Wise wrote: 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 ^ Which, of course, is the problem. Once you have a solution besides get it upstream, you throw whatever you feel like into OFED instead of whatever upstream will accept. How long has OFED shipped the XRC stuff now while it *still* isn't upstream? because I couldn't get any help with trying to add this upstream in any form. Again, OFED is part of the reason this failed. That users had someplace else to get working code besides upstream meant that you didn't have end users putting pressure on the upstream kernel folks to accept *some* form of solution. So, your job was harder because there were no users present to put pressure on mister miller or others, and then you perpetuated the issue by caving and going back to OFED as a last resort. It has become a last resort so often now that trying to get things upstream first is just a sort of private joke amongst some people I think. 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. steps off soap box OFED just needs to go away. It's been far too abused for far too long and it's mere existence is hindering upstream development. I appreciate that you attempt to do the right thing most of the time, but it really needs to be all of the time, and you need your users right there beside you in order to carry the weight you need in order to get solutions designed and accepted instead of running into the brick wall you ran into before. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED 1.5.2-rc2 is delayed
Hi all Due to all comments about raw QP and since we have not yet integrated the new IB-ACM library we delay 1.5.2-rc2 for next week Tziporet Vlad ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Testing today's build
Hi. I installed it on my Dell Cluster:
SLES 11 SP1/ConnectX
RHEL 5.3/Infinihost III
CentOS 5.4/Infinihost III
Installation went smoothly on all three platforms, and I was able to
bring up IPOIB on all three and do pings. Also, I tried rdma_{lat,bw} on
random pairs of nodes and these completed.In particular SLES 11 SP1
seems to work. Thanks.
-jeff
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
