[ofw] Seeking help on WinOF PR 1963

[Alex Naslednikov]

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: ofw-bounces at lists.openfabrics.org [mailto:ofw-bounces at lists.openfabrics.org] 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: ofw-bounces at openfabrics.org [mailto:ofw-bounces at openfabrics.org] 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
ofw at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
_______________________________________________
ofw mailing list
ofw at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw