Re: [ewg] [ANNOUNCE] opensm 3.3.17 release
On Thu, Jan 30, 2014 , Hal Rosenstock h...@dev.mellanox.co.il wrote: There is a new 3.3.17 release of OpenSM. Tarball is available in: http://www.openfabrics.org/downloads/management/ (listed in http://www.openfabrics.org/downloads/management/latest.txt) md5sum: 9c1b85e47ab495110c1944e0f4d634b7 opensm-3.3.17.tar.gz All component versions are from recent master branch. what components are you referring to? Full list of changes is below. [...] ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Next OFA EWG meeting will be on Monday January 6th at 9:00 AM Pacific
On 30/12/2013 21:54, Rupert Dance wrote: Hi All, The next OFA EWG meeting will be on Monday January 6^th at 9:00 AM Pacific [...] Hi Rupert, Are you posting minutes for those meetings? where? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Next OFA EWG meeting will be on Monday January 6th at 9:00 AM Pacific
On 21/01/2014 09:10, Or Gerlitz wrote: On 30/12/2013 21:54, Rupert Dance wrote: Hi All, The next OFA EWG meeting will be on Monday January 6^th at 9:00 AM Pacific [...] Hi Rupert, Are you posting minutes for those meetings? where? Oh, I see that each meeting invite included the minutes of the previous one... sorry for the bother spam ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] initial LIO iSER performance numbers [was: GIT PULL] target updates for v3.10-rc1)
On Thu, May 2, 2013 at 10:31 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: We used RAMDISK_MCP backend which was patched to act as NULL device, so we can test the raw iSER wire performance. Btw, I'll be including a similar patch to allow for RAMDISK_NULL to be configured as a NULL device mode. yep, that would be very helpful, so people can do that sort of testing without hacks... Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] initial LIO iSER performance numbers [was: GIT PULL] target updates for v3.10-rc1)
On 30/04/2013 05:59, Nicholas A. Bellinger wrote: Hello Linus! Here are the target pending changes for the v3.10-rc1 merge window. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next-merge The highlights this round include: - Add fileio support for WRITE_SAME w/ UNMAP=1 discard (asias) - Add fileio support for UNMAP discard (asias) - Add tcm_vhost hotplug support to work with upstream QEMU vhost-scsi-pci code (asias + mst) - Check for aborted sequence in tcm_fc response path (mdr) - Add initial iscsit_transport support into iscsi-target code (nab) - Refactor iscsi-target RX PDU logic + export request PDU handling (nab) - Refactor iscsi-target TX queue logic + export response PDU creation (nab) - Add new iSCSI Extentions for RDMA (ISER) target driver (Or + nab) The biggest changes revolve around iscsi-target refactoring in order to support the iser-target driver. This includes the conversion of the iscsi-target data-path to use modern se_cmd-cmd_kref counting, and allowing transport independent aspects of RX/TX PDU request/response handling be shared across existing traditional iscsi-target code, and the new iser-target code. Hi Nic, everyone, So LIO iser target code is now merged into Linus tree, and will be in kernel 3.10, exciting! Here's some data on raw performance numbers we were able to get with the LIO iser code. For single initiator and single lun, block sizes varying over the range 1KB,2KB... 128KB doing random read: 1KB 227,870K 2KB 458,099K 4KB 909,761K 8KB 1,679,922K 16KB 3,233,753K 32KB 4,905,139K 64KB 5,294,873K 128KB 5,565,235K When enlarging the number of luns and still with single initiator, for 1KB randomreads we get: 1 LUN = 230k IOPS 2 LUNs = 420k IOPS 4 LUNs = 740k IOPS When enlarging the number of initiators, and each having four lunswe get for 1KB random reads: 1 initiator x 4 LUNs = 740k IOPS 2 initiators x 4 LUNs = 1480k IOPS 3 initiators x 4 LUNs = 1570k IOPS So all in all, things scale pretty nicely, and we observe a some bottleneck in the IOPS rate around 1.6 Million IOPS, so there's where to improve... Here's the fio command line used by the initiators $ fio --cpumask=0xfc --rw=randread --bs=1k --numjobs=2 --iodepth=128 --runtime=62 --time_based --size=1073741824k --loops=1 --ioengine=libaio --direct=1 --invalidate=1 --fsync_on_close=1 --randrepeat=1 --norandommap --group_reporting --exitall --name dev-sdb-randread-1k-2thr-libaio-128iodepth-62sec --filename=/dev/sdb And some details on the setup: The nodes are HP ProLiant DL380p Gen8 with the following CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz two NUMA nodes with eight cores each, 32GB RAM, PCI express gen3 8x, the HCA being Mellanox ConnectX3 with firmware 2.11.500 The target node was running upstream kernel and the initiators RHEL 6.3 kernel, all X86_64 We used RAMDISK_MCP backend which was patched to act as NULL device, so we can test the raw iSER wire performance. Or. Thanks to Or Gerlitz + Mellanox for supporting the iser-target development effort! Thank you, --nab Andy Grover (2): target/iscsi: Remove chap_set_random() target/iscsi: Use ISCSI_LOGIN_CURRENT/NEXT_STAGE macros Asias He (10): target/file: Add WRITE_SAME w/ UNMAP=1 emulation support target/file: Add UNMAP emulation support target/file: Add fd_do_unmap() helper target/iblock: Add iblock_do_unmap() helper target: Add sbc_execute_unmap() helper target/file: Set is_nonrot attribute tcm_vhost: Refactor the lock nesting rule tcm_vhost: Add hotplug/hotunplug support tcm_vhost: Add ioctl to get and set events missed flag tcm_vhost: Enable VIRTIO_SCSI_F_HOTPLUG Jörn Engel (2): qla2xxx: Remove unused function target: Change default sense key of NOT_READY Mark Rustad (1): tcm_fc: Check for aborted sequence Nicholas Bellinger (9): target: Add export of target_get_sess_cmd symbol iscsi-target: Add iscsit_transport API template iscsi-target: Initial traditional TCP conversion to iscsit_transport iscsi-target: Add iser-target parameter keys + setup during login iscsi-target: Add per transport iscsi_cmd alloc/free iscsi-target: Refactor RX PDU logic + export request PDU handling iscsi-target: Refactor TX queue logic + export response PDU creation iscsi-target: Add iser network portal attribute iser-target: Add iSCSI Extensions for RDMA (iSER) target driver Wei Yongjun (1): tcm_fc: using kfree_rcu() to simplify the code drivers/infiniband/Kconfig |1 + drivers/infiniband/Makefile|1 + drivers/infiniband/ulp/isert/Kconfig |5 + drivers/infiniband/ulp/isert/Makefile |2 + drivers/infiniband/ulp/isert/ib_isert.c| 2281 drivers/infiniband/ulp/isert/ib_isert.h| 138 ++ drivers/infiniband/ulp/isert/isert_proto.h | 47 + drivers
[ewg] Fwd: [RFC 00/11] Add support for iSCSI Extentions for RDMA (ISER) target
FYI - for those of you who aren't subscribed to linux-rdma, an RFC was posted for a patch series adding support for iSCSI Extentions for RDMA (ISER) to the in kernel SCSI target -- Forwarded message -- From: Nicholas A. Bellinger n...@linux-iscsi.org Date: Fri, Mar 8, 2013 at 3:45 AM Subject: [RFC 00/11] Add support for iSCSI Extentions for RDMA (ISER) target To: target-devel target-de...@vger.kernel.org Cc: linux-rdma linux-r...@vger.kernel.org, linux-scsi linux-s...@vger.kernel.org, Roland Dreier rol...@kernel.org, Or Gerlitz ogerl...@mellanox.com, Alexander Nezhinsky alexand...@mellanox.com, Nicholas Bellinger n...@linux-iscsi.org From: Nicholas Bellinger n...@linux-iscsi.org Hi Folks, This series is first RFC for iSCSI Extentions for RDMA (ISER) target support with existing iscsi-target TCP based socket code for a future v3.10 merge. This code is available in git here: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git iser_target-rfcv1 Ths includes a basic iscsit_transport API that allows different transports to reside under a single iscsi-target configfs control plane, using an pre-defined network portal attribute to enable a rdma_cm listener on top of existing ipoib portals. The review patches are broken down into: Patch #1 - #3 include iscsi-target API template, conversion of iscsi/tcp login path to use API template, plus add iser RFC parameter keys. Patch #4 - #5 allow external iscsi_cmd descriptor allocation / free, and refactoring of RX side PDU request handling to allow incoming PDU logic to be called by external ib_isert workqueue process context. Patch #6 allows iscsi-target to use per transport API template immediate / response callbacks in the per-connection TX thread completion path, and refactoring of response PDU creation for export to external ib_isert code. Patch #7 adds the pre-defined iser network portal attribute under the existing iscsi-target configfs tree. Patch #8 - #11 is the external ib_isert.ko module code seperated into individual commits for review. So at this point this code is functional and pushing sustained RDMA_WRITE + RDMA_READ traffic using open-iscsi on top of v3.8-rc7 code. Thus far we're using Mellanox IB HCAs for initial development, and will be verfiying using RCoE capable NICs as well in the near future. Note there are still plently of performance tuning, active I/O shutdown testing, and various exception path hardening left to be done over the upcoming weeks. The branch at target-pending.git/iser_target-wip will be updated as review comments + regressions + new bugs are addressed. Many thanks to Or Gerlitz and Mellanox for their support. Thank you, --nab Nicholas Bellinger (11): iscsi-target: Add iscsit_transport API template iscsi-target: Initial traditional TCP conversion to iscsit_transport iscsi-target: Add iser-target parameter keys + setup during login iscsi-target: Add per transport iscsi_cmd alloc/free iscsi-target: Refactor RX PDU logic + export request PDU handling iscsi-target: Refactor TX queue logic + export response PDU creation iscsi-target: Add iser network portal attribute iser-target: Add base + proto includes iser-target: Add logic for verbs iser-target: Add logic for core iser-target: Add Makefile + Kconfig drivers/infiniband/Kconfig |1 + drivers/infiniband/Makefile|1 + drivers/infiniband/ulp/isert/Kconfig |6 + drivers/infiniband/ulp/isert/Makefile |5 + drivers/infiniband/ulp/isert/isert_base.h | 123 ++ drivers/infiniband/ulp/isert/isert_core.c | 1720 drivers/infiniband/ulp/isert/isert_core.h | 12 + drivers/infiniband/ulp/isert/isert_proto.h | 47 + drivers/infiniband/ulp/isert/isert_verbs.c | 476 +++ drivers/infiniband/ulp/isert/isert_verbs.h |5 + drivers/target/iscsi/Makefile |3 +- drivers/target/iscsi/iscsi_target.c| 1119 +--- drivers/target/iscsi/iscsi_target.h|1 + drivers/target/iscsi/iscsi_target_configfs.c | 75 + drivers/target/iscsi/iscsi_target_core.h | 25 +- drivers/target/iscsi/iscsi_target_device.c |1 + drivers/target/iscsi/iscsi_target_erl1.c |8 +- drivers/target/iscsi/iscsi_target_login.c | 466 +-- drivers/target/iscsi/iscsi_target_login.h |6 + drivers/target/iscsi/iscsi_target_nego.c | 185 +--- drivers/target/iscsi/iscsi_target_nego.h | 11 +- drivers/target/iscsi/iscsi_target_parameters.c | 87 ++- drivers/target/iscsi/iscsi_target_parameters.h | 16 +- drivers/target/iscsi/iscsi_target_tmr.c|1 + drivers/target/iscsi/iscsi_target_tpg.c|6 +- drivers/target/iscsi/iscsi_target_transport.c | 57 + drivers/target/iscsi/iscsi_target_util.c | 62 +- drivers/target/iscsi/iscsi_target_util.h |2 + include/target/iscsi
Re: [ewg] strange value of IB port rate
On 20/02/2013 13:54, Hal Rosenstock wrote: In the case of DOWN ports, rate is meaningless and should be ignored. should be fixed by 0559d8dc13a1cd68b5e64c0b61659f36c7b5c89f IB/core: Don't return EINVAL from sysfs rate attribute for invalid speeds ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] RDMA/nes: Fix for TSO low nic throughput - linux-next-pending
On 08/09/2012 03:37, Tatyana Nikolova wrote:
Fix for TSO low nic throughput with linux-3.5
skb_is_gso() is changed to bool and returns 1 instead of MSS.
The gso_size from skb_shared_info is now used to pass MSS to hardware.
here's the form of this function from net-next
static inline bool skb_is_gso(const struct sk_buff *skb)
{
return skb_shinfo(skb)-gso_size;
}
its bool indeed, but does return gso_size
(the patch is linux-next-pending)
I don't see it in net-next, through which exact tree are you merging it?
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] pointers to last OFA conference presentations
On Thu, May 17, 2012 at 12:59 AM, Ken Strandberg k...@openfabrics.orgwrote: We discontinued registration requirement weeks ago. To see all downloadable content, pull down the OFA/OFED RESOURCES menu, pick OFA Doc Downloads and pick Presentations or Videos and navigate to the desire area. For the last conference content, there's a link from the home page in the left column, which will take you to a table (the agenda) where you can download or view videos. what a news! spreading the word right a way. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] pointers to last OFA conference presentations
Hi, Is there a way to provide references to the sessions which doesn't require registration? I tried and didn't find out. This is needed now, when we send to the upstream Linux maintainers the patches which implement things like user space Ethernet stack - flow steering, RSS/TSS, Ethernet IPoIB driver etc etc there's no way I can ask a maintainer to subscribe to this or that site, just for the sake of being able to obtain a presentation which elaborates on code we submit. All the kernel mailing lists are open for all, and one need not be subscribed in order to send patches or question. Following the we are the 99% / occupy wall street spirit, I would suggest to have the presentations and actually the whole of the OFA site FREE for all, comments welcome, could you maybe raise that to the group that runs OFA? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Web site update
On 3/28/2011 11:29 PM, Ken Strandberg wrote: Or, Nothing is lost. I can bring this content over. It will take me several days; it's hours of work to bring it under the new site. As to policies, you might want to also bring Scot Schultz and Jim Ryan into the conversation. So few days have passed.. and it seems that all documents from past Sonoma OFA conferences are very much lost e.g here https://openfabrics.org/ofa-documents/presentations/cat_view/57-ofa-documents/23-presentations/40-workshops.html you can see no sign for pre-2010 Sonoma. For OFA 2011 there are docs but I can't think on less friendly manner to build the page and for 2010 the docs are empty. What was wrong in the older web site that the OFA member companies had to pay money and make this site such non usable? why the site isn't open for everyone? and even after registration / login you can't find there any docs? how can new comers to the rdma industry catch up without all the good old materials / presentations from 2005/6/7/8/9/10 . I have bunch of people asking me questions in various rdma/IB related issues and I can't point them anywhere. Or. -Original Message- From: Or Gerlitz [mailto:ogerl...@mellanox.com] Sent: Monday, March 28, 2011 1:14 PM To: Ken Strandberg Cc: Bill Boas; ewg Subject: RE: [ewg] Web site update Hi Ken, 1st, and most - there were tons (and I mean that) of precious materials on the older site from the 2008 and 2009 OFA Sonoma conferences, we must find them and make them available onsite, were they all lost? 2nd, as for this directive of being unable to read materials unless you're a member, I'm copying Bill Boas, maybe he can explain the rational - Bill, if the subscription idea is to get people who are interested to receive the newsletter to sign for it through their subscription, why make visibility for the rest of the content be dependent on that subscription as well? Or. From: Ken Strandberg [k...@kenstrandberg.com] Sent: 28 March 2011 19:30 To: Or Gerlitz Subject: RE: [ewg] Web site update Hi Or, The only past content we have is from SC10 and the 2010 Sonoma conference. There are links to this content from the page you reference, though with our current style sheet the links are NOT very clear. We are working on changing the style sheet to make these look more obvious. If you use this page, look for where it says to download ...'here.' And click on here. If you've done that, you should be taken to a page with the names of downloadable files. Then you just click on the Download button for the file you want. Another way to get these files is under the OFED/OFA Resources menu OFA Doc Downloads Videos or Presentations. If you aren't seeing the pages with Download buttons, please let me know. You have access rights to all this content. And please let me know what browser you're using if you can't get to these pages. I need to make sure they are available to the appropriate users. Regarding access rights, I'm just implementing what I've been directed by the organization's management. You should contact one of the Exec team if you have concerns regarding our policies. But, ANYTHING regarding the web site should be directed to me. Please let me know whether or not this helps. Either way. Thanks. Ken Strandberg webmana...@openfabrics.org k...@catlowcommunications.com -Original Message- From: Or Gerlitz [mailto:ogerl...@mellanox.com] Sent: Monday, March 28, 2011 9:32 AM To: Ken Strandberg Cc: ewg@lists.openfabrics.org; x...@openfabrics.org; m...@openfabrics.org Subject: Re: [ewg] Web site update On 3/28/2011 6:27 PM, Or Gerlitz wrote: I was trying to provide pointer for partners on past conferences presentations and can't do that the page says To download content from this event, you must login first, why we require that if the purpose of registration is requested so that your name is included in Newsletter ?! Also after doing registration/login I can't get any content from previous conferences @ http://www.openfabrics.org/jofa/index.php?option=com_contentview=articleid =30Itemid=16 any idea if this is broken or I'm doing something which is wrong? Or. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1498/3535 - Release Date: 03/28/11 - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1498/3535 - Release Date: 03/28/11 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Multiple IP subnets in a single partition
On 10/12/2011 3:28 PM, richard Croucher wrote: I understand that's it not good practice however I'm seeking to understand whether actual problems have been observed. The only issues I can suggest will be because of ARP is in the shared broadcast domain.Is there any IPoIB state in the SM other than QoS? I can't think of any reason why there should be. Even though ARP requests will be seen by interfaces in a different subnet, they should not respond with it's GUID since they will not match the requested IP address. wrong, see http://lxr.linux.no/#linux+v3.0/Documentation/networking/ip-sysctl.txt#L926 I think this refers back to behaviour seen many years ago, when multihomed hosts were rare. There was a tendency for them to respond on all interfaces to ARP requests for their nodename and cause ARP resolution problems.. Is there a reproducable test case of this problem, since I certainly know of systems which are configured like this and appear to be working fine. Maybe, they've just been lucky, but so far I've seen numerous messages saying don't do it and none to say what actually goes wrong. For basic testing and/or PoC you can set net.ipv4.conf.*.arp_ignore to 1 or alike (2). For production, I wouldn't do that or at least do it after conducting a deeper study (I gave you the heads-up, so please share your findings...), Indeed, I know that in the iscsi multipathing world people use multi-homed NICs on the same IP subne, though. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Web site update
Or Gerlitz wrote: Yes. I'll pull content over. But it'll take some time. For the mean time, can you send the direct link into the old website, I need some materials from Sonoma 2008, 2009 and want to get there, thanks Hi, I just noted that in the new website you've killed the link to the general list, the list is inactive but its archives are of use for developers, just add a pointer to http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general Also what about the content from Prev OFA (2009 2008 2007 2006) conferences you've promised to deliver into the new web? Looking there I only see the 2010 and 2011 materials. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] 1.6 pull request: IB/qib: Prevent driver hang with unprogrammed boards
On 4/12/2011 3:45 PM, Mike Marciniszyn wrote: No rush. We had the patch, tested it, applied it internally, and shared it. Roland's comment came in after my emails to Vlad. The point I was trying to make is why not waiting for review/acceptance for upstream before pushing it further into a stack which is going to be released way after this review is conducted? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] 1.6 pull request: IB/qib: Prevent driver hang with unprogrammed boards
Mike Marciniszyn wrote: Vlad, Please pull the following patch from ~mmarciniszyn/scm/ofed_1_6/linux-2.6. Guys, why rushing here? any reason not to wait a minute to see if/what form of the patch is accepted upstream? Or. commit 7fdf362a2fa75cfd46c88ccc8f13a8d72adedb5f Author: Mitko Haralanov mi...@qlogic.com Date: Mon Apr 11 09:57:28 2011 -0400 IB/qib: Prevent driver hang with unprogrammed boards ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Web site update
Ken Strandberg wrote: Or, Nothing is lost. I can bring this content over. It will take me several days; it's hours of work to bring it under the new site. Ken, thanks for the update, can this be done so we have back all the past years presentations? As to policies, you might want to also bring Scot Schultz and Jim Ryan into the conversation. I've added Jim, I don't have Scot email's Or. -Original Message- From: Or Gerlitz [mailto:ogerl...@mellanox.com] Sent: Monday, March 28, 2011 1:14 PM To: Ken Strandberg Cc: Bill Boas; ewg Subject: RE: [ewg] Web site update Hi Ken, 1st, and most - there were tons (and I mean that) of precious materials on the older site from the 2008 and 2009 OFA Sonoma conferences, we must find them and make them available onsite, were they all lost? 2nd, as for this directive of being unable to read materials unless you're a member, I'm copying Bill Boas, maybe he can explain the rational - Bill, if the subscription idea is to get people who are interested to receive the newsletter to sign for it through their subscription, why make visibility for the rest of the content be dependent on that subscription as well? Or. From: Ken Strandberg [k...@kenstrandberg.com] Sent: 28 March 2011 19:30 To: Or Gerlitz Subject: RE: [ewg] Web site update Hi Or, The only past content we have is from SC10 and the 2010 Sonoma conference. There are links to this content from the page you reference, though with our current style sheet the links are NOT very clear. We are working on changing the style sheet to make these look more obvious. If you use this page, look for where it says to download ...'here.' And click on here. If you've done that, you should be taken to a page with the names of downloadable files. Then you just click on the Download button for the file you want. Another way to get these files is under the OFED/OFA Resources menu OFA Doc Downloads Videos or Presentations. If you aren't seeing the pages with Download buttons, please let me know. You have access rights to all this content. And please let me know what browser you're using if you can't get to these pages. I need to make sure they are available to the appropriate users. Regarding access rights, I'm just implementing what I've been directed by the organization's management. You should contact one of the Exec team if you have concerns regarding our policies. But, ANYTHING regarding the web site should be directed to me. Please let me know whether or not this helps. Either way. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Web site update
Jim, Scot - can you comment on why registration is needed to be exposed to ofa past conferences content? also, Ken - I just realized that the new site also lost the downloads page (here's the old link http://www.openfabrics.org/downloads/) to where among other use cases ) component developers (e.g librdmac, opensm, mad librararies, etc) post tar file based releases to be picked by ofed and distros - maybe you want to spend more time on debugging that move? Or. On Tue, Mar 29, 2011 at 4:16 PM, Ryan, Jim jim.r...@intel.com wrote: Adding Scot who has been incredibly helpful on web issues in the past Jim -Original Message- From: Or Gerlitz [mailto:ogerl...@mellanox.com] Sent: Tuesday, March 29, 2011 12:50 AM To: Ken Strandberg Cc: 'Cheri Winterberg'; 'Bill Boas'; ewg@lists.openfabrics.org; Ryan, Jim Subject: Re: [ewg] Web site update Ken Strandberg wrote: Or, Nothing is lost. I can bring this content over. It will take me several days; it's hours of work to bring it under the new site. Ken, thanks for the update, can this be done so we have back all the past years presentations? As to policies, you might want to also bring Scot Schultz and Jim Ryan into the conversation. I've added Jim, I don't have Scot email's Or. -Original Message- From: Or Gerlitz [mailto:ogerl...@mellanox.com] Sent: Monday, March 28, 2011 1:14 PM To: Ken Strandberg Cc: Bill Boas; ewg Subject: RE: [ewg] Web site update Hi Ken, 1st, and most - there were tons (and I mean that) of precious materials on the older site from the 2008 and 2009 OFA Sonoma conferences, we must find them and make them available onsite, were they all lost? 2nd, as for this directive of being unable to read materials unless you're a member, I'm copying Bill Boas, maybe he can explain the rational - Bill, if the subscription idea is to get people who are interested to receive the newsletter to sign for it through their subscription, why make visibility for the rest of the content be dependent on that subscription as well? Or. From: Ken Strandberg [k...@kenstrandberg.com] Sent: 28 March 2011 19:30 To: Or Gerlitz Subject: RE: [ewg] Web site update Hi Or, The only past content we have is from SC10 and the 2010 Sonoma conference. There are links to this content from the page you reference, though with our current style sheet the links are NOT very clear. We are working on changing the style sheet to make these look more obvious. If you use this page, look for where it says to download ...'here.' And click on here. If you've done that, you should be taken to a page with the names of downloadable files. Then you just click on the Download button for the file you want. Another way to get these files is under the OFED/OFA Resources menu OFA Doc Downloads Videos or Presentations. If you aren't seeing the pages with Download buttons, please let me know. You have access rights to all this content. And please let me know what browser you're using if you can't get to these pages. I need to make sure they are available to the appropriate users. Regarding access rights, I'm just implementing what I've been directed by the organization's management. You should contact one of the Exec team if you have concerns regarding our policies. But, ANYTHING regarding the web site should be directed to me. Please let me know whether or not this helps. Either way. ___ 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] Web site update
Yes. I'll pull content over. But it'll take some time. For the mean time, can you send the direct link into the old website, I need some materials from Sonoma 2008, 2009 and want to get there, thanks Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] bonding doc: fixed spelling mistakes
fixed spelling mistakes Signed-off-by: Or Gerlitz ogerl...@mellanox.com diff --git a/readme_and_howto/ib-bonding.txt b/readme_and_howto/ib-bonding.txt index 1727d6b..f3d043d 100644 --- a/readme_and_howto/ib-bonding.txt +++ b/readme_and_howto/ib-bonding.txt @@ -33,7 +33,7 @@ Update 6 or Update 7) and for Redhat-EL5 and above. TYPE=Bonding MTU=according to the slave's MTU -Exmaple: for bond0 (master) the file is named /etc/sysconfig/network-scripts/ifcfg-bond0 +Example: for bond0 (master) the file is named /etc/sysconfig/network-scripts/ifcfg-bond0 with the following text in the file: DEVICE=bond0 @@ -49,7 +49,7 @@ MTU=65520 Note: 65520 is a valid mtu value only if all IPoIB slaves operate in connected mode and are configured with the same value. For IPoIB slaves that work in -datagram modee, use MTU=2044. If you don't set correct mtu or don't set mtu at +datagram mode, use MTU=2044. If you don't set correct mtu or don't set mtu at all (and letting it to be set to the default value), performance of the interface might decrease. @@ -116,7 +116,7 @@ BONDING_SLAVE0=slave0 BONDING_SLAVE1=slave1 MTU=according to the slave's MTU -Exmaple: for bond0 (master) the file is named /etc/sysconfig/network/ifcfg-bond0 +Example: for bond0 (master) the file is named /etc/sysconfig/network/ifcfg-bond0 with the following text in the file: BOOTPROTO=static @@ -134,7 +134,7 @@ MTU=65520 Note: 65520 is a valid mtu value only if all IPoIB slaves operate in connected mode and are configured with the same value. For IPoIB slaves that work in -datagram modee, use MTU=2044. If you don't set correct mtu or don't set mtu at +datagram mode, use MTU=2044. If you don't set correct mtu or don't set mtu at all (and letting it to be set to the default value), performance of the interface might decrease. @@ -153,11 +153,11 @@ After the configuration is saved, restart the network service by running: 2.3 Configuring Ethernet slaves --- -It is not possible to have a mix of Ethernt slaves and IPoIB slaves under the +It is not possible to have a mix of Ethernet slaves and IPoIB slaves under the same bonding master. It is possible however that a bonding master of Ethernet -slaves and a bonding master of IPoIB slaves will co-exist in one machne. +slaves and a bonding master of IPoIB slaves will co-exist in one machine. To configure Ethernet slaves under a bonding master use the following -instructios (depending on the OS) +instructions (depending on the OS) * Under Redhat-AS4 @@ -178,7 +178,7 @@ No special instructions are required. * Under SLES10 -When using both type of bonding under, it is neccessary to update the +When using both type of bonding under, it is necessary to update the MANDATORY_DEVICES environment variable in /etc/sysconfig/network/config with the names of the InfiniBand devices ( ib0, ib1, etc. ). Otherwise, bonding devices will be created before InfiniBand devices at boot time. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] libibverbs: Add new enums
Aleksey Senin wrote: IBV_SEND_IP_CSUM added to ibv_send_flags. Should be used to control calculation checksum at hardware layer. what checksum - IB? IP? UDP? TCP? how the caller is supposed to know if they can set this flag? IBV_WC_WITH_VLAN added to ibv_wc_flags, Should be used to add VLAN support to WC flags So who is setting this flag (none of the patches does that) and where is the vlan located on the wc structure? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] ofa_1_5_kernel 20101128-0200 daily build status
Richard Croucher richard.crouc...@informatix-sol.com wrote: I've just installed OFED 1.5.2 using your install.pl on two brand new servers I'm building. Certainly a lot better experience than the last time I did this with the standard OFED release a few years ago. These were two new freshly build servers with OpenSuSe11.2 with a 2.6.31 kernel ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] ofa_1_5_kernel 20101128-0200 daily build status
Richard Croucher richard.crouc...@informatix-sol.com wrote: I've just installed OFED 1.5.2 using your install.pl on two brand new servers I'm building. Certainly a lot better experience than the last time I did this with the standard OFED release a few years ago. These were two new freshly build servers with OpenSuSe11.2 with a 2.6.31 kernel So what makes you use ofed at all? anything wrong with the IB bits provided by your distro? I'm not sure if/how this works exactly with Yast, but on RHEL et al, installing the IB stack is done with one yum command of yum groupinstall Openfabrics Enterprise Distribution, so you're all set within 1-2 minutes, including setting the IPoIB network scripts and opensm. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] EWG/OFED meeting agenda for today - Nov 8
Tziporet Koren wrote: OFED 1.5.3: - Mellanox going to update mlx4 driver for the 1.5.3 Hi Tziporet, What features are you thinking to add in this update? thanks, Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [Fwd: Re: mlx4_en delta from upstream (was mlx4_en: ping does not resume after failover)]
Yevgeny, I'm forwarding to ewg as it seems your post didn't get there Or. ---BeginMessage--- Or Gerlitz wrote: Yevgeny Petrilin wrote: Sure, I am preparing the patches Hi Yevgeny, I didn't see any posting of patch/es to netdev and there's nothing new in Linus tree from you since May13, the day you made this comment. Are you expecting to push the bonding related fix for 2.6.36? Hi, Sorry I didn't answer earlier, was out for a couple of weeks. I am submitting this. The reason it was delayed, is that Aleksey checked the fix and claimed there is still a bug, Then rechecked and said it was OK. Yevgeny---End Message--- ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] mlx4_en delta from upstream (was mlx4_en: ping does not resume after failover)
Or Gerlitz wrote: Yevgeny Petrilin wrote: Sure, I am preparing the patches Hi Yevgeny, I didn't see any posting of patch/es to netdev and there's nothing new in Linus tree from you since May13, the day you made this comment. Are you expecting to push the bonding related fix for 2.6.36? Is there anything else in that or close importance level mlx4_en wise which is in ofed and from some reason wasn't push upstream? e.g I see a patch subject (0119) saying Fix a crash with prioritiesed vlan packets this sounds bad... [...] hit this or other problems fixed by patches from the below list if upstream is used? Can you comment here? I see now that more mlx4_en patches were added to ofed since last month, so the delta with upstream becomes bigger every week or so. Also, can you spare few seconds/minutes to have your patches contain change-log? some of the mlx4_en ones don't have that, which makes it much harder to understand what they are all about. Or. mlx4_en_0010_remove_redundant_variable.patch mlx4_en_0020_fix_partial_rings.patch mlx4_en_0030_rx_flow_changes.patch mlx4_en_0040_interface_name_in_messages.patch mlx4_en_0050_renaming_en_params_to_en_ethtool.patch mlx4_en_0060_multiqueue_support.patch mlx4_en_0080_driver_version.patch mlx4_en_0090_linear_rx_dropped_counter.patch mlx4_en_0100_dropped_tx_packets.patch mlx4_en_0101_tx_optimizations.patch mlx4_en_0102_remove_ring_refill.patch mlx4_en_0104_not_using_srqs.patch mlx4_en_0105_dma_mapping_fixes.patch mlx4_en_0106_setting_dev_for_inline_rx.patch mlx4_en_0107_add_vlan_features.patch mlx4_en_0108_set_actual_ring_size.patch mlx4_en_0109_set_correct_size_mask.patch mlx4_en_0110_selftest.patch mlx4_en_0111_perm_addr_field.patch mlx4_en_0112_CLOSE_PORT_at_end_of_teardown.patch mlx4_en_0113_Setting-the-correct-value-to-MAX_TX_RINGS.patch mlx4_en_0114_latency_mod_for_small_packets.patch mlx4_en_0115_less_resources.patch mlx4_en_0116_link_state_report.patch mlx4_en_0117_port_up_in_transmit.patch mlx4_en_0119_tagged_packets_crash_fix.patch mlx4_en_0120_device_ids_table.patch mlx4_en_0130_Allow-interfaces-to-correspond-to-each-other.patch mlx4_en_0140_extend-cap-flags-to-64-bit.patch mlx4_en_0150_offloads_for_vlan_interfaces.patch mlx4_en_0160_UDP_rss.patch mlx4_en_0170__ip_summed_NONE_fix.patch mlx4_en_0180_reporting_transceiver_type.patch mlx4_en_0190_get_set_ringsize_use_actual_size.patch mlx4_en_0200_mlx4_en_destroy_allocator_only_when_using_frags.patch mlx4_en_0210_multicast_promisc_cap.patch mlx4_en_0220_reconfigure_mac_address.patch ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] install/uninstall kernel-ib in non-disruptive manner
Hi Vlad, I noted that after uninstalling kernel-ib, the EL5 service script provided by the distro openib package is gone. Can this be fixed, such that one can install/uninstall kernel-ib in non-disruptive manner? Or. # rpm -ql openib-1.4.1-3.el5 /etc/ofed /etc/ofed/fixup-mtrr.awk /etc/ofed/openib.conf /etc/rc.d/init.d/openibd /etc/sysconfig/network-scripts/ifup-ib /etc/udev/rules.d/90-ib.rules # rpm -ql kernel-ib | grep -v updates /etc/infiniband /etc/infiniband/connectx.conf /etc/infiniband/info /etc/infiniband/openib.conf /etc/init.d/openibd /etc/modprobe.d/ib_ipoib.conf /etc/modprobe.d/mlx4_en.conf /etc/udev/rules.d/90-ib.rules /sbin/connectx_port_config /sbin/ib_ipoib_sysctl /sbin/mlx4_en_sysctl /usr/bin/ibdev2netdev ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [ANNOUNCE] OFED 1.5.2 rc1 is available
Or Gerlitz wrote: I don't see any mentioning of IBoE open issues, e.g depicted in ofa bz cases such as: bz 2005 Rocce fails when 1 port is IB and the other is Ethernet bz 2024 clients fail when global pauses or PPP enabled on switch bz 2043 OFED 1.5.1 crashes after running Mcast over RoCE Hi Tziporet, I didn't see any response from you, can this be addressed? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v3] IB Core: RAW ETH support
Alekseys Senin wrote:
+ Add new RAW_ETY QP type in order to build RAW Ethernet packets over iWARP
and RoCEE.
+--- a/include/rdma/ib_verbs.h
b/include/rdma/ib_verbs.h
+@@ -571,6 +571,7 @@ enum ib_qp_type {
+ IB_QPT_UD,
+ IB_QPT_XRC,
+ IB_QPT_RAW_IPV6,
++IB_QPT_RAW_ETH,
+ IB_QPT_RAW_ETY
I got confused here, the change log say you add RAW_ETY wheres the patch adds
RAW_ETH, which is correct? can you please fix that.
Or.
___
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
Alekseys Senin wrote: This patch adds support to RAW ETH QP in ib core. are these patches applicable to the mainstream kernel code or would only apply/function over ofed? Or. ___ 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: The patches can't be applies to upstream kernel. An attempt to do this failed. I guess that some of RoCEE patches are still missing in kernel upstream. Eli, can you elaborate on that? is there any real dependence between the RoCE patches to the raw qp ones? what is this dependence in high level, is it placement of change sets in the code or actual flows? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [ANNOUNCE] OFED 1.5.2 rc1 is available
Tziporet Koren wrote: Hi Or, sorry for not answering before Issue 2043 - is already fixed Issue 2005 - We released 2.7.700 FW that solve this issue. Issue 2024 - Eli just answered in bugzilla. Hi Tziporet, 1st and most, good to hear from you... thanks for the detailed answer. Still, for bz 2024, Eli's reply was addressing a case where the Cisco switch was instrumented for PFC, but not the case of global pause under which the problem still happens, per the original description. Did someone from Mellanox actually got to validate bz 2043, it was declared fixed and verified in the very same minute and by the same person... Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [ANNOUNCE] OFED 1.5.2 rc1 is available
Eli Cohen wrote: I don't know what you're talking about WRT 2043. It's status is RESOLVED, not VERIFIED. And you may address me directly [...] we'll check about the global frames case Hi Eli, please hold the horses... I was confusing between resolved to verified, mistakes happen, you know. Saying all that, thanks for looking into validating the case! Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [ANNOUNCE] OFED 1.5.2 rc1 is available
Vladimir Sokolovsky wrote: Known issues: librdmacm-1.0.12 compilation fails on RHEL4.x Hi Tziporet, I don't see any mentioning of IBoE open issues, e.g depicted in ofa bz cases such as: bz 2005 Rocce fails when 1 port is IB and the other is Ethernet bz 2024 bv_rc_pingpong 2 or more clients fail when global pauses or PPP enabled on switch bz 2043 OFED 1.5.1 crashes after running Mcast over RoCE (caused by send_lat benchmark) 2005 might be solved by new firmware, but the case isn't verified/closed Also I sent two notes to linux-rdma asking Vlad/Eli to clarify the issue of IB port counters when using the IBoE patches over --IB--, but there was no reply, Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Update the component list in Bugzilla
Tziporet Koren wrote: There is a component called Installer already Please use it (I already changed in this bug) Hi Tziporet, I believe that the problem here isn't in the installation process but rather in the scripts, with the number of scripts getting bigger, e.g to support dual IB/Eth mode, IPoIB sysctls etc maybe its better to set a different component? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] mlx4_en: ping does not resume after failover
Or Gerlitz wrote: Vladimir Sokolovsky wrote: It was fixed in the OFED-1.5.1-rc4, by the following commit: Author: Yevgeny Petrilin yevge...@mellanox.co.il Date: Wed Mar 10 18:46:55 2010 +0200 mlx4_en: reconfigure mac address Hi Yevgeny, I don't see this commit in Linus tree, does this means that the upstream mlx4_en bits would not work well or even not at all under bonding? can this fix be pushed? Hi Yevgeny, I don't see this in Linus tree and as such believe this still isn't pushed upstream, correct? Assuming this is the case, I'd hate to think that I can't use mlx4_en / bonding e.g for KVM based environments which are all based on recent kernels, can you push that for 2.6.35, please? Or ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] mlx4_en: ping does not resume after failover
Yevgeny Petrilin wrote: Sure, I am preparing the patches cool. Is there anything else in that or close importance level mlx4_en wise which is in ofed and from some reason wasn't push upstream? e.g I see a patch subject (0119) saying Fix a crash with prioritiesed vlan packets this sounds bad... am I expected to hit this or other problems fixed by patches from the below list if upstream is used? Or. mlx4_en_0010_remove_redundant_variable.patch mlx4_en_0020_fix_partial_rings.patch mlx4_en_0030_rx_flow_changes.patch mlx4_en_0040_interface_name_in_messages.patch mlx4_en_0050_renaming_en_params_to_en_ethtool.patch mlx4_en_0060_multiqueue_support.patch mlx4_en_0080_driver_version.patch mlx4_en_0090_linear_rx_dropped_counter.patch mlx4_en_0100_dropped_tx_packets.patch mlx4_en_0101_tx_optimizations.patch mlx4_en_0102_remove_ring_refill.patch mlx4_en_0104_not_using_srqs.patch mlx4_en_0105_dma_mapping_fixes.patch mlx4_en_0106_setting_dev_for_inline_rx.patch mlx4_en_0107_add_vlan_features.patch mlx4_en_0108_set_actual_ring_size.patch mlx4_en_0109_set_correct_size_mask.patch mlx4_en_0110_selftest.patch mlx4_en_0111_perm_addr_field.patch mlx4_en_0112_CLOSE_PORT_at_end_of_teardown.patch mlx4_en_0113_Setting-the-correct-value-to-MAX_TX_RINGS.patch mlx4_en_0114_latency_mod_for_small_packets.patch mlx4_en_0115_less_resources.patch mlx4_en_0116_link_state_report.patch mlx4_en_0117_port_up_in_transmit.patch mlx4_en_0119_tagged_packets_crash_fix.patch mlx4_en_0120_device_ids_table.patch mlx4_en_0130_Allow-interfaces-to-correspond-to-each-other.patch mlx4_en_0140_extend-cap-flags-to-64-bit.patch mlx4_en_0150_offloads_for_vlan_interfaces.patch mlx4_en_0160_UDP_rss.patch mlx4_en_0170__ip_summed_NONE_fix.patch mlx4_en_0180_reporting_transceiver_type.patch mlx4_en_0190_get_set_ringsize_use_actual_size.patch mlx4_en_0200_mlx4_en_destroy_allocator_only_when_using_frags.patch mlx4_en_0210_multicast_promisc_cap.patch mlx4_en_0220_reconfigure_mac_address.patch ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [ANNOUNCE] OFED-1.5.1 GA is available
Vladimir Sokolovsky wrote: Fixed in OFED release notes thanks. Yes, it was fixed in OFED-1.5.1-rc4: See, mlx4_en_0220_reconfigure_mac_address.patch okay, got it. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [Bug 1965] mlx4_en: ping does not resume after failover
Vladimir Sokolovsky wrote: It was fixed in the OFED-1.5.1-rc4, by the following commit: Author: Yevgeny Petrilin yevge...@mellanox.co.il Date: Wed Mar 10 18:46:55 2010 +0200 mlx4_en: reconfigure mac address Hi Yevgeny, I don't see this commit in Linus tree, does this means that the upstream mlx4_en bits would not work well or even not at all under bonding? can this fix be pushed? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [Bug 1965] mlx4_en: ping does not resume after failover
Hi Vlad, Yevgeny Is there a way to get this fix? AFAIK, this bugzilla system isn't there for monitoring the Mellanox ofed flavor, isn't it? Or. bugzilla-dae...@lists.openfabrics.org wrote: https://bugs.openfabrics.org/show_bug.cgi?id=1965 vent...@mellanox.co.il changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #13 from vent...@mellanox.co.il 2010-03-24 08:49 --- Fix had been verified in MLNX_OFED-1.5.1 RC5. Closing ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [ANNOUNCE] OFED-1.5.1 GA is available
Vladimir Sokolovsky wrote: I am pleased to announce that OFED-1.5.1 GA release is done 11. iSER is supported on kernel.org 2.6.30, 2.6.31 and 2.6.32 only. this is wrong, we added support for RHEL 5.4, see the iser RN 1965,major,P3,RHEL 5,yevge...@mellanox.co.il,RESOLVED,FIXED,Bonding mlx4_en: ping does not resume after failover between 10G ports so is this fix in or out? if in, what's the patch name? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED bugs and 1.5.1 GA release
The planned schedule is this - RC5 - tomorrow Mar 17 - GA - Monday Mar 22 Ali, Jack, I just came a cross few commits made by two of you to the ofed 1.5.1 tree, which were'nt sent for review anywhere, is there something special in these patches which didn't let you send them upstream? I would hate to think that the reason is your ability to push into ofed whatever you want to 8 days ago Ali Ayoub ib_core: big LSO support wr opcode for packets larger 8 days ago Ali Ayoub mlx4_core: big LSO support preparation for packets 8 days ago Jack Morgenstein mlx4_ib: fix SRQ initialization per PRM requirements 8 days ago Jack Morgenstein mlx4_core: deprecate bogus CQ completion event warnin Tziporet, why such patches (e.g to the IB core) are added like this in such time? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] EWG/OFED meeting agenda for today (Mar 8)
Tziporet Koren wrote: 1. OFED 1.5.1 ... Release schedule proposal: ... GA - Mar 15, 2010 My proposal: Plan for 1.5.2 on end of Q2 Tziporet, Lets try to learn from the experience / troubles caused by XRC being released through ofed bypassing upstream inclusion and apply the lesson for IBoE. IBoE is out there for people want to experiment with (through 1.5) and its not in the kernel yet, and as such APIs/ABI may still change for the inclusion. Basically, the whole point of 1.5.1 as the EWG was discussing in SC/09 was to do the IBoE merge in a way which meets the quality and process criteria. Maybe the 1.5.1 can be canceled or the EWG can call distros not to adopt it and wait for 1.5.2, or other ideas what people can bring up while being in Sonoma. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED-1.5.1 failure over iWarp
Sean Hefty wrote: If I look at what's there today, we're trying to find some way to match the net_device src_dev_addr with some sort of address associated with an ib_device. In the case of actual IB, the net_device src_dev_addr contains the SGID, which provides the mapping. Steve, can you please clarify the iWarp case for me? For iWarp, doesn't the src_dev_addr contain the MAC? So, the 'GID's reported for an iWarp device is really just the MAC. Is this correct? If this is the case, then couldn't rocee (I hate that name) report its MAC as one of its GIDs? This would ensure that the mapping between net_device and ib_device was correct. Sean, AFAIK, reporting the MAC as one of the GIDs was part of the IBoE (feel free not to use names which you don't like) design presented couple of time, isn't it, Eli, Liran? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] EWG/OFED meeting agenda for today (Jan 11, 2010)
Brian J. Murrell wrote: How about the ISER/iSCSI on kernels 2.6.30 situation? Moni (CC-ed here) will send update on this later today Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Is this the right place for questions on OFED?
Stefan Kuhne stefan.ku...@dialup.fh-aachen.de wrote: I use it because of i've one package with all i need ofed is made of twenty or so RPMs, in the same manner that your distro is made of twenty thousand or so RPMs which you can selectively choose from. The IB stack RPMs have their dependencies well set and as such with yum et al based tools you can install what you need and the pre-req packages will be installed as well (e.g yum install opensm with install the IB mng stack along with opensm). And someone told me, that it is faster. IB wise, this is all wrong and if not, I'd like to hear why. Eth wise, for some unclear reason ofed provides the mlx4_en driver for which it does include tons of patches which aren't present in the upstream version, maybe some of them are performace related. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] vendor supplied iser CANNOT be used with OFED 1.5
Brian, I am looking on how to enable ofed provided iser to get working with distros using older then 2.6.30 kernels, I hope to have some update next week which could be merged into the 1.5.x series . Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] docs: Document NFSRDMA mlx4 firmware requirement
Jon Mason wrote: Firmware 2.6.0 has known issues that prevent the RDMA connection from being established. Looking on bz 1815 I couldn't see why you say there are known issues with connection establishment in firmware 2.6, as the problems there were around fast reg work requests, have I missed something? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] docs: Document NFSRDMA mlx4 firmware requirement
Tziporet Koren wrote: There was a FW bug with FRWR that was fixed in FW 2.7.0 What is not clear here? exactly, the bug has nothing to do with the connection establishment but rather with fast reg work requests, while the text points towards conn establishment. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes
Or Gerlitz ogerl...@voltaire.com wrote: Tziporet, any reason not to wait till this core patch is accepted to the mainline kernel? Vlad, Tziporet, any reason not to address my question, silently ignore my email and just pull this without acking as you usually do, what's the story behind that?! Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes
Betsy Zeller wrote: the agreement in Sonoma was that anything submitted to OFED should also be in the process of going into the kernel. what prevents you from sending a reminder to Roland? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes
Ralph Campbell wrote: I don't think this is likely to happen since it fixes Roland's original concern with exporting struct ib_port whatever, still its a patch to the core that adds new API, etc, needs to pass the maintainer acceptance. Its been two weeks since you sent v2, so a kindly reminder to Roland might do the job, try it. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/qib: latest QIB driver fixes
Ralph Campbell wrote: Vlad, please pull from Ralph, Tziporet, any reason not to wait till this core patch is accepted to the mainline kernel? Or. commit 840bbefeda26d21bffae6b7cdc88e981fcfb0a45 Author: Ralph Campbell (QLogic) ral...@hosting.openfabrics.org Date: Mon Nov 30 14:09:34 2009 -0800 IB/core: allow HCAs to create IB port sysfs files This patch adds a new function to sysfs.c so that HCAs can create files in /sys/class/infiniband/hca/ports/N/. There is no need for an unregister function since the kobject reference will go to zero when ib_unregister_device() is called. Signed-off-by: Ralph Campbell ralph.campb...@qlogic.com ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH 7/9] rdma/cm: fix loopback address support
Sean Hefty sean.he...@intel.com wrote: I will create a new librdmacm package that corresponds with the changes I made all my testing of the patch set with librdmacm 1.0.10 and patched 2.6.32-rc5 kernel, where as I wrote you, I was focusing on AF_INET/PS_TCP and AF_INET/PS_IPOIB. I understand that Dave was covering AF_INET6/PS_TCP with plenty of the ipv6 variations. So what will this new librdmacm package will let cover which wasn't possible so far? do you refer to ipv6 support in mckey? anything else? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH 7/9] rdma/cm: fix loopback address support
Changes were your changes to mckey, plus changes Dave added to cmatose to support IPv6. The actual library itself hasn't been modified. okay, got it. I was under the impression that mckey still misses an option to get from the user an ipv6 multicast address which isn't all zeros nor unmapped, correct? or the -m option will work with both ipv4 and ipv6 addresses? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RE: [ofw] SC'09 BOF - Meeting notes
facts... the patch set sent from downtown Yoqne'am isn't an addition of feature turns out that some folks from the Mellanox RD group found this sentence insulting, and I am apologizing for that. Mentioning the geographic location of the developers didn't come to serve why I find the patch set this or that, but rather send the author of the email I was responding on to go and do homework in his own company office. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
Liran Liss wrote: The patches don't change the logic of existing flows at all, so we are not risking *anything* in terms of the stability of the current stack. I understand that this is your assessment of the situation, looking on the series present at the ofed1.5 rdmaoe branch in a black box manner yields that many many files are touched, see below. Coming and saying that changes in your HW LL driver are out of the scope for other companies to discuss is not acceptable, since we provide enterprise ready stack based on your HW driver. As for vlan id and priorities - we are fully aware to the importance of exposing vlan ids and priorities to the user, but thanks for pointing this out. sure, I am saying this since my first look on the patches, couple of months ago, good that someone listens now. There are deployments today that work fine with the current patches all the rdmaoe materials saying the lossless traffic class is a must, are you saying that this works well also without it? then why from architect point of view you have posed this requirement? Or. $ cat rdmaoe_patches core_0300_refine_device_personality.patch core_0310-Add-RDMAoE-transport-protocol.patch core_0320_rdmaoe_support_qp1.patch core_0330_umad-Enable-support-only-for-IB-ports.patch core_0340_Enable-CM-support-for-RDMAoE.patch core_0350-CMA-device-binding.patch core_0360_RDMAoE-UD-packet-packing-support.patch core_0370-support-RDMAoE-from-userspace.patch core_0380_mcast-support-to-rdmaoe.patch core_0390_cma-move-netdev-mac.patch mlx4_2000_RDMAoE-address-resolution.patch mlx4_2010_RDMAoE-support-allow-interfaces-to-correspond.patch mlx4_2020_handle_mcast_mac.patch mlx4_2030_fix_port_num.patch mlx4_2040_Fix-multicast-handling.patch xxx_rdmaoe_port_notice.patch $ cat rdmaoe_patches | xargs diffstat b/drivers/infiniband/core/cm.c | 25 - b/drivers/infiniband/core/cma.c | 54 +- b/drivers/infiniband/core/mad.c | 41 +- b/drivers/infiniband/core/multicast.c |4 b/drivers/infiniband/core/sa_query.c| 39 +- b/drivers/infiniband/core/ucm.c |8 b/drivers/infiniband/core/ucma.c|2 b/drivers/infiniband/core/user_mad.c|6 b/drivers/infiniband/core/verbs.c | 25 + b/drivers/infiniband/hw/mlx4/main.c | 56 ++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c | 12 b/include/rdma/ib_addr.h| 93 b/include/rdma/ib_verbs.h | 11 b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c |3 b/net/sunrpc/xprtrdma/svc_rdma_transport.c |3 drivers/infiniband/core/cm.c|5 drivers/infiniband/core/cma.c | 254 +++-- drivers/infiniband/core/ucm.c | 13 drivers/infiniband/core/ucma.c | 31 + drivers/infiniband/core/user_mad.c | 16 drivers/infiniband/hw/mlx4/ah.c | 22 - drivers/infiniband/hw/mlx4/main.c | 110 - drivers/infiniband/hw/mlx4/mlx4_ib.h| 13 drivers/infiniband/hw/mlx4/qp.c | 29 + include/rdma/ib_verbs.h |4 ofed_kernel-fixes/drivers/infiniband/core/agent.c | 39 +- ofed_kernel-fixes/drivers/infiniband/core/local_sa.c| 22 - ofed_kernel-fixes/drivers/infiniband/core/mad.c | 45 +- ofed_kernel-fixes/drivers/infiniband/core/notice.c |4 ofed_kernel-fixes/drivers/infiniband/core/ud_header.c | 111 + ofed_kernel-fixes/drivers/infiniband/core/uverbs.h |1 ofed_kernel-fixes/drivers/infiniband/core/uverbs_cmd.c | 32 + ofed_kernel-fixes/drivers/infiniband/core/uverbs_main.c |1 ofed_kernel-fixes/drivers/infiniband/core/verbs.c |9 ofed_kernel-fixes/drivers/infiniband/hw/mlx4/ah.c | 187 +++-- ofed_kernel-fixes/drivers/infiniband/hw/mlx4/mad.c | 32 + ofed_kernel-fixes/drivers/infiniband/hw/mlx4/main.c | 309 ++-- ofed_kernel-fixes/drivers/infiniband/hw/mlx4/mlx4_ib.h | 19 ofed_kernel-fixes/drivers/infiniband/hw/mlx4/qp.c | 169 ++-- ofed_kernel-fixes/drivers/net/mlx4/en_main.c| 15 ofed_kernel-fixes/drivers/net/mlx4/en_port.c|4 ofed_kernel-fixes/drivers/net/mlx4/en_port.h|3 ofed_kernel-fixes/drivers/net/mlx4/fw.c |3 ofed_kernel-fixes/drivers/net/mlx4/intf.c | 20 + ofed_kernel-fixes/drivers/net/mlx4/main.c |6 ofed_kernel-fixes/drivers/net/mlx4/mlx4.h |1 ofed_kernel-fixes/include/linux/mlx4/cmd.h |1
Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
Richard Frank richard.fr...@oracle.com wrote: How can 1500 lines out of 240k lines be a big change.. do I have these numbers right - is the big change you are referring too? Rick, the change set is way not self contained but rather touches various parts of the core IB stack (rdma-cm module, ib address resolution module, ib uverbs module and even the mad module) and ofcourse some of the kernel and user space IB hw specific libraries. What is the risk area that you are worried about .. do you think it will break current transports or existing ULPs? yes, this would be simply not supportable, think about that, you want to hand your customers with a code which didn't pass review nor acceptance by the Linux IB stack maintainers (Roland and Sean), say, next a crash happens at this or that module / line, next, what you except the maintainers to do? If it's just about how the implementation is done.. can this be resolved concurrently with getting the bits available for evaluation now.. an rdmaoe branch at the git tree was set and an releases are maintained, its all what you need for evaluation, five lines later you're talking on deployments... As RoCEE is totally transparent to existing ULPs.. any potential changes would not be visible.. and therefore not an issue for ULP / clients going forward.. right? this is how you see things, since the IBTA IBXoE annex isn't released, you just don't know what would be the bottom line. Oracle would like to see RoCEE get into 1.5 you guys have set a note to the rds developer community that that Oracle recently moved from 1.3.x to 1.4.y, no special work is expected on 1.5.z and that you have lots of plans for 1.6.w ... what's the urgency to get these bits into 1.5? We are testing with RoCEE now and plan to deploy it fairly soon.. in very large configuratio the proposed patch set doesn't let you use non zero VLAN, aren't you expecting Ethernet customers to trivially require that? also you can't use non zero traffic class (priority bits), where all the IBXoE materials are talking about how much working on a lossless traffic class is a must... if indeed this is the case, the patch set is useless without the ability to specify a traffic class, as CEE switches would typically (always?) set only some of the traffic classes to be lossless (e.g the ones used for FCoE, IBXoE) and the rest to be lossy Or ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RE: [ofw] SC'09 BOF - Meeting notes
get the RDMAoE code into 1.5, marked as evaluation if that is EWG's assessment rather than push it off to 1.6. This is important technology that should not be held back It would be great if RoCEE were part of 1.5 even if it were listed as evaluation.. for now. this is leading edge technology, so saying that it is for early evaluation is appropriate what is the thing you want to list as evaluation the whole ofed version or the rdmaoe part of it? in case you refer to the latter, this is impossible, since the rdmaoe patch set touches various areas of the IB stack code and is way not self contained, so the whole IB stack becomes for evaluation, this stack is developed since June 2004 and maintained in the kernel since early 2005, over the last year we see more and more people (e.g from the FSI market) looking and delpolying IB, as the technology and code became enterprise ready. Do you really want that after five years in January 2010 this stack will become experimental? why? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RE: [ofw] SC'09 BOF - Meeting notes
It was disclosed at the BOD meeting that there is no defined process for inclusion of new features in OFED releases facts... the patch set sent from downtown Yoqne'am isn't an addition of feature but rather pose changes everywhere in the IB stack, so maybe the BOD should get together again and discuss things based on facts? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCHv6 0/10] RDMAoE support
Eli Cohen wrote: This new series reflects changes based on feedback from the community on the previous set of patches, and is tagged v6. Previous series were posted to the openfabrics general list only. Changes from v5: 1. Bug fixes. How do you expect a reviewer to learn what were the bugs and what are the fixes and if there are bugs that are known and weren't fixed yet? is one expected to do a diff between patches? where is the listing of changes from vX for X=1,2,3,4? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] what is the status of iSER suppor in OFED 1.5?
Tziporet Koren wrote: Anatoly said yesterday you are testing some solution Can you update the progress? not much progress, lets discuss that next week Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RE: SC'09 BOF
Woodruff, Robert J wrote: I think that we need to discuss this in the EWG meeting first as to what release the code should go into. Since it has not been accepted upstream and as there may be changes needed after the formal spec is released, we may want to consider leaving it in an experimental branch until the code is ready for upstream inclusion and put it into the next OFED release. indeed, the code has hardly started a review and it is way --not-- self contained, the patches touch various portions of the core IB stack (rdma-cm ib-addr, user/kernel ABI/API) and are not limited say to a hardware driver. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] ofa_1_5_kernel 20091007-0200 daily build status
Vladimir Sokolovsky wrote: Can you answer this? Note: Currently, if someone want to use ISER with kernel 2.6.30 he can't use OFED-1.5 Hi Vlad, Brian We're checking this. Basically, I'd like to see people using their distro iSCSI stack. Now, I am checking what does it take for someone that chose to replace her distro provided IB stack with something else (e.g the ofed modules). When I try to load the ofed iser module I get plenty of symbol disagreement errors. If I use modprobe -f I can load the iser module, let me check that and think a bit. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] ofa_1_5_kernel 20091007-0200 daily build status
Or Gerlitz wrote: Basically, I'd like to see people using their distro iSCSI stack. Now, I am checking what does it take for someone that chose to replace her distro provided IB stack with something else (e.g the ofed modules). Brian, You (Sun) may basically be in the other side of the same problem, suppose you have Lustre build to distro X and then someone replaced the IB stack to be that of ofed Y. Lustre uses the IB stack (verbs/rdma-cm) directly and hence should have the same symbol version issue, how do you solve that? rebuild Lustre? load it with modprobe -f? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: Possible process deadlock in RMPP flow
Eli Cohen wrote: Thanks Or. This one is already in OFED 1.4.2 but apparently this is a different problem. Once I have information whether the patch Roland posted fixed it I will update the list. Eli, did you find a commit that fixes the problem you reported on? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: Possible process deadlock in RMPP flow
Eli Cohen wrote: On Wed, Sep 23, 2009 at 09:08:28AM -0700, Sean Hefty wrote: What kernel does 1.4.2 map to? I think OFED 1.4.2 is based on kernel 2.6.27 but they're using RHEL 5.3 Yes, the usual mess: ofed X is based on kernel Y1 but with some additions from kernel Y2 plus plenty of unreviwed and non-merged patches. Distro Z picks ofed X and the result is 99% unsupportable as Roland said. Somehow this ofed creature is still hanging around working on the the next damage its going to bring into this world (code name 1.5) Eli, here's a little tip for you, I had the displeasure to resolve bunch of support cases originating from the fact that the below 2 years old commit missed some ofed version (sorry forgot the number...), maybe it would help you as well? Under a normal setting, if this commit actually solves a bug being hit by many costumers, someone would have opened a distro bugzilla case saying, please pick this commit for your kernel, the customers would have either wait for the next distro update or use a distro intermediate kernel. Currently, I understand that distros are picking ofed versions and that's it. Or. commit b61d92d8ae6aa13b17d1c31e69d123879cec2ee2 Author: Sean Hefty sean.he...@intel.com Date: Fri Nov 30 17:30:18 2007 -0800 IB/mad: Fix incorrect access to items on local_list ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] ipv6 support in rping
David J. Wilder wrote: I am not finding support for ipv6 in rping in the 1.5 beta. What is the story for ipv6 support? Is it supported by librdma and missing in rping? Is ipv6 in rping planed? rping supports IPv6 since last year, see the below commit Or. commit 267c28a2f03b8fb63fa9907badd4130c710a1305 Author: Aleksey Senin aleks...@voltaire.com Date: Thu Aug 14 08:01:58 2008 -0700 rping: add ipv6 support Signed-off-by: Aleksey Senin aleks...@voltaire.com Signed-off-by: Sean Hefty sean.he...@intel.com ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED 1.5 beta release is available
Tziporet Koren wrote: Changes from OFED-1.4.1 1 General changes o Kernel code based on 2.6.30 2 SDP o Performance improvements 3 uDAPL o New library 4 Management o OpenSM - Mesh Analysis for LASH routing algorithm. - Reloadable OpenSM configuration (preliminary implemented) - Routing paths sorted balancing (for UpDown and MinHops) - Weighted Lid Matrices calculation (for UpDown, MinHop and DOR). - I/O nodes connectivity (for FatTree). 5 MPI: - For now same versions as in OFED 1.4.1 there's also a whole new IB driver (QIB) and also new RDS transport (TCP), isn't it? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: ofed/iscsi etc
Vladimir Sokolovsky wrote: Current behavior was specifically defined and coded by Voltaire I'm still not sure to understand the problem and the proposed solutions, is it all contained in Woody's email or there's more in some other threads or bugzilla case/s? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: OFED 1.4.1-rc5 symbol disagreements
Hi OGC gang, May you guys spare the general list from your ofed related postings? I don't see any reason for them to be sent to this list nor how does it serve you, thx Or. Brian M. Rzycki wrote: I downloaded and installed OFED-1.4.1-rc5.tgz on the machine. I configured one of the Mellanox infiniband interfaces and then reboot the system. When installing I chose 2,3: 2) Install OFED Software 3) All packages (all of Basic, HPC) Upon reboot I see the following messages in the dmesg log: Jon Mason wrote: I do not think anyone has backported 2.6.27 (as I do not see a kernel_addons/backport/2.6.27 backport dir). The fix is a simple 1 liner in pagemap.h consisting of: #define __grab_cache_page grab_cache_page Since there is not a backport dir for this kernel, do we really want to add support for it this late in the OFED 1.4.1 release? I have not done any NFSRDMA testing for this kernel. So this could end up to be something that could delay the 1.41. release further. Steve Wise wrote: Open Fabrics Enterprise Distribution (OFED) CHELSIO T3 RNIC RELEASE NOTES - December 2008 + May 2009 The iw_cxgb3 and cxgb3 modules provide RDMA and NIC support for the -Chelsio S310/320 and R310/320 series adapters. Make sure you choose the -'cxgb3' and 'libcxgb3' options when generating your ofed-1.4 rpms. +Chelsio S series adapters. Make sure you choose the 'cxgb3' and +'libcxgb3' options when generating your ofed-1.4.1 rpms. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] Build failures on current 1.4.1 dailies
Gennadiy Nerubayev wrote: Well, I need a recent-ish vanilla kernel due to some performance advantages over stock redhat in some usage scenarios. OFED goes on top of that because of the ease of installation and use.I know I can install and use some of the userspace ofed stuff (opensm, utils, management, libs, etc) along with the in-kernel infinband stack on 2.6.29.1, but even that does not include the whole picture compared to full ofed. Simple stuff still needs to be added for it to be functional, such as 90-ib.rules which is part of the ofa_kernel rpm package; but I digress. You mentioned redhat, so you could use the IB stack provided by the distro and just replace the kernel. This IB stack has all the components you have mentioned. Also, this may sound dumb, but where do I get the support for SDP with in-kernel stack? I can build the libsdp stuff in ofed, but the actual module appears to be ofa_kernel only? sdp was never submitted upstream... do you use it? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] ibv_devinfo on 1.4.1-rc4 shows only 1 port
Mike Aho wrote: Pradeep and I discussed this. The firmware is 2.3 on the card and will be moved to the most current level. sounds like you have the one port hca (Sinai), send the ibv_devinfo output Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: features / freeze
Tziporet Koren wrote: In any case - if the EoIB code will not be ready it will not be in 1.5 Unlike the IBoE patchset, EoIB is more of a stand alone in the sense that it adds a driver to the IB stack and generally speaking doesn't touch other components, where the IBoE patches touch many components and hence the review/process is critical to avoid the kind of troubles we have now with XRC, for example. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Build failures on current 1.4.1 dailies
Gennadiy Nerubayev para...@gmail.com wrote: Running on 2.6.27.21 x64. ofa_kernel build error as follows: What makes you use ofed on this kernel? if you need newer features, simply use 2.6.29.1 or newer bits. Also if you still need to use ofed, the place its worked out is the ewg list @ ewg@lists.openfabrics.org, the general list is for the upstream kernel. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: features / freeze
Woodruff, Robert J wrote: Yes, in general we have agreed in the EWG that any code that goes into OFED should first be reviewed and accepted for upstream inclusion (or at least be accepted by Roland for a future kernel.org kernel.) before it goes into OFED. Given that the feature freeze for OFED 1.5 is coming up pretty soon, I would suggest starting this process as soon as you can if you want to try to get this driver into OFED 1.5 Hi Woody and the EWG, recalling our related thread from couples of weeks ago, I didn't see any sign for the IBoE nor EoIB code being sent to review for mainline inclusion - does it mean neither of them is planned for the coming release? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [PATCH v3] mlx4_ib: Optimize hugetlab pages support
Eli Cohen wrote: You mention in Bugzilla an mckey test but I don't know this test. Can you send how to obatain the test and instructions how to build it and run it? Eli, mckey is installed with librdmac-utils, has man page, etc. Its source is under the examples directory of the librdmacm src tree, you can clone Sean's librdmacm git from ofa to get it - OK? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] can't remove ofed1.3.x packages
Hi Vlad, doing $ rpm -e libsdp-1.1.99-1.ofed1.3.1 error: libsdp-1.1.99-1.ofed1.3.1 specifies multiple packages I noted that ofed1.3.x had the practice of installing multiple packages with the same name! e.g see below the sorting of packages. So how can I remove a specific package (I don't want to do huge uninstall/install just remove 2-3 packages)? also has this fixed in the next release? Or. $ rpm -qav | grep ofed1.3.1 | sort dapl-1.2.7-1.ofed1.3.1 dapl-1.2.7-1.ofed1.3.1 dapl-2.0.9-1.ofed1.3.1 dapl-2.0.9-1.ofed1.3.1 dapl-devel-1.2.7-1.ofed1.3.1 dapl-devel-1.2.7-1.ofed1.3.1 dapl-devel-2.0.9-1.ofed1.3.1 dapl-devel-2.0.9-1.ofed1.3.1 dapl-utils-2.0.9-1.ofed1.3.1 dapl-utils-2.0.9-1.ofed1.3.1 ibutils-1.2-1.ofed1.3.1 libibcm-1.0.2-1.ofed1.3.1 libibcm-1.0.2-1.ofed1.3.1 libibcm-devel-1.0.2-1.ofed1.3.1 libibcm-devel-1.0.2-1.ofed1.3.1 libibcommon-1.0.8-1.ofed1.3.1 libibcommon-devel-1.0.8-1.ofed1.3.1 libibcommon-devel-1.0.8-1.ofed1.3.1 libibmad-1.1.6-1.ofed1.3.1 libibmad-devel-1.1.6-1.ofed1.3.1 libibmad-devel-1.1.6-1.ofed1.3.1 libibumad-1.1.7-1.ofed1.3.1 libibverbs-1.1.1-1.ofed1.3.1 libibverbs-1.1.1-1.ofed1.3.1 libibverbs-devel-1.1.1-1.ofed1.3.1 libibverbs-devel-1.1.1-1.ofed1.3.1 libibverbs-utils-1.1.1-1.ofed1.3.1 libibverbs-utils-1.1.1-1.ofed1.3.1 libmlx4-1.0-1.ofed1.3.1 libmlx4-1.0-1.ofed1.3.1 libmthca-1.0.4-1.ofed1.3.1 libmthca-1.0.4-1.ofed1.3.1 librdmacm-1.0.7-1.ofed1.3.1 librdmacm-1.0.7-1.ofed1.3.1 librdmacm-devel-1.0.7-1.ofed1.3.1 librdmacm-devel-1.0.7-1.ofed1.3.1 librdmacm-utils-1.0.7-1.ofed1.3.1 librdmacm-utils-1.0.7-1.ofed1.3.1 libsdp-1.1.99-1.ofed1.3.1 libsdp-1.1.99-1.ofed1.3.1 libsdp-devel-1.1.99-1.ofed1.3.1 libsdp-devel-1.1.99-1.ofed1.3.1 mstflint-1.3-1.ofed1.3.1 perftest-1.2-1.ofed1.3.1 qperf-0.4.0-1.ofed1.3.1 sdpnetstat-1.60-1.ofed1.3.1 srptools-0.0.4-1.ofed1.3.1 tvflash-0.9.0-1.ofed1.3.1 here I assume to see the content of both the 64 and 32 bit packages, correct? $ rpm -ql libsdp-1.1.99-1.ofed1.3.1 | xargs file /etc/libsdp.conf: ASCII English text /usr/lib64/libsdp.so.1: symbolic link to `libsdp.so.1.0.0' /usr/lib64/libsdp.so.1.0.0: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped /usr/share/doc/libsdp-1.1.99: directory /usr/share/doc/libsdp-1.1.99/COPYING: ASCII English text /usr/share/doc/libsdp-1.1.99/ChangeLog: ASCII English text /usr/share/doc/libsdp-1.1.99/NEWS: ASCII text /usr/share/doc/libsdp-1.1.99/README:ASCII English text /etc/libsdp.conf: ASCII English text /usr/lib/libsdp.so.1: symbolic link to `libsdp.so.1.0.0' /usr/lib/libsdp.so.1.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped /usr/lib/libsdp_sys.so.1: symbolic link to `libsdp_sys.so.1.0.0' /usr/lib/libsdp_sys.so.1.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped /usr/share/doc/libsdp-1.1.99: directory /usr/share/doc/libsdp-1.1.99/COPYING: ASCII English text /usr/share/doc/libsdp-1.1.99/ChangeLog: ASCII English text /usr/share/doc/libsdp-1.1.99/NEWS: ASCII text /usr/share/doc/libsdp-1.1.99/README:ASCII English text ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH RFC v3] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
Tung, Chien Tin wrote: 3) and calls cma_alloc_any_port() to allocate a port number which may not correspond to the port number for the bound socket. With the addition of getnam(), sin_port is filled in with the reserved port number and cma_any_port will evaluate to false and the reserved port will get used instead. So the only problem was carving a port from the proprietary ports pool of the rdma-cm where a port was already allocated from the network stack? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
***SPAM*** Re: [ewg] RE: OFED meeting agenda for today (Oct 22)
RDS – GA with RDMA API - wrong, RDS patches are now on hold for 1.4 such that 1.4.1 is a must just in that sense GA with RDMA API is already done over IB. I don't agree. Andy, can you comment? My understanding is that the stable RDS code is present at the 1.3.x tree but this code is also not GA-ed yet, and that in any case the RDS code in the ofed 1.4 (soon to be 1.4.y) tree in not certified nor GA-ed RDS patches on hold are those that supports iWARP. This is on top of the above. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [PATCH] IB/ipoib: enhance ethtool support
Tziporet Koren wrote: Do you wish to add these to OFED 1.4? yes ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
***SPAM*** Re: [ewg] Re: [PATCH] IB/ipoib: enhance ethtool support
On Sun, Oct 26, 2008 at 1:58 PM, Tziporet Koren [EMAIL PROTECTED] wrote: Can you send a mail to Vlad with the patch for OFED Hi Vlad, Here it is : http://lists.openfabrics.org/pipermail/ewg/2008-October/012268.html Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RE: OFED meeting agenda for today (Oct 22)
Woodruff, Robert J wrote: Attached are the 0.3 version of the BOF slides that we can review today. slide 11 (1.4 features) says RDS – GA with RDMA API - wrong, RDS patches are now on hold for 1.4 such that 1.4.1 is a must just in that sense Congestion Control in ibutils - can someone elaborate what is the exact feature? SDP – GA - can someone say what is new here? VPI support: Eth and IB for ConnectX - what is VPI and how it is used? I understand that the mlx4_en driver was added to the release. Not that I understand what an ethernet NIC has to do with the RDMA stack, nor when it was ever discussed in public that the release would contain this NIC driver. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH] IB/ipoib: enhance ethtool support
IB/ipoib: improve ethtool support for older kernels
In non-recent kernels such as the ones used by RH5 the core networking ethtool
code doesn't apply the ethtool_op_get_xxx functions by default, so the driver
has to supply them. Without this patch ethtool -k on ipoib devices would print
wrong information eg:
# cat /sys/class/net/ib0/features
0x11423
# ethtool -k ib0
Offload parameters for ib0:
Cannot get device rx csum settings: Operation not supported
Cannot get device tx csum settings: Operation not supported
Cannot get device scatter-gather settings: Operation not supported
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
Signed-off-by: Or Gerlitz [EMAIL PROTECTED]
Index: linux-2.6.27/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
===
--- linux-2.6.27.orig/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
+++ linux-2.6.27/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c
@@ -129,7 +135,11 @@ static void ipoib_get_ethtool_stats(stru
static const struct ethtool_ops ipoib_ethtool_ops = {
.get_drvinfo= ipoib_get_drvinfo,
+ .get_tx_csum= ethtool_op_get_tx_csum,
+ .get_sg = ethtool_op_get_sg,
.get_tso= ethtool_op_get_tso,
+ .get_ufo= ethtool_op_get_ufo,
.get_coalesce = ipoib_get_coalesce,
.set_coalesce = ipoib_set_coalesce,
.get_flags = ethtool_op_get_flags,
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] STOP the onslaught of EWG spam - disallowing non member posts
Jeff Squyres wrote: The EWG list has gotten spam bombed over the last few hours. I lost count at 500+ spams in my inbox. I therefore logged into openfabrics.org and changed the site-wide password for Mailman (I have notified Jeff Becker of the new password). I then changed the EWG list to silently discard all non-member posts. Since I didn't know if other OF lists were being spam-bombed, I did the same for all OF lists as well. Hi Jeff, Disallowing non members posts to the general list is problematic, since as of the below MAINTAINERS entry this is where people from the kernel community post issues they have with the RDMA stack, and you don't expect everyone to subscribe the list... white-listing member posts sounds fine, but this is a bit too much. As Sasha said and as was mentioned few times in the past, it seems like the old @openib.org aliases cause us lots of troubles, maybe we should just remove them. Or. INFINIBAND SUBSYSTEM P: Roland Dreier M: [EMAIL PROTECTED] P: Sean Hefty M: [EMAIL PROTECTED] P: Hal Rosenstock M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.openib.org/ T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git S: Supported ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH RFCv2] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
Steve Wise wrote: From: Steve Wise [EMAIL PROTECTED] This is needed for iwarp providers that support native and rdma connections over the same interface. Optionally turned on by the new rdma_cm unify_tcp_port_space module option. OK, I guess this can get it, as least from my side, thanks for fixing it. --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -809,6 +815,8 @@ static void cma_release_port(struct rdma_id_private *id_priv) kfree(bind_list); } mutex_unlock(lock); + if (id_priv-sock) + sock_release(id_priv-sock); } any specific reason to put this here and not in rdma_destroy_id? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH RFC ofed-1.4] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space
Vladimir Sokolovsky wrote: Steve Wise wrote: Tziporet EWG members, iWARP customers including Sandia Labs have asked that we include this in OFED distributions to correctly unify the host stack and iwarp stack TCP port space. I recommend we maintain this patch as part of the OFED distribution. I you agree, then we can pull this in as a patch file in kernel_patches/fixes/ for ofed-1.4. Thanks, Steve. - RDMA/CMA: Allocate PS_TCP ports from the host TCP port space This is needed for iwarp providers that support native and rdma connections over the same interface. Signed-off-by: Steve Wise [EMAIL PROTECTED] --- drivers/infiniband/core/cma.c | 27 ++- 1 files changed, 26 insertions(+), 1 deletions(-) Added to the ofed_1_4/linux-2.6.git ofed_kernel as kernel_patches/fixes/cma_0040_allocate_PS_TCP_ports.patch Vlad, This patch breaks iscsi targets that use the same port for iscsi/tcp and iscsi/rdma over IB, please remove it. I asked Steve to send an updated version that opens the socket-for-rdma-cm-id-behind-the-cover only for iWARP devices. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] soft lockup in the kernel mad layer
Tziporet Koren wrote: Yet another evidence on the confusion created by the existence of two trains carrying IB bits. Both a fix or feature can be here but not there in a given time frame. I disagree here. I don't see how can you disagree with the fact that for me, its confusing. Your claim below goes down to the details of why this patch was not included in ofed 1.3, where I say that the existence of an entity (riding train) which is not the kernel nor a distribution cause confusion and the case of this patch is an example for many other cases of where this fix/feature exist? is it kernel version X, ofed version Y or distro update/service-pack Z This patch was only accepted to 2.6.25 so we have not missed it since we were based on 2.6.24 (and yes this bug was in the kernel too) In next version (1.4) the fix would be inside in any case. The only thing is that we sometime take patches from newer kernel to OFED especially bug fixes. Or ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] soft lockup in the kernel mad layer
Jack Morgenstein wrote: Note that Roland asked Linus to pull this patch for the kernel 2.6.25 tree on Jan 25, 2008: http://lists.openfabrics.org/pipermail/general/2008-January/045492.html OK, I see. Yet another evidence on the confusion created by the existence of two trains carrying IB bits. Both a fix or feature can be here but not there in a given time frame. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] soft lockup in the kernel mad layer
Or Gerlitz wrote: doing some tests against some nodes with new HCA firmware (connectx FW 2.5) which seems to be very slow responding on node info queries, I think that I have stepped on a bug/s in the kernel mad code The IB bits used on this node are not the mainline kernel ones but rather git://git.openfabrics.org/ofed_1_3/linux-2.6.git ofed_kernel commit 564e9e9383272f4311fd87ff4e5447cfcebad73a Jack, Vlad Looking now on the ofed_1_3/linux-2.6.git tree, I don't see the below commit there, am I correct? Is it because the fix was pushed to the kernel after the feature freeze of ofed 1.3 but not into ofed since you don't pick all the fixes that get into the kernel during an ofed cycle? Or. commit b61d92d8ae6aa13b17d1c31e69d123879cec2ee2 Author: Sean Hefty [EMAIL PROTECTED] Date: Fri Nov 30 17:30:18 2007 -0800 IB/mad: Fix incorrect access to items on local_list In cancel_mads(), MADs are moved from the wait_list and local_list to a cancel_list for processing. However, the structures on these two lists are not the same. The wait_list references struct ib_mad_send_wr_private, but local_list references struct ib_mad_local_private. Cancel_mads() treats all items moved to the cancel_list as struct ib_mad_send_wr_private. This leads to a system crash when requests are moved from the local_list to the cancel_list. Fix this by leaving local_list alone. All requests on the local_list have completed are just awaiting processing by a queued worker thread. Bug (crash) reported by Dotan Barak [EMAIL PROTECTED]. Problem with local_list access reported by Robert Reynolds [EMAIL PROTECTED]. Signed-off-by: Sean Hefty [EMAIL PROTECTED] Signed-off-by: Roland Dreier [EMAIL PROTECTED] diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c index 5eace99..fbe16d5 100644 --- a/drivers/infiniband/core/mad.c +++ b/drivers/infiniband/core/mad.c @@ -2275,8 +2275,6 @@ static void cancel_mads(struct ib_mad_agent_private *mad_agent_priv) /* Empty wait list to prevent receives from finding a request */ list_splice_init(mad_agent_priv-wait_list, cancel_list); - /* Empty local completion list as well */ - list_splice_init(mad_agent_priv-local_list, cancel_list); spin_unlock_irqrestore(mad_agent_priv-lock, flags); /* Report all cancelled requests */ ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] non srq panic patch
David J. Wilder wrote: This patch fixes a panic when shared receive queues are not used. Signed-off-by: David Wilder [EMAIL PROTECTED] If this patch fixes a problem which also exists in the mainline kernel, it has to be accepted upstream (to Roland's tree) before submission to the ewg list. If its not relevant to the mainline code, but rather a result of a problem in a patch that exists only in ofed, the correct way to go would be to fix the patch, send it to the general list for review towards upstream acceptance and then just pull it into ofed. Other then that, this change-log comment is totally mysterious and it requires a detailed read of the patch to know what is the problem and what is the fix. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: ofed 1.4 kernel git tree
Tziporet Koren wrote: Steve Wise wrote: Never mind. I see it is at 2.6.26-rc1 at least. But when I do a git tag -l it doesn't show the 2.6.26 tag? Vlad will upgrade to latest 2.6.26 rc soon Tziporet, For simplicity, process transparency and following the decisions in Sonoma - as the next version is to be based on 2.6.27 why not base the 1.4 kernel git tree on the for-2.6.27 branch of Roland's tree until 2.6.27-rc1 is out? Why at this point we have forty three kernel patches? my understanding is that other then the local-sa and xrc, two features which are not upstream as of lack of consensus on their implementation, there should be clean table here. Eli, specifically, ipoib wise, I guess we agree that the lesson from the previous version should be learned... does anything prevent you from pushing the ipoib patches to Roland or removing them from ofed? Or. cma_0010_response_timeout.patch cma_0030_tavor_quirk.patch core_0010_dma_map_sg.patch core_0050_xrc.patch core_0060_xrc_file_desc.patch core_0080_kernel_xrc.patch core_0090_core_delete_redundant_check_for_DR_SMP.patch core_0100_core_Dont_modify_outgoing_DR_SMP_if_first_pa.patch core_0110_xrc_rcv.patch cxgb3_00300_add_ofed_version_tag.patch ehca_0011_Alloc_firmware_context_with_GFP_ATOMIC.patch ehca_0012_Change_version_number.patch ipoib_0110_set_default_cq_patams.patch ipoib_0290_reduce_cm_tx.patch ipoib_0310_def_ring_sizes.patch ipoib_0320_small_skb_copy.patch ipoib_0340_neigh_crash_wa.patch ipoib_0370_selector.patch mlx4_0010_add_wc.patch mlx4_0015_set_cacheline_sz.patch mlx4_0020_cmd_tout.patch mlx4_0040_qp_max_msg.patch mlx4_0045_qp_flags.patch mlx4_0070_xrc.patch mlx4_0080_profile_parm.patch mlx4_0090_fix_sq_wrs.patch mlx4_0120_xrc_kernel.patch mlx4_0125_xrc_kernel_missed.patch mlx4_0210_xrc_rcv.patch mlx4_0220_enable_qos.patch mlx4_0250_debug_output.patch mlx4_0260_optimze_stamping.patch mlx4_0290_mcast_loopback.patch mlx4_0310_date_version.patch mthca_0001_catas_wqueue_namelen.patch mthca_0002_wrid_swap.patch mthca_0010_bogus_qp.patch sean_cm_limit_mra_timeout.patch sean_local_sa_1_notifications.patch sean_local_sa_2_cache.patch sean_local_sa_3_disable.patch sean_local_sa_4_fix_hang.patch uverbs_warning.patch ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] [PATCH ofed-1.3.1 0/2] IB/ehca: Misc fixes
Stefan Roscher wrote: Hi Vlad! I'm sending you a patch set for ehca to be included in ofed-1.3.1. These patches are based on OFED-1.3.1-rc1 and already included in kernel main line. Hi Stefan, Can you please spare the general list from these posts? why we have to see each patch of your twice, once when you send it upstream and second when you ask to include it in OFED?! Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: OFED 1.3 w/ a Lustre kernel (was Re: [ofa-general] kernel ib build (OFED 1.3) fails on SLES 10)
Chris Worley wrote: I'm building OFED 1.3 for an RHEL5.1 kernel for Lustre 1.6.4.3: 2.6.18-53.1.13.el5_lustre.1.6.4.3smp. ofed in maintained in the ewg list ewg@lists.openfabrics.org, please send your questions over there. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] IB/ipoib: Fix neigh destructor oops for kernels older than 2.6.21
Eli Cohen wrote: Unfortunately not. But I did not want to leave this problem pending anymore since I want to get some mileage on it. Still, if we have a better solution it would be easy to adopt since this patch is independent of all others. I see, next time, could you drop a mail saying that you decided to move on with something, etc? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] Install IPoIB separately ..
Nathan Dauchy wrote: This coupling of install and build steps complicates life for users and seems like a step backwards from OFED-1.2. From the OFED Aug 13 meeting summary, this change was made in part because the previous build method and manner of handling dependencies did not follow standard RPM usage. I don't think that uninstalling multiple RPM's and rebuilding them in order to add another RPM is standard RPM usage either. Can this be put on the to-do list for OFED-1.3.2? Is install.pl the only way to reliably build OFED-1.3? Can you please spare the general list from those discussions on the ofed distro startup? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] [ GIT PULL ofed-1.3.1] - more cxgb3 fixes for -rc1
Steve Wise wrote: Vlad, Please pull these additional upstream bug fixes into ofed-1.3.1. Pull from Steve, can these emails remain in the ewg mailing list? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] status of ofed ipoib changes which are not upstream
Eli Cohen wrote: I don't intend to push this to upstream kernel but I think we should keep it for ofed since for older kernels it provides better performance. Again, the patch is very sensitive by nature, it did not pass a review and numerous bugs were associated with it through the 1.3 cycle, I think isn't it should be enough to see that there is a problem here. If you see this differently, then send it for review only for old kernels, state on which kernels you see improvement, what is this improvement and then we see. 16 kernel_patches/fixes/ipoib_0210_draft_wr.patch 17 kernel_patches/fixes/ipoib_0220_ud_post_list.patch 18 kernel_patches/fixes/ipoib_0230_srq_post_n.patch 19 kernel_patches/fixes/ipoib_0250_non_srq_param.patch 20 kernel_patches/fixes/ipoib_0290_reduce_cm_tx.patch 21 kernel_patches/fixes/ipoib_0310_def_ring_sizes.patch 22 kernel_patches/fixes/ipoib_0320_small_skb_copy.patch 23 kernel_patches/fixes/ipoib_0330_child_mtu.patch 24 kernel_patches/fixes/ipoib_selector_updated.patch We have a few critical bugs in ofed which I will address first and in the background I'll push the fixes first and then the other patches. I hope to get more of them to 2.6.26 and the rest will wait for 2.6.27. With critical bugs in ofed (1.3) are you referring to the IPoIB related cases 985,989,1004,etc or its something else? 2.6.26 feature window is going to be closed any day now, so the way to go is review and merge them into the for-2.6.27 branch, but lets do it now and not 3 months away. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: split CQs for IPOIB UD
Roland Dreier wrote: what about this patch: http://lists.openfabrics.org/pipermail/general/2008-March/048322.html Looks mostly OK, I plan to merge it. Hi Eli, OK, so we start a review here, good! I see now (that you made a day later a v1 post for this patch @ http://lists.openfabrics.org/pipermail/general/2008-March/048381.html fixing some receive size calculations, and that some variations plus fixes exist in the copy and related patches in ofed 1.3. For example the call to skb_orphan() was moved from where it is placed here, there's a bug fix for the CQ size calculations, ipoib_ib_handle_tx_wc() gets a need_lock flag, etc. Please let us know if you want to merge the v1 post (can it be updated such that it applies against the current git?) or you want first to update it etc. thanks, Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] status of ofed ipoib changes which are not upstream
Or Gerlitz wrote: What's the status of merging your ipoib related patches? Looking on Roland's git I see that the checksum offload, LSO, and most of the cq moderation patches are merged, but things like the cq split along with all the small packet optimizations aren't. Hi Eli, I made a pass on the ofed 1.3 ipoib patches attempting to sort them to ones which are merged upstream and ones which aren't, I'll be happy if you can validate my sorting. I can assist with reviewing the non merged ones, once you send them to the general list. ones that were already merged to kernel later then the one 1.3 was based on, or were that merged since 1.3 was released -- 1 kernel_patches/fixes/ipoib_0010_Add-high-dma-support-to-ipoib.patch 2 kernel_patches/fixes/ipoib_0020_Add-s-g-support-for-IPOIB.patch 3 kernel_patches/fixes/ipoib_0040_checksum-offload.patch 4 kernel_patches/fixes/ipoib_0050_Add-LSO-support.patch 5 kernel_patches/fixes/ipoib_0060_ethtool-support.patch 6 kernel_patches/fixes/ipoib_0070_modiy_cq_params.patch 7 kernel_patches/fixes/ipoib_0120_check_grat_arp_with_cm.patch 8 kernel_patches/fixes/ipoib_0200_non_srq.patch 9 kernel_patches/fixes/ipoib_0240_4kmtu.patch 10 kernel_patches/fixes/ipoib_0260_pkey_change.patch 11 kernel_patches/fixes/ipoib_0270_remove_alloc.patch 12 kernel_patches/fixes/ipoib_0300_reap.patch non merged and (except for cq def params cq split) not submitted for review -- 13 kernel_patches/fixes/ipoib_0110_set_default_cq_patams.patch 14 kernel_patches/fixes/ipoib_0180_split_cq.patch 15 kernel_patches/fixes/ipoib_0190_unsig_udqp.patch 16 kernel_patches/fixes/ipoib_0210_draft_wr.patch 17 kernel_patches/fixes/ipoib_0220_ud_post_list.patch 18 kernel_patches/fixes/ipoib_0230_srq_post_n.patch 19 kernel_patches/fixes/ipoib_0250_non_srq_param.patch 20 kernel_patches/fixes/ipoib_0290_reduce_cm_tx.patch 21 kernel_patches/fixes/ipoib_0310_def_ring_sizes.patch 22 kernel_patches/fixes/ipoib_0320_small_skb_copy.patch 23 kernel_patches/fixes/ipoib_0330_child_mtu.patch 24 kernel_patches/fixes/ipoib_selector_updated.patch merged partially and in different form (yours applied to few allocations and used vmap, roland's handled one allocation and uses vmalloc) -- 25 kernel_patches/fixes/ipoib_0280_vmap.patch I am mostly worried from patches 13-24 skipping the review cycle for 2.6.26, some of them are kind of very sensitive on the one hand and not very attractive on the other hand eg: you have decided to hold off with the merge of ipoib_0190_unsig_udqp.patch since you say it does not provide any benefit. I see in the ofed git that eight bugs where found in this patch through the 1.3 cycle and this is before mainline review! other patches. I say that if you don't submit it to mainline, drop it from ofed. Also - - the srq post list and ud post receive list are kind of simple and not involving much states, can they be submitted to review without much effort from your side? - the child mtu patch seems like a bug fix, doesn't it apply also to mainline? - the selector patch is from ofed 1.1 or so, can't it just be removed? - etc Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] status of ofed ipoib changes which are not upstream
Eli Cohen wrote: 15 kernel_patches/fixes/ipoib_0190_unsig_udqp.patch On older kernels this patch seems to improve throughput of small messages so we should make the effort to include it. I would like to verify this again and if this is correct I will send for review. I don't see why should performance gain only with old kernels justify including such patch, Roland? 16 kernel_patches/fixes/ipoib_0210_draft_wr.patch 17 kernel_patches/fixes/ipoib_0220_ud_post_list.patch 18 kernel_patches/fixes/ipoib_0230_srq_post_n.patch 19 kernel_patches/fixes/ipoib_0250_non_srq_param.patch 20 kernel_patches/fixes/ipoib_0290_reduce_cm_tx.patch 21 kernel_patches/fixes/ipoib_0310_def_ring_sizes.patch 22 kernel_patches/fixes/ipoib_0320_small_skb_copy.patch 23 kernel_patches/fixes/ipoib_0330_child_mtu.patch 24 kernel_patches/fixes/ipoib_selector_updated.patch OK, I'll review them and submit what I think is important and drop the others. Good, the only tiny problem is that the merge window on 2.6.26 opened eleven days ago, which means its going to be closed soon, seems we had somehow bad timing here, I guess it was not intended, correct? Anyway, lets review them all now, such that this way or another, each patch of this list is either dropped (unsig_udqp ?!) or merged through 2.6.26 or the for-2.6.27 branch of Roland's tree, OK? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
