Ethernet Products
Determine ramifications of Intel® Ethernet products and technologies
5225 Discussions

On the state of 802.3az with Intel X550

hardfault
Novice
2,971 Views

Hi

 

This is an attempt to resurrect an old topic that seems to get very little love - probably because moderators are not notified of new posts on old topics, so I'd like to renew this (if this could be merged to the old topic, I'd be happy as well).

https://community.intel.com/t5/Ethernet-Products/802-3az-EEE-support-on-X550-T1-2-NICs/m-p/284819#M2602

 

I'm aware Intel basically aims to replace the X550-Series with the x710 and later, but I'm quite disappointed in the current state.

In 2016, a Bug was stated in the errata, with the possible fix in NVM later:
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-x550-spec-update.pd...
The datasheet for the chip on the Ark (https://ark.intel.com/content/www/us/en/ark/products/84329/intel-ethernet-controller-x550at2.html) still lists EEE (Energy Efficient Ethernet) and the registers are documented.

The Ark entry (https://ark.intel.com/content/www/us/en/ark/products/84329/intel-ethernet-controller-x550at2.html) still lists "Intel Ethernet Power Management", which describes more or less 802.3az.

Then, the Feature Support Matrix document revision 2.8 (335253-019) just erases EEE completely (which is odd). Reading the Specification Update Revision 2.9 (333717-010) we get the errata moved from "it will have a fix later (2016)" to "Energy Efficient Ethernet (EEE) is not enabled in the X550. The X550 does not negotiate to or transition to EEE mode with a EEE-capable link partner."

Meanwhile the Datasheet has no mention of any issues despite being updated later: Revision 2.6 January 2021 333369-008

So what does this mean in the end? Is the silicon broken that prevents the chip from ever operating for 802.3az or is it an NVM issue (then the question is: Why/Why is it not fixed?). The datasheet just states "Initial EEER.TX_LPI_EN configuration is loaded from NVM", so in theory, it should be possible to enable it? And if it is possible to enable, which does the NVM/driver-Combo not allow for it?

 

Can you please clarify what the state on this is? After all, the Chip is still actively used and 10GBASE-T in itself is draining a lot of energy. Does it really make sense from an environmental standpoint to not support EEE? I could understand if it was an unfixable silicon bug, but why is it not marked clearly in the datasheet, then?

There was a patch to FreeBSD at some point to disable EEE: https://reviews.freebsd.org/D21673
Can you clarify which devices now actually support 802.3az and which ones do not? 

 

Thanks

0 Kudos
1 Solution
Achilles_Intel
Moderator
2,522 Views

Hello hardfault,


Greetings.


The datasheets are the baseline for the documentation, the latest information and addendums to that are the documented in the Spec Update (dated September 2020, page 9). So the spec updates supersede the the datasheets for any discrepancies. The datasheet will not be updated.


In addition, unfortunately, as much as we want to assist you, we will not be able to provide collateral on the FW and on manipulating the NVM binaries.


Let us know if you have further questions or need clarifications. We will reach out after 3 business days should we not receive a response from you.


Thank you and have a nice day.



Best regards,

Achilles M.

Intel Customer Support


View solution in original post

0 Kudos
11 Replies
Achilles_Intel
Moderator
2,938 Views

Hello hardfault,


Thank you for posting in Intel Ethernet Communities.


Please allow us to further check on this and discuss this matter internally. We will provide you with an update within 3 business days.


Let us know if you have questions or need clarifications.


Thank you and have a nice day.



Best regards,

Achilles M.

Intel Customer Support


0 Kudos
Achilles_Intel
Moderator
2,920 Views

Hello hardfault,


Good day.


Please be informed that we are still looking into your inquiry. Please allow us more time to further check on this matter. We will provide you with an update on it within 3 business days.


Thank you for your understanding.



Best regards,

Achilles M.

Intel Customer Support


0 Kudos
Caguicla_Intel
Moderator
2,903 Views

Hello hardfault,


We highly appreciate your kind patience on this request.


Pease see below update from our engineering team and let us know if you have questions or clarifications. 


X550 never enabled EEE and should probably be flagged as de-featured. Due to the age of this product, it will be unlikely be enabled due to significant FW development, validation, and SW support. 


Please accept our sincerest apologies for the inconvenience that this might have caused.


Looking forward to your reply. 


Should there be no response from you, I’ll make sure to reach out after 3 business days.


Best regards,

Crisselle C.

Intel® Customer Support


0 Kudos
hardfault
Novice
2,885 Views

Hi Crisselle

 

Thank you for the answer.
I do realize that Intel "de-featured" the product. However, I'm not sure what you mean by "X550 never enabled EEE". The silicon is still there, no? I don't think Intel would sell a chip and reference registers in the datasheet that do not exist.

According to the referenced commit ( https://reviews.freebsd.org/D21673 ), there are many variations (dev id) for X550 around. My request is to specifically clear up which devices from a hardware/(NVM) perspective physically support EEE. Is changing the firmware/NVM required to enable EEE on X550 or would this just be an issue of writing to a register?
(like is done, e.g. here: https://github.com/migrax/eee-X550)

I do not request the driver team to rewrite the entire driver (although that would be nice, of course ), but just a technical clarification what the hurdles are to patching the source myself and, eventually, submit a patch to enable it.

Also, while being an old chip, X550 is still sold actively and, as you surely know, quite wide-spread.

For that, it would actually be nice to see that Intel and the Environment is not just empty words:

"We aspire to be a global leader in sustainability and enable partners and customers to reduce their environmental and climate impacts through our actions. Our environmental projects and company-wide targets are driving reductions in greenhouse gas emissions, energy use, water use, and waste generation around the world."

Providing EEE to a widespread NIC would actually achieve this goal, replacing NICs (particularly those On-Board with SuperMicro/AsRock Rack boards) would create new electronic waste.

 

To reiterate the questions:

1) Is the current NVM/Hardware-Combo in theory capable of running EEE (not talking about potential bugs / specification deviations, just pure hard "will it try and work if possible?")

2) What are the differences for the different Dev IDs (backplane x550) and do some of those change the answer for 1) ?

 

Cheers
hardfault

0 Kudos
Achilles_Intel
Moderator
2,807 Views

Hello hardfault,


Thank you for the clarification on your inquiry. Please allow us to further discuss this with our engineering team. We will provide you with an update on this matter within 3 business days.


Thank you for your patience and cooperation.



Best regards,

Achilles M.

Intel Customer Support


0 Kudos
Achilles_Intel
Moderator
2,670 Views

Hello hardfault,


Good day.


As much as we want to assist you in this matter, enabling this feature for any of the DevIDs would require FW/NVM development and also driver support. Since this has been defeatured, we may not be able to provide additional support.


The FreeBSD link shared for DevID 15ab is for the X552 PHY, it is not the same as the X550 controller. Please accept our sincerest apologies for the inconvenience however, it was already defeatured so we are unable to support your request.


Let us know if you have further questions or need clarifications. We will reach out after 3 business days should we not receive an update from you.


Thank you and have a nice day.



Best regards,

Achilles M.

Intel Customer Support


0 Kudos
hardfault
Novice
2,620 Views

Hello

 

Thanks for your reply.

"

The FreeBSD link shared for DevID 15ab is for the X552 PHY, it is not the same as the X550 controller. Please accept our sincerest apologies for the inconvenience however, it was already defeatured so we are unable to support your request.

"

Yes, I understand that. I have no issue with the X552 or X553 not supporting EEE as those devices were never advertised with that feature (to the best of my knowledge). However, while that patch claimed to disable EEE for just the X552 and X553, it also does not enable it for X550 (8086:1563).

https://www.intel.com/content/www/us/en/products/sku/88209/intel-ethernet-converged-network-adapter-x550t2/specifications.html

https://cdrdv2.intel.com/v1/dl/getcontent/333369

As of today (2022-03-12), the linked datasheet Revision 2.6 / Jan 21 ( 333369-008 ) still advertises 802.3az EEE for X550-T2 network adapter card. This is very misleading and you probably should adjust this. There are a lot of documents flying around stating conflicting information, mind you, but this is the most accessible document.

hardfault_0-1647103866696.png

 

"
As much as we want to assist you in this matter, enabling this feature for any of the DevIDs would require FW/NVM development and also driver support. Since this has been defeatured, we may not be able to provide additional support.
"

Yeah driver support is about 50 lines of code I can provide easily if that's the problem. After all, the registers are already there. It's not like it's a completely new feature. However, I do not have access to documentation of the NVM beyond what is stated in the datasheet. 

I do not agree with the phrasing "additional support". Essentially, you sell and keep selling a device advertising a capability without the intention of ever supporting said function. That's not additional support, that's the minimum support guaranteed.

It may well be that it was just forgotten to update some documents - I'm not suggesting malicious intent on the side of Intel - but I'm still extremely disappointed in how this is handled. Unless the device is broken / has bugs to work around, I cannot imagine this NVM change taking more than a week of work for someone who knows the chip. Work, mind you, that was initially planned for the release of the X550 and was thus already factored in. I think the "defeaturing" practice is not very customer-friendly.

 

However, I can feel you are unwilling to fix that. Maybe the given link of the Datasheet may convince someone with you that you're still selling the device advertising the features, so it may be worthwhile investing into it, but I expect it's cheaper for you to just adjust the datasheet.

 

In any case: Is there any chance to obtain more detailed documentation about the inner workings of the NIC and/or the firmware image such that I can create a patch for the NVM myself, possibly under NDA? That way, I could get the device working and you could get the work done for free if I were to succeed.

(I know this is grasping for straws and I'm pretty sure I know the answer already, but I still wanted to give it a try)

As you can see, I simply have too many of those chips deployed on boards that I'm not willing to replace in the short run, which is why I'm willing to put quite some work into this.

 

Best

hardfault

0 Kudos
Achilles_Intel
Moderator
2,556 Views

Hello hardfault,


Good day.


Please be informed that we are checking on your latest concern and we will provide you with an update as soon as it is available. However, we cannot guarantee anything. We will provide you with an update no later than 3 business days.


Thank you for your patience and understanding.



Best regards,

Achilles M.

Intel Customer Support


0 Kudos
Achilles_Intel
Moderator
2,523 Views

Hello hardfault,


Greetings.


The datasheets are the baseline for the documentation, the latest information and addendums to that are the documented in the Spec Update (dated September 2020, page 9). So the spec updates supersede the the datasheets for any discrepancies. The datasheet will not be updated.


In addition, unfortunately, as much as we want to assist you, we will not be able to provide collateral on the FW and on manipulating the NVM binaries.


Let us know if you have further questions or need clarifications. We will reach out after 3 business days should we not receive a response from you.


Thank you and have a nice day.



Best regards,

Achilles M.

Intel Customer Support


0 Kudos
hardfault
Novice
2,499 Views

Hello Achilles

Thanks for your reply.

I'm not sure how "The datasheet will not be updated" aligns with the fact that the Datasheet revision is explicitly newer than the spec update and actually lists changes. So it is, in fact, updated, Intel just doesn't bother correcting the information in the datasheet, apparently (especially when it *removes* previously advertised features - what "lucky" coincidence). Linking the errata directly on the product page would be the least Intel could do. 

 

It is disappointing that there is no intention of fixing a feature of an otherwise perfectly good chip, while also denying the ability to fixing it off-vendor. I can understand the intention of protecting IP, but this makes the x550 inelegible where power consumption laws are getting more and more strict.

What really grinds my gears here is that many competitors cards released in 2017 have no issues following this official spec while consuming less than half the power and having a pricetag considerably lower to that of the x550. Yes, they have fewer advertised features, but those vendors also do not defeature them after some time seemingly at random.

Intel used to be expensive, but made up for it by providing good drivers and support.

Well, while disappointed, I cannot say I'm surprised. In any case, thank you @Achilles_Intel and @Caguicla_Intel for your quick replies and information on the topic, 10/10 to you.

 

Best
hardfault

0 Kudos
Achilles_Intel
Moderator
2,409 Views

Hello hardfault,


First and foremost, we do apologize again for the inconvenience this may have caused. We understand your predicament about a feature which did not push through however, it was Intel's decision not to enable it in the end.

 

As for the documentation, we have taken note of your additional feedbacks and rest assured that they will be relayed to concerned department.  

 

We will now be closing the case and if you need any additional information, please submit a new question as this thread will no longer be monitored.


Thank you and have nice day.



Best regards,

Achilles M.

Intel Customer Support


0 Kudos
Reply