From: Manfred Schlaegl <manfred.schlaegl@gmx.at>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
netdev@vger.kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org, mkl@pengutronix.de
Subject: Re: [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv
Date: Mon, 22 Jun 2015 12:10:14 +0200 [thread overview]
Message-ID: <5587DF06.3010509@gmx.at> (raw)
In-Reply-To: <1434905444-11438-1-git-send-email-socketcan@hartkopp.net>
Hello!
On 2015-06-21 18:50, Oliver Hartkopp wrote:
> As reported by Manfred Schlaegl here
>
> http://marc.info/?l=linux-netdev&m=143482089824232&w=2
>
> commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for
> overlapping CAN filters" requires the skb->tstamp to be set to check for
> identical CAN skbs.
>
> As net timestamping is influenced by several players (netstamp_needed and
> netdev_tstamp_prequeue) Manfred missed a proper timestamp which leads to
> CAN frame loss.
>
> As skb timestamping became now mandatory for CAN related skbs this patch
> makes sure that received CAN skbs always have a proper timestamp set.
> Maybe there's a better solution in the future but this patch fixes the
> CAN frame loss so far.
>
I'm not sure, but maybe this patch (and also my original one) opens a new potential issue with timestamps.
If the timestamp is set at allocation time, this cancels setting the timestamp at delivery (by net_timestamp_check in, for example, netif_receive_skb_internal.) -> So it changes the behavior of timestamping (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/timestamping.txt?id=b953c0d234bc72e8489d3bf51a276c5c4ec85345) generally.
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.
What do you thing about this?
best regards,
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
WARNING: multiple messages have this Message-ID (diff)
From: Manfred Schlaegl <manfred.schlaegl@gmx.at>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
netdev@vger.kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org, mkl@pengutronix.de
Subject: Re: [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv
Date: Mon, 22 Jun 2015 12:10:14 +0200 [thread overview]
Message-ID: <5587DF06.3010509@gmx.at> (raw)
In-Reply-To: <1434905444-11438-1-git-send-email-socketcan@hartkopp.net>
Hello!
On 2015-06-21 18:50, Oliver Hartkopp wrote:
> As reported by Manfred Schlaegl here
>
> http://marc.info/?l=linux-netdev&m=143482089824232&w=2
>
> commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for
> overlapping CAN filters" requires the skb->tstamp to be set to check for
> identical CAN skbs.
>
> As net timestamping is influenced by several players (netstamp_needed and
> netdev_tstamp_prequeue) Manfred missed a proper timestamp which leads to
> CAN frame loss.
>
> As skb timestamping became now mandatory for CAN related skbs this patch
> makes sure that received CAN skbs always have a proper timestamp set.
> Maybe there's a better solution in the future but this patch fixes the
> CAN frame loss so far.
>
I'm not sure, but maybe this patch (and also my original one) opens a new potential issue with timestamps.
If the timestamp is set at allocation time, this cancels setting the timestamp at delivery (by net_timestamp_check in, for example, netif_receive_skb_internal.) -> So it changes the behavior of timestamping (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/timestamping.txt?id=b953c0d234bc72e8489d3bf51a276c5c4ec85345) generally.
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.
What do you thing about this?
best regards,
Manfred
next prev parent reply other threads:[~2015-06-22 10:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-21 16:50 [PATCH - regression 4.1-rc8] can: fix loss of CAN frames in raw_rcv Oliver Hartkopp
2015-06-21 16:50 ` Oliver Hartkopp
2015-06-21 16:57 ` Marc Kleine-Budde
2015-06-21 17:10 ` Oliver Hartkopp
2015-06-21 17:10 ` Oliver Hartkopp
2015-06-22 10:10 ` Manfred Schlaegl [this message]
2015-06-22 10:10 ` Manfred Schlaegl
2015-06-22 10:34 ` Oliver Hartkopp
2015-06-22 10:34 ` Oliver Hartkopp
2015-06-22 11:49 ` Manfred Schlaegl
2015-06-22 11:49 ` Manfred Schlaegl
2015-06-22 15:09 ` Oliver Hartkopp
2015-06-22 15:09 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5587DF06.3010509@gmx.at \
--to=manfred.schlaegl@gmx.at \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.