From: Eric Dumazet <dada1@cosmosbay.com>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: "David S. Miller" <davem@davemloft.net>, Andi Kleen <ak@suse.de>,
netdev@vger.kernel.org
Subject: Re: af_packet: don't enable global timestamps
Date: Tue, 4 Sep 2007 09:59:58 +0200 [thread overview]
Message-ID: <20070904095958.53c86337.dada1@cosmosbay.com> (raw)
In-Reply-To: <20070904063525.060e7a77@oldman>
On Tue, 4 Sep 2007 06:35:25 +0100
Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> Andi mentioned he did something like this already, but never
> submitted it.
>
> The dhcp client application uses AF_PACKET with a packet filter to
> receive data. The application doesn't even use timestamps, but because
> the AF_PACKET API has timestamps, they get turned on globally which
> causes an expensive time of day lookup for every packet received
> on any system that uses the standard DHCP client.
>
> The fix is to not enable the timestamp (but use if if available).
> This causes the time lookup to only occur on those packets
> that are destined for the AF_PACKET socket.
> The timestamping occurs after packet filtering
> so all packets dropped by filtering to not cause a clock call.
>
> The one downside of this a a few microseconds additional delay
> added from the normal timestamping location (netif_rx) until the
> receive callback in AF_PACKET. But since the offset is fairly consistent
> it should not upset applications that do want really use timestamps,
> like wireshark.
This patch seems the correct fix for this longstanding problem.
Please note that if wireshark/tcpdump processes really want precise timestamps,
they still can ask this by using setsockopt(SO_TIMESTAMP or SO_TIMESTAMPNS) on their private socket.
(We already know that running a sniffer has a cost anyway)
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
>
> --- a/net/packet/af_packet.c 2007-07-23 09:31:26.000000000 +0100
> +++ b/net/packet/af_packet.c 2007-09-03 14:55:00.000000000 +0100
> @@ -640,11 +640,10 @@ static int tpacket_rcv(struct sk_buff *s
> h->tp_snaplen = snaplen;
> h->tp_mac = macoff;
> h->tp_net = netoff;
> - if (skb->tstamp.tv64 == 0) {
> - __net_timestamp(skb);
> - sock_enable_timestamp(sk);
> - }
> - tv = ktime_to_timeval(skb->tstamp);
> + if (skb->tstamp.tv64)
> + tv = ktime_to_timeval(skb->tstamp);
> + else
> + do_gettimeofday(&tv);
> h->tp_sec = tv.tv_sec;
> h->tp_usec = tv.tv_usec;
>
next prev parent reply other threads:[~2007-09-04 8:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-04 5:35 af_packet: don't enable global timestamps Stephen Hemminger
2007-09-04 7:59 ` Eric Dumazet [this message]
2007-09-06 12:56 ` David Miller
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=20070904095958.53c86337.dada1@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=ak@suse.de \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).