netdev - RE: [net-next, v2, 7/7] enetc: support PTP domain timestamp conversion

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: <DB7PR04MB5017313658AC779FBA59843DF83F9@DB7PR04MB5017.eurprd04.prod.outlook.com>
Date:   Mon, 31 May 2021 11:31:24 +0000
From:   "Y.b. Lu" <yangbo.lu@....com>
To:     Richard Cochran <richardcochran@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Claudiu Manoil <claudiu.manoil@....com>
Subject: RE: [net-next, v2, 7/7] enetc: support PTP domain timestamp
 conversion

> -----Original Message-----
> From: Y.b. Lu <yangbo.lu@....com>
> Sent: 2021年5月31日 18:52
> To: Richard Cochran <richardcochran@...il.com>; Claudiu Manoil
> <claudiu.manoil@....com>
> Cc: netdev@...r.kernel.org; David S . Miller <davem@...emloft.net>; Jakub
> Kicinski <kuba@...nel.org>
> Subject: RE: [net-next, v2, 7/7] enetc: support PTP domain timestamp
> conversion
> 
> Hi Claudiu and Richard,
> 
> > -----Original Message-----
> > From: Richard Cochran <richardcochran@...il.com>
> > Sent: 2021年5月25日 20:37
> > To: Y.b. Lu <yangbo.lu@....com>
> > Cc: netdev@...r.kernel.org; David S . Miller <davem@...emloft.net>;
> > Claudiu Manoil <claudiu.manoil@....com>; Jakub Kicinski
> > <kuba@...nel.org>
> > Subject: Re: [net-next, v2, 7/7] enetc: support PTP domain timestamp
> > conversion
> >
> > On Fri, May 21, 2021 at 12:36:19PM +0800, Yangbo Lu wrote:
> >
> > > @@ -472,13 +473,36 @@ static void enetc_get_tx_tstamp(struct
> > > enetc_hw
> > *hw, union enetc_tx_bd *txbd,
> > >  	*tstamp = (u64)hi << 32 | tstamp_lo;  }
> > >
> > > -static void enetc_tstamp_tx(struct sk_buff *skb, u64 tstamp)
> > > +static int enetc_ptp_parse_domain(struct sk_buff *skb, u8 *domain) {
> > > +	unsigned int ptp_class;
> > > +	struct ptp_header *hdr;
> > > +
> > > +	ptp_class = ptp_classify_raw(skb);
> > > +	if (ptp_class == PTP_CLASS_NONE)
> > > +		return -EINVAL;
> > > +
> > > +	hdr = ptp_parse_header(skb, ptp_class);
> > > +	if (!hdr)
> > > +		return -EINVAL;
> > > +
> > > +	*domain = hdr->domain_number;
> >
> > This is really clunky.  We do NOT want to have drivers starting to
> > handle the PTP.  That is the job of the user space stack.
> >
> > Instead, the conversion from raw time stamp to vclock time stamp
> > should happen in the core infrastructure.  That way, no driver hacks
> > will be needed, and it will "just work" everywhere.
> 
> That's perfect way.
> 
> >
> > We need a way to associate a given socket with a particular vclock.
> > Perhaps we can extend the SO_TIMESTAMPING API to allow that.
> 
> How about adding a flag SOF_TIMESTAMPING_BIND_PHC, and redefining the
> data passing by setsockopt like,
> 
> struct timestamping {
>        int flags;
>        u8 hwtstamp_phc; /*phc index */
> };
> 
> The sock could have a new member sk_hwtstamp_phc to record it.

But one problem is how to check the phc availability for current network interface.
If user can make sure it's using right phc device for current network interface, that's no problem.
Otherwise, timestamp will be token on wrong phc...

> 
> >
> > > +	return 0;
> > > +}
> >
> > Thanks,
> > Richard