netdev - Re: [REGRESSION] r8169: jumbo fixes caused jumbo regressions!

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: <20121113223512.GA29342@electric-eye.fr.zoreil.com>
Date:	Tue, 13 Nov 2012 23:35:12 +0100
From:	Francois Romieu <romieu@...zoreil.com>
To:	Kirill Smelkov <kirr@....spb.ru>
Cc:	Realtek linux nic maintainers <nic_swsd@...ltek.com>,
	Hayes Wang <hayeswang@...ltek.com>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	netdev@...r.kernel.org
Subject: Re: [REGRESSION] r8169: jumbo fixes caused jumbo regressions!

Kirill Smelkov <kirr@....spb.ru> :
[...]
> My test is to stream raw video from 8 PAL cameras to net - 4 for 720x576@25 and
> 4 for 360x288@25 which for YUYV format occupies ~ 860 Mbps of bandwidth. The
> program to transmit/receive video is here: http://repo.or.cz/w/rawv.git

$ git clone  http://repo.or.cz/w/rawv.git
Cloning into 'rawv'...
fatal: http://repo.or.cz/w/rawv.git/info/refs not valid: is this a git repository?

[...]
> (by the way, on atom system, without tx csum offload, half of cpu time
> is spent only to calculate checksums...)

:o(

> Now I wonder, where that 6K limit came from and why they say it is now
> not possible to use jumbos together with tx csum offload ?

Here is an excerpt from a mail where Hayes explained the rules of
engagement back in may 2011 (John Lumby and Chris Friesen were Cced then):

! The Max tx sizes for 8168 series are as following:
! 
! 8168B is 4K bytes.
! 8168C and 8168CP are 6K bytes.
! 8168D and later are 9K bytes.
! 
! Note that these sizes all include head size. That is, the mtu must less than
! these values.
! You have to enable Jumbo frame feature when the tx size is large, otherwise the
! packet would not be sent. Because the hw doesn't provide the threshold, the
! checking for MTU > 1500 is just for convenience for sw.
! 
! The TSO couldn't work with some feature which need to disable hw checksum, such
! as Jumbo frame. The hw checksum have to be disabled in certain situations, so
! the TSO feature should be checked in these situations, too.

> Is my testing enough to justify raising the limits and allowing tx offload ?

I don't oppose knobs to go off-limits but I'll need some rather good reason
before changing the manufacturer's suggested defaults.

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