Revision: 2.85

September 2012

Specification Update

31

Status:

A1, A2 NoFix

▼ Return to Summary

37. TimeSync: Missing Tx timestamps in SerDes mode

Problem:

When transmitting a TimeSync packet in SerDes mode, there is a probability that the

timestamp will not be sampled in the Tx Timestamp Value registers and thus

TSYNCTXCTL.TXTT will not be set.

There is no issue when using 10/100/1000 BASE-T(Copper) mode.

Implication: Missing timestamps make it difficult for the software to effectively implement the

TimeSync functionality.

Workaround: The software should implement a timeout while waiting for TSYNCTXCTL.TXTT to be set

after transmitting a TimeSync packet. In case no timestamp has been captured, the

software may resend the TimeSync packet until the timestamp capture is successful, as

indicated by TSYNCTXCTL.TXTT being read as 1. The receiving software must be able to

handle these repeated packets.

Status:

A1, A2 NoFix

▼ Return to Summary

38. Virtualization: Dropped Packets When Using VM-to-VM Switching

Problem:

In a virtualized environment using IOV or VMDq, the 82576 supports up to 8 VMs with up

to 2 queues per VM. As specified in the datasheet, when a packet is switched between

VMs, RSS is not used for Rx queue selection within a VM.

However, there is also no default queue defined. Instead, the Tx queue number (0 or 1)

within the source VM is used as the Rx queue number within the destination VM. If a

packet is provided to Tx Queue 1 within a VM and it is switched to a VM in which only one

queue is used and therefore Rx Queue 1 is not defined, the packet is dropped.

Implication: There might be no communication between VMs on the same 82576 device.

This only applies to a virtualized environment using IOV or VMDq.

Workaround: Use only one Tx queue per VM.

OR

Ensure that two Rx queues are defined on all VMs.

The first option above is implemented in Intel igb/igbvf 2.6.36 kernel drivers.

Status:

A1, A2 NoFix

▼ Return to Summary

Problem:

The 82576 should provide a data out hold time of 50 ns on the SFPx_I2C_DATA pins. The

actual hold time is about 16 ns.

Implication: Timing specification violation. There have been no reports of failures resulting from this

timing. Note that the data input hold time required is zero, so the provided output hold

time should be more than enough as long as the I2C CLK and DATA signals are

reasonably matched on the board.

Workaround: NA