[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <55882529.7030605@hartkopp.net>
Date: Mon, 22 Jun 2015 17:09:29 +0200
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Manfred Schlaegl <manfred.schlaegl@....at>, netdev@...r.kernel.org,
davem@...emloft.net, linux-kernel@...r.kernel.org,
mkl@...gutronix.de
Subject: Re: [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv
On 22.06.2015 13:49, Manfred Schlaegl wrote:
> On 2015-06-22 12:34, Oliver Hartkopp wrote:
>> On 22.06.2015 12:10, Manfred Schlaegl wrote:
>>> Hypothetical example: If timestamping is enabled by the user and there is a significant delay between allocation and delivery of a skb (early allocation in driver or something) the timestamp does not reflect the reception time anymore.
>>
>> The change only affects CAN skbs.
>> These skbs are allocated at CAN frame reception time, filled with content and then sent to the network layer.
>>
>> AFAICS the timestamp becomes more precise for CAN related skbs.
>> I did not see any case of 'early allocation' in linux/drivers/net/can, did you?
>
> No, I also did not find this case in current driver implementations -- because of that I gave the hypothetical example.
> I just was worried about that this may be a potential latent issue for future driver implementations and wanted to indicate this.
>
> But I trust your expertise, so if you are fine with it, I'm too. ;-)
I don't claim to be 'an expert' :-)
But our usual use-case is CAN logging which enables the timestamping on all
CAN interfaces anyway - without any problems.
As the timestamp is calculated only once this patch moves the timestamp
creation closer to the CAN frame arrival time - so latency finally decreases.
Best regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists