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

Groups > linux.kernel > #1503528 > unrolled thread

[PATCH net-next 0/6] net: use core MTU range checking everywhere

Started byJarod Wilson <jarod@redhat.com>
First post2016-10-19 04:40 +0200
Last post2016-10-20 21:00 +0200
Articles 4 on this page of 44 — 14 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH net-next 0/6] net: use core MTU range checking everywhere Jarod Wilson <jarod@redhat.com> - 2016-10-19 04:40 +0200
    [PATCH net-next 6/6] net: use core MTU range checking in misc drivers Jarod Wilson <jarod@redhat.com> - 2016-10-19 04:40 +0200
      Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers Robin Holt <robinmholt@gmail.com> - 2016-10-19 16:40 +0200
      Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Sabrina Dubroca <sd@queasysnail.net> - 2016-10-19 18:10 +0200
        Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-20 00:50 +0200
          Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 05:20 +0200
            Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-22 11:40 +0200
              Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-22 21:00 +0200
    Re: [PATCH net-next 0/6] net: use core MTU range checking  everywhere David Miller <davem@davemloft.net> - 2016-10-19 21:20 +0200
      Re: [PATCH net-next 0/6] net: use core MTU range checking everywhere Jarod Wilson <jarod@redhat.com> - 2016-10-19 21:30 +0200
    [PATCH net-next v2 9/9] ipv4/6: use core net MTU range checking Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
    [PATCH net-next v2 3/9] net: use core MTU range checking in wireless drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
      Re: [PATCH net-next v2 3/9] net: use core MTU range checking in  wireless drivers Johannes Berg <johannes@sipsolutions.net> - 2016-10-20 20:30 +0200
        Re: [PATCH net-next v2 3/9] net: use core MTU range checking in  wireless drivers David Miller <davem@davemloft.net> - 2016-10-20 20:50 +0200
    [PATCH net-next v2 1/9] ethernet: use net core MTU range checking in more drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
    [PATCH net-next v2 4/9] net: use core MTU range checking in WAN drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
    [PATCH net-next v2 2/9] net: use core MTU range checking in USB NIC drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
    [PATCH net-next v2 0/9] net: use core MTU range checking everywhere Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
      [PATCH net-next v2 5/9] net: use core MTU range checking in core net infra Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
      [PATCH net-next v2 6/9] net: use core MTU range checking in virt drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
        RE: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers Haiyang Zhang <haiyangz@microsoft.com> - 2016-10-20 20:10 +0200
          RE: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers "Kershner, David A" <David.Kershner@unisys.com> - 2016-10-20 22:50 +0200
        Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers "Michael S. Tsirkin" <mst@redhat.com> - 2016-10-20 22:30 +0200
          Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers Jarod Wilson <jarod@redhat.com> - 2016-10-21 04:40 +0200
            Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers "Michael S. Tsirkin" <mst@redhat.com> - 2016-10-21 05:40 +0200
              Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt drivers Aaron Conole <aconole@bytheb.org> - 2016-10-21 15:30 +0200
        Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers Wei Liu <wei.liu2@citrix.com> - 2016-10-21 12:10 +0200
      [PATCH net-next v2 8/9] s390/net: use net core MTU range checking Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
      [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
        Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers Rémi Denis-Courmont <remi@remlab.net> - 2016-10-21 09:00 +0200
        Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc  drivers Sebastian Reichel <sre@kernel.org> - 2016-10-21 18:30 +0200
        Re: [net-next,v2,7/9] net: use core MTU range checking in misc drivers Sven Eckelmann <sven@narfation.org> - 2016-10-22 09:30 +0200
        Re: [PATCH net-next v2 7/9] net: use core MTU range checking in  misc drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-22 21:20 +0200
          Re: [PATCH net-next v2 7/9] net: use core MTU range checking in  misc drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-22 21:30 +0200
            Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc  drivers Jarod Wilson <jarod@redhat.com> - 2016-10-23 03:20 +0200
              [PATCH net-next 1/2] firewire: net: fix maximum possible MTU Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-23 16:30 +0200
                [PATCH net-next 2/2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-23 16:40 +0200
                  Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards Jarod Wilson <jarod@redhat.com> - 2016-10-24 04:00 +0200
                    [PATCH net-next 2/2 v2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-24 14:30 +0200
                      Re: [PATCH net-next 2/2 v2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards Jarod Wilson <jarod@redhat.com> - 2016-10-25 05:10 +0200
                  Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards David Miller <davem@davemloft.net> - 2016-10-26 23:40 +0200
                Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU Jarod Wilson <jarod@redhat.com> - 2016-10-24 04:00 +0200
                Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU David Miller <davem@davemloft.net> - 2016-10-26 23:40 +0200
      Re: [PATCH net-next v2 0/9] net: use core MTU range checking  everywhere David Miller <davem@davemloft.net> - 2016-10-20 21:00 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1509859 — Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards

FromDavid Miller <davem@davemloft.net>
Date2016-10-26 23:40 +0200
SubjectRe: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards
Message-ID<swE5s-Ye-35@gated-at.bofh.it>
In reply to#1506711
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date: Sun, 23 Oct 2016 16:30:56 +0200

> firewire-net, like the older eth1394 driver, reduced the initial MTU to
> less than 1500 octets if the local link layer controller's asynchronous
> packet reception limit was lower.
> 
> This is bogus, since this reception limit does not have anything to do
> with the transmission limit.  Neither did this reduction affect the TX
> path positively, nor could it prevent link fragmentation at the RX path.
> 
> Many FireWire CardBus cards have a max_rec of 9, causing an initial MTU
> of 1024 - 16 = 1008.  RFC 2734 and RFC 3146 allow a minimum max_rec = 8,
> which would result in an initial MTU of 512 - 16 = 496.  On such cards,
> IPv6 could only be employed if the MTU was manually increased to 1280 or
> more, i.e. IPv6 would not work without intervention from userland.
> 
> We now always initialize the MTU to 1500, which is the default according
> to RFC 2734 and RFC 3146.
> 
> On a VIA VT6316 based CardBus card which was affected by this, changing
> the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
> RX remains unaffected.
> 
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Applied.

[toc] | [prev] | [next] | [standalone]

#1506821 — Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU

FromJarod Wilson <jarod@redhat.com>
Date2016-10-24 04:00 +0200
SubjectRe: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU
Message-ID<svCIp-Pc-1@gated-at.bofh.it>
In reply to#1506710
On Sun, Oct 23, 2016 at 04:29:03PM +0200, Stefan Richter wrote:
> Commit b3e3893e1253 ("net: use core MTU range checking in misc drivers")
> mistakenly introduced an upper limit for firewire-net's MTU based on the
> local link layer controller's reception capability.  Revert this.  Neither
> RFC 2734 nor our implementation impose any particular upper limit.
> 
> Actually, to be on the safe side and to make the code explicit, set
> ETH_MAX_MTU = 65535 as upper limit now.
> 
> (I replaced sizeof(struct rfc2734_header) by the equivalent
> RFC2374_FRAG_HDR_SIZE in order to avoid distracting long/int conversions.)
> 
> Fixes: b3e3893e1253('net: use core MTU range checking in misc drivers')
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Acked-by: Jarod Wilson <jarod@redhat.com>

-- 
Jarod Wilson
jarod@redhat.com

[toc] | [prev] | [next] | [standalone]

#1509848 — Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU

FromDavid Miller <davem@davemloft.net>
Date2016-10-26 23:40 +0200
SubjectRe: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU
Message-ID<swE5r-Ye-1@gated-at.bofh.it>
In reply to#1506710
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date: Sun, 23 Oct 2016 16:29:03 +0200

> Commit b3e3893e1253 ("net: use core MTU range checking in misc drivers")
> mistakenly introduced an upper limit for firewire-net's MTU based on the
> local link layer controller's reception capability.  Revert this.  Neither
> RFC 2734 nor our implementation impose any particular upper limit.
> 
> Actually, to be on the safe side and to make the code explicit, set
> ETH_MAX_MTU = 65535 as upper limit now.
> 
> (I replaced sizeof(struct rfc2734_header) by the equivalent
> RFC2374_FRAG_HDR_SIZE in order to avoid distracting long/int conversions.)
> 
> Fixes: b3e3893e1253('net: use core MTU range checking in misc drivers')
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

Applied.

[toc] | [prev] | [next] | [standalone]

#1505186 — Re: [PATCH net-next v2 0/9] net: use core MTU range checking everywhere

FromDavid Miller <davem@davemloft.net>
Date2016-10-20 21:00 +0200
SubjectRe: [PATCH net-next v2 0/9] net: use core MTU range checking everywhere
Message-ID<suqJj-2WR-1@gated-at.bofh.it>
In reply to#1505152
From: Jarod Wilson <jarod@redhat.com>
Date: Thu, 20 Oct 2016 13:55:15 -0400

> This stack of patches should get absolutely everything in the kernel
> converted from doing their own MTU range checking to the core MTU range
> checking. This second spin includes alterations to hopefully fix all
> concerns raised with the first, as well as including some additional
> changes to drivers and infrastructure where I completely missed necessary
> updates.
> 
> These have all been built through the 0-day build infrastructure via the
> (rebasing) master branch at https://github.com/jarodwilson/linux-muck, which
> at the time of the most recent compile across 147 configs, was based on
> net-next at commit 7b1536ef0aa0.

Series applied, hopefully this gets most of the fallout.

Thanks Jarod.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web