[DPDK/ethdev Bug 1961] Rx timestamp no rollover indication

[bugzilla@dpdk.org]

http://bugs.dpdk.org/show_bug.cgi?id=1961

            Bug ID: 1961
           Summary: Rx timestamp no rollover indication
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: stephen@networkplumber.org
  Target Milestone: ---

Each PMD has its own internal hardware counter for receive timestamps. But this
counter can and will roll over so using it for things like packet capture is
impossible with current API's. Need something more complete and richer than
existing read_clock API.

AI analysis showed:

  The Rollover Problem

  Hardware timestamps typically use a fixed-width counter that wraps around:
  - 32-bit counter at 1GHz = rollover every ~4.3 seconds
  - 40-bit counter at 1GHz = rollover every ~18 minutes
  - 48-bit counter at 1GHz = rollover every ~3.3 days

  Without knowing the counter width, you can't detect or handle rollovers
correctly!

  Current API Limitations

  The read_clock operation only returns:
  int rte_eth_read_clock(uint16_t port_id, uint64_t *clock);

  This doesn't tell you:
  1. Counter bit width - Is it 32, 40, 48, or 64 bits?
  2. Rollover period - How often does it wrap?
  3. Clock frequency - Needed to calculate rollover time
  4. Timestamp format - Raw counter vs scaled nanoseconds

  What's Needed for Robust Packet Capture

  struct rte_eth_timestamp_info {
      uint64_t frequency_hz;     /* Clock frequency */
      uint8_t  counter_bits;     /* Actual counter width (32/40/48/64) */
      uint64_t rollover_nsec;    /* Rollover period in nanoseconds */
      uint64_t current_value;    /* Current counter reading */
      enum {
          RTE_TS_FORMAT_RAW_COUNTER,
          RTE_TS_FORMAT_NANOSECONDS,
          RTE_TS_FORMAT_PTP_TIME
      } format;
  };

  Real-World Impact on Packet Capture

  Without rollover information, packet capture tools face impossible choices:

  Problem 1: Undetected Rollover

  /* Packet 1: timestamp = 0xFFFFFFF0 (near max for 32-bit) */
  /* Packet 2: timestamp = 0x00000010 (rolled over) */
  /* Without knowing it's 32-bit, this looks like time went backwards! */

  Problem 2: Incorrect Delta Calculation

  /* If you assume 64-bit but it's actually 40-bit: */
  delta = pkt2_ts - pkt1_ts;  /* Huge negative or wrong positive value */

  Problem 3: Can't Maintain Absolute Time

  /* Need to track rollovers to maintain wall-clock correlation: */
  absolute_time = (rollover_count * rollover_period) + current_timestamp;
  /* But without knowing rollover_period, this is impossible */

  Specific Driver Issues

  Looking at actual implementations:

  - Intel E810 (ice): 40-bit counter @ 812.5MHz = ~22 minute rollover
  - Intel 700 series (i40e/iavf): 48-bit counter, but what frequency?
  - Mellanox: Various counter widths depending on firmware
  - Broadcom: Often 48-bit, but frequency varies

  None of this is exposed through the API!

  Proposed API Enhancement

  /* Better API for timestamp capabilities */
  int rte_eth_timestamp_info_get(uint16_t port_id, 
                                  struct rte_eth_timestamp_info *info);

  /* Helper to handle rollover */
  uint64_t rte_eth_timestamp_normalize(uint16_t port_id,
                                       uint64_t hw_timestamp,
                                       uint64_t *rollover_count);

  This would let packet capture tools:
  1. Detect and handle rollovers correctly
  2. Maintain accurate absolute timestamps across rollovers
  3. Generate proper pcap timestamps even for long captures
  4. Warn users about rollover limitations

-- 
You are receiving this mail because:
You are the assignee for the bug.