linux-kernel - RE: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AM4PR0401MB2260F7ADB5A5567F0896A81DFF8C0@AM4PR0401MB2260.eurprd04.prod.outlook.com>
Date:   Wed, 30 Nov 2016 07:35:13 +0000
From:   Andy Duan <fugang.duan@....com>
To:     Nikita Yushchenko <nikita.yoush@...entembedded.com>,
        "David S. Miller" <davem@...emloft.net>,
        Troy Kisky <troy.kisky@...ndarydevices.com>,
        "Andrew Lunn" <andrew@...n.ch>, Eric Nelson <eric@...int.com>,
        Philippe Reynes <tremyfr@...il.com>,
        Johannes Berg <johannes@...solutions.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Chris Healy <cphealy@...il.com>,
        Fabio Estevam <fabio.estevam@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [patch net / RFC] net: fec: increase frame size limitation to
 actually available buffer

From: Nikita Yushchenko <nikita.yoush@...entembedded.com> Sent: Wednesday, November 30, 2016 2:36 PM
 >To: Andy Duan <fugang.duan@....com>; David S. Miller
 ><davem@...emloft.net>; Troy Kisky <troy.kisky@...ndarydevices.com>;
 >Andrew Lunn <andrew@...n.ch>; Eric Nelson <eric@...int.com>; Philippe
 >Reynes <tremyfr@...il.com>; Johannes Berg <johannes@...solutions.net>;
 >netdev@...r.kernel.org
 >Cc: Chris Healy <cphealy@...il.com>; Fabio Estevam
 ><fabio.estevam@....com>; linux-kernel@...r.kernel.org
 >Subject: Re: [patch net / RFC] net: fec: increase frame size limitation to
 >actually available buffer
 >
 >> But I think it is not necessary since the driver don't support jumbo frame.
 >
 >Hardcoded 1522 raises two separate issues.
 >
 >(1) When DSA is in use, frames processed by FEC chip contain DSA tag and
 >thus can be larger than hardcoded limit of 1522. This issue is not FEC-specific,
 >any driver that hardcodes maximum frame size to 1522 (many
 >do) will have this issue if used with DSA.
 >
 >Clean solution for this must take into account that difference between MTU
 >and max frame size is no longer known at compile time. Actually this is the
 >case even without DSA, due to VLANs: max frame size is (MTU + 18) without
 >VLANs, but (MTU + 22) with VLANs. However currently drivers tend to ignore
 >this and hardcode 22.  With DSA, 22 is not enough, need to add switch-
 >specific tag size to that.
 >
 >Not yet sure how to handle this. DSA-specific API to find out tag size could be
 >added, but generic solution should handle all cases of dynamic difference
 >between MTU and max frame size, not only DSA.
 >
 >
 >(2) There is some demand to use larger frames for optimization purposes.
 >
 >FEC register fields that limit frame size are 14-bit, thus allowing frames up to
 >(4k-1). I'm about to prepare a larger patch:
 >- add ndo_change_mtu handler, allowing MTU up to (4k - overhead),
 >- set MAX_FL / TRUNC_FL based on configured MTU,
 >- if necessary, do buffer reallocation with larger buffers.
 >
 >Is this suitable for upstreaming?
 >Is there any policy related to handling larger frames?

Of course, welcome to upstream the jumbo frame patches, but hope to also add the transmit jumbo frame, not only receive path, which is helpful for testing with two boards connection.
And, some notes need you to care:
- the maximum jumbo frame should consider the fifo size. Different chip has different fifo size. Like i.MX53 tx and rx share one fifo, i.mx6q/dl/sl have separate 4k fifo for tx and rx, i.mx6sx/i.mx7x have separate 8k fifo for tx and rx.
- rx fifo watermark to generate pause frame in busy loading system to avoid fifo overrun. In general,  little pause frames bring better performance, mass of pause frames cause worse performance.


Regards,
Andy