All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"gospo@redhat.com" <gospo@redhat.com>,
	"sassmann@redhat.com" <sassmann@redhat.com>
Subject: Re: [net-next 06/12] ixgbe: Hardware Timestamping + PTP Hardware Clock (PHC)
Date: Mon, 14 May 2012 10:28:26 -0700	[thread overview]
Message-ID: <4FB140BA.3070700@intel.com> (raw)
In-Reply-To: <20120512053458.GC2190@netboy.at.omicron.at>

On 05/11/2012 10:34 PM, Richard Cochran wrote:
> On Fri, May 11, 2012 at 07:23:44PM +0000, Keller, Jacob E wrote:
>>
>>
>> I believe this very rare case might be possible, but I don't think
>> that checking the ptp seqid will fix anything. In normal cases,
>> hardware latches Rx packet timestamp, then the ptp packet goes into
>> the queue and we process it shortly after. Before we process that
>> packet there will never be another packet in the queue that needs a
>> timestamp. We know this because the hardware stops timestamping
>> until we unlatch the RX registers. This should mean we don't need to
>> check the sequence ID, and spending time doing it would never fix
>> the issue you are talking about.
>>
>> The issue is for when a packet is timestamped and then never reaches
>> the queue. Then the rx stamp registers are locked for good, because
>> we never clear them, and hardware would never timestamp another
>> receive packet. I don't know a good solution to this, except to
>> clear the registers periodically. Do you have any suggestions?
>
> Well, one solution would be to check every received packet with the
> BPF in ptp_classify.h (whenever Rx time stamping is enabled).
>
> When the driver finds an event packet in the Rx queue, and
> TSYNCRXCTL[RXTT] is set, it reads out the time stamp along with
> RXSATRL/H. If the fields match, then add the time stamp to the skb.
>
> [ Or perhaps instead of using RXSATRL/H, just use the descriptor bit.
>    If *not* set, then the time stamp does not belong to this packet. ]
>
> HTH,
> Richard

Ok, this sounds like a good plan. Considering that the device already 
doesn't allow timestamping of other types of packets, so it doesn't need 
to be general purpose.

Am I correct in thinking all I need to do is check the type and if it 
matches the currently configured rx timestamp mode, then double check 
the bit for whether a timestamp is available, and whether the descriptor 
had a timestamp bit enabled?

Thanks

- Jake

  reply	other threads:[~2012-05-14 17:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-10  6:46 [net-next 00/12][pull request] Intel Wired LAN Driver Updates Jeff Kirsher
2012-05-10  6:46 ` [net-next 01/12] igb: output register's information related to RX/TX queue[4-15] Jeff Kirsher
2012-05-10  6:46 ` [net-next 02/12] ixgbe: Exit on error case in VF message processing Jeff Kirsher
2012-05-10  6:46 ` [net-next 03/12] ixgbe: Clean up priority based flow control Jeff Kirsher
2012-05-10  6:46 ` [net-next 04/12] ixgbe: Set Drop_EN bit when multiple Rx queues are present w/o " Jeff Kirsher
2012-05-10  6:46 ` [net-next 05/12] ixgbe: Fix bogus error message Jeff Kirsher
2012-05-10  6:46 ` [net-next 06/12] ixgbe: Hardware Timestamping + PTP Hardware Clock (PHC) Jeff Kirsher
2012-05-10 14:11   ` Richard Cochran
2012-05-10 21:53     ` Keller, Jacob E
2012-05-11  5:15       ` Richard Cochran
2012-05-11 18:05         ` Keller, Jacob E
2012-05-11 19:23         ` Keller, Jacob E
2012-05-12  5:34           ` Richard Cochran
2012-05-14 17:28             ` Jacob Keller [this message]
2012-05-14 22:42             ` Jacob Keller
2012-05-15  5:32               ` Richard Cochran
2012-05-11 19:34         ` Keller, Jacob E
2012-05-12  5:24           ` Richard Cochran
2012-05-10  6:46 ` [net-next 07/12] ixgbe: Enable timesync clock-out feature for PPS support on X540 Jeff Kirsher
2012-05-10 14:17   ` Richard Cochran
2012-05-10 21:54     ` Keller, Jacob E
2012-05-11  5:36       ` Richard Cochran
2012-05-11 18:09         ` Keller, Jacob E
2012-05-10 22:08     ` Keller, Jacob E
2012-05-11  5:40       ` Richard Cochran
2012-05-11 18:10         ` Keller, Jacob E
2012-05-10  6:46 ` [net-next 08/12] ixgbe: correct disable_rx_buff timeout Jeff Kirsher
2012-05-10  6:46 ` [net-next 09/12] ixgbe: add support for get_ts_info Jeff Kirsher
2012-05-10  6:46 ` [net-next 10/12] ixgbe: support software timestamping Jeff Kirsher
2012-05-10  6:46 ` [net-next 11/12] ixgbe: cleanup the hwmon function calls Jeff Kirsher
2012-05-10  6:46 ` [net-next 12/12] ixgbe: update version number Jeff Kirsher
2012-05-11  3:18 ` [net-next 00/12][pull request] Intel Wired LAN Driver Updates 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=4FB140BA.3070700@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=davem@davemloft.net \
    --cc=gospo@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=sassmann@redhat.com \
    /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.