[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130417102218.GA13873@netboy>
Date: Wed, 17 Apr 2013 12:22:18 +0200
From: Richard Cochran <richardcochran@...il.com>
To: Willem de Bruijn <willemb@...gle.com>
Cc: Paul Chavent <Paul.Chavent@...ra.fr>,
Daniel Borkmann <dborkman@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
daniel.borkmann@....ee.ethz.ch, xemul@...allels.com,
ebiederm@...ssion.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net-packet: tx timestamping on tpacket ring
On Mon, Apr 15, 2013 at 12:59:26PM -0400, Willem de Bruijn wrote:
>
> If I understand correctly, the problem that Richard refers to is that
> when one socket requests rx timestamping, all rx skbuffs have to be
> timestamped as it is not known early in the datapath to which socket
> they will be enqueued. As a result, the timestamps in skbuffs depend
> on the preferences of other active sockets. Correct me if I'm wrong.
No, that is not it.
Hardware time stamping needs to be globally enabled at the driver
level using the SIOCSHWTSTAMP [1] ioctl. The hardware has various
different abilities, usually one of:
- no time stamping
- some subset of PTP packets
- all packets
So depending on the mode, not all packets will receive a time
stamp. In addition, some of the hardware can only time stamp one
packet at a time. Furthermore, time stamps can get dropped in high
traffic situations.
The code in af_packet.c unconditionally delivers some sort of time
stamp, with an inexplicable fall back to gettimeofday. Thus, the user
space has no way of knowing what is being reported in the time stamp.
Thanks,
Richard
1. See Documentation/networking/timestamping.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists