From: Stefan Richter <stefanr@s5r6.in-berlin.de> To: "David S. Miller" <davem@davemloft.net> Cc: netdev@vger.kernel.org, linux1394-devel@lists.sourceforge.net, Jarod Wilson <jarod@redhat.com>, linux-kernel@vger.kernel.org Subject: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards Date: Sun, 23 Oct 2016 16:30:56 +0200 [thread overview] Message-ID: <20161023163056.6bc38610@kant> (raw) In-Reply-To: <20161023162903.4166a35d@kant> 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> --- drivers/firewire/net.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c index 99379542b263..03715e7d9d92 100644 --- a/drivers/firewire/net.c +++ b/drivers/firewire/net.c @@ -1463,13 +1463,7 @@ static int fwnet_probe(struct fw_unit *unit, goto out; dev->local_fifo = dev->handler.offset; - /* - * Use the RFC 2734 default 1500 octets or the maximum payload - * as initial MTU - */ - net->mtu = min(1500U, - (1U << (card->max_receive + 1)) - - RFC2374_FRAG_HDR_SIZE - IEEE1394_GASP_HDR_SIZE); + net->mtu = 1500U; net->min_mtu = ETH_MIN_MTU; net->max_mtu = ETH_MAX_MTU; -- Stefan Richter -======----- =-=- =-=== http://arcgraph.de/sr/
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Richter <stefanr@s5r6.in-berlin.de> To: "David S. Miller" <davem@davemloft.net> Cc: Wilson <jarod@redhat.com>, netdev@vger.kernel.org, linux1394-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Jarod Subject: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards Date: Sun, 23 Oct 2016 16:30:56 +0200 [thread overview] Message-ID: <20161023163056.6bc38610@kant> (raw) In-Reply-To: <20161023162903.4166a35d@kant> 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> --- drivers/firewire/net.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c index 99379542b263..03715e7d9d92 100644 --- a/drivers/firewire/net.c +++ b/drivers/firewire/net.c @@ -1463,13 +1463,7 @@ static int fwnet_probe(struct fw_unit *unit, goto out; dev->local_fifo = dev->handler.offset; - /* - * Use the RFC 2734 default 1500 octets or the maximum payload - * as initial MTU - */ - net->mtu = min(1500U, - (1U << (card->max_receive + 1)) - - RFC2374_FRAG_HDR_SIZE - IEEE1394_GASP_HDR_SIZE); + net->mtu = 1500U; net->min_mtu = ETH_MIN_MTU; net->max_mtu = ETH_MAX_MTU; -- Stefan Richter -======----- =-=- =-=== http://arcgraph.de/sr/ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
next prev parent reply other threads:[~2016-10-23 14:31 UTC|newest] Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-19 2:33 [PATCH net-next 0/6] net: use core MTU range checking everywhere Jarod Wilson 2016-10-19 2:33 ` [PATCH net-next 1/6] net: use core MTU range checking in USB NIC drivers Jarod Wilson 2016-10-19 2:33 ` [PATCH net-next 2/6] net: use core MTU range checking in wireless drivers Jarod Wilson 2016-10-19 7:38 ` Johannes Berg 2016-10-19 14:27 ` Jarod Wilson 2016-10-19 14:28 ` Johannes Berg 2016-10-19 2:33 ` [PATCH net-next 3/6] net: use core MTU range checking in WAN drivers Jarod Wilson 2016-10-21 12:04 ` Krzysztof Hałasa 2016-10-19 2:33 ` [PATCH net-next 4/6] net: use core MTU range checking in core net infra Jarod Wilson 2016-10-19 12:17 ` Jiri Benc 2016-10-19 14:51 ` Jarod Wilson 2016-10-19 13:55 ` Sabrina Dubroca 2016-10-19 14:40 ` Jarod Wilson 2016-10-19 15:28 ` Sabrina Dubroca 2016-10-19 15:46 ` Jarod Wilson 2016-10-19 2:33 ` [PATCH net-next 5/6] net: use core MTU range checking in virt drivers Jarod Wilson 2016-10-19 13:06 ` Aaron Conole 2016-10-19 13:06 ` Aaron Conole 2016-10-19 13:59 ` Michael S. Tsirkin 2016-10-19 13:59 ` Michael S. Tsirkin 2016-10-19 14:03 ` Michael S. Tsirkin 2016-10-19 14:03 ` Michael S. Tsirkin 2016-10-19 14:17 ` Jarod Wilson 2016-10-19 14:17 ` Jarod Wilson 2016-10-19 14:15 ` Jarod Wilson 2016-10-19 14:15 ` Jarod Wilson 2016-10-19 14:07 ` Haiyang Zhang 2016-10-19 14:07 ` Haiyang Zhang via Virtualization 2016-10-19 14:23 ` Jarod Wilson 2016-10-19 14:23 ` Jarod Wilson 2016-10-19 14:23 ` Jarod Wilson 2016-10-19 22:21 ` Shrikrishna Khare 2016-10-19 22:21 ` Shrikrishna Khare 2016-10-19 2:33 ` Jarod Wilson 2016-10-19 2:33 ` [PATCH net-next 6/6] net: use core MTU range checking in misc drivers Jarod Wilson 2016-10-19 14:37 ` Robin Holt 2016-10-19 16:05 ` Sabrina Dubroca 2016-10-19 22:38 ` Stefan Richter 2016-10-20 3:16 ` Jarod Wilson [not found] ` <20161020031641.GJ18569-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-10-22 9:36 ` Stefan Richter 2016-10-22 9:36 ` Stefan Richter 2016-10-22 18:51 ` Stefan Richter 2016-10-19 19:10 ` [PATCH net-next 0/6] net: use core MTU range checking everywhere David Miller 2016-10-19 19:29 ` Jarod Wilson 2016-10-20 17:55 ` [PATCH net-next v2 0/9] " Jarod Wilson 2016-10-20 17:55 ` [PATCH net-next v2 1/9] ethernet: use net core MTU range checking in more drivers Jarod Wilson 2016-10-20 17:55 ` Jarod Wilson 2016-10-20 17:55 ` [PATCH net-next v2 2/9] net: use core MTU range checking in USB NIC drivers Jarod Wilson 2016-10-20 17:55 ` [PATCH net-next v2 3/9] net: use core MTU range checking in wireless drivers Jarod Wilson 2016-10-20 18:22 ` Johannes Berg 2016-10-20 18:38 ` David Miller 2016-10-20 17:55 ` [PATCH net-next v2 4/9] net: use core MTU range checking in WAN drivers Jarod Wilson 2016-10-20 17:55 ` [PATCH net-next v2 5/9] net: use core MTU range checking in core net infra Jarod Wilson 2016-10-20 17:55 ` [PATCH net-next v2 6/9] net: use core MTU range checking in virt drivers Jarod Wilson 2016-10-20 17:55 ` Jarod Wilson 2016-10-20 18:05 ` Haiyang Zhang via Virtualization 2016-10-20 18:05 ` Haiyang Zhang 2016-10-20 18:05 ` Haiyang Zhang 2016-10-20 20:12 ` Kershner, David A 2016-10-20 20:12 ` Kershner, David A 2016-10-20 20:23 ` Michael S. Tsirkin 2016-10-21 2:37 ` Jarod Wilson 2016-10-21 2:37 ` Jarod Wilson 2016-10-21 3:36 ` Michael S. Tsirkin 2016-10-21 3:36 ` Michael S. Tsirkin 2016-10-21 13:24 ` Aaron Conole 2016-10-21 13:24 ` Aaron Conole 2016-10-20 20:23 ` Michael S. Tsirkin 2016-10-21 10:09 ` Wei Liu 2016-10-21 10:09 ` Wei Liu 2016-10-20 17:55 ` [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers Jarod Wilson 2016-10-20 17:55 ` Jarod Wilson 2016-10-21 6:52 ` Rémi Denis-Courmont 2016-10-21 6:52 ` Rémi Denis-Courmont 2016-10-21 16:22 ` Sebastian Reichel 2016-10-21 16:22 ` Sebastian Reichel [not found] ` <20161020175524.6184-8-jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-10-22 7:17 ` [net-next,v2,7/9] " Sven Eckelmann 2016-10-22 7:17 ` Sven Eckelmann 2016-10-22 19:16 ` [PATCH net-next v2 7/9] " Stefan Richter 2016-10-22 19:16 ` Stefan Richter 2016-10-22 19:27 ` Stefan Richter 2016-10-23 1:18 ` Jarod Wilson 2016-10-23 14:29 ` [PATCH net-next 1/2] firewire: net: fix maximum possible MTU Stefan Richter 2016-10-23 14:30 ` Stefan Richter [this message] 2016-10-23 14:30 ` [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards Stefan Richter 2016-10-24 1:50 ` Jarod Wilson 2016-10-24 12:26 ` [PATCH net-next 2/2 v2] " Stefan Richter 2016-10-24 12:26 ` Stefan Richter 2016-10-25 3:05 ` Jarod Wilson 2016-10-26 21:29 ` [PATCH net-next 2/2] " David Miller 2016-10-26 21:29 ` David Miller 2016-10-29 20:16 ` [PATCH net-next] firewire: net: really fix maximum possible MTU Stefan Richter 2016-10-30 3:01 ` David Miller 2016-10-24 1:50 ` [PATCH net-next 1/2] firewire: net: " Jarod Wilson 2016-10-26 21:29 ` David Miller 2016-10-26 21:29 ` David Miller 2016-10-20 17:55 ` [PATCH net-next v2 8/9] s390/net: use net core MTU range checking Jarod Wilson 2016-10-20 17:55 ` [PATCH net-next v2 9/9] ipv4/6: use core net " Jarod Wilson 2016-10-20 18:53 ` [PATCH net-next v2 0/9] net: use core MTU range checking everywhere David Miller
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20161023163056.6bc38610@kant \ --to=stefanr@s5r6.in-berlin.de \ --cc=davem@davemloft.net \ --cc=jarod@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux1394-devel@lists.sourceforge.net \ --cc=netdev@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.