netdev - Re: [PATCH (net.git) 2/4] stmmac: fix and better tune the default buffer sizes

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]

Date:	Tue, 4 Mar 2014 08:20:49 +0100
From:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
To:	David Laight <David.Laight@...LAB.COM>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH (net.git) 2/4] stmmac: fix and better tune the default
 buffer sizes

Hello David

Sorry, can you tell me what is the final your opinion about
this patch?

I think that it not good to keep 4KiB as default and your main concern
was about the default buffer size that depended on VLAN ifconfig.

So I could adopt 1536bytes as default and remove ifdef.

I'd like to resubmit these first patches that add some relevant fixes
in the driver especially for EEE and chained mode that doesn't work
after latest reworks.

Best Regards
Peppe

On 2/27/2014 2:54 PM, Giuseppe CAVALLARO wrote:
> Hi David
>
> On 2/27/2014 2:31 PM, David Laight wrote:
>> From: Giuseppe CAVALLARO
>> ...
>>>> Also (provided the hardware supports it) the rx buffers (are these
>>>> the ones being sized?) need to be aligned on a 4n+2 boundary in
>>>> order to avoid a realignment copy later on.
>>>
>>> This is true and indeed I had added the STMMAC_ALIGN to align all.
>>> In the past to get the right alignment for SH4.
>>>
>>>> So I'm not sure that some of these sizes are right and/or optimal.
>>>
>>> What do you suggest?
>>>
>>> Maybe, I can use a default for sure < 4KiB suitable to be used for VLAN
>>> frames (it will be aligned later).
>>
>> Dunno... It rather depends on what the length is actually used for!
>> What you don’t want to be doing is adding 2 (for the 4n+2) and then
>> mallocing a 4096+2 byte buffer somewhere.
>
> thanks for your support.
>
> What do you mean for 4n+2?
>
> we reserve 2 more when allocate the skb.
> I had seen that, When I used 2KiB as default this pushes us to allocate
> from the next larger slab on old SH4 platforms and sometime forcing me
> to increment the min_free_kbytes also when we work with the std
> Ethernet MTU :-(.
>
> So for sure 4KiB is really big and not good especially for embedded
> system where this driver lives.
>
>>
>> If the hardware does receive desegmentation, then you need to handle
>> the 64k+ receives somewhere.
>> If it doesn't then it doesn't matter if the hardware rx buffer size is
>> slightly too large (eg for VLAN or encapsulation full sized frames in
>> PPoE).
>> 1536 bytes for the memory buffer avoids cache line sharing (read to
>> offset 2).
>
> IIUC, so what you finally suggest is to use a default value w/o Koption
> and 1536bytes is suitable for vlan etc. This is ok and can be managed
> w/o breaking the compatibility with old mac where the rx hw buffer
> are limited in size and where jumbo is not supported.
>
>> The last ethernet driver I wrote from scratch (maybe 20 years ago) set
>> the rx-ring to point to an array of 512 byte buffers (last was shorter
>> to avoid an extra page) and did an aligned copy into the message buffer.
>> Only frames that crossed the ring end needed two copies.
>> ISTR making the copy be cache line aligned so that a special cache line
>> copy function could be used (I don't know if it ever was).
>> For that system the cost of the aligned data copies was less that the
>> complexity and cost of setting up the iommu.
>
> ok
>
> peppe
>>
>>     David
>>
>>
>>
>>
>>
>
>
>

--
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