[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190908204224.GA2730@lunn.ch>
Date: Sun, 8 Sep 2019 22:42:24 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: David Miller <davem@...emloft.net>, f.fainelli@...il.com,
vivien.didelot@...il.com, vinicius.gomes@...el.com,
vedang.patel@...el.com, richardcochran@...il.com,
weifeng.voon@...el.com, jiri@...lanox.com, m-karicheri2@...com,
Jose.Abreu@...opsys.com, ilias.apalodimas@...aro.org,
jhs@...atatu.com, xiyou.wangcong@...il.com,
kurt.kanzenbach@...utronix.de, netdev@...r.kernel.org
Subject: Re: [PATCH v1 net-next 00/15] tc-taprio offload for SJA1105 DSA
On Sun, Sep 08, 2019 at 12:07:27PM +0100, Vladimir Oltean wrote:
> I think Richard has been there when the taprio, etf qdiscs, SO_TXTIME
> were first defined and developed:
> https://patchwork.ozlabs.org/cover/808504/
> I expect he is capable of delivering a competent review of the entire
> series, possibly way more competent than my patch set itself.
>
> The reason why I'm not splitting it up is because I lose around 10 ns
> of synchronization offset when using the hardware-corrected PTPCLKVAL
> clock for timestamping rather than the PTPTSCLK free-running counter.
Hi Vladimir
I'm not suggesting anything is wrong with your concept, when i say
split it up. It is more than when somebody sees 15 patches, they
decide they don't have the time at the moment, and put it off until
later. And often later never happens. If however they see a smaller
number of patches, they think that yes they have time now, and do the
review.
So if you are struggling to get something reviewed, make it more
appealing for the reviewer. Salami tactics.
Andrew
Powered by blists - more mailing lists