| To: | Dave Hansen <haveblue@xxxxxxxxxx> |
|---|---|
| Subject: | Re: e1000 performance hack for ppc64 (Power4) |
| From: | Anton Blanchard <anton@xxxxxxxxx> |
| Date: | Sat, 14 Jun 2003 08:38:41 +1000 |
| Cc: | Herman Dierks <hdierks@xxxxxxxxxx>, "Feldman, Scott" <scott.feldman@xxxxxxxxx>, David Gibson <dwg@xxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Nancy J Milliner <milliner@xxxxxxxxxx>, Ricardo C Gonzalez <ricardoz@xxxxxxxxxx>, Brian Twichell <twichell@xxxxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <1055521263.3531.2055.camel@nighthawk> |
| References: | <OF0078342A.E131D4B1-ON85256D44.0051F7C0@pok.ibm.com> <1055521263.3531.2055.camel@nighthawk> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.4i |
> Wouldn't you get most of the benefit from copying that stuff around in > the driver if you allocated the skb->data aligned in the first place? Nice try, but my understanding is that on the transmit path we reserve the maximum sized TCP header, copy the data in then form our TCP header backwards from that point. Since the TCP header size changes with various options, its not an easy task. One thing I thought of doing was to cache the current TCP header size and align the next packet based on it, with an extra cacheline at the start for it to spill into if the TCP header grew. This is only worth it if most packets will have the same sized header. Networking guys: is this a valid assumption? Anton |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [patch] IPV6: Refcount leaks in udpv6_connect(), Ville Nuorvala |
|---|---|
| Next by Date: | Re: e1000 performance hack for ppc64 (Power4), David S. Miller |
| Previous by Thread: | RE: e1000 performance hack for ppc64 (Power4), Dave Hansen |
| Next by Thread: | Re: e1000 performance hack for ppc64 (Power4), David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |