Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1208376 > unrolled thread

[v1 0/6] *** nps_enet fixups ***

Back to article view | Back to linux.kernel

Contents

  [v1 0/6] *** nps_enet fixups *** Noam Camus <noamc@ezchip.com> - 2015-08-17 08:00 +0200
    Re: [v1 0/6] *** nps_enet fixups *** David Miller <davem@davemloft.net> - 2015-08-17 19:40 +0200
      RE: [v1 0/6] *** nps_enet fixups *** Noam Camus <noamc@ezchip.com> - 2015-08-18 07:10 +0200
        Re: [v1 0/6] *** nps_enet fixups *** David Miller <davem@davemloft.net> - 2015-08-18 07:30 +0200

#1208376 — [v1 0/6] *** nps_enet fixups ***

From: Noam Camus <noamc@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1208747

From: Noam Camus <noamc@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1209035

From: David Miller [mailto:davem@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1209043

From: Noam Camus <noamc@ezchip.com>
Date: Tue, 18 Aug 2015 05:04:20 +0000

> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web