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


Groups > linux.kernel > #1665042 > unrolled thread

[PATCH] via-rhine: add support for changing MTU

Started byMagnus Damm <magnus.damm@gmail.com>
First post2017-06-13 19:30 +0200
Last post2017-06-14 18:30 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] via-rhine: add support for changing MTU Magnus Damm <magnus.damm@gmail.com> - 2017-06-13 19:30 +0200
    Re: [PATCH] via-rhine: add support for changing MTU David Miller <davem@davemloft.net> - 2017-06-13 23:40 +0200
      Re: [PATCH] via-rhine: add support for changing MTU Magnus Damm <magnus.damm@gmail.com> - 2017-06-14 08:10 +0200
        Re: [PATCH] via-rhine: add support for changing MTU David Miller <davem@davemloft.net> - 2017-06-14 18:30 +0200

#1665042 — [PATCH] via-rhine: add support for changing MTU

FromMagnus Damm <magnus.damm@gmail.com>
Date2017-06-13 19:30 +0200
Subject[PATCH] via-rhine: add support for changing MTU
Message-ID<tRXND-2nq-3@gated-at.bofh.it>
From: Magnus Damm <damm+renesas@opensource.se>

Allow adjusting the MTU for via-rhine devices in case of no TX alignment
buffer is used.

Lightly tested on ALIX2D13 hardware by making use of VXLAN with MTU set
to 1500 on top of via-rhine devices with 1550 MTU. Without this patch
the VXLAN MTU is limited to less than 1500.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Developed on top of next-20170613

 drivers/net/ethernet/via/via-rhine.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

--- 0001/drivers/net/ethernet/via/via-rhine.c
+++ work/drivers/net/ethernet/via/via-rhine.c	2017-06-14 02:05:25.410607110 +0900
@@ -518,6 +518,7 @@ static void rhine_get_stats64(struct net
 static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
 static const struct ethtool_ops netdev_ethtool_ops;
 static int  rhine_close(struct net_device *dev);
+static int rhine_change_mtu(struct net_device *dev, int new_mtu);
 static int rhine_vlan_rx_add_vid(struct net_device *dev,
 				 __be16 proto, u16 vid);
 static int rhine_vlan_rx_kill_vid(struct net_device *dev,
@@ -894,6 +895,7 @@ static const struct net_device_ops rhine
 	.ndo_set_mac_address 	 = eth_mac_addr,
 	.ndo_do_ioctl		 = netdev_ioctl,
 	.ndo_tx_timeout 	 = rhine_tx_timeout,
+	.ndo_change_mtu 	 = rhine_change_mtu,
 	.ndo_vlan_rx_add_vid	 = rhine_vlan_rx_add_vid,
 	.ndo_vlan_rx_kill_vid	 = rhine_vlan_rx_kill_vid,
 #ifdef CONFIG_NET_POLL_CONTROLLER
@@ -981,6 +983,14 @@ static int rhine_init_one_common(struct
 				 NETIF_F_HW_VLAN_CTAG_RX |
 				 NETIF_F_HW_VLAN_CTAG_FILTER;
 
+	/* Allow MTU configuration as long as TX alignment buffer is unused */
+	if (!(rp->quirks & rqRhineI)) {
+		/* Packets less than 64 octets will raise RDES0.RUNT. */
+		dev->min_mtu = ETH_ZLEN - ETH_HLEN;
+		/* Hardware has 11 bits of RDES0.Rx_Length including FCS. */
+		dev->max_mtu = 0x1fff - ETH_HLEN - ETH_FCS_LEN;
+	}
+
 	/* dev->name not defined before register_netdev()! */
 	rc = register_netdev(dev);
 	if (rc)
@@ -1399,6 +1409,15 @@ static void rhine_set_carrier(struct mii
 		   mii->force_media, netif_carrier_ok(dev));
 }
 
+static int rhine_change_mtu(struct net_device *dev, int new_mtu)
+{
+	if (dev->flags & IFF_UP)
+		return -EBUSY;
+
+	dev->mtu = new_mtu;
+	return 0;
+}
+
 /**
  * rhine_set_cam - set CAM multicast filters
  * @ioaddr: register block of this Rhine

[toc] | [next] | [standalone]


#1665221

FromDavid Miller <davem@davemloft.net>
Date2017-06-13 23:40 +0200
Message-ID<tS1HA-4L9-13@gated-at.bofh.it>
In reply to#1665042
From: Magnus Damm <magnus.damm@gmail.com>
Date: Wed, 14 Jun 2017 02:18:27 +0900

> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Allow adjusting the MTU for via-rhine devices in case of no TX alignment
> buffer is used.
> 
> Lightly tested on ALIX2D13 hardware by making use of VXLAN with MTU set
> to 1500 on top of via-rhine devices with 1550 MTU. Without this patch
> the VXLAN MTU is limited to less than 1500.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>

Why is the TX alignment buffer such an obstacle?

It would be so much nicer if this could be supported for all chip
variants instead of some certain subset which users have no idea
of figuring out.  It's a really bad user experience to set them
up for failure like this.

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


#1665467

FromMagnus Damm <magnus.damm@gmail.com>
Date2017-06-14 08:10 +0200
Message-ID<tS9F7-1we-7@gated-at.bofh.it>
In reply to#1665221
On Wed, Jun 14, 2017 at 6:33 AM, David Miller <davem@davemloft.net> wrote:
> From: Magnus Damm <magnus.damm@gmail.com>
> Date: Wed, 14 Jun 2017 02:18:27 +0900
>
>> From: Magnus Damm <damm+renesas@opensource.se>
>>
>> Allow adjusting the MTU for via-rhine devices in case of no TX alignment
>> buffer is used.
>>
>> Lightly tested on ALIX2D13 hardware by making use of VXLAN with MTU set
>> to 1500 on top of via-rhine devices with 1550 MTU. Without this patch
>> the VXLAN MTU is limited to less than 1500.
>>
>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>
> Why is the TX alignment buffer such an obstacle?

Not such a big obstacle - I simply took the easy way out for this
first step. Adding support for MTU configuration when TX alignment is
required requires a bit more effort, and it also makes the driver
implementation slightly more complex.

The particular silicon version of via-rhine devices on my ALIX2D13
boards do not require the TX alignment workaround, but I should be
able to add some local test code for development purpose.

As for the TX alignment workaround implementation, when needed the
driver allocates rp->tx_bufs to PKT_BUF_SIZE * TX_RING_SIZE. To
support a larger MTU setting without increasing default memory usage
this TX side can be adjusted to manage buffers in a more dynamic way,
perhaps similar to the RX side with rp->rx_buf_sz.

> It would be so much nicer if this could be supported for all chip
> variants instead of some certain subset which users have no idea
> of figuring out.  It's a really bad user experience to set them
> up for failure like this.

Sure, I agree!

Will update the code with the TX alignment workaround and resend after
some much needed testing. It will most likely take some time, so
please don't block anything on this.

Cheers,

/ magnus

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


#1666052

FromDavid Miller <davem@davemloft.net>
Date2017-06-14 18:30 +0200
Message-ID<tSjl7-7u8-7@gated-at.bofh.it>
In reply to#1665467
From: Magnus Damm <magnus.damm@gmail.com>
Date: Wed, 14 Jun 2017 15:02:30 +0900

> Will update the code with the TX alignment workaround and resend after
> some much needed testing. It will most likely take some time, so
> please don't block anything on this.

Thank you.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web