netdev - Re: [PATCH RFC 0/5] net:stmmac: fix jumbo frames handling and optimisation

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:	Fri, 18 Oct 2013 18:24:04 +0200
From:	Jimmy PERCHET <jimmy.perchet@...rot.com>
To:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
CC:	<netdev@...r.kernel.org>, Jimmy Perchet <jimmy.perchet@...rot.com>
Subject: Re: [PATCH RFC 0/5] net:stmmac: fix jumbo frames handling and optimisation

Hello Peppe,

Thanks for your concern,

I add some details :

> I tested jumbo on chips w/o enhanced some time ago, so welcome further
> tests as you did (maybe on new chips).

I'm working with 3.71a version, in 2KiB + 2KiB configuration.

>> *(1/5) Threshold dma mode is needed on rx path if jumbo frames are expected.
> 
> hmm, this depends on the HW. In the past I used HW with a Fifo that is
> 16KiB for rx buffers and 8KiB for tx.

I used rxfifo_over_2048 flag in order to guess if threshold mode is necessary.


>> *(3/5) On low speed link (10MBit/s), some TX descriptors can remain dirty
>> if the tx coalescence timer expires before they were treated. Re-arm timer
>> in this case.
> 
> hmm not clear to me, let me look at the patch. I hope the link should
> not impact... never seen on my side.
> 
Tx coalescence default parameters are : one interrupt every 64 descriptors
and 40ms timer.
Let say, one is transferring 63 jumbo frames(9KiB) over 10Mb/s link:
* 63<64 there is no interrupt.
* when the timer expires, only 5 descriptors have to be cleaned.(40ms@...b/s)
* at the end, 58 dirty descriptors remain.
Normally, they will be cleaned at the next transfer. The real problem appears
if the socket's "wmem" is too small. The transfer stall :
*Socket is waiting for buffer's cleanup before performing a new transfer.
*Driver is waiting for new transfer before performing cleanup.
Re-arming the timer allows to continue cleanup, thus the socket's
wake-up threshold will be reach.


Best Regards,
Jimmy

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