Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
On Mon, Oct 17, 2016 at 04:07:12PM -0400, Jarod Wilson wrote: > On Mon, Oct 17, 2016 at 01:25:53PM -0400, David Miller wrote: > > From: Jakub Kicinski > > Date: Mon, 17 Oct 2016 18:20:49 +0100 > > > > > Hm. I must be missing something really obvious. I just booted > > > net-next an hour ago and couldn't set MTU to anything larger than 1500 > > > on either nfp or igb. As far as I can read the code it will set the > > > max_mtu to 1500 in setup_ether() but none of the jumbo-capable drivers > > > had been touched by Jarod so far... > > > > Indeed. > > > > Jarod, this doesn't work. > > > > I guess the idea was that if the driver overrides ndo_change_mtu and > > enforeced it's limits there, the driver would still work after your > > changes. > > > > But that isn't what is happening, look at the IGB example. > > > > It uses ether_setup(), which sets those new defaults, but now when > > the MTU is changed you enforce those default min/max before the > > driver's ->ndo_change_mtu() has a change to step in front and make > > the decision on it's own. > > > > This means your changes pretty much did indeed break a lot of > > drivers's ability to set larger than a 1500 byte MTU. > > Argh. Yeah, I see it now. I was primarily operating with the follow-on > patches also in play, which do touch all the ethernet drivers and set > max_mtu to match current behavior, didn't consider the max_mtu case where > only the initial patches were applied and the follow-on ones weren't. I've > sent that set, which should theoretically make this problem go away, but I > can also try to rework things if need be to restore intermediate jumbo > frames functionality. (And there are actually non-ethernet devices that > also call ether_setup and may or may not have larger than 1500 mtu that > aren't yet addressed by that follow-on set). Looks like the simplest thing to do is going to be to revert a52ad514, and only make that change after all callers of ether_setup() are setting min/max_mtu themselves as needed, then it can be reintroduced. -- Jarod Wilson ja...@redhat.com
Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
On Mon, Oct 17, 2016 at 01:25:53PM -0400, David Miller wrote: > From: Jakub Kicinski > Date: Mon, 17 Oct 2016 18:20:49 +0100 > > > Hm. I must be missing something really obvious. I just booted > > net-next an hour ago and couldn't set MTU to anything larger than 1500 > > on either nfp or igb. As far as I can read the code it will set the > > max_mtu to 1500 in setup_ether() but none of the jumbo-capable drivers > > had been touched by Jarod so far... > > Indeed. > > Jarod, this doesn't work. > > I guess the idea was that if the driver overrides ndo_change_mtu and > enforeced it's limits there, the driver would still work after your > changes. > > But that isn't what is happening, look at the IGB example. > > It uses ether_setup(), which sets those new defaults, but now when > the MTU is changed you enforce those default min/max before the > driver's ->ndo_change_mtu() has a change to step in front and make > the decision on it's own. > > This means your changes pretty much did indeed break a lot of > drivers's ability to set larger than a 1500 byte MTU. Argh. Yeah, I see it now. I was primarily operating with the follow-on patches also in play, which do touch all the ethernet drivers and set max_mtu to match current behavior, didn't consider the max_mtu case where only the initial patches were applied and the follow-on ones weren't. I've sent that set, which should theoretically make this problem go away, but I can also try to rework things if need be to restore intermediate jumbo frames functionality. (And there are actually non-ethernet devices that also call ether_setup and may or may not have larger than 1500 mtu that aren't yet addressed by that follow-on set). -- Jarod Wilson ja...@redhat.com
Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
From: Jakub Kicinski Date: Mon, 17 Oct 2016 18:20:49 +0100 > Hm. I must be missing something really obvious. I just booted > net-next an hour ago and couldn't set MTU to anything larger than 1500 > on either nfp or igb. As far as I can read the code it will set the > max_mtu to 1500 in setup_ether() but none of the jumbo-capable drivers > had been touched by Jarod so far... Indeed. Jarod, this doesn't work. I guess the idea was that if the driver overrides ndo_change_mtu and enforeced it's limits there, the driver would still work after your changes. But that isn't what is happening, look at the IGB example. It uses ether_setup(), which sets those new defaults, but now when the MTU is changed you enforce those default min/max before the driver's ->ndo_change_mtu() has a change to step in front and make the decision on it's own. This means your changes pretty much did indeed break a lot of drivers's ability to set larger than a 1500 byte MTU.
Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
On Mon, 17 Oct 2016 13:15:13 -0400 (EDT), David Miller wrote: > From: Jakub Kicinski > Date: Mon, 17 Oct 2016 18:00:27 +0100 > > > On Mon, 17 Oct 2016 12:49:54 -0400 (EDT), David Miller wrote: > >> From: Jakub Kicinski > >> Date: Mon, 17 Oct 2016 17:20:06 +0100 > >> > >> > Please correct me if I'm wrong but it seems like we are now limiting > >> > _all_ ethernet drivers to ETH_DATA_LEN in net-next. > >> > >> No, because the driver can increase the netdev->max_mtu value as needed. > > > > But since almost no driver is doing that, yet, right now in net-next > > jumbo frames are not possible, no? I thought the idea was the leave > > the value at 0 so drivers can opt-in as needed but since setup_ether() > > is initializing to 1500 now all ethernet driver get a default of > > limiting to 1500. > > > > IOW this patch made checks which were done only in eth_change_mtu() > > mandatory for all drivers. > > The conversions he made were in cases where the driver's method was doing > exactly the same thing eth_change_mtu() does not. > > He strictly worked to keep the behavior identical compared to before his > changes, please read his patches carefully. Hm. I must be missing something really obvious. I just booted net-next an hour ago and couldn't set MTU to anything larger than 1500 on either nfp or igb. As far as I can read the code it will set the max_mtu to 1500 in setup_ether() but none of the jumbo-capable drivers had been touched by Jarod so far...
Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
From: Jakub Kicinski Date: Mon, 17 Oct 2016 18:00:27 +0100 > On Mon, 17 Oct 2016 12:49:54 -0400 (EDT), David Miller wrote: >> From: Jakub Kicinski >> Date: Mon, 17 Oct 2016 17:20:06 +0100 >> >> > Please correct me if I'm wrong but it seems like we are now limiting >> > _all_ ethernet drivers to ETH_DATA_LEN in net-next. >> >> No, because the driver can increase the netdev->max_mtu value as needed. > > But since almost no driver is doing that, yet, right now in net-next > jumbo frames are not possible, no? I thought the idea was the leave > the value at 0 so drivers can opt-in as needed but since setup_ether() > is initializing to 1500 now all ethernet driver get a default of > limiting to 1500. > > IOW this patch made checks which were done only in eth_change_mtu() > mandatory for all drivers. The conversions he made were in cases where the driver's method was doing exactly the same thing eth_change_mtu() does not. He strictly worked to keep the behavior identical compared to before his changes, please read his patches carefully.
Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
On Mon, 17 Oct 2016 18:00:27 +0100, Jakub Kicinski wrote: > On Mon, 17 Oct 2016 12:49:54 -0400 (EDT), David Miller wrote: > > From: Jakub Kicinski > > Date: Mon, 17 Oct 2016 17:20:06 +0100 > > > > > Please correct me if I'm wrong but it seems like we are now limiting > > > _all_ ethernet drivers to ETH_DATA_LEN in net-next. > > > > No, because the driver can increase the netdev->max_mtu value as needed. > > But since almost no driver is doing that, yet, right now in net-next > jumbo frames are not possible, no? I thought the idea was the leave > the value at 0 so drivers can opt-in as needed but since setup_ether() > is initializing to 1500 now all ethernet driver get a default of > limiting to 1500. > > IOW this patch made checks which were done only in eth_change_mtu() > mandatory for all drivers. all ethernet drivers to be clear
Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
On Mon, 17 Oct 2016 12:49:54 -0400 (EDT), David Miller wrote: > From: Jakub Kicinski > Date: Mon, 17 Oct 2016 17:20:06 +0100 > > > Please correct me if I'm wrong but it seems like we are now limiting > > _all_ ethernet drivers to ETH_DATA_LEN in net-next. > > No, because the driver can increase the netdev->max_mtu value as needed. But since almost no driver is doing that, yet, right now in net-next jumbo frames are not possible, no? I thought the idea was the leave the value at 0 so drivers can opt-in as needed but since setup_ether() is initializing to 1500 now all ethernet driver get a default of limiting to 1500. IOW this patch made checks which were done only in eth_change_mtu() mandatory for all drivers.
Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
From: Jakub Kicinski Date: Mon, 17 Oct 2016 17:20:06 +0100 > Please correct me if I'm wrong but it seems like we are now limiting > _all_ ethernet drivers to ETH_DATA_LEN in net-next. No, because the driver can increase the netdev->max_mtu value as needed.
Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
On Fri, 7 Oct 2016 22:04:34 -0400, Jarod Wilson wrote:
> @@ -357,6 +356,8 @@ void ether_setup(struct net_device *dev)
> dev->type = ARPHRD_ETHER;
> dev->hard_header_len= ETH_HLEN;
> dev->mtu= ETH_DATA_LEN;
> + dev->min_mtu= ETH_MIN_MTU;
> + dev->max_mtu= ETH_DATA_LEN;
> dev->addr_len = ETH_ALEN;
> dev->tx_queue_len = 1000; /* Ethernet wants good queues */
> dev->flags = IFF_BROADCAST|IFF_MULTICAST;
This chunk seems to be breaking MTUs > 1500 for me.
On Fri, 7 Oct 2016 22:04:33 -0400, Jarod Wilson wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f1fe26f..f376639 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6499,9 +6499,18 @@ int dev_set_mtu(struct net_device *dev, int new_mtu)
> if (new_mtu == dev->mtu)
> return 0;
>
> - /* MTU must be positive.*/
> - if (new_mtu < 0)
> + /* MTU must be positive, and in range */
> + if (new_mtu < 0 || new_mtu < dev->min_mtu) {
> + net_err_ratelimited("%s: Invalid MTU %d requested, hw min %d\n",
> + dev->name, new_mtu, dev->min_mtu);
> return -EINVAL;
> + }
> +
> + if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
> + net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
> + dev->name, new_mtu, dev->min_mtu);
> + return -EINVAL;
> + }
Please correct me if I'm wrong but it seems like we are now limiting
_all_ ethernet drivers to ETH_DATA_LEN in net-next.
[PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
With centralized MTU checking, there's nothing productive done by eth_change_mtu that isn't already done in dev_set_mtu, so mark it as deprecated and remove all usage of it in the kernel. All callers have been audited for calls to alloc_etherdev* or ether_setup directly, which means they all have a valid dev->min_mtu and dev->max_mtu. Now eth_change_mtu prints out a netdev_warn about being deprecated, for the benefit of out-of-tree drivers that might be utilizing it. Of note, dvb_net.c actually had dev->mtu = 4096, while using eth_change_mtu, meaning that if you ever tried changing it's mtu, you couldn't set it above 1500 anymore. It's now getting dev->max_mtu also set to 4096 to remedy that. v2: fix up lantiq_etop, missed breakage due to drive not compiling on x86 CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson --- arch/m68k/emu/nfeth.c | 1 - drivers/isdn/hysdn/hysdn_net.c| 1 - drivers/media/dvb-core/dvb_net.c | 2 +- drivers/net/appletalk/ipddp.c | 1 - drivers/net/cris/eth_v10.c| 1 - drivers/net/ethernet/3com/3c509.c | 1 - drivers/net/ethernet/3com/3c515.c | 1 - drivers/net/ethernet/3com/3c574_cs.c | 1 - drivers/net/ethernet/3com/3c589_cs.c | 1 - drivers/net/ethernet/3com/3c59x.c | 2 -- drivers/net/ethernet/3com/typhoon.c | 1 - drivers/net/ethernet/8390/8390.c | 1 - drivers/net/ethernet/8390/8390p.c | 1 - drivers/net/ethernet/8390/ax88796.c | 1 - drivers/net/ethernet/8390/axnet_cs.c | 1 - drivers/net/ethernet/8390/etherh.c| 1 - drivers/net/ethernet/8390/hydra.c | 1 - drivers/net/ethernet/8390/mac8390.c | 1 - drivers/net/ethernet/8390/mcf8390.c | 1 - drivers/net/ethernet/8390/ne2k-pci.c | 1 - drivers/net/ethernet/8390/pcnet_cs.c | 1 - drivers/net/ethernet/8390/smc-ultra.c | 1 - drivers/net/ethernet/8390/wd.c| 1 - drivers/net/ethernet/8390/zorro8390.c | 1 - drivers/net/ethernet/adaptec/starfire.c | 1 - drivers/net/ethernet/adi/bfin_mac.c | 1 - drivers/net/ethernet/allwinner/sun4i-emac.c | 1 - drivers/net/ethernet/amd/a2065.c | 1 - drivers/net/ethernet/amd/am79c961a.c | 1 - drivers/net/ethernet/amd/ariadne.c| 1 - drivers/net/ethernet/amd/atarilance.c | 1 - drivers/net/ethernet/amd/au1000_eth.c | 1 - drivers/net/ethernet/amd/declance.c | 1 - drivers/net/ethernet/amd/hplance.c| 1 - drivers/net/ethernet/amd/lance.c | 1 - drivers/net/ethernet/amd/mvme147.c| 1 - drivers/net/ethernet/amd/ni65.c | 1 - drivers/net/ethernet/amd/nmclan_cs.c | 1 - drivers/net/ethernet/amd/pcnet32.c| 1 - drivers/net/ethernet/amd/sun3lance.c | 1 - drivers/net/ethernet/amd/sunlance.c | 1 - drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 1 - drivers/net/ethernet/apple/bmac.c | 1 - drivers/net/ethernet/apple/mace.c | 1 - drivers/net/ethernet/apple/macmace.c | 1 - drivers/net/ethernet/aurora/nb8800.c | 1 - drivers/net/ethernet/cadence/macb.c | 1 - drivers/net/ethernet/cirrus/cs89x0.c | 1 - drivers/net/ethernet/cirrus/ep93xx_eth.c | 1 - drivers/net/ethernet/cirrus/mac89x0.c | 1 - drivers/net/ethernet/davicom/dm9000.c | 1 - drivers/net/ethernet/dec/tulip/de2104x.c | 1 - drivers/net/ethernet/dec/tulip/de4x5.c| 1 - drivers/net/ethernet/dec/tulip/dmfe.c | 1 - drivers/net/ethernet/dec/tulip/tulip_core.c | 1 - drivers/net/ethernet/dec/tulip/uli526x.c | 1 - drivers/net/ethernet/dec/tulip/winbond-840.c | 1 - drivers/net/ethernet/dec/tulip/xircom_cb.c| 1 - drivers/net/ethernet/dnet.c | 1 - drivers/net/ethernet/ec_bhf.c | 1 - drivers/net/ethernet/fealnx.c | 1 - drivers/net/ethernet/freescale/fec_main.c | 1 - drivers/net/ethernet/freescale/fec_mpc52xx.c | 1 - drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 1 - drivers/net/ethernet/freescale/ucc_geth.c | 1 - drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 1 - drivers/net/ethernet/hisilicon/hip04_eth.c| 1 - dri
