Re: [v1 0/6] *** nps_enet fixups ***
From: Noam Camus Date: Tue, 18 Aug 2015 05:04:20 + > I followed "Hardware Architecture" section from: > http://www.linuxfoundation.org/collaborate/workgroups/networking/napi > and came up with "reduce processing latency" idea. That document has lots of incorrect advice, that's for sure. For one thing, it also says to count TX work against the budget, you absolutely should not do this. TX work is "free" compared to RX work (which is several orders of magnitude more expensive) and therefore should not count against the NAPI budget value. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [v1 0/6] *** nps_enet fixups ***
From: David Miller [mailto:da...@davemloft.net] Sent: Monday, August 17, 2015 8:36 PM > You should not move TX completion out of NAPI handling, NAPI poll is exactly > where it belongs. > > If you handle it in hardware interrupt context you have to use > dev_kfree_skb_irq() which defers the operation to software interrupt context > anyways and is thus expensive. > Whereas if you keep TX completion in your NAPI handler the kfree is handled > synchronously and efficiently, as well as making SKB's potentially available > for RX reclaim. I followed "Hardware Architecture" section from: http://www.linuxfoundation.org/collaborate/workgroups/networking/napi and came up with "reduce processing latency" idea. Anyway, I will restore TX completion back to NAPI poll. > I'm not applying this series, you are doing with TX handling exactly what we > tell people not to do. I will come up with revised series in v2. Noam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v1 0/6] *** nps_enet fixups ***
From: Noam Camus Date: Mon, 17 Aug 2015 08:58:33 +0300 > This patch set is a bunch of fixes to make nps_enet work correctly with > all platforms, i.e. real device, emulation system, and simulation system. > The main trigger for this patch set was that in our emulation system > the TX end interrupt is "edge-sensitive" and therefore we cannot use the > cause register since it is not sticky. > Also: > TX is handled during HW interrupt context and not NAPI job. > race with TX done was fixed. > added acknowledge for TX when device is "level sensitive". > enable drop of control frames which is not needed for regular usage. > > So most of this patch set is about TX handling, which is now more complete. You should not move TX completion out of NAPI handling, NAPI poll is exactly where it belongs. If you handle it in hardware interrupt context you have to use dev_kfree_skb_irq() which defers the operation to software interrupt context anyways and is thus expensive. Whereas if you keep TX completion in your NAPI handler the kfree is handled synchronously and efficiently, as well as making SKB's potentially available for RX reclaim. I'm not applying this series, you are doing with TX handling exactly what we tell people not to do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[v1 0/6] *** nps_enet fixups ***
From: Noam Camus This patch set is a bunch of fixes to make nps_enet work correctly with all platforms, i.e. real device, emulation system, and simulation system. The main trigger for this patch set was that in our emulation system the TX end interrupt is "edge-sensitive" and therefore we cannot use the cause register since it is not sticky. Also: TX is handled during HW interrupt context and not NAPI job. race with TX done was fixed. added acknowledge for TX when device is "level sensitive". enable drop of control frames which is not needed for regular usage. So most of this patch set is about TX handling, which is now more complete. Noam Camus (6): NET: nps_enet: replace use of cause register NET: nps_enet: reduce processing latency. NET: nps_enet: TX done race condition NET: nps_enet: drop control frames NET: nps_enet: TX done acknowledge. NET: nps_enet: minor namespace cleanup drivers/net/ethernet/ezchip/nps_enet.c | 44 +-- drivers/net/ethernet/ezchip/nps_enet.h | 20 -- 2 files changed, 24 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [v1 0/6] *** nps_enet fixups ***
From: David Miller [mailto:da...@davemloft.net] Sent: Monday, August 17, 2015 8:36 PM You should not move TX completion out of NAPI handling, NAPI poll is exactly where it belongs. If you handle it in hardware interrupt context you have to use dev_kfree_skb_irq() which defers the operation to software interrupt context anyways and is thus expensive. Whereas if you keep TX completion in your NAPI handler the kfree is handled synchronously and efficiently, as well as making SKB's potentially available for RX reclaim. I followed Hardware Architecture section from: http://www.linuxfoundation.org/collaborate/workgroups/networking/napi and came up with reduce processing latency idea. Anyway, I will restore TX completion back to NAPI poll. I'm not applying this series, you are doing with TX handling exactly what we tell people not to do. I will come up with revised series in v2. Noam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v1 0/6] *** nps_enet fixups ***
From: Noam Camus no...@ezchip.com Date: Tue, 18 Aug 2015 05:04:20 + I followed Hardware Architecture section from: http://www.linuxfoundation.org/collaborate/workgroups/networking/napi and came up with reduce processing latency idea. That document has lots of incorrect advice, that's for sure. For one thing, it also says to count TX work against the budget, you absolutely should not do this. TX work is free compared to RX work (which is several orders of magnitude more expensive) and therefore should not count against the NAPI budget value. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v1 0/6] *** nps_enet fixups ***
From: Noam Camus no...@ezchip.com Date: Mon, 17 Aug 2015 08:58:33 +0300 This patch set is a bunch of fixes to make nps_enet work correctly with all platforms, i.e. real device, emulation system, and simulation system. The main trigger for this patch set was that in our emulation system the TX end interrupt is edge-sensitive and therefore we cannot use the cause register since it is not sticky. Also: TX is handled during HW interrupt context and not NAPI job. race with TX done was fixed. added acknowledge for TX when device is level sensitive. enable drop of control frames which is not needed for regular usage. So most of this patch set is about TX handling, which is now more complete. You should not move TX completion out of NAPI handling, NAPI poll is exactly where it belongs. If you handle it in hardware interrupt context you have to use dev_kfree_skb_irq() which defers the operation to software interrupt context anyways and is thus expensive. Whereas if you keep TX completion in your NAPI handler the kfree is handled synchronously and efficiently, as well as making SKB's potentially available for RX reclaim. I'm not applying this series, you are doing with TX handling exactly what we tell people not to do. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[v1 0/6] *** nps_enet fixups ***
From: Noam Camus no...@ezchip.com This patch set is a bunch of fixes to make nps_enet work correctly with all platforms, i.e. real device, emulation system, and simulation system. The main trigger for this patch set was that in our emulation system the TX end interrupt is edge-sensitive and therefore we cannot use the cause register since it is not sticky. Also: TX is handled during HW interrupt context and not NAPI job. race with TX done was fixed. added acknowledge for TX when device is level sensitive. enable drop of control frames which is not needed for regular usage. So most of this patch set is about TX handling, which is now more complete. Noam Camus (6): NET: nps_enet: replace use of cause register NET: nps_enet: reduce processing latency. NET: nps_enet: TX done race condition NET: nps_enet: drop control frames NET: nps_enet: TX done acknowledge. NET: nps_enet: minor namespace cleanup drivers/net/ethernet/ezchip/nps_enet.c | 44 +-- drivers/net/ethernet/ezchip/nps_enet.h | 20 -- 2 files changed, 24 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
