Usha, We installed our latest driver (pre-released version of MLNX-WinOF 2.1.1) and latest IOmeter version. We were not able to reproduce the problem with various kinds of setup (including setups with heavy stress of 4 simultaneous workers). We tested it on 2008 x64 and 2008 R2 OSes. Can you please provide the exact configuration of your IOmeter test ? On the other hand, we found some differences between MLNX 2.1.1 and OFA 2.2.0 drivers. Can you please test the setup with our driver? You can find latest MLNX WHQLed driver at: http://www.mellanox.com/content/pages.php?pg=products_dyn&product_family=32&menu_section=34#tab-two
I can send you the drivers also of 2.1.1,if needed Alexander (XaleX) Naslednikov, Software Engineer Mellanox -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Usha Srinivasan Sent: Thursday, February 25, 2010 9:21 PM To: ofw_list Subject: [ofw] Seeking help on WinOF PR 1963 Hello Fellow-WinOFers, I wrote up PR 1963 yesterday and have added plenty of additional information today. I am running the latest WinOF on Windows 2008 R2 with 2 ConnectX DDR cards. I cannot get Iometer to run; I cannot get ib_send_bw to send large number of packets. I am able to run ibv_send_bw but with abysmal performance. Can anyone look at the PR and provide some assistance? Has anyone run winof_2-2_RC2_win7_x64 on Windows 2008 R2? Thanks in advance! Usha -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sean Hefty Sent: Monday, February 22, 2010 3:02 PM To: 'Leonid Keller'; 'James Yang'; Tzachi Dar; ofw_list Subject: Re: [ofw] API breakage in trunk > > > I don't see any reason why ib_ca_attr_t can't just be extended ... >One can do it. >It doesn't break backward compatability, so old applications will work >well with new kernel (i.e. with extended ib_ca_attr_t). >But new applications, running against old kernel, may crash. Maybe it's time to separate the user space APIs from the user to kernel interfaces from the kernel APIs. >> > // for LLE >> > enum rdma_transport_type[MAX_PORT_NUM] transport; >> > >> > // for vendor specific info >> > enum vendor_info_type vendor_info; >> > union { >> > uplink_info_t mlnx_vendor_info; >> // for >> >Mellanox >> > }; We could add new calls to obtain vendor specific data. Although the transport type ideally belongs as a common attribute. The Linux solution to the problem was to make use of padding in the structure, which you suggested as the 'third' solution. That may be the cleanest way to add new fields to the structure _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
