From: Jeff Kirsher <hidden> Date: 2012-08-23 09:56:56
This series contains updates to e1000 and igb. Patches for e1000
consist of code cleanups and patches for igb adds loopback support
for i210 as well as PTP fixes.
The following are changes since commit 0fa7fa98dbcc2789409ed24e885485e645803d7f:
packet: Protect packet sk list with mutex (v2)
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Bruce Allan (7):
e1000e: use correct type for read of 32-bit register
e1000e: cleanup strict checkpatch check
e1000e: cleanup - remove inapplicable comment
e1000e: cleanup checkpatch PREFER_PR_LEVEL warning
e1000e: cleanup - remove unnecessary variable
e1000e: update driver version number
e1000e: cleanup strict checkpatch MEMORY_BARRIER checks
Carolyn Wyborny (1):
igb: Add loopback test support for i210.
Eric Dumazet (1):
igb: reduce Rx header size
Matthew Vick (4):
igb: Tidy up wrapping for CONFIG_IGB_PTP.
igb: Update PTP function names/variables and locations.
igb: Correct PTP support query from ethtool.
igb: Store the MAC address in the name in the PTP struct.
drivers/net/ethernet/intel/e1000e/82571.c | 4 +-
drivers/net/ethernet/intel/e1000e/ethtool.c | 3 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 28 +-
drivers/net/ethernet/intel/igb/igb.h | 29 +-
drivers/net/ethernet/intel/igb/igb_ethtool.c | 136 ++++----
drivers/net/ethernet/intel/igb/igb_main.c | 272 +--------------
drivers/net/ethernet/intel/igb/igb_ptp.c | 488 ++++++++++++++++++++-------
7 files changed, 490 insertions(+), 470 deletions(-)
--
1.7.11.4
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:56:57
From: Bruce Allan <redacted>
CHECK: multiple assignments should be avoided
Signed-off-by: Bruce Allan <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/e1000e/ethtool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:56:57
From: Bruce Allan <redacted>
The POEMB register is 32 bits, not 16.
Signed-off-by: Bruce Allan <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/e1000e/82571.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:56:57
From: Bruce Allan <redacted>
Early Receive has been disabled in the driver so this comment is no longer
applicable.
Signed-off-by: Bruce Allan <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:56:58
From: Bruce Allan <redacted>
checkpatch warning: Prefer pr_info(... to printk(KERN_INFO, ...
Signed-off-by: Bruce Allan <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
@@ -4330,9 +4330,8 @@ static void e1000_print_link_info(struct e1000_adapter *adapter)u32ctrl=er32(CTRL);/* Link status message must follow this format for user tools */-printk(KERN_INFO"e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",-adapter->netdev->name,-adapter->link_speed,+pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",+adapter->netdev->name,adapter->link_speed,adapter->link_duplex==FULL_DUPLEX?"Full":"Half",(ctrl&E1000_CTRL_TFCE)&&(ctrl&E1000_CTRL_RFCE)?"Rx/Tx":(ctrl&E1000_CTRL_RFCE)?"Rx":
@@ -4558,8 +4557,8 @@ static void e1000_watchdog_task(struct work_struct *work)adapter->link_speed=0;adapter->link_duplex=0;/* Link status message must follow this format */-printk(KERN_INFO"e1000e: %s NIC Link is Down\n",-adapter->netdev->name);+pr_info("e1000e: %s NIC Link is Down\n",+adapter->netdev->name);netif_carrier_off(netdev);if(!test_bit(__E1000_DOWN,&adapter->state))mod_timer(&adapter->phy_info_timer,
@@ -4330,9 +4330,8 @@ static void e1000_print_link_info(struct e1000_adapter *adapter) u32 ctrl = er32(CTRL); /* Link status message must follow this format for user tools */- printk(KERN_INFO "e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",- adapter->netdev->name,- adapter->link_speed,+ pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",+ adapter->netdev->name, adapter->link_speed, adapter->link_duplex == FULL_DUPLEX ? "Full" : "Half", (ctrl & E1000_CTRL_TFCE) && (ctrl & E1000_CTRL_RFCE) ? "Rx/Tx" : (ctrl & E1000_CTRL_RFCE) ? "Rx" :
I think these conversions are not a good idea.
When you have a specific message format that must be
followed, use printk.
pr_<level> may at some point in the near future use
#define pr_fmt(fmt) KBUiLD_MODNAME ": " fmt
as a global default equivalent.
@@ -4330,9 +4330,8 @@ static void e1000_print_link_info(struct e1000_adapter *adapter) u32 ctrl = er32(CTRL); /* Link status message must follow this format for user tools */- printk(KERN_INFO "e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",- adapter->netdev->name,- adapter->link_speed,+ pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",+ adapter->netdev->name, adapter->link_speed, adapter->link_duplex == FULL_DUPLEX ? "Full" : "Half", (ctrl & E1000_CTRL_TFCE) && (ctrl & E1000_CTRL_RFCE) ? "Rx/Tx" : (ctrl & E1000_CTRL_RFCE) ? "Rx" :
I think these conversions are not a good idea.
When you have a specific message format that must be
followed, use printk.
pr_<level> may at some point in the near future use
#define pr_fmt(fmt) KBUiLD_MODNAME ": " fmt
as a global default equivalent.
Hey Jeff.
The comment above this change (and the other) reads
/* Link status message must follow this format for user tools */
This file already uses #define pr_fmt(fmt) KBUILD_MODNAME...
With this patch, the output form changes to use 2 prefixes.
Is that really desired? Probably not.
If the comments are old and don't apply any more, they
should be removed.
@@ -4330,9 +4330,8 @@ static void e1000_print_link_info(struct e1000_adapter *adapter) u32 ctrl = er32(CTRL); /* Link status message must follow this format for user tools */- printk(KERN_INFO "e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",- adapter->netdev->name,- adapter->link_speed,+ pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",+ adapter->netdev->name, adapter->link_speed, adapter->link_duplex == FULL_DUPLEX ? "Full" : "Half", (ctrl & E1000_CTRL_TFCE) && (ctrl & E1000_CTRL_RFCE) ? "Rx/Tx" : (ctrl & E1000_CTRL_RFCE) ? "Rx" :
I think these conversions are not a good idea.
When you have a specific message format that must be
followed, use printk.
pr_<level> may at some point in the near future use
#define pr_fmt(fmt) KBUiLD_MODNAME ": " fmt
as a global default equivalent.
Hey Jeff.
The comment above this change (and the other) reads
/* Link status message must follow this format for user tools */
This file already uses #define pr_fmt(fmt) KBUILD_MODNAME...
With this patch, the output form changes to use 2 prefixes.
Is that really desired? Probably not.
If the comments are old and don't apply any more, they
should be removed.
Bruce really should answer this since this is his patch and there was a
reason why he made the change. My guess was the current output was
providing incorrect or mis-leading information.
@@ -4330,9 +4330,8 @@ static void e1000_print_link_info(struct e1000_adapter *adapter) u32 ctrl = er32(CTRL); /* Link status message must follow this format for user tools */- printk(KERN_INFO "e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",- adapter->netdev->name,- adapter->link_speed,+ pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",+ adapter->netdev->name, adapter->link_speed, adapter->link_duplex == FULL_DUPLEX ? "Full" : "Half", (ctrl & E1000_CTRL_TFCE) && (ctrl & E1000_CTRL_RFCE) ? "Rx/Tx" : (ctrl & E1000_CTRL_RFCE) ? "Rx" :
[]
quoted
The comment above this change (and the other) reads
/* Link status message must follow this format for user tools */
This file already uses #define pr_fmt(fmt) KBUILD_MODNAME...
With this patch, the output form changes to use 2 prefixes.
Is that really desired? Probably not.
If the comments are old and don't apply any more, they
should be removed.
Bruce really should answer this since this is his patch and there was a
reason why he made the change. My guess was the current output was
providing incorrect or mis-leading information.
My guess is he was just shutting up checkpatch and
didn't notice the newly doubled prefix.
happy weekend...
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:56:58
From: Bruce Allan <redacted>
Signed-off-by: Bruce Allan <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:56:59
From: Bruce Allan <redacted>
Signed-off-by: Bruce Allan <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:57:00
From: Carolyn Wyborny <redacted>
Early release of i210 devices had the loopback test of the ethtool
self-test disabled. This patch enables the loopback test for i210 devices.
Signed-off-by: Carolyn Wyborny <redacted>
Tested-by: Jeff Pieper <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 51 +++++++++-------------------
1 file changed, 16 insertions(+), 35 deletions(-)
@@ -1511,33 +1511,22 @@ static int igb_integrated_phy_loopback(struct igb_adapter *adapter){structe1000_hw*hw=&adapter->hw;u32ctrl_reg=0;-u16phy_reg=0;hw->mac.autoneg=false;-switch(hw->phy.type){-casee1000_phy_m88:-/* Auto-MDI/MDIX Off */-igb_write_phy_reg(hw,M88E1000_PHY_SPEC_CTRL,0x0808);-/* reset to update Auto-MDI/MDIX */-igb_write_phy_reg(hw,PHY_CONTROL,0x9140);-/* autoneg off */-igb_write_phy_reg(hw,PHY_CONTROL,0x8140);-break;-casee1000_phy_82580:-/* enable MII loopback */-igb_write_phy_reg(hw,I82580_PHY_LBK_CTRL,0x8041);-break;-casee1000_phy_i210:-/* set loopback speed in PHY */-igb_read_phy_reg(hw,(GS40G_PAGE_SELECT&GS40G_PAGE_2),-&phy_reg);-phy_reg|=GS40G_MAC_SPEED_1G;-igb_write_phy_reg(hw,(GS40G_PAGE_SELECT&GS40G_PAGE_2),-phy_reg);-ctrl_reg=rd32(E1000_CTRL_EXT);-default:-break;+if(hw->phy.type==e1000_phy_m88){+if(hw->phy.id!=I210_I_PHY_ID){+/* Auto-MDI/MDIX Off */+igb_write_phy_reg(hw,M88E1000_PHY_SPEC_CTRL,0x0808);+/* reset to update Auto-MDI/MDIX */+igb_write_phy_reg(hw,PHY_CONTROL,0x9140);+/* autoneg off */+igb_write_phy_reg(hw,PHY_CONTROL,0x8140);+}else{+/* force 1000, set loopback */+igb_write_phy_reg(hw,I347AT4_PAGE_SELECT,0);+igb_write_phy_reg(hw,PHY_CONTROL,0x4140);+}}/* add small delay to avoid loopback test failure */
@@ -1555,7 +1544,7 @@ static int igb_integrated_phy_loopback(struct igb_adapter *adapter)E1000_CTRL_FD|/* Force Duplex to FULL */E1000_CTRL_SLU);/* Set link up enable bit */-if((hw->phy.type==e1000_phy_m88)||(hw->phy.type==e1000_phy_i210))+if(hw->phy.type==e1000_phy_m88)ctrl_reg|=E1000_CTRL_ILOS;/* Invert Loss of Signal */wr32(E1000_CTRL,ctrl_reg);
@@ -1563,11 +1552,10 @@ static int igb_integrated_phy_loopback(struct igb_adapter *adapter)/* Disable the receiver on the PHY so when a cable is plugged in, the*PHYdoesnotbegintoautonegwhenacableisreconnectedtotheNIC.*/-if((hw->phy.type==e1000_phy_m88)||(hw->phy.type==e1000_phy_i210))+if(hw->phy.type==e1000_phy_m88)igb_phy_disable_receiver(adapter);-udelay(500);-+mdelay(500);return0;}
@@ -1827,13 +1815,6 @@ static int igb_loopback_test(struct igb_adapter *adapter, u64 *data)*data=0;gotoout;}-if((adapter->hw.mac.type==e1000_i210)-||(adapter->hw.mac.type==e1000_i211)){-dev_err(&adapter->pdev->dev,-"Loopback test not supported on this part at this time.\n");-*data=0;-gotoout;-}*data=igb_setup_desc_rings(adapter);if(*data)gotoout;
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:57:00
From: Bruce Allan <redacted>
Add comments to memory barriers per strict checkpatch.
Signed-off-by: Bruce Allan <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
@@ -3787,6 +3791,10 @@ static int e1000_test_msi_interrupt(struct e1000_adapter *adapter)gotomsi_test_failed;}+/*+*Forcememorywritestocompletebeforeenablingandfiringan+*interrupt.+*/wmb();e1000_irq_enable(adapter);
@@ -3798,7 +3806,7 @@ static int e1000_test_msi_interrupt(struct e1000_adapter *adapter)e1000_irq_disable(adapter);-rmb();+rmb();/* read flags after interrupt has been fired */if(adapter->flags&FLAG_MSI_TEST_FAILED){adapter->int_mode=E1000E_INT_MODE_LEGACY;
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:57:02
From: Matthew Vick <redacted>
For users without CONFIG_IGB_PTP=y, we should not be compiling any PTP
code into the driver. Tidy up the wrapping in igb to support this.
Signed-off-by: Matthew Vick <redacted>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Jeff Pieper <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/igb/igb.h | 8 ++++++--
drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 ++--
drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++++++++++------
3 files changed, 25 insertions(+), 10 deletions(-)
@@ -3184,8 +3185,10 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,srrctl|=(PAGE_SIZE/2)>>E1000_SRRCTL_BSIZEPKT_SHIFT;#endifsrrctl|=E1000_SRRCTL_DESCTYPE_HDR_SPLIT_ALWAYS;+#ifdef CONFIG_IGB_PTPif(hw->mac.type>=e1000_82580)srrctl|=E1000_SRRCTL_TIMESTAMP;+#endif /* CONFIG_IGB_PTP *//* Only set Drop Enable if we are supporting multiple queues */if(adapter->vfs_allocated_count||adapter->num_rx_queues>1)srrctl|=E1000_SRRCTL_DROP_EN;
@@ -4229,9 +4232,11 @@ static __le32 igb_tx_cmd_type(u32 tx_flags)if(tx_flags&IGB_TX_FLAGS_VLAN)cmd_type|=cpu_to_le32(E1000_ADVTXD_DCMD_VLE);+#ifdef CONFIG_IGB_PTP/* set timestamp bit if present */if(tx_flags&IGB_TX_FLAGS_TSTAMP)cmd_type|=cpu_to_le32(E1000_ADVTXD_MAC_TSTAMP);+#endif /* CONFIG_IGB_PTP *//* set segmentation bits for TSO */if(tx_flags&IGB_TX_FLAGS_TSO)
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-23 11:04:04
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
From: Matthew Vick <redacted>
For users without CONFIG_IGB_PTP=y, we should not be compiling any PTP
code into the driver. Tidy up the wrapping in igb to support this.
Actually, you are doing more than that. You are adding a bunch of
comments onto the already existing #endifs.
quoted hunk
Signed-off-by: Matthew Vick <redacted>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Jeff Pieper <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/igb/igb.h | 8 ++++++--
drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 ++--
drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++++++++++------
3 files changed, 25 insertions(+), 10 deletions(-)
@@ -2180,11 +2180,12 @@ static int __devinit igb_probe(struct pci_dev *pdev,}#endif+#ifdef CONFIG_IGB_PTP/* do hw tstamp init after resetting */igb_ptp_init(adapter);+#endif /* CONFIG_IGB_PTP */-#endif
But this is just churn. You aren't actually improving anything
here. It is already clear that the #endif belongs to the #ifdef just
three lines above.
If you are on some kind of campaign to comment all the endifs, then
you should say so, and, to be consistent, you should not overlook the
CONFIG_IGB_DCA blocks.
But I think it really isn't needed.
Thanks,
Richard
From: Vick, Matthew <hidden> Date: 2012-08-23 16:09:33
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 4:04 AM
To: Kirsher, Jeffrey T
Cc: davem@davemloft.net; Vick, Matthew; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
quoted
From: Matthew Vick <redacted>
For users without CONFIG_IGB_PTP=y, we should not be compiling any
PTP
quoted
code into the driver. Tidy up the wrapping in igb to support this.
Actually, you are doing more than that. You are adding a bunch of
comments onto the already existing #endifs.
Fair enough. Would you like me to update the patch description?
This is legitimate, to reduce memory footprint.
[...]
But this is just churn. You aren't actually improving anything here. It
is already clear that the #endif belongs to the #ifdef just three lines
above.
If you are on some kind of campaign to comment all the endifs, then you
should say so, and, to be consistent, you should not overlook the
CONFIG_IGB_DCA blocks.
But I think it really isn't needed.
Thanks,
Richard
I'm willing to work on a follow on patch to add proper endings to CONFIG_IGB_DCA blocks. The reasoning here was "I'm working on the wrapping for the code here anyway, so I might as well make it consistent."
Personally, I think it is an improvement. If you want to add #endif comments, you may as well be consistent about it.
Cheers,
Matthew
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-23 17:30:03
On Thu, Aug 23, 2012 at 04:09:30PM +0000, Vick, Matthew wrote:
quoted
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 4:04 AM
To: Kirsher, Jeffrey T
Cc: davem@davemloft.net; Vick, Matthew; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
quoted
From: Matthew Vick <redacted>
For users without CONFIG_IGB_PTP=y, we should not be compiling any
PTP
quoted
code into the driver. Tidy up the wrapping in igb to support this.
Actually, you are doing more than that. You are adding a bunch of
comments onto the already existing #endifs.
Fair enough. Would you like me to update the patch description?
Better would be to drop of the pendantic #endif /*CONFIG_FOO*/ stuff.
It is just churn.
Thanks,
Richard
From: Vick, Matthew <hidden> Date: 2012-08-23 17:41:20
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 10:30 AM
To: Vick, Matthew
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
On Thu, Aug 23, 2012 at 04:09:30PM +0000, Vick, Matthew wrote:
quoted
quoted
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 4:04 AM
To: Kirsher, Jeffrey T
Cc: davem@davemloft.net; Vick, Matthew; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for
CONFIG_IGB_PTP.
quoted
quoted
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
quoted
From: Matthew Vick <redacted>
For users without CONFIG_IGB_PTP=y, we should not be compiling
any
quoted
quoted
PTP
quoted
code into the driver. Tidy up the wrapping in igb to support
this.
quoted
quoted
Actually, you are doing more than that. You are adding a bunch of
comments onto the already existing #endifs.
Fair enough. Would you like me to update the patch description?
Better would be to drop of the pendantic #endif /*CONFIG_FOO*/ stuff.
It is just churn.
Thanks,
Richard
I'm willing to drop it, but I would like to drop it universally in the driver if that's the case. Is that acceptable? There's no overly long or complex wrapping section in the driver that I think merits being sloppy with the end comments.
Cheers,
Matthew
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-23 18:03:59
On Thu, Aug 23, 2012 at 05:40:01PM +0000, Vick, Matthew wrote:
quoted
Better would be to drop of the pendantic #endif /*CONFIG_FOO*/ stuff.
It is just churn.
Thanks,
Richard
I'm willing to drop it, but I would like to drop it universally in the driver if that's the case. Is that acceptable? There's no overly long or complex wrapping section in the driver that I think merits being sloppy with the end comments.
Well, I don't know about the other cases.
drivers/net/ethernet/intel/igb$ grep \#endif *.c | grep -v CONFIG | wc -l
28
drivers/net/ethernet/intel/igb$ grep \#endif *.c | grep CONFIG | wc -l
8
(none of these are for _IGB_PTP)
Having #endif comments is useful when it makes the code more clear. It
is a matter of taste, but I do think having such comments for just two
lines in between is ugly and silly.
Thanks,
Richard
From: "Keller, Jacob E" <jacob.e.keller@intel.com> Date: 2012-08-23 18:04:46
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Richard Cochran
Sent: Thursday, August 23, 2012 10:30 AM
To: Vick, Matthew
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
On Thu, Aug 23, 2012 at 04:09:30PM +0000, Vick, Matthew wrote:
quoted
quoted
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 4:04 AM
To: Kirsher, Jeffrey T
Cc: davem@davemloft.net; Vick, Matthew; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for
CONFIG_IGB_PTP.
quoted
quoted
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
quoted
From: Matthew Vick <redacted>
For users without CONFIG_IGB_PTP=y, we should not be compiling any
PTP
quoted
code into the driver. Tidy up the wrapping in igb to support this.
Actually, you are doing more than that. You are adding a bunch of
comments onto the already existing #endifs.
Fair enough. Would you like me to update the patch description?
Better would be to drop of the pendantic #endif /*CONFIG_FOO*/ stuff.
It is just churn.
Personally disagree here. I do agree that the churn is annoying with how it breaks git blame, however, in general I prefer tags at the end of #ifdefs even for short ones because it increases my ability to quickly spot matches. The end comment aligns with the starting comment, and even for small blocks makes it easier to process. It is less necessary the smaller the block, but I always prefer to have it than not.
That said, it is nice when git blame points to the right place, and the comments aren't super necessary for such short blocks.
- Jake
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
From: Vick, Matthew <hidden> Date: 2012-08-23 18:40:32
-----Original Message-----
From: Keller, Jacob E
Sent: Thursday, August 23, 2012 11:04 AM
To: Richard Cochran; Vick, Matthew
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: RE: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
[...]
Personally disagree here. I do agree that the churn is annoying with
how it breaks git blame, however, in general I prefer tags at the end
of #ifdefs even for short ones because it increases my ability to
quickly spot matches. The end comment aligns with the starting comment,
and even for small blocks makes it easier to process. It is less
necessary the smaller the block, but I always prefer to have it than
not.
That said, it is nice when git blame points to the right place, and the
comments aren't super necessary for such short blocks.
- Jake
I tend to agree with Jake here--I like having the information. I'm fine removing them, but I'd like to do it for all CONFIG_IGB_PTP wrapping if we're going to do it. What do you think, Richard?
Cheers,
Matthew
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-24 07:04:27
On Thu, Aug 23, 2012 at 06:40:25PM +0000, Vick, Matthew wrote:
I tend to agree with Jake here--I like having the information. I'm fine removing them, but I'd like to do it for all CONFIG_IGB_PTP wrapping if we're going to do it. What do you think, Richard?
I took a look at the #ifdefs in igb_main.c, and I would say they are
okay as is, except for the CONFIG_PM ones, which could use a comment
at the #endifs.
(a matter of taste, though)
Thanks,
Richard
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-24 10:11:05
On Thu, Aug 23, 2012 at 06:40:25PM +0000, Vick, Matthew wrote:
I tend to agree with Jake here--I like having the information. I'm fine removing them, but I'd like to do it for all CONFIG_IGB_PTP wrapping if we're going to do it. What do you think, Richard?
Come to think of it, I never liked the CONFIG_IGB_PTP very much in the
first place. These were added after the fact by Jeff Kirsher. He had
said off list that there was some issue with CONFIG_PTP_1588_CLOCK and
igb as a module, or something like that. At that time I said, just go
ahead and fix it up.
I think it would be better if the "time stamp all Rx packets" of the
82580 were always available, and that the PHC feature always be
compiled when CONFIG_PTP_1588_CLOCK is selected.
Maybe you could ask Jeff what the issue was, and then see if there is
a way to remove CONFIG_IGB_PTP altogether.
Thanks,
Richard
From: Ben Hutchings <hidden> Date: 2012-08-24 16:51:33
On Fri, 2012-08-24 at 12:10 +0200, Richard Cochran wrote:
On Thu, Aug 23, 2012 at 06:40:25PM +0000, Vick, Matthew wrote:
quoted
I tend to agree with Jake here--I like having the information. I'm fine removing them, but I'd like to do it for all CONFIG_IGB_PTP wrapping if we're going to do it. What do you think, Richard?
Come to think of it, I never liked the CONFIG_IGB_PTP very much in the
first place. These were added after the fact by Jeff Kirsher. He had
said off list that there was some issue with CONFIG_PTP_1588_CLOCK and
igb as a module, or something like that. At that time I said, just go
ahead and fix it up.
If there is some feature of a driver that depends on an optional
modularisable subsystem, and you want the driver to be built without
that feature when the subsystem is missing, then the feature has to be
disabled when the driver is built-in and the subsystem is a module. So
in general you need:
config DRIVER_FEATURE
bool "This is a really neat feature for the driver"
depends on DRIVER && SUBSYSTEM && !(DRIVER=y && SUBYSTEM=m)
I think it would be better if the "time stamp all Rx packets" of the
82580 were always available, and that the PHC feature always be
compiled when CONFIG_PTP_1588_CLOCK is selected.
Maybe you could ask Jeff what the issue was, and then see if there is
a way to remove CONFIG_IGB_PTP altogether.
Even if they are to be enabled automatically, CONFIG_IGB_PTP and similar
config symbols are important as shorthand. So I think what you want is:
config IGB_PTP
def_bool y
depends on IGB && PTP_1588_CLOCK && !(IGB=y && PTP_1588_CLOCK=m)
(But currently it's actually *selecting* PTP_1588_CLOCK. We should
probably have drivers consistently select or depend on it, not a
mixture.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
From: "Keller, Jacob E" <jacob.e.keller@intel.com> Date: 2012-08-24 19:38:53
-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Friday, August 24, 2012 9:51 AM
To: Richard Cochran
Cc: Vick, Matthew; Keller, Jacob E; Kirsher, Jeffrey T;
davem@davemloft.net; netdev@vger.kernel.org; gospo@redhat.com;
sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
On Fri, 2012-08-24 at 12:10 +0200, Richard Cochran wrote:
quoted
On Thu, Aug 23, 2012 at 06:40:25PM +0000, Vick, Matthew wrote:
quoted
I tend to agree with Jake here--I like having the information. I'm
fine removing them, but I'd like to do it for all CONFIG_IGB_PTP wrapping
if we're going to do it. What do you think, Richard?
quoted
Come to think of it, I never liked the CONFIG_IGB_PTP very much in the
first place. These were added after the fact by Jeff Kirsher. He had
said off list that there was some issue with CONFIG_PTP_1588_CLOCK and
igb as a module, or something like that. At that time I said, just go
ahead and fix it up.
If there is some feature of a driver that depends on an optional
modularisable subsystem, and you want the driver to be built without that
feature when the subsystem is missing, then the feature has to be disabled
when the driver is built-in and the subsystem is a module. So in general
you need:
config DRIVER_FEATURE
bool "This is a really neat feature for the driver"
depends on DRIVER && SUBSYSTEM && !(DRIVER=y && SUBYSTEM=m)
quoted
I think it would be better if the "time stamp all Rx packets" of the
82580 were always available, and that the PHC feature always be
compiled when CONFIG_PTP_1588_CLOCK is selected.
Maybe you could ask Jeff what the issue was, and then see if there is
a way to remove CONFIG_IGB_PTP altogether.
Even if they are to be enabled automatically, CONFIG_IGB_PTP and similar
config symbols are important as shorthand. So I think what you want is:
config IGB_PTP
def_bool y
depends on IGB && PTP_1588_CLOCK && !(IGB=y && PTP_1588_CLOCK=m)
(But currently it's actually *selecting* PTP_1588_CLOCK. We should
probably have drivers consistently select or depend on it, not a
mixture.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer;
that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
The IGP_PTP is necessary otherwise you have to do something like #if defined(CONFIG_PTP_1588_CLOCK), or #ifdef CONFIG_PTP_1588_CLOCK \ #ifdef CONFIG_PTP_1588_CLOCK_MODULE
The main reason that I wouldn't want to un-wrap the timestamping is because the hwtstamp ioctl is somewhat problematic because it is almost all ptp only. Also, some of the parts for igb driver don't support timestamp all, they only support ptp only packets, and this would be a lot more confusing since I would say still only allow that if ptp is on.. (since those values are useless except with the PHC clock)
- Jake
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-25 06:20:26
On Fri, Aug 24, 2012 at 07:38:38PM +0000, Keller, Jacob E wrote:
The IGP_PTP is necessary otherwise you have to do something like #if defined(CONFIG_PTP_1588_CLOCK), or #ifdef CONFIG_PTP_1588_CLOCK \ #ifdef CONFIG_PTP_1588_CLOCK_MODULE
Yes, but maybe use IGP_PTP as Ben described?
The main reason that I wouldn't want to un-wrap the timestamping is because the hwtstamp ioctl is somewhat problematic because it is almost all ptp only. Also, some of the parts for igb driver don't support timestamp all, they only support ptp only packets, and this would be a lot more confusing since I would say still only allow that if ptp is on.. (since those values are useless except with the PHC clock)
I keep trying to explain that receive time stamping (HWTSTAMP_FILTER_ALL)
is useful all by itself. It has nothing to do with PTP, and the 82580
can do this with very little ** overhead.
I myself have used this feature when debugging and profiling quasi
real time Ethernet protocols like EtherCAT and IEC61850-9-2. The other
drivers that offer this (gianfar and vxge) do so without any CONFIG
conditionals.
IMHO, the Rx time stamping feature should always be available. It is
really not much different than the vlan feature.
Thanks,
Richard
** Both igb_rx_hwtstamp and igb_tx_hwtstamp only add a single test
when time stamping is not enabled.
From: "Keller, Jacob E" <jacob.e.keller@intel.com> Date: 2012-08-26 01:33:44
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Friday, August 24, 2012 11:20 PM
To: Keller, Jacob E
Cc: Ben Hutchings; Vick, Matthew; Kirsher, Jeffrey T; davem@davemloft.net;
netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
On Fri, Aug 24, 2012 at 07:38:38PM +0000, Keller, Jacob E wrote:
quoted
The IGP_PTP is necessary otherwise you have to do something like #if
defined(CONFIG_PTP_1588_CLOCK), or #ifdef CONFIG_PTP_1588_CLOCK \
#ifdef CONFIG_PTP_1588_CLOCK_MODULE
Yes, but maybe use IGP_PTP as Ben described?
That's exactly what I was saying :) That's the reason why IGP_PTP is necessary.
quoted
The main reason that I wouldn't want to un-wrap the timestamping is
because the hwtstamp ioctl is somewhat problematic because it is
almost all ptp only. Also, some of the parts for igb driver don't
support timestamp all, they only support ptp only packets, and this
would be a lot more confusing since I would say still only allow that
if ptp is on.. (since those values are useless except with the PHC
clock)
I keep trying to explain that receive time stamping (HWTSTAMP_FILTER_ALL)
is useful all by itself. It has nothing to do with PTP, and the 82580 can
do this with very little ** overhead.
I myself have used this feature when debugging and profiling quasi real
time Ethernet protocols like EtherCAT and IEC61850-9-2. The other drivers
that offer this (gianfar and vxge) do so without any CONFIG conditionals.
IMHO, the Rx time stamping feature should always be available. It is
really not much different than the vlan feature.
IMO it should be but only for parts with HWTSTAMP_FILTER_ALL, and only for that mode (other modes should be ignored) because timestamping only PTP packets is a PTP feature, so this change should still disable other modes if they exist.
Thanks,
Richard
** Both igb_rx_hwtstamp and igb_tx_hwtstamp only add a single test
when time stamping is not enabled.
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-26 13:01:42
On Sun, Aug 26, 2012 at 01:33:42AM +0000, Keller, Jacob E wrote:
IMO it should be but only for parts with HWTSTAMP_FILTER_ALL, and only for that mode (other modes should be ignored) because timestamping only PTP packets is a PTP feature, so this change should still disable other modes if they exist.
Yes, the other Rx modes are PTP specific, and they don't make sense
unless the PTP clock is also enabled.
IIRC, on the Tx side, the 82580 can time stamp any marked packet
regardless of the packet contents, so this should also be always
available, along with HWTSTAMP_FILTER_ALL.
Thanks,
Richard
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-23 11:28:43
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
From: Matthew Vick <redacted>
For users without CONFIG_IGB_PTP=y, we should not be compiling any PTP
code into the driver. Tidy up the wrapping in igb to support this.
I would appreciate being put on Cc: for any PTP stuff.
Also, if you really want to improve the IGB driver, maybe you could
look at what happens to the time stamping when you do an ifdown/ifup
on the card. It seems to screw everything (observed on kernel 3.5).
Thanks,
Richard
From: Vick, Matthew <hidden> Date: 2012-08-23 16:27:50
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 4:29 AM
To: Kirsher, Jeffrey T
Cc: davem@davemloft.net; Vick, Matthew; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
quoted
From: Matthew Vick <redacted>
For users without CONFIG_IGB_PTP=y, we should not be compiling any
PTP
quoted
code into the driver. Tidy up the wrapping in igb to support this.
I would appreciate being put on Cc: for any PTP stuff.
Also, if you really want to improve the IGB driver, maybe you could
look at what happens to the time stamping when you do an ifdown/ifup on
the card. It seems to screw everything (observed on kernel 3.5).
Thanks,
Richard
Will do going forward. I appreciate the review.
I actually have two patches coming up that bring some further improvements--these first couple patches are foundation for those. In a patch coming up, the ifdown/ifup issue gets resolved.
Cheers,
Matthew
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:57:03
From: Matthew Vick <redacted>
Update ethtool_get_ts_info to not report any supported functionality on
82575 and add support for V2 Sync and V2 Delay packets. In the case
where CONFIG_IGB_PTP is not defined, we should be reporting default
values.
Signed-off-by: Matthew Vick <redacted>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Jeff Pieper <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 59 +++++++++++++++++-----------
1 file changed, 37 insertions(+), 22 deletions(-)
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-23 11:24:31
On Thu, Aug 23, 2012 at 02:56:52AM -0700, Jeff Kirsher wrote:
From: Matthew Vick <redacted>
Update ethtool_get_ts_info to not report any supported functionality on
82575 and add support for V2 Sync and V2 Delay packets. In the case
where CONFIG_IGB_PTP is not defined, we should be reporting default
values.
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Vick, Matthew <hidden> Date: 2012-08-23 16:39:33
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-
owner@vger.kernel.org] On Behalf Of Richard Cochran
Sent: Thursday, August 23, 2012 4:24 AM
To: Kirsher, Jeffrey T
Cc: davem@davemloft.net; Vick, Matthew; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 12/13] igb: Correct PTP support query from
ethtool.
On Thu, Aug 23, 2012 at 02:56:52AM -0700, Jeff Kirsher wrote:
quoted
From: Matthew Vick <redacted>
Update ethtool_get_ts_info to not report any supported functionality
on
82575 and add support for V2 Sync and V2 Delay packets. In the case
where CONFIG_IGB_PTP is not defined, we should be reporting default
values.
From: Jeff Kirsher <hidden> Date: 2012-08-23 09:57:04
From: Matthew Vick <redacted>
Where possible, move PTP-related functions into igb_ptp.c and update the
names of functions and variables to match the established coding style
in the files and specify that they are PTP-specific.
Signed-off-by: Matthew Vick <redacted>
Tested-by: Jeff Pieper <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
drivers/net/ethernet/intel/igb/igb.h | 17 +-
drivers/net/ethernet/intel/igb/igb_ethtool.c | 34 +-
drivers/net/ethernet/intel/igb/igb_main.c | 257 +-------------
drivers/net/ethernet/intel/igb/igb_ptp.c | 485 ++++++++++++++++++++-------
4 files changed, 398 insertions(+), 395 deletions(-)
@@ -5750,37 +5750,6 @@ static int igb_poll(struct napi_struct *napi, int budget)return0;}-#ifdef CONFIG_IGB_PTP-/**-*igb_tx_hwtstamp-utilityfunctionwhichchecksforTXtimestamp-*@q_vector:pointertoq_vectorcontainingneededinfo-*@buffer:pointertoigb_tx_bufferstructure-*-*Ifwewereaskedtodohardwarestampingandsuchatimestampis-*available,thenitmusthavebeenforthisskbherebecauseweonly-*allowonlyonesuchpacketintothequeue.-*/-staticvoidigb_tx_hwtstamp(structigb_q_vector*q_vector,-structigb_tx_buffer*buffer_info)-{-structigb_adapter*adapter=q_vector->adapter;-structe1000_hw*hw=&adapter->hw;-structskb_shared_hwtstampsshhwtstamps;-u64regval;--/* if skb does not support hw timestamp or TX stamp not valid exit */-if(likely(!(buffer_info->tx_flags&IGB_TX_FLAGS_TSTAMP))||-!(rd32(E1000_TSYNCTXCTL)&E1000_TSYNCTXCTL_VALID))-return;--regval=rd32(E1000_TXSTMPL);-regval|=(u64)rd32(E1000_TXSTMPH)<<32;--igb_systim_to_hwtstamp(adapter,&shhwtstamps,regval);-skb_tstamp_tx(buffer_info->skb,&shhwtstamps);-}-#endif /* CONFIG_IGB_PTP */-/***igb_clean_tx_irq-Reclaimresourcesaftertransmitcompletes*@q_vector:pointertoq_vectorcontainingneededinfo
@@ -232,29 +283,265 @@ static int igb_settime(struct ptp_clock_info *ptp, const struct timespec *ts)return0;}-staticintptp_82576_enable(structptp_clock_info*ptp,-structptp_clock_request*rq,inton)+staticintigb_ptp_enable(structptp_clock_info*ptp,+structptp_clock_request*rq,inton){return-EOPNOTSUPP;}-staticintptp_82580_enable(structptp_clock_info*ptp,-structptp_clock_request*rq,inton)+staticvoidigb_ptp_overflow_check(structwork_struct*work){-return-EOPNOTSUPP;+structigb_adapter*igb=+container_of(work,structigb_adapter,ptp_overflow_work.work);+structtimespects;++igb_ptp_gettime(&igb->ptp_caps,&ts);++pr_debug("igb overflow check at %ld.%09lu\n",ts.tv_sec,ts.tv_nsec);++schedule_delayed_work(&igb->ptp_overflow_work,+IGB_SYSTIM_OVERFLOW_PERIOD);}-staticvoidigb_overflow_check(structwork_struct*work)+/**+*igb_ptp_tx_hwtstamp-utilityfunctionwhichchecksforTXtimestamp+*@q_vector:pointertoq_vectorcontainingneededinfo+*@buffer:pointertoigb_tx_bufferstructure+*+*Ifwewereaskedtodohardwarestampingandsuchatimestampis+*available,thenitmusthavebeenforthisskbherebecauseweonly+*allowonlyonesuchpacketintothequeue.+*/+voidigb_ptp_tx_hwtstamp(structigb_q_vector*q_vector,+structigb_tx_buffer*buffer_info){-structtimespects;-structigb_adapter*igb=-container_of(work,structigb_adapter,overflow_work.work);+structigb_adapter*adapter=q_vector->adapter;+structe1000_hw*hw=&adapter->hw;+structskb_shared_hwtstampsshhwtstamps;+u64regval;-igb_gettime(&igb->caps,&ts);+/* if skb does not support hw timestamp or TX stamp not valid exit */+if(likely(!(buffer_info->tx_flags&IGB_TX_FLAGS_TSTAMP))||+!(rd32(E1000_TSYNCTXCTL)&E1000_TSYNCTXCTL_VALID))+return;-pr_debug("igb overflow check at %ld.%09lu\n",ts.tv_sec,ts.tv_nsec);+regval=rd32(E1000_TXSTMPL);+regval|=(u64)rd32(E1000_TXSTMPH)<<32;-schedule_delayed_work(&igb->overflow_work,IGB_OVERFLOW_PERIOD);+igb_ptp_systim_to_hwtstamp(adapter,&shhwtstamps,regval);+skb_tstamp_tx(buffer_info->skb,&shhwtstamps);+}++voidigb_ptp_rx_hwtstamp(structigb_q_vector*q_vector,+unione1000_adv_rx_desc*rx_desc,+structsk_buff*skb)+{+structigb_adapter*adapter=q_vector->adapter;+structe1000_hw*hw=&adapter->hw;+u64regval;++if(!igb_test_staterr(rx_desc,E1000_RXDADV_STAT_TSIP|+E1000_RXDADV_STAT_TS))+return;++/*+*Ifthisbitisset,thentheRXregisterscontainthetimestamp.No+*otherpacketwillbetimestampeduntilwereadtheseregisters,so+*readtheregisterstomakethemavailableagain.Becauseonlyone+*packetcanbetimestampedatatime,weknowthattheregister+*valuesmustbelongtothisonehereandthereforewedon'tneedto+*compareanyoftheadditionalattributesstoredforit.+*+*Ifnothingwentwrong,thenitshouldhaveasharedtx_flagsthatwe+*canturnintoaskb_shared_hwtstamps.+*/+if(igb_test_staterr(rx_desc,E1000_RXDADV_STAT_TSIP)){+u32*stamp=(u32*)skb->data;+regval=le32_to_cpu(*(stamp+2));+regval|=(u64)le32_to_cpu(*(stamp+3))<<32;+skb_pull(skb,IGB_TS_HDR_LEN);+}else{+if(!(rd32(E1000_TSYNCRXCTL)&E1000_TSYNCRXCTL_VALID))+return;++regval=rd32(E1000_RXSTMPL);+regval|=(u64)rd32(E1000_RXSTMPH)<<32;+}++igb_ptp_systim_to_hwtstamp(adapter,skb_hwtstamps(skb),regval);+}++/**+*igb_ptp_hwtstamp_ioctl-controlhardwaretimestamping+*@netdev:+*@ifreq:+*@cmd:+*+*Outgoingtimestampingcanbeenabledanddisabled.Playniceand+*disableitwhenrequested,althoughitshouldn'tcaseanyoverhead+*whennopacketneedsit.Atmostonepacketinthequeuemaybe+*markedfortimestamping,otherwiseitwouldbeimpossibletotell+*forsuretowhichpacketthehardwaretimestampbelongs.+*+*Incomingtimestampinghastobeconfiguredviathehardware+*filters.Notallcombinationsaresupported,inparticularevent+*typehastobespecified.Matchingthekindofeventpacketis+*notsupported,withtheexceptionof"all V2 events regardless of+*level2or4".+*+**/+intigb_ptp_hwtstamp_ioctl(structnet_device*netdev,+structifreq*ifr,intcmd)+{+structigb_adapter*adapter=netdev_priv(netdev);+structe1000_hw*hw=&adapter->hw;+structhwtstamp_configconfig;+u32tsync_tx_ctl=E1000_TSYNCTXCTL_ENABLED;+u32tsync_rx_ctl=E1000_TSYNCRXCTL_ENABLED;+u32tsync_rx_cfg=0;+boolis_l4=false;+boolis_l2=false;+u32regval;++if(copy_from_user(&config,ifr->ifr_data,sizeof(config)))+return-EFAULT;++/* reserved for future extensions */+if(config.flags)+return-EINVAL;++switch(config.tx_type){+caseHWTSTAMP_TX_OFF:+tsync_tx_ctl=0;+caseHWTSTAMP_TX_ON:+break;+default:+return-ERANGE;+}++switch(config.rx_filter){+caseHWTSTAMP_FILTER_NONE:+tsync_rx_ctl=0;+break;+caseHWTSTAMP_FILTER_PTP_V1_L4_EVENT:+caseHWTSTAMP_FILTER_PTP_V2_L4_EVENT:+caseHWTSTAMP_FILTER_PTP_V2_L2_EVENT:+caseHWTSTAMP_FILTER_ALL:+/*+*registerTSYNCRXCFGmustbeset,thereforeitisnot+*possibletotimestampbothSyncandDelay_Reqmessages+*=>fallbacktotimestampingallpackets+*/+tsync_rx_ctl|=E1000_TSYNCRXCTL_TYPE_ALL;+config.rx_filter=HWTSTAMP_FILTER_ALL;+break;+caseHWTSTAMP_FILTER_PTP_V1_L4_SYNC:+tsync_rx_ctl|=E1000_TSYNCRXCTL_TYPE_L4_V1;+tsync_rx_cfg=E1000_TSYNCRXCFG_PTP_V1_SYNC_MESSAGE;+is_l4=true;+break;+caseHWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:+tsync_rx_ctl|=E1000_TSYNCRXCTL_TYPE_L4_V1;+tsync_rx_cfg=E1000_TSYNCRXCFG_PTP_V1_DELAY_REQ_MESSAGE;+is_l4=true;+break;+caseHWTSTAMP_FILTER_PTP_V2_L2_SYNC:+caseHWTSTAMP_FILTER_PTP_V2_L4_SYNC:+tsync_rx_ctl|=E1000_TSYNCRXCTL_TYPE_L2_L4_V2;+tsync_rx_cfg=E1000_TSYNCRXCFG_PTP_V2_SYNC_MESSAGE;+is_l2=true;+is_l4=true;+config.rx_filter=HWTSTAMP_FILTER_SOME;+break;+caseHWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:+caseHWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:+tsync_rx_ctl|=E1000_TSYNCRXCTL_TYPE_L2_L4_V2;+tsync_rx_cfg=E1000_TSYNCRXCFG_PTP_V2_DELAY_REQ_MESSAGE;+is_l2=true;+is_l4=true;+config.rx_filter=HWTSTAMP_FILTER_SOME;+break;+caseHWTSTAMP_FILTER_PTP_V2_EVENT:+caseHWTSTAMP_FILTER_PTP_V2_SYNC:+caseHWTSTAMP_FILTER_PTP_V2_DELAY_REQ:+tsync_rx_ctl|=E1000_TSYNCRXCTL_TYPE_EVENT_V2;+config.rx_filter=HWTSTAMP_FILTER_PTP_V2_EVENT;+is_l2=true;+is_l4=true;+break;+default:+return-ERANGE;+}++if(hw->mac.type==e1000_82575){+if(tsync_rx_ctl|tsync_tx_ctl)+return-EINVAL;+return0;+}++/*+*Per-packettimestampingonlyworksifallpacketsare+*timestamped,soenabletimestampinginallpacketsas+*longasonerxfilterwasconfigured.+*/+if((hw->mac.type>=e1000_82580)&&tsync_rx_ctl){+tsync_rx_ctl=E1000_TSYNCRXCTL_ENABLED;+tsync_rx_ctl|=E1000_TSYNCRXCTL_TYPE_ALL;+}++/* enable/disable TX */+regval=rd32(E1000_TSYNCTXCTL);+regval&=~E1000_TSYNCTXCTL_ENABLED;+regval|=tsync_tx_ctl;+wr32(E1000_TSYNCTXCTL,regval);++/* enable/disable RX */+regval=rd32(E1000_TSYNCRXCTL);+regval&=~(E1000_TSYNCRXCTL_ENABLED|E1000_TSYNCRXCTL_TYPE_MASK);+regval|=tsync_rx_ctl;+wr32(E1000_TSYNCRXCTL,regval);++/* define which PTP packets are time stamped */+wr32(E1000_TSYNCRXCFG,tsync_rx_cfg);++/* define ethertype filter for timestamped packets */+if(is_l2)+wr32(E1000_ETQF(3),+(E1000_ETQF_FILTER_ENABLE|/* enable filter */+E1000_ETQF_1588|/* enable timestamping */+ETH_P_1588));/* 1588 eth protocol type */+else+wr32(E1000_ETQF(3),0);++#define PTP_PORT 319+/* L4 Queue Filter[3]: filter by destination port and protocol */+if(is_l4){+u32ftqf=(IPPROTO_UDP/* UDP */+|E1000_FTQF_VF_BP/* VF not compared */+|E1000_FTQF_1588_TIME_STAMP/* Enable Timestamping */+|E1000_FTQF_MASK);/* mask all inputs */+ftqf&=~E1000_FTQF_MASK_PROTO_BP;/* enable protocol check */++wr32(E1000_IMIR(3),htons(PTP_PORT));+wr32(E1000_IMIREXT(3),+(E1000_IMIREXT_SIZE_BP|E1000_IMIREXT_CTRL_BP));+if(hw->mac.type==e1000_82576){+/* enable source port check */+wr32(E1000_SPQF(3),htons(PTP_PORT));+ftqf&=~E1000_FTQF_MASK_SOURCE_PORT_BP;+}+wr32(E1000_FTQF(3),ftqf);+}else{+wr32(E1000_FTQF(3),E1000_FTQF_MASK);+}+wrfl();++/* clear TX/RX time stamp registers, just to be sure */+regval=rd32(E1000_TXSTMPH);+regval=rd32(E1000_RXSTMPH);++returncopy_to_user(ifr->ifr_data,&config,sizeof(config))?+-EFAULT:0;}voidigb_ptp_init(structigb_adapter*adapter)
@@ -266,39 +553,39 @@ void igb_ptp_init(struct igb_adapter *adapter)casee1000_i211:casee1000_i350:casee1000_82580:-adapter->caps.owner=THIS_MODULE;-strcpy(adapter->caps.name,"igb-82580");-adapter->caps.max_adj=62499999;-adapter->caps.n_ext_ts=0;-adapter->caps.pps=0;-adapter->caps.adjfreq=ptp_82580_adjfreq;-adapter->caps.adjtime=igb_adjtime;-adapter->caps.gettime=igb_gettime;-adapter->caps.settime=igb_settime;-adapter->caps.enable=ptp_82580_enable;-adapter->cc.read=igb_82580_systim_read;-adapter->cc.mask=CLOCKSOURCE_MASK(IGB_NBITS_82580);-adapter->cc.mult=1;-adapter->cc.shift=0;+adapter->ptp_caps.owner=THIS_MODULE;+strcpy(adapter->ptp_caps.name,"igb-82580");+adapter->ptp_caps.max_adj=62499999;+adapter->ptp_caps.n_ext_ts=0;+adapter->ptp_caps.pps=0;+adapter->ptp_caps.adjfreq=igb_ptp_adjfreq_82580;+adapter->ptp_caps.adjtime=igb_ptp_adjtime;+adapter->ptp_caps.gettime=igb_ptp_gettime;+adapter->ptp_caps.settime=igb_ptp_settime;+adapter->ptp_caps.enable=igb_ptp_enable;+adapter->cc.read=igb_ptp_read_82580;+adapter->cc.mask=CLOCKSOURCE_MASK(IGB_NBITS_82580);+adapter->cc.mult=1;+adapter->cc.shift=0;/* Enable the timer functions by clearing bit 31. */wr32(E1000_TSAUXC,0x0);break;casee1000_82576:-adapter->caps.owner=THIS_MODULE;-strcpy(adapter->caps.name,"igb-82576");-adapter->caps.max_adj=1000000000;-adapter->caps.n_ext_ts=0;-adapter->caps.pps=0;-adapter->caps.adjfreq=ptp_82576_adjfreq;-adapter->caps.adjtime=igb_adjtime;-adapter->caps.gettime=igb_gettime;-adapter->caps.settime=igb_settime;-adapter->caps.enable=ptp_82576_enable;-adapter->cc.read=igb_82576_systim_read;-adapter->cc.mask=CLOCKSOURCE_MASK(64);-adapter->cc.mult=1;-adapter->cc.shift=IGB_82576_TSYNC_SHIFT;+adapter->ptp_caps.owner=THIS_MODULE;+strcpy(adapter->ptp_caps.name,"igb-82576");+adapter->ptp_caps.max_adj=1000000000;+adapter->ptp_caps.n_ext_ts=0;+adapter->ptp_caps.pps=0;+adapter->ptp_caps.adjfreq=igb_ptp_adjfreq_82576;+adapter->ptp_caps.adjtime=igb_ptp_adjtime;+adapter->ptp_caps.gettime=igb_ptp_gettime;+adapter->ptp_caps.settime=igb_ptp_settime;+adapter->ptp_caps.enable=igb_ptp_enable;+adapter->cc.read=igb_ptp_read_82576;+adapter->cc.mask=CLOCKSOURCE_MASK(64);+adapter->cc.mult=1;+adapter->cc.shift=IGB_82576_TSYNC_SHIFT;/* Dial the nominal frequency. */wr32(E1000_TIMINCA,INCPERIOD_82576|INCVALUE_82576);break;
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-23 11:16:28
On Thu, Aug 23, 2012 at 02:56:51AM -0700, Jeff Kirsher wrote:
From: Matthew Vick <redacted>
Where possible, move PTP-related functions into igb_ptp.c and update the
names of functions and variables to match the established coding style
in the files and specify that they are PTP-specific.
Function renaming as an end in itself? Sounds like churn to me. Also,
I disagree with some of the displacements.
-#ifdef CONFIG_IGB_PTP
-/**
- * igb_tx_hwtstamp - utility function which checks for TX time stamp
- * @q_vector: pointer to q_vector containing needed info
- * @buffer: pointer to igb_tx_buffer structure
- *
- * If we were asked to do hardware stamping and such a time stamp is
- * available, then it must have been for this skb here because we only
- * allow only one such packet into the queue.
- */
-static void igb_tx_hwtstamp(struct igb_q_vector *q_vector,
- struct igb_tx_buffer *buffer_info)
-{
- struct igb_adapter *adapter = q_vector->adapter;
- struct e1000_hw *hw = &adapter->hw;
- struct skb_shared_hwtstamps shhwtstamps;
- u64 regval;
-
- /* if skb does not support hw timestamp or TX stamp not valid exit */
- if (likely(!(buffer_info->tx_flags & IGB_TX_FLAGS_TSTAMP)) ||
- !(rd32(E1000_TSYNCTXCTL) & E1000_TSYNCTXCTL_VALID))
- return;
-
- regval = rd32(E1000_TXSTMPL);
- regval |= (u64)rd32(E1000_TXSTMPH) << 32;
-
- igb_systim_to_hwtstamp(adapter, &shhwtstamps, regval);
- skb_tstamp_tx(buffer_info->skb, &shhwtstamps);
-}
-#endif /* CONFIG_IGB_PTP */
-
Here you have taken a static local function and made it into a global
function. This can have performance impacts.
quoted hunk
/**
* igb_clean_tx_irq - Reclaim resources after transmit completes
* @q_vector: pointer to q_vector containing needed info
This name stinks, too. You know that you can have time stamping all by
itself, right? It is logically separate from the ptp clock stuff.
This patch doesn't really improve the driver at all, IMHO.
Thanks,
Richard
From: Vick, Matthew <hidden> Date: 2012-08-23 16:26:29
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 4:16 AM
To: Kirsher, Jeffrey T
Cc: davem@davemloft.net; Vick, Matthew; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 11/13] igb: Update PTP function names/variables
and locations.
On Thu, Aug 23, 2012 at 02:56:51AM -0700, Jeff Kirsher wrote:
quoted
From: Matthew Vick <redacted>
Where possible, move PTP-related functions into igb_ptp.c and update
the names of functions and variables to match the established coding
style in the files and specify that they are PTP-specific.
Function renaming as an end in itself? Sounds like churn to me. Also, I
disagree with some of the displacements.
The goal was to make it clear what was required for the PTP flow and what wasn't. Again, ixgbe was my reference in this. Personally, I disagree with the old naming scheme.
Why have you moved this block? How are these "PTP-related"?
This is just git's diff being silly. :) Rather than move igb_get_ts_info up, git thought I moved those other functions down. I wanted igb_get_ts_info to be with the other get functions.
quoted
#ifdef CONFIG_IGB_PTP
-static int igb_ethtool_get_ts_info(struct net_device *dev,
+static int igb_get_ts_info(struct net_device *dev,
I like the old name better.
The old name is out of the coding style of igb. Every other function is igb_get_* or igb_set_*, with the exception of igb_ethtool_begin and igb_ethtool_complete. Are you suggesting we add _ethtool to every ethtool function in igb?
quoted
-#ifdef CONFIG_IGB_PTP
-/**
- * igb_tx_hwtstamp - utility function which checks for TX time stamp
- * @q_vector: pointer to q_vector containing needed info
- * @buffer: pointer to igb_tx_buffer structure
- *
- * If we were asked to do hardware stamping and such a time stamp is
- * available, then it must have been for this skb here because we
only
- * allow only one such packet into the queue.
- */
-static void igb_tx_hwtstamp(struct igb_q_vector *q_vector,
- struct igb_tx_buffer *buffer_info)
-{
- struct igb_adapter *adapter = q_vector->adapter;
- struct e1000_hw *hw = &adapter->hw;
- struct skb_shared_hwtstamps shhwtstamps;
- u64 regval;
-
- /* if skb does not support hw timestamp or TX stamp not valid
Here you have taken a static local function and made it into a global
function. This can have performance impacts.
Which, this function calls igb_systim_to_hwtstamp anyway, which is global. Also, in a follow-on patch I have coming, igb_ptp_tx_hwtstamp won't even be called in clean_tx_irq, FWIW.
quoted
/**
* igb_clean_tx_irq - Reclaim resources after transmit completes
* @q_vector: pointer to q_vector containing needed info @@ -5827,7
+5796,7 @@ static bool igb_clean_tx_irq(struct igb_q_vector
This name stinks, too. You know that you can have time stamping all by
itself, right? It is logically separate from the ptp clock stuff.
This patch doesn't really improve the driver at all, IMHO.
Thanks,
Richard
Yes, I'm aware. But, as it stands today, we don't use it for anything else. If the function is feature specific, then we should be calling it out as such.
I'm sorry you feel like this patch doesn't improve the driver. The goal is code cleanup and consistency, both of which I consider to be driver improvements and is why I made the patches.
Cheers,
Matthew
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-23 17:53:49
On Thu, Aug 23, 2012 at 04:22:02PM +0000, Vick, Matthew wrote:
quoted
quoted
#ifdef CONFIG_IGB_PTP
-static int igb_ethtool_get_ts_info(struct net_device *dev,
+static int igb_get_ts_info(struct net_device *dev,
I like the old name better.
The old name is out of the coding style of igb. Every other function is igb_get_* or igb_set_*, with the exception of igb_ethtool_begin and igb_ethtool_complete. Are you suggesting we add _ethtool to every ethtool function in igb?
No, just leave the names alone, and keep the functions where they
are. It is just churn.
One of the most useful ways to understand code (at least for me) is to
use git blame. It tells you when code was added, what the reason was,
and how the change looks in context. By moving and renaming willy
nilly, you are obscuring this valuable information.
quoted
quoted
-#ifdef CONFIG_IGB_PTP
-/**
- * igb_tx_hwtstamp - utility function which checks for TX time stamp
- * @q_vector: pointer to q_vector containing needed info
- * @buffer: pointer to igb_tx_buffer structure
- *
- * If we were asked to do hardware stamping and such a time stamp is
- * available, then it must have been for this skb here because we
only
- * allow only one such packet into the queue.
- */
-static void igb_tx_hwtstamp(struct igb_q_vector *q_vector,
- struct igb_tx_buffer *buffer_info)
-{
- struct igb_adapter *adapter = q_vector->adapter;
- struct e1000_hw *hw = &adapter->hw;
- struct skb_shared_hwtstamps shhwtstamps;
- u64 regval;
-
- /* if skb does not support hw timestamp or TX stamp not valid
This name stinks, too. You know that you can have time stamping all by
itself, right? It is logically separate from the ptp clock stuff.
This patch doesn't really improve the driver at all, IMHO.
Thanks,
Richard
Yes, I'm aware. But, as it stands today, we don't use it for anything else. If the function is feature specific, then we should be calling it out as such.
Right now the time stamping is being equated with the clock functions,
but it really should be decoupled. The 82580 can time stamp every
received packet, which can be interesting for performance monitoring,
even without PTP (and adding *that* would be a useful change).
I'm sorry you feel like this patch doesn't improve the driver. The goal is code cleanup and consistency, both of which I consider to be driver improvements and is why I made the patches.
But the code wasn't dirty in the first place. It doesn't need this
"cleaning." This series undoes the inline-able functions for no good
reason. As far as ixgbe goes, this driver came first, so you might as
well be making *that* driver consistent with this one.
Thanks,
Richard
From: "Keller, Jacob E" <jacob.e.keller@intel.com> Date: 2012-08-23 18:00:40
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Richard Cochran
Sent: Thursday, August 23, 2012 10:54 AM
To: Vick, Matthew
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 11/13] igb: Update PTP function names/variables and
locations.
On Thu, Aug 23, 2012 at 04:22:02PM +0000, Vick, Matthew wrote:
quoted
quoted
quoted
#ifdef CONFIG_IGB_PTP
-static int igb_ethtool_get_ts_info(struct net_device *dev,
+static int igb_get_ts_info(struct net_device *dev,
I like the old name better.
The old name is out of the coding style of igb. Every other function is
igb_get_* or igb_set_*, with the exception of igb_ethtool_begin and
igb_ethtool_complete. Are you suggesting we add _ethtool to every ethtool
function in igb?
No, just leave the names alone, and keep the functions where they are. It
is just churn.
One of the most useful ways to understand code (at least for me) is to use
git blame. It tells you when code was added, what the reason was, and how
the change looks in context. By moving and renaming willy nilly, you are
obscuring this valuable information.
quoted
quoted
quoted
-#ifdef CONFIG_IGB_PTP
-/**
- * igb_tx_hwtstamp - utility function which checks for TX time
stamp
- * @q_vector: pointer to q_vector containing needed info
- * @buffer: pointer to igb_tx_buffer structure
- *
- * If we were asked to do hardware stamping and such a time stamp
is
- * available, then it must have been for this skb here because we
only
- * allow only one such packet into the queue.
- */
-static void igb_tx_hwtstamp(struct igb_q_vector *q_vector,
- struct igb_tx_buffer *buffer_info)
-{
- struct igb_adapter *adapter = q_vector->adapter;
- struct e1000_hw *hw = &adapter->hw;
- struct skb_shared_hwtstamps shhwtstamps;
- u64 regval;
-
- /* if skb does not support hw timestamp or TX stamp not valid
This name stinks, too. You know that you can have time stamping all
by itself, right? It is logically separate from the ptp clock stuff.
This patch doesn't really improve the driver at all, IMHO.
Thanks,
Richard
Yes, I'm aware. But, as it stands today, we don't use it for anything
else. If the function is feature specific, then we should be calling it
out as such.
Right now the time stamping is being equated with the clock functions, but
it really should be decoupled. The 82580 can time stamp every received
packet, which can be interesting for performance monitoring, even without
PTP (and adding *that* would be a useful change).
The timestamp all does not really work with the ptp clock features gone, because you don't have the clock. You can't equate the time values of the packets when the clock isn't synched to something meaningful. Yes that does not require PTP adjustment functions, but it does require the SYSTIME setup and some method to get the clock correct, which currently is only done in the PTP init sequence. Timestamp all packets also can cause a performance hit when used with certain workloads.
quoted
I'm sorry you feel like this patch doesn't improve the driver. The goal
is code cleanup and consistency, both of which I consider to be driver
improvements and is why I made the patches.
But the code wasn't dirty in the first place. It doesn't need this
"cleaning." This series undoes the inline-able functions for no good
reason. As far as ixgbe goes, this driver came first, so you might as well
be making *that* driver consistent with this one.
ixgbe hardware is (currently) even more closely synched with PTP for the register bits so it does make some sense for ixgbe to remain the way it is. Right now the igb features are partially synched (even before this change) in odd ways. The time values returned when PHC information is disabled are basically only useful for comparing between themselves, not with any meaningful clock on the device.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-23 18:11:30
On Thu, Aug 23, 2012 at 06:00:37PM +0000, Keller, Jacob E wrote:
quoted
Right now the time stamping is being equated with the clock functions, but
it really should be decoupled. The 82580 can time stamp every received
packet, which can be interesting for performance monitoring, even without
PTP (and adding *that* would be a useful change).
The timestamp all does not really work with the ptp clock features
gone, because you don't have the clock. You can't equate the time
values of the packets when the clock isn't synched to something
meaningful. Yes that does not require PTP adjustment functions, but
it does require the SYSTIME setup and some method to get the clock
correct, which currently is only done in the PTP init sequence.
Relative, high resolution time stamps can be interesting all by
themselves. That is why wireshark has a whole menu of timing choices
including relative since start, inter-packet, and so on.
Timestamp all packets also can cause a performance hit when used with certain workloads.
Only when enabled.
ixgbe hardware is (currently) even more closely synched with PTP for the register bits so it does make some sense for ixgbe to remain the way it is. Right now the igb features are partially synched (even before this change) in odd ways. The time values returned when PHC information is disabled are basically only useful for comparing between themselves, not with any meaningful clock on the device.
Yes, I agree that igb is a bit oddly synced WRT clock and time
stamping. I would welcome a change to let it have HW time stamping as
an independent feature.
Thanks,
Richard
From: Vick, Matthew <hidden> Date: 2012-08-23 18:45:54
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 11:11 AM
To: Keller, Jacob E
Cc: Vick, Matthew; Kirsher, Jeffrey T; davem@davemloft.net;
netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 11/13] igb: Update PTP function names/variables
and locations.
[...]
Relative, high resolution time stamps can be interesting all by
themselves. That is why wireshark has a whole menu of timing choices
including relative since start, inter-packet, and so on.
[...]
Yes, I agree that igb is a bit oddly synced WRT clock and time
stamping. I would welcome a change to let it have HW time stamping as
an independent feature.
Thanks,
Richard
Isn't this discussion creeping outside the scope of this patch? My aim here with this patch is to help tidy up PTP code as it is today. As it is today, igb has no support for hardware timestamping without PTP. If you or someone else writes a follow-on patch to add hardware timestamping without PTP, then they can move and rename the functions accordingly (and I'd personally really appreciate it if they did rename it, since a generic function should be named like a generic function and a PTP function should be named like a PTP function).
Cheers,
Matthew
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-24 06:56:07
On Thu, Aug 23, 2012 at 06:44:24PM +0000, Vick, Matthew wrote:
Isn't this discussion creeping outside the scope of this patch?
Yes, it is. I am suggesting that the driver could use improvement, but
not by renaming functions to suit your or someone else's taste.
Instead, you could work on the time stamping feature.
(And if, along the way, you end up renaming the functions that you
change, then I won't complain ;)
Thanks,
Richard
From: Vick, Matthew <hidden> Date: 2012-08-24 15:52:33
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 11:56 PM
To: Vick, Matthew
Cc: Keller, Jacob E; Kirsher, Jeffrey T; davem@davemloft.net;
netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 11/13] igb: Update PTP function names/variables
and locations.
On Thu, Aug 23, 2012 at 06:44:24PM +0000, Vick, Matthew wrote:
quoted
Isn't this discussion creeping outside the scope of this patch?
Yes, it is. I am suggesting that the driver could use improvement, but
not by renaming functions to suit your or someone else's taste.
Instead, you could work on the time stamping feature.
(And if, along the way, you end up renaming the functions that you
change, then I won't complain ;)
Thanks,
Richard
Looking over the discussions and by trying to reach consensus, I think what I will do is re-spin patch 3 that Jeff sent (Correct PTP support query from ethtool.) to V2 with your feedback and work with Jeff to send all of my patchset up together. This first group of patches is groundwork for the last two. How does this sound?
Cheers,
Matthew
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-25 05:48:58
On Fri, Aug 24, 2012 at 03:52:30PM +0000, Vick, Matthew wrote:
Looking over the discussions and by trying to reach consensus, I think what I will do is re-spin patch 3 that Jeff sent (Correct PTP support query from ethtool.) to V2 with your feedback and work with Jeff to send all of my patchset up together. This first group of patches is groundwork for the last two. How does this sound?
Sound good to me.
BTW, if you have some bug fixes coming (like ifup/ifdown), please put
them *before* any other renaming/refactoring. In that way, the bug fix
can do directly to 3.5 stable, too.
Thanks,
Richard
From: Vick, Matthew <hidden> Date: 2012-08-27 15:23:45
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Friday, August 24, 2012 10:49 PM
To: Vick, Matthew
Cc: Keller, Jacob E; Kirsher, Jeffrey T; davem@davemloft.net;
netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 11/13] igb: Update PTP function names/variables
and locations.
On Fri, Aug 24, 2012 at 03:52:30PM +0000, Vick, Matthew wrote:
quoted
Looking over the discussions and by trying to reach consensus, I
think what I will do is re-spin patch 3 that Jeff sent (Correct PTP
support query from ethtool.) to V2 with your feedback and work with
Jeff to send all of my patchset up together. This first group of
patches is groundwork for the last two. How does this sound?
Sound good to me.
BTW, if you have some bug fixes coming (like ifup/ifdown), please put
them *before* any other renaming/refactoring. In that way, the bug fix
can do directly to 3.5 stable, too.
Thanks,
Richard
Unfortunately, the way I've built the series makes it difficult to put those fixes before the re-factoring. The need for the design change drove the re-factor to give me the foundation. I'll make a note to myself to come up with something to apply to stable.
Cheers,
Matthew
From: Richard Cochran <richardcochran@gmail.com> Date: 2012-08-27 16:44:41
Unfortunately, the way I've built the series makes it difficult to put those fixes before the re-factoring. The need for the design change drove the re-factor to give me the foundation. I'll make a note to myself to come up with something to apply to stable.
Hm, I didn't see anything here that looks like bug fix. Did I miss
something? What causes the ifup/ifdown weirdness, anyhow?
(It seems hard to believe that it has something to do with the names
or locations of the various functions.)
Thanks,
Richard
From: Vick, Matthew <hidden> Date: 2012-08-27 17:39:47
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Monday, August 27, 2012 9:44 AM
To: Vick, Matthew
Cc: Keller, Jacob E; Kirsher, Jeffrey T; davem@davemloft.net;
netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 11/13] igb: Update PTP function names/variables
and locations.
quoted
Unfortunately, the way I've built the series makes it difficult to
put those fixes before the re-factoring. The need for the design change
drove the re-factor to give me the foundation. I'll make a note to
myself to come up with something to apply to stable.
Hm, I didn't see anything here that looks like bug fix. Did I miss
something? What causes the ifup/ifdown weirdness, anyhow?
(It seems hard to believe that it has something to do with the names or
locations of the various functions.)
Thanks,
Richard
Sorry, I wasn't very clear--I mean the bug fix I have for ifup/ifdown is in the next few patches with the implementation change I'm doing, since the code I have in place to fix it applies only to the new implementation. I'll have to make a separate patch for stable to address it there.
If the ifup/ifdown weirdness happens because we never re-enable timestamping in the hardware following reset and the device goes through a reset during an ifdown/ifup cycle. It's a pretty straightforward fix, so it shouldn't be much effort to spin up something for stable.
Matthew
From: Vick, Matthew <hidden> Date: 2012-08-23 18:35:23
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 10:54 AM
To: Vick, Matthew
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 11/13] igb: Update PTP function names/variables
and locations.
On Thu, Aug 23, 2012 at 04:22:02PM +0000, Vick, Matthew wrote:
quoted
quoted
quoted
#ifdef CONFIG_IGB_PTP
-static int igb_ethtool_get_ts_info(struct net_device *dev,
+static int igb_get_ts_info(struct net_device *dev,
I like the old name better.
The old name is out of the coding style of igb. Every other function
is igb_get_* or igb_set_*, with the exception of igb_ethtool_begin and
igb_ethtool_complete. Are you suggesting we add _ethtool to every
ethtool function in igb?
No, just leave the names alone, and keep the functions where they are.
It is just churn.
One of the most useful ways to understand code (at least for me) is to
use git blame. It tells you when code was added, what the reason was,
and how the change looks in context. By moving and renaming willy
nilly, you are obscuring this valuable information.
Repairing is not churn. I think it's better to make the code clearer than require developers use git blame to figure out who named a function in a silly way. I agree, it kind of stinks to lose that history, but I'd rather not skip making the right change because of git blame concerns.
[...]
quoted
Which, this function calls igb_systim_to_hwtstamp anyway, which is
global.
So how does calling two global functions in series improve performance?
It isn't calling two global functions. It's calling a global function that calls a static function.
quoted
Also, in a follow-on patch I have coming, igb_ptp_tx_hwtstamp won't
even be called in clean_tx_irq, FWIW.
If this is part of some larger plan, then it would help to see that
plan.
Definitely fair enough. I will work with Jeff to try and push the whole series next time (at the very least, I'd like to re-spin the series for the ethtool query patch).
quoted
quoted
quoted
/**
* igb_clean_tx_irq - Reclaim resources after transmit completes
* @q_vector: pointer to q_vector containing needed info @@
-5827,7
+5796,7 @@ static bool igb_clean_tx_irq(struct igb_q_vector
This name stinks, too. You know that you can have time stamping all
by itself, right? It is logically separate from the ptp clock
stuff.
quoted
quoted
This patch doesn't really improve the driver at all, IMHO.
Thanks,
Richard
Yes, I'm aware. But, as it stands today, we don't use it for anything
else. If the function is feature specific, then we should be calling it
out as such.
Right now the time stamping is being equated with the clock functions,
but it really should be decoupled. The 82580 can time stamp every
received packet, which can be interesting for performance monitoring,
even without PTP (and adding *that* would be a useful change).
As Jake said, there's no support for hardware timestamping without PTP today. As such, if the function is only useful for that feature, then I think it's less ambiguous to leave it the way I've coded it today. If we de-couple hardware timestamping and clock synchronization, which I wouldn't be opposed to, then the function name can reflect becoming more generic. As it stands, I'd rather not call something generic when it isn't. I think it's misleading, personally.
quoted
I'm sorry you feel like this patch doesn't improve the driver. The
goal is code cleanup and consistency, both of which I consider to be
driver improvements and is why I made the patches.
But the code wasn't dirty in the first place. It doesn't need this
"cleaning." This series undoes the inline-able functions for no good
reason. As far as ixgbe goes, this driver came first, so you might as
well be making *that* driver consistent with this one.
Thanks,
Richard
Actually, yes, the code *was* dirty, because it breaks the coding style of the rest of the driver and isn't as self-documenting as it could be, and the inline-able functions you claim I'm destroying called global functions anyway. Also, just because igb came first doesn't mean we should ignore porting better or clearer solutions from later drivers. If something is better or clearer, I think we should use be using it.
Cheers,
Matthew
From: "Keller, Jacob E" <jacob.e.keller@intel.com> Date: 2012-08-23 18:49:06
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Vick, Matthew
Sent: Thursday, August 23, 2012 11:35 AM
To: Richard Cochran
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: RE: [net-next 11/13] igb: Update PTP function names/variables and
locations.
quoted
-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, August 23, 2012 10:54 AM
To: Vick, Matthew
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 11/13] igb: Update PTP function names/variables
and locations.
On Thu, Aug 23, 2012 at 04:22:02PM +0000, Vick, Matthew wrote:
quoted
quoted
quoted
#ifdef CONFIG_IGB_PTP
-static int igb_ethtool_get_ts_info(struct net_device *dev,
+static int igb_get_ts_info(struct net_device *dev,
I like the old name better.
The old name is out of the coding style of igb. Every other function
is igb_get_* or igb_set_*, with the exception of igb_ethtool_begin and
igb_ethtool_complete. Are you suggesting we add _ethtool to every
ethtool function in igb?
No, just leave the names alone, and keep the functions where they are.
It is just churn.
One of the most useful ways to understand code (at least for me) is to
use git blame. It tells you when code was added, what the reason was,
and how the change looks in context. By moving and renaming willy
nilly, you are obscuring this valuable information.
Repairing is not churn. I think it's better to make the code clearer than
require developers use git blame to figure out who named a function in a
silly way. I agree, it kind of stinks to lose that history, but I'd rather
not skip making the right change because of git blame concerns.
The history isn't lost, it is just obscured. I agree if the change is necessary it should be done. I think we all disagree on what is necessary. I would prefer function names to match. Richard has a point regarding the time stamping all packets, however again the ioctl turning that on tends to be quite PTP centric already. I think that value isn't necessarily added due to the current coupling of the features. It is partially coupled by the hardware anyways.
Effectively with the PTP framework disabled you have a half useful feature that is enabled by a strange ioctl that has a lot of PTP specific names, and doesn't always do what you want.
I am not sure how much work would be required to get to a state where the separation of function makes sense.
- Jake
quoted
[...]
quoted
Which, this function calls igb_systim_to_hwtstamp anyway, which is
global.
So how does calling two global functions in series improve performance?
It isn't calling two global functions. It's calling a global function that
calls a static function.
quoted
quoted
Also, in a follow-on patch I have coming, igb_ptp_tx_hwtstamp won't
even be called in clean_tx_irq, FWIW.
If this is part of some larger plan, then it would help to see that
plan.
Definitely fair enough. I will work with Jeff to try and push the whole
series next time (at the very least, I'd like to re-spin the series for
the ethtool query patch).
quoted
quoted
quoted
quoted
/**
* igb_clean_tx_irq - Reclaim resources after transmit completes
* @q_vector: pointer to q_vector containing needed info @@
-5827,7
+5796,7 @@ static bool igb_clean_tx_irq(struct igb_q_vector
This name stinks, too. You know that you can have time stamping
all by itself, right? It is logically separate from the ptp clock
stuff.
quoted
quoted
This patch doesn't really improve the driver at all, IMHO.
Thanks,
Richard
Yes, I'm aware. But, as it stands today, we don't use it for
anything
else. If the function is feature specific, then we should be calling
it out as such.
Right now the time stamping is being equated with the clock functions,
but it really should be decoupled. The 82580 can time stamp every
received packet, which can be interesting for performance monitoring,
even without PTP (and adding *that* would be a useful change).
As Jake said, there's no support for hardware timestamping without PTP
today. As such, if the function is only useful for that feature, then I
think it's less ambiguous to leave it the way I've coded it today. If we
de-couple hardware timestamping and clock synchronization, which I
wouldn't be opposed to, then the function name can reflect becoming more
generic. As it stands, I'd rather not call something generic when it
isn't. I think it's misleading, personally.
quoted
quoted
I'm sorry you feel like this patch doesn't improve the driver. The
goal is code cleanup and consistency, both of which I consider to be
driver improvements and is why I made the patches.
But the code wasn't dirty in the first place. It doesn't need this
"cleaning." This series undoes the inline-able functions for no good
reason. As far as ixgbe goes, this driver came first, so you might as
well be making *that* driver consistent with this one.
Thanks,
Richard
Actually, yes, the code *was* dirty, because it breaks the coding style of
the rest of the driver and isn't as self-documenting as it could be, and
the inline-able functions you claim I'm destroying called global functions
anyway. Also, just because igb came first doesn't mean we should ignore
porting better or clearer solutions from later drivers. If something is
better or clearer, I think we should use be using it.
Cheers,
Matthew
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
From: Vick, Matthew <hidden> Date: 2012-08-23 18:58:23
-----Original Message-----
From: Keller, Jacob E
Sent: Thursday, August 23, 2012 11:48 AM
To: Vick, Matthew; Richard Cochran
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; sassmann@redhat.com
Subject: RE: [net-next 11/13] igb: Update PTP function names/variables
and locations.
[...]
The history isn't lost, it is just obscured. I agree if the change is
necessary it should be done. I think we all disagree on what is
necessary. I would prefer function names to match. Richard has a point
regarding the time stamping all packets, however again the ioctl
turning that on tends to be quite PTP centric already. I think that
value isn't necessarily added due to the current coupling of the
features. It is partially coupled by the hardware anyways.
Effectively with the PTP framework disabled you have a half useful
feature that is enabled by a strange ioctl that has a lot of PTP
specific names, and doesn't always do what you want.
I am not sure how much work would be required to get to a state where
the separation of function makes sense.
- Jake
Fair point about the history.
Since these functions are tightly coupled with PTP, it makes sense to call them that for now. Long-term, I completely agree with Richard--once the function is independent of PTP, we should give it a generic name.
Cheers,
Matthew