netdev - RE: [net-next 07/12] ixgbe: Enable timesync clock-out feature for PPS support on X540

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <02874ECE860811409154E81DA85FBB5807794293@ORSMSX105.amr.corp.intel.com>
Date:	Thu, 10 May 2012 22:08:44 +0000
From:	"Keller, Jacob E" <jacob.e.keller@...el.com>
To:	"Keller, Jacob E" <jacob.e.keller@...el.com>,
	Richard Cochran <richardcochran@...il.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>
Subject: RE: [net-next 07/12] ixgbe: Enable timesync clock-out feature for
 PPS support on X540

> -----Original Message-----
> From: Keller, Jacob E
> Sent: Thursday, May 10, 2012 2:55 PM
> To: 'Richard Cochran'; Kirsher, Jeffrey T
> Cc: davem@...emloft.net; netdev@...r.kernel.org; gospo@...hat.com;
> sassmann@...hat.com
> Subject: RE: [net-next 07/12] ixgbe: Enable timesync clock-out feature for PPS
> support on X540
> 
> 
> 
> > -----Original Message-----
> > From: Richard Cochran [mailto:richardcochran@...il.com]
> > Sent: Thursday, May 10, 2012 7:17 AM
> > To: Kirsher, Jeffrey T
> > Cc: davem@...emloft.net; Keller, Jacob E; netdev@...r.kernel.org;
> > gospo@...hat.com; sassmann@...hat.com
> > Subject: Re: [net-next 07/12] ixgbe: Enable timesync clock-out feature
> > for PPS support on X540
> >
> > On Wed, May 09, 2012 at 11:46:48PM -0700, Jeff Kirsher wrote:
> > > From: Jacob E Keller <jacob.e.keller@...el.com>
> > >
> > > This patch enables the PPS system in the PHC framework, by enabling
> > > the clock-out feature on the X540 device. Causes the SDP0 to be set
> > > as a 1Hz clock. Also configures the timesync interrupt cause in
> > > order to report each pulse to the PPS via the PHC framework, which
> > > can be used for general system clock synchronization. (This allows a
> > > stable method for tuning the general system time via the on-board
> > > SYSTIM register based clock.)
> >
> > Glad to see the PPS output and internal PPS support.
> >
> > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > index 9a83c40..1ad6e2a 100644
> > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> >
> > ...
> >
> > >  /**
> > > + * ixgbe_ptp_check_pps_event
> > > + * @adapter - the private adapter structure
> > > + * @eicr - the interrupt cause register value
> > > + *
> > > + * This function is called by the interrupt routine when checking
> > > +for
> > > + * interrupts. It will check and handle a pps event.
> > > + */
> > > +void ixgbe_ptp_check_pps_event(struct ixgbe_adapter *adapter, u32
> > > +eicr) {
> > > +	struct ixgbe_hw *hw = &adapter->hw;
> > > +	struct ptp_clock_event event;
> > > +
> > > +	event.type = PTP_CLOCK_PPS;
> > > +
> > > +	/* Make sure ptp clock is valid, and PPS event enabled */
> > > +	if (!adapter->ptp_clock ||
> > > +	    !(adapter->flags2 & IXGBE_FLAG2_PTP_PPS_ENABLED))
> > > +		return;
> > > +
> > > +	switch (hw->mac.type) {
> > > +	case ixgbe_mac_X540:
> > > +		if (eicr & IXGBE_EICR_TIMESYNC)
> >
> > Since this function is called in every interrupt, I would check this
> > flag first thing.
> >
> Not sure what you mean? Check this before checking the other interrupts?
> I can do that.
> 
> > > +			ptp_clock_event(adapter->ptp_clock, &event);
> > > +		break;
> > > +	default:
> > > +		break;
> > > +	}
> > > +}
> >
> > Thanks,
> > Richard

Oops stupid mail program sent that on accident. Anyways: I think you might be
right, Richard. We don't read those timestamp values unless the stat err bit
for timestamps is set on the descriptor. But I am not sure what happens when the
tjmestamped packet is dropped off the end of the ring. What would you propose
here? How can we detect if this timestamp doesn't match the packet? I can look
into using the extra hardware features for matching timestamps. That might be
a more useful, in that it would help prevent this case.

- Jake
--
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