WG82574L S LBA8 Intel, WG82574L S LBA8 Datasheet - Page 227

• Manufacturer Part Number: WG82574L S LBA8
• Manufacturer: Intel

Specifications of WG82574L S LBA8

• Operating Supply Voltage (typ): 3.3V
• Operating Temp Range: 0C to 85C
• Operating Temperature Classification: Commercial
• Mounting: Surface Mount
• Pin Count: 64
• Lead Free Status / RoHS Status: Compliant

System Manageability—82574 GbE Controller
8.9.5
8.9.6
Unable to Transmit Packets from the MC
If the MC has been transmitting and receiving data without issue for a period of time
and then begins to receive NACKs from the 82574 when it attempts to write a packet,
the problem is most likely due to the fact that the buffers internal to the 82574 are full
of data that has been received from the network; however, has yet to be read by the
MC.
Being an embedded device, the 82574 has limited buffers that it shares for receiving
and transmitting data. If a MC does not keep the incoming data read, the 82574 can be
filled up, which does not enable the MC to transmit anymore data, resulting in NACKs.
If this situation occurs, the recommended solution is to have the MC issue a Receive
Enable command to disable anymore incoming data, go read all the data from the
82574 and then use the Receive Enable command to enable incoming data once again.
SMBus Fragment Size
The SMBus specification indicates a maximum SMBus transaction size of 32 bytes. Most
of the data passed between the 82574 and the MC over the SMBus is RMCP/RMCP+
traffic, which by its very nature (UDP traffic) is significantly larger than 32 bytes in
length, thus requiring multiple SMBus transactions to move a packet from the 82574 to
the MC or to send a packet from the MC to the 82574.
Recognizing this bottleneck, the 82574 can handle up to 240 bytes of data within a
single transaction. This is a configurable setting within the NVM.
The default value in the NVM images is 32, per the SMBus specification. If performance
is an issue, it is recommended that you increase this size.
During the initialization phase, the firmware within the 82574 allocates buffers based
upon the SMBus fragment size setting within the NVM. The 82574 firmware has a finite
amount of RAM for its use, as such the larger the SMBus fragment size, the fewer
buffers it can allocate. As such, the MC implementation must take care to send data
over the SMBus in an efficient way.
For example, the 82574 firmware has 3 KB of RAM it can use for buffering SMBus
fragments. If the SMBus fragment size is 32 bytes then the firmware could allocate 96
buffers of size 32 bytes each. As a result, the MC could then send a large packet of data
(such as KVM) that is 800 bytes in size in 25 fragments of size 32 bytes apiece.
However, this might not be the most efficient way because the MC must break the 800
bytes of data into 25 fragments and send each one at a time.
If the SMBus fragment size is changed to 240 bytes, the 82574 firmware can create 12
buffers of 240 bytes each to receive SMBus fragments. The MC can now send that same
800 bytes of KVM data in only four fragments, which is much more efficient.
The problem of changing the SMBus fragment size in the NVM is if the MC does not also
reflect this change. If a programmer changes the SMBus fragment size in the 82574 to
240 bytes and then wants to send 800 bytes of KVM data, the MC can still only send the
data in 32 byte fragments. As a result, the firmware runs out of memory.
This is because the 82574 firmware created the 12 buffers of 240 bytes each for
fragments, however the MC is only sending fragments of size 32 bytes. This results in a
memory waste of 208 bytes per fragment in this case, and when the MC attempts to
send more than 12 fragments in a single transaction, the 82574 NACKs the SMBus
transaction due to not enough memory to store the KVM data.
227