@Chen Hamami
Thank you, but I am not sure if you understand the problem or the issue with it.
The Mellanox ConnectX-4 dual port VPI product brief (here: http://www.mellanox.com/related-docs/prod_adapter_cards/PB_ConnectX-4_VPI_Card.pdf) states, in the compatibility section, Windows and also that it works with “– Interoperable with InfiniBand or 1/10/25/40/50/100Gb Ethernet switches”.
But that’s not exactly entirely true.
(There is an asterisk next to the supported OS/distribution list, which says: “This section describes hardware features and capabilities. Please refer to the driver and firmware release notes for feature availability.”)
Insodoing, referring to the WinOF-2 release notes (for Windows Server 2016 server), there is no mention anywhere in the release notes that states that the opensm is not packages with the WinOF-2 driver, which means that for someone who is running an unmanaged Mellanox SB-7790 or 7890 externally managed switch, it will give the impression that there is an issue with the hardware when the answer is because the opensm manager is no longer part of the WinOF-2 driver.
In other words, the combination of Mellanox hardware and Mellanox software is insufficient to actually achieve what the product brief and the driver release notes states: that it 4x EDR Infiniband works or is compatible with Windows.
That’s just simply not true.
Nowhere in the marketing or the advertising material, does it state that you need either a MANAGED switch (which has the OpenSM built-in to it) or that you will need another system, running Linux, so that IT can run the OpenSM OR that you will have to download and/or compile the OpenSM from source in order to get it to work/run in a pure Windows environment.
I’m not going to tell you how to run your business, but if it were me, I would be really interested in talking with the Office of General Counsel to make sure that the advertising and marketing material that has been published cannot be interpreted as I have explained it such that it would become a violation of the California Business & Professional Code §§17200 and 17500 and California Civil Code §1770(a) because as far as I can tell, with a set up as I have described, it does not work as advertised/published.
And to be honest and frank, would it really be that difficult to roll the OpenSM back into the next release of the driver? Maybe it’s more involved than I might imagine, being a customer that doesn’t know nor understand the intricacies of doing something like this, but even if it was just a sample code so that we would be able to get the system up and running, all of the advertising and marketing material can be re-written such that if you want something else, you’ll have to do something else instead.
But at least have it in there (like it’s part of the MLNX Linux OFED driver), so I don’t really understand why it can’t be part of the WinOF-2 driver. Yes, I understand that you said that it was a “marketing” decision, but it’s software. The OpenSM driver/module that’s included with the MLNX Linux driver is, if I recall correctly, disabled by default until you enable it.
I’m not a programmer, so I lack the capacity, the expertise, nor the knowledge to be able to understand why this solution, which to an end customer, appears to be something that should be doable, isn’t done, resulting in undue litigation risk exposure to the company, all because of a “marketing” decision which drove a change in software (driver).