linux-kernel - RE: arm: Optimization for ethernet MAC handling at91

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3DBBD805E3BA064A87F551C0E8BD367402897428@MAILSRV.intcomgrp.com>
Date:	Tue, 12 Jan 2010 14:39:43 -0500
From:	"James Kosin" <JKosin@...comgrp.com>
To:	"Eric Dumazet" <eric.dumazet@...il.com>
Cc:	<linux-kernel@...r.kernel.org>,
	"Linux Netdev List" <netdev@...r.kernel.org>
Subject: RE: arm: Optimization for ethernet MAC handling at91_ether.c

-----Original Message-----
>From: Eric Dumazet [mailto:eric.dumazet@...il.com] 
>Sent: Tuesday, January 12, 2010 2:25 PM
>To: James Kosin
>Cc: linux-kernel@...r.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/