Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1533003

Re: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer

From Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Newsgroups linux.kernel
Subject Re: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer
Date 2016-11-30 07:40 +0100
Message-ID <sJ6IF-2A5-3@gated-at.bofh.it> (permalink)
References <sIVtU-3Fz-37@gated-at.bofh.it> <sJ6IF-2A5-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[patch net / RFC] net: fec: increase frame size limitation to actually available buffer Nikita Yushchenko <nikita.yoush@cogentembedded.com> - 2016-11-29 19:40 +0100
  Re: [patch net / RFC] net: fec: increase frame size limitation to  actually available buffer Nikita Yushchenko <nikita.yoush@cogentembedded.com> - 2016-11-30 07:40 +0100
    RE: [patch net / RFC] net: fec: increase frame size limitation to  actually available buffer Andy Duan <fugang.duan@nxp.com> - 2016-11-30 08:40 +0100
    Re: [patch net / RFC] net: fec: increase frame size limitation to  actually available buffer Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> - 2016-11-30 09:40 +0100
      DSA vs envelope frames Nikita Yushchenko <nikita.yoush@cogentembedded.com> - 2016-11-30 16:00 +0100
        Re: DSA vs envelope frames Andrew Lunn <andrew@lunn.ch> - 2016-11-30 16:20 +0100
          Re: DSA vs envelope frames Florian Fainelli <f.fainelli@gmail.com> - 2016-12-01 04:50 +0100
        Re: DSA vs envelope frames Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> - 2016-12-01 13:50 +0100
  RE: [patch net / RFC] net: fec: increase frame size limitation to  actually available buffer Andy Duan <fugang.duan@nxp.com> - 2016-11-30 11:20 +0100
  Re: [patch net / RFC] net: fec: increase frame size limitation to  actually available buffer Zefir Kurtisi <zefir.kurtisi@neratec.com> - 2016-11-30 17:20 +0100

csiph-web