Re: [PATCH net-next] net: macb: replace literal constant with NET_IP_ALIGN
On 07/01/2015 04:44 PM, Eric Dumazet wrote: I really doubt this adapter can process millions of packets per second ? I was suggesting this since I was taking into consideration the comment from skbuff.c, we can save several CPU cycles by avoiding having to disable and re-enable IRQs. Is there a downside to this? I would rather enable GRO, it would be more useful. I had no idea what GRO is, so I have read about it [0] and looked at a couple of drivers which use it. They all seem to replace netif_receive_skb with napi_gro_receive and when there are no more packets in napi_pool they call napi_gro_flush. Is it that simple? Regards [0] https://lwn.net/Articles/358910/ -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: macb: replace literal constant with NET_IP_ALIGN
On 07/01/2015 01:56 PM, Eric Dumazet wrote: Then please use netdev_alloc_skb_ip_align(), so that you get rid of skb_reserve() Thank you for the suggestion. I can do that. A related question, should I also replace netdev_alloc with napi_alloc_skb in places where I have a napi struct? -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
macb: zynq: why is SG disabled?
Hello, After reading the GEM part of Zynq7000 Technical Reference Manual [0], I think that SG should be supported. Is there a reason why SG is disabled in macb for Zynq? Best regards, Nicolae Rosia -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: macb: replace literal constant with NET_IP_ALIGN
On Wed, Jul 1, 2015 at 6:33 PM, Eric Dumazet eric.duma...@gmail.com wrote: [...] This only matters in terms of few nano seconds per packet, so for 10Gb+ NIC anyway. Absolute noise for most NIC. I'll give it a try and benchmark. I achieved a huge speedup by moving TX into napi [0], but my hardware doesn't support multiple TX queues and I can't test that situation. Yes, but main question is : Do you have the hardware to test your changes ? Yes, I have a Xilinx ZC706 board with a Zynq7 XC7Z045 processor [1] [0] https://patchwork.ozlabs.org/patch/488949/ [1] http://www.xilinx.com/products/boards-and-kits/ek-z7-zc706-g.html -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] net: macb: replace literal constant with NET_IP_ALIGN
Signed-off-by: Nicolae Rosia nicolae.ro...@certsign.ro
---
drivers/net/ethernet/cadence/macb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index caeb395..dbb5160 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2554,9 +2554,9 @@ static void at91ether_rx(struct net_device *dev)
while (lp-rx_ring[lp-rx_tail].addr MACB_BIT(RX_USED)) {
p_recv = lp-rx_buffers + lp-rx_tail * AT91ETHER_MAX_RBUFF_SZ;
pktlen = MACB_BF(RX_FRMLEN, lp-rx_ring[lp-rx_tail].ctrl);
- skb = netdev_alloc_skb(dev, pktlen + 2);
+ skb = netdev_alloc_skb(dev, pktlen + NET_IP_ALIGN);
if (skb) {
- skb_reserve(skb, 2);
+ skb_reserve(skb, NET_IP_ALIGN);
memcpy(skb_put(skb, pktlen), p_recv, pktlen);
skb-protocol = eth_type_trans(skb, dev);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: macb napi strange behavior
Hi,
I gave it a shot. Can you please take a look?
I don't know how to deal with multiple queues since Zynq 7000 has one
queue per interface.
I get a performance improvement of over 110 Mbps in IP forwarding (680
Mbps vs 570 Mbps) and a massive reduction of interrupts.
Patch below.
From: Nicolae Rosia nicolae.ro...@certsign.ro
Date: Fri, 26 Jun 2015 19:44:50 +0300
Subject: [PATCH] macb: use tx napi
---
drivers/net/ethernet/cadence/macb.c | 37 ++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 30eedb1..2a3ecf7 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -602,10 +602,13 @@ static void macb_tx_interrupt(struct macb_queue *queue)
{
unsigned int tail;
unsigned int head;
+#if 0
u32 status;
+#endif
struct macb *bp = queue-bp;
u16 queue_index = queue - bp-queues;
+#if 0
status = macb_readl(bp, TSR);
macb_writel(bp, TSR, status);
@@ -614,6 +617,7 @@ static void macb_tx_interrupt(struct macb_queue *queue)
netdev_vdbg(bp-dev, macb_tx_interrupt status = 0x%03lx\n,
(unsigned long)status);
+#endif
head = queue-tx_head;
for (tail = queue-tx_tail; tail != head; tail++) {
@@ -951,12 +955,17 @@ static int macb_poll(struct napi_struct *napi, int budget)
status = macb_readl(bp, RSR);
macb_writel(bp, RSR, status);
-work_done = 0;
+status = macb_readl(bp, TSR);
+if (status) {
+macb_writel(bp, TSR, status);
+macb_tx_interrupt(bp-queues[0]);
+}
netdev_vdbg(bp-dev, poll: status = %08lx, budget = %d\n,
(unsigned long)status, budget);
work_done = bp-macbgem_ops.mog_rx(bp, budget);
+
if (work_done budget) {
napi_complete(napi);
@@ -969,6 +978,16 @@ static int macb_poll(struct napi_struct *napi, int budget)
} else {
macb_writel(bp, IER, MACB_RX_INT_FLAGS);
}
+
+/* Packets received while interrupts were disabled */
+status = macb_readl(bp, TSR);
+if (status) {
+if (bp-caps MACB_CAPS_ISR_CLEAR_ON_WRITE)
+macb_writel(bp, ISR, MACB_BIT(TCOMP));
+napi_reschedule(napi);
+} else {
+macb_writel(bp, IER, MACB_TX_INT_FLAGS);
+}
}
/* TODO: Handle errors */
@@ -1029,8 +1048,17 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
break;
}
-if (status MACB_BIT(TCOMP))
-macb_tx_interrupt(queue);
+if (status MACB_BIT(TCOMP)) {
+/* disable tx interrupts */
+queue_writel(queue, IDR, MACB_TX_INT_FLAGS);
+if (bp-caps MACB_CAPS_ISR_CLEAR_ON_WRITE)
+queue_writel(queue, ISR, MACB_BIT(TCOMP));
+
+if (napi_schedule_prep(bp-napi)) {
+netdev_vdbg(bp-dev, scheduling TX softirq\n);
+__napi_schedule(bp-napi);
+}
+}
/*
* Link change detection isn't possible with RMII, so we'll
@@ -2348,6 +2376,7 @@ static int macb_probe(struct platform_device *pdev)
}
macb_probe_queues(mem, queue_mask, num_queues);
+dev_err(pdev-dev, queue count: %d.\n, num_queues);
dev = alloc_etherdev_mq(sizeof(*bp), num_queues);
if (!dev)
goto err_out_disable_clocks;
@@ -2377,6 +2406,8 @@ static int macb_probe(struct platform_device *pdev)
if (!(queue_mask (1 hw_q)))
continue;
+dev_err(pdev-dev, queue index: %d\n, q);
+
queue = bp-queues[q];
queue-bp = bp;
if (hw_q) {
--
2.1.0
On Sat, Jun 20, 2015 at 7:43 PM, Francois Romieu rom...@fr.zoreil.com wrote:
Florian Fainelli f.faine...@gmail.com :
[...]
Typically, NAPI is used at the receive side of the Ethernet NIC/driver
to lower the hard/soft interrupt context switch, although there is
nothing that prevent you to implement a similar scheme for the
transmit side. Usually, for transmit you will be submitting one packet
for transmission and get a completion interrupt, so without interrupt
coalescing (software or hardware) you can end-up with 1 interrupt per
packet transmitted.
The wording is a bit shy: there is a long standing policy to move
everything to NAPI context (as well as go mostly lockless, etc.).
Any taker to move macb Tx processing to NAPI context or should I consider it ?
--
Ueimor
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: macb napi strange behavior
On Sat, Jun 20, 2015 at 7:43 PM, Francois Romieu rom...@fr.zoreil.com wrote: Florian Fainelli f.faine...@gmail.com : [...] Typically, NAPI is used at the receive side of the Ethernet NIC/driver to lower the hard/soft interrupt context switch, although there is nothing that prevent you to implement a similar scheme for the transmit side. Usually, for transmit you will be submitting one packet for transmission and get a completion interrupt, so without interrupt coalescing (software or hardware) you can end-up with 1 interrupt per packet transmitted. The wording is a bit shy: there is a long standing policy to move everything to NAPI context (as well as go mostly lockless, etc.). Any taker to move macb Tx processing to NAPI context or should I consider it ? I can help with testing! -- To unsubscribe from this list: send the line unsubscribe netdev in
Re: macb napi strange behavior
Hi, On Wed, Jun 17, 2015 at 9:54 PM, Jaeden Amero jaeden.am...@ni.com wrote: On 06/17/2015 11:09 AM, Nicolae Rosia wrote: The times we've seen tons of interrupts on Ethernet with interrupts routed through the PL was when the FPGA was unprogrammed (or in the process of being reprogrammed), or was configured with the interrupt line tied to asserted. In the latter case, Linux would eventually stop handling any more interrupts for that port due to the interrupt storm. This isn't the case. The FPGA is programmed, and indeed I'm using the second MAC routed through PL to SFP. The interesting thing is that I'm seeing the exact behavior on the other side (another Zynq7 board), with eth0 having lots of interrupts. It seems that the interface receiving packets doesn't have a high IRQ activity in contrast to the one sending packets. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
macb napi strange behavior
Hello, I'm trying to determine why I have a huge number of IRQs for only a macb interface and the other one works just fine (low IRQ activity). I have activated IP forward and I'm just forwarding packets from eth0 to eth1. The platform is Zynq7, Linux kernel 4.0, vanilla macb. cat /proc/interrupts: [...] 144: 679425 0 GIC 54 eth0 145: 17867097 0 GIC 77 eth1 [...] Any ideas? Best regards, Nicolae Rosia -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
