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  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:	Wed, 14 Nov 2012 13:25:30 +0400
From:	Kirill Smelkov <>
To:	Francois Romieu <>
Cc:	Realtek linux nic maintainers <>,
	Hayes Wang <>,
	"David S. Miller" <>,
	Greg Kroah-Hartman <>,
Subject: Re: [REGRESSION] r8169: jumbo fixes caused jumbo regressions!

On Tue, Nov 13, 2012 at 11:35:12PM +0100, Francois Romieu wrote:
> Kirill Smelkov <> :
> [...]
> > 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:
> $ git clone
> Cloning into 'rawv'...
> fatal: not valid: is this a git repository?

That's a gitweb view. The actual git repo is here:


sorry for confusion.

( if you'll want to test with vivi on a slow system, you'll need my
  patches, currently staging in media-tree patchwork, or available here:

  git://   vivi-speedup-and-fps.over-net-next )

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

yes, that large. In top, my workload is

                                %sy     %id     %si
    default driver load         ~25     ~45     ~27
    (ethtool -k shows
     tx-checksumming: off)

    after                        ~8     ~81     ~11
    `ethtool -K eth0 tx on`

that's why the issue is important.

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

Can't find that mail in gmane netdev archive and on google, to restore
full context. Was that in private?

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

This part is clear.

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

I don't enable TSO nor I need it. The text indirectly says that hw
checksum should be disabled when jumbo frames are used.


Hayes, Realtek linux nic maintainers,

    could you please confirm that for all 8168C and 8168CP jumbo_max is
    6K and that when jumbos are used, tx checksumming should be off?

    If so, how come my two chips work stable with ~7K jumbos and tx checksum
    offload on (tested this night again for ~16 hours without any problem).

    thanks beforehand.

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

Thanks. Let's see what Realtek people say.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists