netdev - Re: [net] e1000: Small packets may get corrupted during padding by HW

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <50580CDF.5050108@gmail.com>
Date:	Mon, 17 Sep 2012 22:55:43 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, alexander.h.duyck@...el.com,
	tushar.n.dave@...el.com, john.r.fastabend@...el.com,
	mirqus@...il.com, jeffrey.t.kirsher@...el.com,
	netdev@...r.kernel.org, gospo@...hat.com, sassmann@...hat.com
Subject: Re: [net] e1000: Small packets may get corrupted during padding by
 HW

On 9/17/2012 10:45 PM, Eric Dumazet wrote:
> On Mon, 2012-09-17 at 20:27 -0700, Alexander Duyck wrote:
>
>> It also just occurred to me that there might be some benefit in cache
>> aligning the max header size.  It seems like doing something like that
>> should reduce the overall memory footprint and would probably improve
>> performance.
> Given that most ACK packets are 66 bytes (14 ethernet + 20 IP + 32 TCP),
> I am not sure we need to make any tweak on alignment ?
I'm honestly not sure myself.  I will probably spend a few hours 
tomorrow tweaking a few things to test and see if there is any gain to 
be had there.  The only reason why it occurred to me is that it really 
isn't too far off from what we did back on the Rx side, except for there 
we were aligning at the start of the buffer and working our way up.

Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html