[Intel-wired-lan] [PATCH v3 1/9] igc: Fix igc_ptp_rx_pktstamp()

[Guedes, Andre]

> On Nov 4, 2020, at 2:26 PM, Fijalkowski, Maciej <maciej.fijalkowski at intel.com> wrote:
> 
>>>> 
>>>> +     /* Adjust timestamp for the RX latency based on link speed */
>>>> +     switch (adapter->link_speed) {
>>>> +     case SPEED_10:
>>>> +             adjust = IGC_I225_RX_LATENCY_10;
>>>> +             break;
>>>> +     case SPEED_100:
>>>> +             adjust = IGC_I225_RX_LATENCY_100;
>>>> +             break;
>>>> +     case SPEED_1000:
>>>> +             adjust = IGC_I225_RX_LATENCY_1000;
>>>> +             break;
>>>> +     case SPEED_2500:
>>>> +             adjust = IGC_I225_RX_LATENCY_2500;
>>>> +             break;
>>>> +     default:
>>>> +             adjust = 0;
>>>> +             netdev_warn_once(adapter->netdev, "Imprecise timestamp\n");
>>> 
>>> How is timestamp related to link speed? I mean, this warning is telling me
>>> that there is something wrong with the timestamp that hw put onto frame,
>>> not that link speed is cranky.
>> 
>> The timestamp is sampled at the beginning of the packet. Although the timestamp
>> logic is located as close as possible to the PHY interface, there is a latency
>> between the moment the PHY received the first bit of the packet and the moment
>> the timestamp logic samples. That latency depends on the link speed and is
>> specified in the datasheet so software can adjust it.
> 
> Thanks for that explanation! I meant that warning should say something
> like "wrong link speed, can not adjust timestamp", but OTOH I have a
> feeling that all of the speeds that this HW supports are handled in this
> switch statement, so probably arguing about that warning is pointless? :)

For TSN use cases, timestamp precision is very important. If, for any reason, adapter->link_speed is off, we want to at least log that information.