Messages in this thread | | | Subject | RE: arm: Optimization for ethernet MAC handling at91_ether.c | Date | Tue, 12 Jan 2010 14:39:43 -0500 | From | "James Kosin" <> |
| |
-----Original Message----- >From: Eric Dumazet [mailto:eric.dumazet@gmail.com] >Sent: Tuesday, January 12, 2010 2:25 PM >To: James Kosin >Cc: linux-kernel@vger.kernel.org; Linux Netdev List >Subject: Re: arm: Optimization for ethernet MAC handling at91_ether.c > >Le 12/01/2010 20:03, James Kosin a écrit : >> >> Scratch that. The interrupt doesn't queue up or send another packet directly. So, it wouldn't help on performance here. But, may in other implementations that queue/transmit packets in the ISR. At least in the case where the transmitter is limited to one. >> > >It could, at least on SMP. tx completion wakes a blocked sender, while >this cpu continue with RX handling (possibly expensive) > >But even on UP, doing tx completion before rx handling allows >a better reuse of skb just freed (and partly present in cpu cache, if available). > >Start of IRQ > >1) tx completion > -> free a skb > >2) rx handling: > -> allocate an skb, kmalloc() reuses previous one, still in cpu cache. > >End of IRQ
I think this may work to improve things slightly; since, the transmitter always frees the skb regardless of error or success currently.
What I was proposing was to modify the sequence slightly to be more like this:
1) tx completion -> test for TX TUND error -> resend the current skb (to avoid having to re-do) -> else -> test for TX RTRY error -> increment error count as before -> free the skb
-- 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/
| |