[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220121145035.z4yv2qsub5mr7ljs@skbuf>
Date: Fri, 21 Jan 2022 14:50:36 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Richard Cochran <richardcochran@...il.com>
CC: Andrew Lunn <andrew@...n.ch>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Grygorii Strashko <grygorii.strashko@...com>,
Jakub Kicinski <kuba@...nel.org>,
Joakim Zhang <qiangqing.zhang@....com>,
Kurt Kanzenbach <kurt@...utronix.de>,
Miroslav Lichvar <mlichvar@...hat.com>,
Russell King <linux@....linux.org.uk>
Subject: Re: [PATCH RFC V1 net-next 3/4] net: Let the active time stamping
layer be selectable.
On Thu, Jan 20, 2022 at 08:05:08PM -0800, Richard Cochran wrote:
> On Fri, Jan 21, 2022 at 04:38:09AM +0100, Andrew Lunn wrote:
>
> > So in the extreme case, you have 7 time stamps, 3 from MACs and 4 from
> > PHYs!
>
> :^)
>
> > I doubt we want to support this, is there a valid use case for it?
>
> Someday, someone will surely say it is important, but with any luck
> I'll be dead by then...
So as I mentioned earlier, the use case would be hardware performance
testing and diagnosing. You may consider that as not that important, but
this is basically what I had to do for several months, and even wrote
a program for that, that collects packet timestamps at all possible points.
And to your point, the more complex a system is, the more important it
becomes to be able to diagnose it precisely.
Powered by blists - more mailing lists