Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 21 Nov 2020 17:53:24 -0800
From:   Richard Cochran <richardcochran@gmail.com>
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Tristram.Ha@microchip.com, ceggers@arri.de, kuba@kernel.org,
        andrew@lunn.ch, robh+dt@kernel.org, vivien.didelot@gmail.com,
        davem@davemloft.net, kurt.kanzenbach@linutronix.de,
        george.mccollister@gmail.com, marex@denx.de,
        helmut.grohne@intenta.de, pbarker@konsulko.com,
        Codrin.Ciubotariu@microchip.com, Woojung.Huh@microchip.com,
        UNGLinuxDriver@microchip.com, netdev@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v3 00/12] net: dsa: microchip: PTP support for
 KSZ956x
Message-ID: <20201122015324.GB997@hoboy.vegasvil.org>
References: <20201118203013.5077-1-ceggers@arri.de>
 <20201118234018.jltisnhjesddt6kf@skbuf>
 <2452899.Bt8PnbAPR0@n95hx1g2>
 <BYAPR11MB35582F880B533EB2EE0CDD1DECE00@BYAPR11MB3558.namprd11.prod.outlook.com>
 <20201121012611.r6h5zpd32pypczg3@skbuf>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201121012611.r6h5zpd32pypczg3@skbuf>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Sat, Nov 21, 2020 at 03:26:11AM +0200, Vladimir Oltean wrote:
> On Thu, Nov 19, 2020 at 06:51:15PM +0000, Tristram.Ha@microchip.com wrote:

> > I think the right implementation is for the driver to remember this receive timestamp
> > of Pdelay_Req and puts it in the tail tag when it sees a 1-step Pdelay_Resp is sent.

As long as this is transparent to user space, it could work.  Remember
that user space simply copies the correction field from the Request
into the Response.  If the driver correctly accumulates the turnaround
time into the correction field of the response, then all is well.
 
> I have mixed feelings about this. IIUC, you're saying "let's implement a
> fixed-size FIFO of RX timestamps of Pdelay_Req messages, and let's match
> them on TX to Pdelay_Resp messages, by {sequenceId, domainNumber}."
> 
> But how deep should we make that FIFO? I.e. how many Pdelay_Req messages
> should we expect before the user space will inject back a Pdelay_Resp
> for transmission?

Good question.  Normally you would expect just one Request pending at
any one time, but nothing guarantees that, and so the driver would
have to match the Req/Resp exactly and deal with rogue/buggy requests
and responses.

Thanks,
Richard