On 6/20/19 1:32 PM, Patel, Vedang wrote:
>
> Ahh.. that’s clearly a false statement. Skb->tstamp is cleared so
> that it is not interpreted as a software timestamp when trying to
> send the Hardware TX timestamp to the userspace. I will rephrase the
> commit message in the next version.
>
> S
> On Jun 20, 2019, at 10:07 AM, Eric Dumazet wrote:
>
>
>
> On 6/20/19 9:49 AM, Patel, Vedang wrote:
>>
>>
>>> On Jun 20, 2019, at 3:47 AM, Eric Dumazet wrote:
>>>
>>>
>>>
>>> On 6/19/19 10:40 AM, Vedang Patel wrote:
skb->tstamp is being used at multiple places. On the transmit sid
On 6/20/19 9:49 AM, Patel, Vedang wrote:
>
>
>> On Jun 20, 2019, at 3:47 AM, Eric Dumazet wrote:
>>
>>
>>
>> On 6/19/19 10:40 AM, Vedang Patel wrote:
>>> skb->tstamp is being used at multiple places. On the transmit side, it
>>> is used to determine the launchtime of the packet. It is also us
> On Jun 20, 2019, at 3:47 AM, Eric Dumazet wrote:
>
>
>
> On 6/19/19 10:40 AM, Vedang Patel wrote:
>> skb->tstamp is being used at multiple places. On the transmit side, it
>> is used to determine the launchtime of the packet. It is also used to
>> determine the software timestamp after the
On 6/19/19 10:40 AM, Vedang Patel wrote:
> skb->tstamp is being used at multiple places. On the transmit side, it
> is used to determine the launchtime of the packet. It is also used to
> determine the software timestamp after the packet has been transmitted.
>
> So, clear out the tstamp value
skb->tstamp is being used at multiple places. On the transmit side, it
is used to determine the launchtime of the packet. It is also used to
determine the software timestamp after the packet has been transmitted.
So, clear out the tstamp value after it has been read so that we do not
report false
