mbox series

[net,0/4] Remove unneeded PHY time stamping option.

Message ID cover.1611198584.git.richardcochran@gmail.com
Headers show
Series Remove unneeded PHY time stamping option. | expand

Message

Richard Cochran Jan. 21, 2021, 4:05 a.m. UTC
The NETWORK_PHY_TIMESTAMPING configuration option adds additional
checks into the networking hot path, and it is only needed by two
rather esoteric devices, namely the TI DP83640 PHYTER and the ZHAW
InES 1588 IP core.  Very few end users have these devices, and those
that do have them are building specialized embedded systems.

Unfortunately two unrelated drivers depend on this option, and two
defconfigs enable it.  It is probably my fault for not paying enough
attention in reviews.

This series corrects the gratuitous use of NETWORK_PHY_TIMESTAMPING.


Richard Cochran (4):
  net: dsa: mv88e6xxx: Remove bogus Kconfig dependency.
  net: mvpp2: Remove unneeded Kconfig dependency.
  ARM: socfpga_defconfig: Disable PHY time stamping by default.
  ARM: axm55xx_defconfig: Disable PHY time stamping by default.

 arch/arm/configs/axm55xx_defconfig   | 1 -
 arch/arm/configs/socfpga_defconfig   | 6 +-----
 drivers/net/dsa/mv88e6xxx/Kconfig    | 1 -
 drivers/net/ethernet/marvell/Kconfig | 1 -
 4 files changed, 1 insertion(+), 8 deletions(-)

Comments

Richard Cochran Jan. 21, 2021, 3:08 p.m. UTC | #1
On Thu, Jan 21, 2021 at 10:27:54AM +0000, Russell King - ARM Linux admin wrote:
> On Wed, Jan 20, 2021 at 08:06:01PM -0800, Richard Cochran wrote:
> > The mvpp2 is an Ethernet driver, and it implements MAC style time
> > stamping of PTP frames.  It has no need of the expensive option to
> > enable PHY time stamping.  Remove the incorrect dependency.
> > 
> > Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> > Fixes: 91dd71950bd7 ("net: mvpp2: ptp: add TAI support")
> 
> NAK.

Can you please explain why mvpp2 requires NETWORK_PHY_TIMESTAMING?

Thanks,
Richard
Jakub Kicinski Jan. 23, 2021, 2:14 a.m. UTC | #2
On Thu, 21 Jan 2021 07:08:02 -0800 Richard Cochran wrote:
> On Thu, Jan 21, 2021 at 10:27:54AM +0000, Russell King - ARM Linux admin wrote:

> > On Wed, Jan 20, 2021 at 08:06:01PM -0800, Richard Cochran wrote:  

> > > The mvpp2 is an Ethernet driver, and it implements MAC style time

> > > stamping of PTP frames.  It has no need of the expensive option to

> > > enable PHY time stamping.  Remove the incorrect dependency.

> > > 

> > > Signed-off-by: Richard Cochran <richardcochran@gmail.com>

> > > Fixes: 91dd71950bd7 ("net: mvpp2: ptp: add TAI support")  

> > 

> > NAK.  

> 

> Can you please explain why mvpp2 requires NETWORK_PHY_TIMESTAMING?


Russell, I think we all agree now this is not the solution to the
problem of which entity should provide the timestamp, but the series
doesn't seem objectionable in itself.

Please LMK if you think otherwise.

(I would put it in net-next tho, given the above this at most a space
optimization.)
Russell King (Oracle) Jan. 23, 2021, 9:39 a.m. UTC | #3
On Fri, Jan 22, 2021 at 06:14:44PM -0800, Jakub Kicinski wrote:
> On Thu, 21 Jan 2021 07:08:02 -0800 Richard Cochran wrote:

> > On Thu, Jan 21, 2021 at 10:27:54AM +0000, Russell King - ARM Linux admin wrote:

> > > On Wed, Jan 20, 2021 at 08:06:01PM -0800, Richard Cochran wrote:  

> > > > The mvpp2 is an Ethernet driver, and it implements MAC style time

> > > > stamping of PTP frames.  It has no need of the expensive option to

> > > > enable PHY time stamping.  Remove the incorrect dependency.

> > > > 

> > > > Signed-off-by: Richard Cochran <richardcochran@gmail.com>

> > > > Fixes: 91dd71950bd7 ("net: mvpp2: ptp: add TAI support")  

> > > 

> > > NAK.  

> > 

> > Can you please explain why mvpp2 requires NETWORK_PHY_TIMESTAMING?

> 

> Russell, I think we all agree now this is not the solution to the

> problem of which entity should provide the timestamp, but the series

> doesn't seem objectionable in itself.

> 

> Please LMK if you think otherwise.

> 

> (I would put it in net-next tho, given the above this at most a space

> optimization.)


Correct - my NAK is on the basis that this series was put forward
as solving the issue I had raised, but in reality it does little
to achieve that.

It is, as you say, just a space optimisation, and I have no issue
with it being merged on that basis.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Richard Cochran Jan. 23, 2021, 1:26 p.m. UTC | #4
On Fri, Jan 22, 2021 at 06:14:44PM -0800, Jakub Kicinski wrote:

> (I would put it in net-next tho, given the above this at most a space

> optimization.)


It isn't just about space but also time.  The reason why I targeted
net and not net-next was that NETWORK_PHY_TIMESTAMPING activates a
function call to skb_clone_tx_timestamp() for every transmitted frame.

	static inline void skb_tx_timestamp(struct sk_buff *skb)
	{
		skb_clone_tx_timestamp(skb);
		if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP)
			skb_tstamp_tx(skb, NULL);
	}

In the abscence of a PHY time stamping device, the check for its
presence inside of skb_clone_tx_timestamp() will of course fail, but
this still incurs the cost of the call on every transmitted skb.

Similarly netif_receive_skb() futilely calls skb_defer_rx_timestamp()
on every received skb.

I would argue that most users don't want this option activated by
accident.

(And yes, we could avoid the functions call by moving the check
outside of the global functions and inline to the call sites.  I'll be
sure to have that in the shiny new improved scheme under discussion.)

Thanks,
Richard
Jakub Kicinski Jan. 23, 2021, 8:12 p.m. UTC | #5
On Sat, 23 Jan 2021 05:26:26 -0800 Richard Cochran wrote:
> On Fri, Jan 22, 2021 at 06:14:44PM -0800, Jakub Kicinski wrote:

> 

> > (I would put it in net-next tho, given the above this at most a space

> > optimization.)  

> 

> It isn't just about space but also time.  The reason why I targeted

> net and not net-next was that NETWORK_PHY_TIMESTAMPING activates a

> function call to skb_clone_tx_timestamp() for every transmitted frame.

> 

> 	static inline void skb_tx_timestamp(struct sk_buff *skb)

> 	{

> 		skb_clone_tx_timestamp(skb);

> 		if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP)

> 			skb_tstamp_tx(skb, NULL);

> 	}

> 

> In the abscence of a PHY time stamping device, the check for its

> presence inside of skb_clone_tx_timestamp() will of course fail, but

> this still incurs the cost of the call on every transmitted skb.

> 

> Similarly netif_receive_skb() futilely calls skb_defer_rx_timestamp()

> on every received skb.

> 

> I would argue that most users don't want this option activated by

> accident.


I see. The only thing I'm worried about then is the churn in patch 3.
This would land in Linus's tree shortly before rc6, kinda late to be
taking chances in the name of minor optimizations :S
 
> (And yes, we could avoid the functions call by moving the check

> outside of the global functions and inline to the call sites.  I'll be

> sure to have that in the shiny new improved scheme under discussion.)
Richard Cochran Jan. 23, 2021, 9:14 p.m. UTC | #6
On Sat, Jan 23, 2021 at 12:12:27PM -0800, Jakub Kicinski wrote:
> I see. The only thing I'm worried about then is the churn in patch 3.

> This would land in Linus's tree shortly before rc6, kinda late to be

> taking chances in the name of minor optimizations :S


;^)

Yeah, by all means, avoid ARM churn... I remember Bad Things there...

Maybe you could take #1 and #2 for net-next?

I should probably submit 3-4 throught the SoC tree anyhow.

Thanks,
Richard
Jakub Kicinski Jan. 23, 2021, 9:38 p.m. UTC | #7
On Sat, 23 Jan 2021 13:14:00 -0800 Richard Cochran wrote:
> On Sat, Jan 23, 2021 at 12:12:27PM -0800, Jakub Kicinski wrote:

> > I see. The only thing I'm worried about then is the churn in patch 3.

> > This would land in Linus's tree shortly before rc6, kinda late to be

> > taking chances in the name of minor optimizations :S  

> 

> ;^)

> 

> Yeah, by all means, avoid ARM churn... I remember Bad Things there...

> 

> Maybe you could take #1 and #2 for net-next?


Done, thanks!

> I should probably submit 3-4 throught the SoC tree anyhow.