[PATCH V3 0/1] tun: dynamically set speed of tun

[PATCH V3 0/1] tun: dynamically set speed of tun

[Zhu Yanjun]

V3:

Follow the advice from Jonathon Reinhart, a new patch is made.

V2:

Follow the advice from Sergei, a new patch is made.

V1:

The default speed of tun is 10M while the normal nic speed is 1000M.
When the speed of tun is accessed by the userspace application, the
default 10M is not proper. In this case, the default tun speed is
changed to 1000M. And this speed can be dynamically configured by
the command "ethtool -s tunX speed 10/100/1000".
 
Zhu Yanjun (1):
  tun: change speed from 10M to dynamically configured

 drivers/net/tun.c           | 42 +++++++++++++++++++++++++++++++++++++++++-
 include/uapi/linux/if_tun.h |  5 +++++
 2 files changed, 46 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH 1/1] tun: change speed from 10M to dynamically configured

[Zhu Yanjun]

The default speed of normal nic is 1000M while the default speed
of tun is 10M. Now the default speed of tun is changed to 1000M.
And there are 3 options: 10M, 100M and 1000M to the speed of tun.
The command "ethtool -s tun0 speed 10/100/1000" can configure the
speed of tun dynamically.

CC: Michael S. Tsirkin <mst@redhat.com>
CC: Jason Wang <jasowang@redhat.com>
CC: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Jonathon Reinhart <jonathon.reinhart@gmail.com>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
 drivers/net/tun.c           | 43 ++++++++++++++++++++++++++++++++++++++++++-
 include/uapi/linux/if_tun.h |  5 +++++
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8c8dc16..423b276 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -950,6 +950,9 @@ static void tun_net_init(struct net_device *dev)
 		dev->addr_len = 0;
 		dev->mtu = 1500;
 
+		/* Set default speed 1000M */
+		tun->flags |= TUN_CTRL_SPD_1000;
+
 		/* Zero header length */
 		dev->type = ARPHRD_NONE;
 		dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
@@ -2257,9 +2260,18 @@ static struct miscdevice tun_miscdev = {
 
 static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
+	struct tun_struct *tun = netdev_priv(dev);
+
+	/* Get the speed of tun */
+	if (tun->flags & TUN_CTRL_SPD_1000) {
+		ethtool_cmd_speed_set(cmd, SPEED_1000);
+	} else if (tun->flags & TUN_CTRL_SPD_100) {
+		ethtool_cmd_speed_set(cmd, SPEED_100);
+	} else
+		ethtool_cmd_speed_set(cmd, SPEED_10);
+
 	cmd->supported		= 0;
 	cmd->advertising	= 0;
-	ethtool_cmd_speed_set(cmd, SPEED_10);
 	cmd->duplex		= DUPLEX_FULL;
 	cmd->port		= PORT_TP;
 	cmd->phy_address	= 0;
@@ -2287,6 +2299,34 @@ static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
 	}
 }
 
+static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+	struct tun_struct *tun = netdev_priv(dev);
+	u32 speed = ethtool_cmd_speed(cmd);
+	int ret = 0;
+
+	/* Set speed flag */
+	switch (speed) {
+	case 10:
+		tun->flags &= ~(TUN_CTRL_SPD_100 | TUN_CTRL_SPD_1000);
+		tun->flags |= TUN_CTRL_SPD_10;
+		break;
+	case 100:
+		tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_1000);
+		tun->flags |= TUN_CTRL_SPD_100;
+		break;
+	case 1000:
+		tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_100);
+		tun->flags |= TUN_CTRL_SPD_1000;
+		break;
+	default:
+		ret = -EINVAL;
+		tun_debug(KERN_INFO, tun, "wrong speed!\n");
+	}
+
+	return ret;
+}
+
 static u32 tun_get_msglevel(struct net_device *dev)
 {
 #ifdef TUN_DEBUG
@@ -2307,6 +2347,7 @@ static void tun_set_msglevel(struct net_device *dev, u32 value)
 
 static const struct ethtool_ops tun_ethtool_ops = {
 	.get_settings	= tun_get_settings,
+	.set_settings	= tun_set_settings,
 	.get_drvinfo	= tun_get_drvinfo,
 	.get_msglevel	= tun_get_msglevel,
 	.set_msglevel	= tun_set_msglevel,
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index 50ae243..78a09a7 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -66,6 +66,11 @@
 #define IFF_PERSIST	0x0800
 #define IFF_NOFILTER	0x1000
 
+/*add speed control, default 1000M*/
+#define TUN_CTRL_SPD_10         0x0020
+#define TUN_CTRL_SPD_100        0x0040
+#define TUN_CTRL_SPD_1000       0x0080
+
 /* Socket options */
 #define TUN_TX_TIMESTAMP 1
 
-- 
1.9.1

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[yzhu1]

add maxk@qti.qualcomm.com, the maintainer of tun/tap driver.

Zhu Yanjun
On 02/13/2015 02:19 PM, Zhu Yanjun wrote:
> The default speed of normal nic is 1000M while the default speed
> of tun is 10M. Now the default speed of tun is changed to 1000M.
> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
> The command "ethtool -s tun0 speed 10/100/1000" can configure the
> speed of tun dynamically.
>
> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: Al Viro <viro@zeniv.linux.org.uk>
> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Jonathon Reinhart <jonathon.reinhart@gmail.com>
> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
> ---
>   drivers/net/tun.c           | 43 ++++++++++++++++++++++++++++++++++++++++++-
>   include/uapi/linux/if_tun.h |  5 +++++
>   2 files changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 8c8dc16..423b276 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -950,6 +950,9 @@ static void tun_net_init(struct net_device *dev)
>   		dev->addr_len = 0;
>   		dev->mtu = 1500;
>   
> +		/* Set default speed 1000M */
> +		tun->flags |= TUN_CTRL_SPD_1000;
> +
>   		/* Zero header length */
>   		dev->type = ARPHRD_NONE;
>   		dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
> @@ -2257,9 +2260,18 @@ static struct miscdevice tun_miscdev = {
>   
>   static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
>   {
> +	struct tun_struct *tun = netdev_priv(dev);
> +
> +	/* Get the speed of tun */
> +	if (tun->flags & TUN_CTRL_SPD_1000) {
> +		ethtool_cmd_speed_set(cmd, SPEED_1000);
> +	} else if (tun->flags & TUN_CTRL_SPD_100) {
> +		ethtool_cmd_speed_set(cmd, SPEED_100);
> +	} else
> +		ethtool_cmd_speed_set(cmd, SPEED_10);
> +
>   	cmd->supported		= 0;
>   	cmd->advertising	= 0;
> -	ethtool_cmd_speed_set(cmd, SPEED_10);
>   	cmd->duplex		= DUPLEX_FULL;
>   	cmd->port		= PORT_TP;
>   	cmd->phy_address	= 0;
> @@ -2287,6 +2299,34 @@ static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
>   	}
>   }
>   
> +static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> +	struct tun_struct *tun = netdev_priv(dev);
> +	u32 speed = ethtool_cmd_speed(cmd);
> +	int ret = 0;
> +
> +	/* Set speed flag */
> +	switch (speed) {
> +	case 10:
> +		tun->flags &= ~(TUN_CTRL_SPD_100 | TUN_CTRL_SPD_1000);
> +		tun->flags |= TUN_CTRL_SPD_10;
> +		break;
> +	case 100:
> +		tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_1000);
> +		tun->flags |= TUN_CTRL_SPD_100;
> +		break;
> +	case 1000:
> +		tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_100);
> +		tun->flags |= TUN_CTRL_SPD_1000;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +		tun_debug(KERN_INFO, tun, "wrong speed!\n");
> +	}
> +
> +	return ret;
> +}
> +
>   static u32 tun_get_msglevel(struct net_device *dev)
>   {
>   #ifdef TUN_DEBUG
> @@ -2307,6 +2347,7 @@ static void tun_set_msglevel(struct net_device *dev, u32 value)
>   
>   static const struct ethtool_ops tun_ethtool_ops = {
>   	.get_settings	= tun_get_settings,
> +	.set_settings	= tun_set_settings,
>   	.get_drvinfo	= tun_get_drvinfo,
>   	.get_msglevel	= tun_get_msglevel,
>   	.set_msglevel	= tun_set_msglevel,
> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index 50ae243..78a09a7 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -66,6 +66,11 @@
>   #define IFF_PERSIST	0x0800
>   #define IFF_NOFILTER	0x1000
>   
> +/*add speed control, default 1000M*/
> +#define TUN_CTRL_SPD_10         0x0020
> +#define TUN_CTRL_SPD_100        0x0040
> +#define TUN_CTRL_SPD_1000       0x0080
> +
>   /* Socket options */
>   #define TUN_TX_TIMESTAMP 1
>   

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Sergei Shtylyov]

On 2/13/2015 9:19 AM, Zhu Yanjun wrote:

> The default speed of normal nic is 1000M while the default speed
> of tun is 10M. Now the default speed of tun is changed to 1000M.
> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
> The command "ethtool -s tun0 speed 10/100/1000" can configure the
> speed of tun dynamically.

> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: Al Viro <viro@zeniv.linux.org.uk>
> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Jonathon Reinhart <jonathon.reinhart@gmail.com>
> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>

[...]

> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index 50ae243..78a09a7 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -66,6 +66,11 @@
>   #define IFF_PERSIST	0x0800
>   #define IFF_NOFILTER	0x1000
>
> +/*add speed control, default 1000M*/

    Please do add spaces after /* and before */.

> +#define TUN_CTRL_SPD_10         0x0020
> +#define TUN_CTRL_SPD_100        0x0040
> +#define TUN_CTRL_SPD_1000       0x0080
> +
>   /* Socket options */
>   #define TUN_TX_TIMESTAMP 1

WBR, Sergei

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Francois Romieu]

Zhu Yanjun <Yanjun.Zhu@windriver.com> :
> The default speed of normal nic is 1000M while the default speed
> of tun is 10M. Now the default speed of tun is changed to 1000M.
> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
> The command "ethtool -s tun0 speed 10/100/1000" can configure the
> speed of tun dynamically.

You don't explain why this patch is needed.

Why should tun_set_settings filter speed this way/at all ?

There's no reason to pollute uapi .h file.

-- 
Ueimor

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Rick Jones]

It is perhaps as much a bug in the monitoring tools as anything else, 
but I have come across (versions of) software - such as collectl I think 
- which when presented with counters indicating a data rate higher than 
the reported link rate of the interface get somewhat cranky.

rick jones

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Francois Romieu]

Rick Jones <rick.jones2@hp.com> :
> It is perhaps as much a bug in the monitoring tools as anything else, but I
> have come across (versions of) software - such as collectl I think - which
> when presented with counters indicating a data rate higher than the reported
> link rate of the interface get somewhat cranky.

It won't fix said software but the device should thus allow almost any
speed.

-- 
Ueimor

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[yzhu1]

Hi, all

When a user space application accesses the tun device by "ethtool " 
command, the returned default speed is 10M
while normal nic default speed is 1000M. The default tun speed 10M is 
somewhat odd compared with the default
speed 1000M.
Sometimes the user space application will treat this 10M as odd thing, 
then will send warnings to the administrator.
So I think maybe the default tun speed 1000M is better. The application 
will not send warnings.
In this case, this patch appears.

Best Regards!
Zhu Yanjun

On 02/14/2015 05:28 AM, Francois Romieu wrote:
> Zhu Yanjun <Yanjun.Zhu@windriver.com> :
>> The default speed of normal nic is 1000M while the default speed
>> of tun is 10M. Now the default speed of tun is changed to 1000M.
>> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
>> The command "ethtool -s tun0 speed 10/100/1000" can configure the
>> speed of tun dynamically.
> You don't explain why this patch is needed.
>
> Why should tun_set_settings filter speed this way/at all ?
>
> There's no reason to pollute uapi .h file.
>

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Stephen Hemminger]

I would like to propose this is as a more complete alternative.

From: Stephen Hemminger <stephen@networkpluber.org>
Subject: [PATCH] tun: support overriding ethtool information

Extensions to allow masqurade of ethtool info and device statistics.
This is useful to provide correct information to SNMP and OSPF routing
daemons when doing hw/sw offload of network device.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

---
 drivers/net/tun.c              | 139 +++++++++++++++++++++++++++++++++++++----
 include/uapi/linux/if_tunnel.h |   9 +++
 2 files changed, 135 insertions(+), 13 deletions(-)

--- a/drivers/net/tun.c	2015-02-16 11:58:00.651506008 -0500
+++ b/drivers/net/tun.c	2015-02-16 11:59:15.560842558 -0500
@@ -60,6 +60,7 @@
 #include <linux/if_arp.h>
 #include <linux/if_ether.h>
 #include <linux/if_tun.h>
+#include <linux/if_tunnel.h>
 #include <linux/if_vlan.h>
 #include <linux/crc32.h>
 #include <linux/nsproxy.h>
@@ -204,6 +205,9 @@ struct tun_struct {
 	struct list_head disabled;
 	void *security;
 	u32 flow_count;
+	u8 duplex;
+	u32 speed;
+	struct ip_tunnel_info	info;
 };
 
 static inline u16 tun16_to_cpu(struct tun_struct *tun, __virtio16 val)
@@ -866,6 +870,33 @@ static netdev_features_t tun_net_fix_fea
 
 	return (features & tun->set_features) | (features & ~TUN_USER_FEATURES);
 }
+
+static int
+tun_net_set_info(struct net_device *dev, const void __user *data)
+{
+	struct tun_struct *tun = netdev_priv(dev);
+	struct ip_tunnel_info info;
+
+	if (!capable(CAP_NET_ADMIN))
+		return -EPERM;
+
+	if (copy_from_user(&info, data, sizeof(info)))
+		return -EFAULT;
+
+	strlcpy(tun->info.driver, info.driver, sizeof(tun->info.driver));
+	strlcpy(tun->info.bus, info.bus, sizeof(tun->info.bus));
+	return 0;
+}
+
+static int
+tun_net_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
+{
+	if (cmd != SIOCDRVINFO)
+		return -EOPNOTSUPP;
+
+	return tun_net_set_info(dev, ifr->ifr_ifru.ifru_data);
+}
+
 #ifdef CONFIG_NET_POLL_CONTROLLER
 static void tun_poll_controller(struct net_device *dev)
 {
@@ -904,6 +935,7 @@ static const struct net_device_ops tap_n
 	.ndo_change_mtu		= tun_net_change_mtu,
 	.ndo_fix_features	= tun_net_fix_features,
 	.ndo_set_rx_mode	= tun_net_mclist,
+	.ndo_do_ioctl		= tun_net_ioctl,
 	.ndo_set_mac_address	= eth_mac_addr,
 	.ndo_validate_addr	= eth_validate_addr,
 	.ndo_select_queue	= tun_select_queue,
@@ -1408,6 +1440,8 @@ static void tun_setup(struct net_device
 
 	tun->owner = INVALID_UID;
 	tun->group = INVALID_GID;
+	tun->speed = SPEED_10;
+	tun->duplex = DUPLEX_FULL;
 
 	dev->ethtool_ops = &tun_ethtool_ops;
 	dev->destructor = tun_free_netdev;
@@ -1654,6 +1688,11 @@ static int tun_set_iff(struct net *net,
 
 		spin_lock_init(&tun->lock);
 
+		strlcpy(tun->info.driver, DRV_NAME, sizeof(tun->info.driver));
+		strlcpy(tun->info.bus,
+			(ifr->ifr_flags & IFF_TUN) ? "tun" : "tap",
+			sizeof(tun->info.bus));
+
 		err = security_tun_dev_alloc_security(&tun->security);
 		if (err < 0)
 			goto err_free_dev;
@@ -2253,10 +2292,12 @@ static struct miscdevice tun_miscdev = {
 
 static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
+	struct tun_struct *tun = netdev_priv(dev);
+
 	cmd->supported		= 0;
 	cmd->advertising	= 0;
-	ethtool_cmd_speed_set(cmd, SPEED_10);
-	cmd->duplex		= DUPLEX_FULL;
+	ethtool_cmd_speed_set(cmd, tun->speed);
+	cmd->duplex		= tun->duplex;
 	cmd->port		= PORT_TP;
 	cmd->phy_address	= 0;
 	cmd->transceiver	= XCVR_INTERNAL;
@@ -2266,21 +2307,24 @@ static int tun_get_settings(struct net_d
 	return 0;
 }
 
+static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+{
+	struct tun_struct *tun = netdev_priv(dev);
+
+	tun->speed = ethtool_cmd_speed(ecmd);
+	tun->duplex = ecmd->duplex;
+
+	return 0;
+}
+
 static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
 {
 	struct tun_struct *tun = netdev_priv(dev);
 
-	strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
+	strlcpy(info->driver, tun->info.driver, sizeof(info->driver));
 	strlcpy(info->version, DRV_VERSION, sizeof(info->version));
 
-	switch (tun->flags & TUN_TYPE_MASK) {
-	case IFF_TUN:
-		strlcpy(info->bus_info, "tun", sizeof(info->bus_info));
-		break;
-	case IFF_TAP:
-		strlcpy(info->bus_info, "tap", sizeof(info->bus_info));
-		break;
-	}
+	strlcpy(info->bus_info, tun->info.bus, sizeof(info->bus_info));
 }
 
 static u32 tun_get_msglevel(struct net_device *dev)
@@ -2303,6 +2347,7 @@ static void tun_set_msglevel(struct net_
 
 static const struct ethtool_ops tun_ethtool_ops = {
 	.get_settings	= tun_get_settings,
+	.set_settings	= tun_set_settings,
 	.get_drvinfo	= tun_get_drvinfo,
 	.get_msglevel	= tun_get_msglevel,
 	.set_msglevel	= tun_set_msglevel,
--- a/include/uapi/linux/if_tunnel.h	2015-02-16 11:58:00.651506008 -0500
+++ b/include/uapi/linux/if_tunnel.h	2015-02-16 11:58:00.651506008 -0500
@@ -17,6 +17,12 @@
 #define SIOCADD6RD      (SIOCDEVPRIVATE + 9)
 #define SIOCDEL6RD      (SIOCDEVPRIVATE + 10)
 #define SIOCCHG6RD      (SIOCDEVPRIVATE + 11)
+#define SIOCDRVINFO	(SIOCDEVPRIVATE + 12)
+
+struct ip_tunnel_info {
+	char driver[32];
+	char bus[32];
+};
 
 #define GRE_CSUM	__cpu_to_be16(0x8000)
 #define GRE_ROUTING	__cpu_to_be16(0x4000)

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Andy Gospodarek]

On Mon, Feb 16, 2015 at 12:03:45PM -0500, Stephen Hemminger wrote:
> I would like to propose this is as a more complete alternative.
> 
> From: Stephen Hemminger <stephen@networkpluber.org>
> Subject: [PATCH] tun: support overriding ethtool information
> 
> Extensions to allow masqurade of ethtool info and device statistics.
> This is useful to provide correct information to SNMP and OSPF routing
> daemons when doing hw/sw offload of network device.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> 
> ---
>  drivers/net/tun.c              | 139 +++++++++++++++++++++++++++++++++++++----
>  include/uapi/linux/if_tunnel.h |   9 +++
>  2 files changed, 135 insertions(+), 13 deletions(-)
> 
> --- a/drivers/net/tun.c	2015-02-16 11:58:00.651506008 -0500
> +++ b/drivers/net/tun.c	2015-02-16 11:59:15.560842558 -0500
> @@ -60,6 +60,7 @@
>  #include <linux/if_arp.h>
>  #include <linux/if_ether.h>
>  #include <linux/if_tun.h>
> +#include <linux/if_tunnel.h>
>  #include <linux/if_vlan.h>
>  #include <linux/crc32.h>
>  #include <linux/nsproxy.h>
> @@ -204,6 +205,9 @@ struct tun_struct {
>  	struct list_head disabled;
>  	void *security;
>  	u32 flow_count;
> +	u8 duplex;
> +	u32 speed;
> +	struct ip_tunnel_info	info;
>  };
>  
>  static inline u16 tun16_to_cpu(struct tun_struct *tun, __virtio16 val)
> @@ -866,6 +870,33 @@ static netdev_features_t tun_net_fix_fea
>  
>  	return (features & tun->set_features) | (features & ~TUN_USER_FEATURES);
>  }
> +
> +static int
> +tun_net_set_info(struct net_device *dev, const void __user *data)
> +{
> +	struct tun_struct *tun = netdev_priv(dev);
> +	struct ip_tunnel_info info;
> +
> +	if (!capable(CAP_NET_ADMIN))
> +		return -EPERM;
> +
> +	if (copy_from_user(&info, data, sizeof(info)))
> +		return -EFAULT;
> +
> +	strlcpy(tun->info.driver, info.driver, sizeof(tun->info.driver));
> +	strlcpy(tun->info.bus, info.bus, sizeof(tun->info.bus));
> +	return 0;
> +}
> +
> +static int
> +tun_net_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> +{
> +	if (cmd != SIOCDRVINFO)
> +		return -EOPNOTSUPP;
> +
> +	return tun_net_set_info(dev, ifr->ifr_ifru.ifru_data);
> +}
> +
>  #ifdef CONFIG_NET_POLL_CONTROLLER
>  static void tun_poll_controller(struct net_device *dev)
>  {
> @@ -904,6 +935,7 @@ static const struct net_device_ops tap_n
>  	.ndo_change_mtu		= tun_net_change_mtu,
>  	.ndo_fix_features	= tun_net_fix_features,
>  	.ndo_set_rx_mode	= tun_net_mclist,
> +	.ndo_do_ioctl		= tun_net_ioctl,
>  	.ndo_set_mac_address	= eth_mac_addr,
>  	.ndo_validate_addr	= eth_validate_addr,
>  	.ndo_select_queue	= tun_select_queue,
> @@ -1408,6 +1440,8 @@ static void tun_setup(struct net_device
>  
>  	tun->owner = INVALID_UID;
>  	tun->group = INVALID_GID;
> +	tun->speed = SPEED_10;
> +	tun->duplex = DUPLEX_FULL;
>  
>  	dev->ethtool_ops = &tun_ethtool_ops;
>  	dev->destructor = tun_free_netdev;
> @@ -1654,6 +1688,11 @@ static int tun_set_iff(struct net *net,
>  
>  		spin_lock_init(&tun->lock);
>  
> +		strlcpy(tun->info.driver, DRV_NAME, sizeof(tun->info.driver));
> +		strlcpy(tun->info.bus,
> +			(ifr->ifr_flags & IFF_TUN) ? "tun" : "tap",
> +			sizeof(tun->info.bus));
> +
>  		err = security_tun_dev_alloc_security(&tun->security);
>  		if (err < 0)
>  			goto err_free_dev;
> @@ -2253,10 +2292,12 @@ static struct miscdevice tun_miscdev = {
>  
>  static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
>  {
> +	struct tun_struct *tun = netdev_priv(dev);
> +
>  	cmd->supported		= 0;
>  	cmd->advertising	= 0;
> -	ethtool_cmd_speed_set(cmd, SPEED_10);
> -	cmd->duplex		= DUPLEX_FULL;
> +	ethtool_cmd_speed_set(cmd, tun->speed);
> +	cmd->duplex		= tun->duplex;
>  	cmd->port		= PORT_TP;
>  	cmd->phy_address	= 0;
>  	cmd->transceiver	= XCVR_INTERNAL;
> @@ -2266,21 +2307,24 @@ static int tun_get_settings(struct net_d
>  	return 0;
>  }
>  
> +static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
> +{
> +	struct tun_struct *tun = netdev_priv(dev);
> +
> +	tun->speed = ethtool_cmd_speed(ecmd);
> +	tun->duplex = ecmd->duplex;
> +
> +	return 0;
> +}
> +
>  static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
>  {
>  	struct tun_struct *tun = netdev_priv(dev);
>  
> -	strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
> +	strlcpy(info->driver, tun->info.driver, sizeof(info->driver));
>  	strlcpy(info->version, DRV_VERSION, sizeof(info->version));
>  
> -	switch (tun->flags & TUN_TYPE_MASK) {
> -	case IFF_TUN:
> -		strlcpy(info->bus_info, "tun", sizeof(info->bus_info));
> -		break;
> -	case IFF_TAP:
> -		strlcpy(info->bus_info, "tap", sizeof(info->bus_info));
> -		break;
> -	}
> +	strlcpy(info->bus_info, tun->info.bus, sizeof(info->bus_info));
>  }
>  
>  static u32 tun_get_msglevel(struct net_device *dev)
> @@ -2303,6 +2347,7 @@ static void tun_set_msglevel(struct net_
>  
>  static const struct ethtool_ops tun_ethtool_ops = {
>  	.get_settings	= tun_get_settings,
> +	.set_settings	= tun_set_settings,
>  	.get_drvinfo	= tun_get_drvinfo,
>  	.get_msglevel	= tun_get_msglevel,
>  	.set_msglevel	= tun_set_msglevel,
> --- a/include/uapi/linux/if_tunnel.h	2015-02-16 11:58:00.651506008 -0500
> +++ b/include/uapi/linux/if_tunnel.h	2015-02-16 11:58:00.651506008 -0500
> @@ -17,6 +17,12 @@
>  #define SIOCADD6RD      (SIOCDEVPRIVATE + 9)
>  #define SIOCDEL6RD      (SIOCDEVPRIVATE + 10)
>  #define SIOCCHG6RD      (SIOCDEVPRIVATE + 11)
> +#define SIOCDRVINFO	(SIOCDEVPRIVATE + 12)
My only complaint, is that the whitespace is different from the line
above.  Rather than requesting you fix this, I'll post a follow-up that
fixes all of these.

Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>

> +
> +struct ip_tunnel_info {
> +	char driver[32];
> +	char bus[32];
> +};
>  
>  #define GRE_CSUM	__cpu_to_be16(0x8000)
>  #define GRE_ROUTING	__cpu_to_be16(0x4000)
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Andy Gospodarek]

Proposed follow-up based on the errors in if_tunnel.h that were brought
to my attention with Stephen's patch.

(Dave, if you want a more official-looking post in a standalone thread I
can do that.)

From: Andy Gospodarek <gospo@cumulusnetworks.com>
Subject: [PATCH net-next] uapi: fixup whitespace for private ioctls

After Stephen's patch added support for new private ioctl (SIOCDRVINFO)
I noticed that his whitespace was correct, but the rest of the
whitespace for the other ioctls was wrong.  This fixes up the others and
should be applied after his.

CC: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>

---
 include/uapi/linux/if_tunnel.h | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
index 3430238..4a65a56 100644
--- a/include/uapi/linux/if_tunnel.h
+++ b/include/uapi/linux/if_tunnel.h
@@ -5,18 +5,18 @@
 #include <asm/byteorder.h>
 
 
-#define SIOCGETTUNNEL   (SIOCDEVPRIVATE + 0)
-#define SIOCADDTUNNEL   (SIOCDEVPRIVATE + 1)
-#define SIOCDELTUNNEL   (SIOCDEVPRIVATE + 2)
-#define SIOCCHGTUNNEL   (SIOCDEVPRIVATE + 3)
-#define SIOCGETPRL      (SIOCDEVPRIVATE + 4)
-#define SIOCADDPRL      (SIOCDEVPRIVATE + 5)
-#define SIOCDELPRL      (SIOCDEVPRIVATE + 6)
-#define SIOCCHGPRL      (SIOCDEVPRIVATE + 7)
-#define SIOCGET6RD      (SIOCDEVPRIVATE + 8)
-#define SIOCADD6RD      (SIOCDEVPRIVATE + 9)
-#define SIOCDEL6RD      (SIOCDEVPRIVATE + 10)
-#define SIOCCHG6RD      (SIOCDEVPRIVATE + 11)
+#define SIOCGETTUNNEL	(SIOCDEVPRIVATE + 0)
+#define SIOCADDTUNNEL	(SIOCDEVPRIVATE + 1)
+#define SIOCDELTUNNEL	(SIOCDEVPRIVATE + 2)
+#define SIOCCHGTUNNEL	(SIOCDEVPRIVATE + 3)
+#define SIOCGETPRL	(SIOCDEVPRIVATE + 4)
+#define SIOCADDPRL	(SIOCDEVPRIVATE + 5)
+#define SIOCDELPRL	(SIOCDEVPRIVATE + 6)
+#define SIOCCHGPRL	(SIOCDEVPRIVATE + 7)
+#define SIOCGET6RD	(SIOCDEVPRIVATE + 8)
+#define SIOCADD6RD	(SIOCDEVPRIVATE + 9)
+#define SIOCDEL6RD	(SIOCDEVPRIVATE + 10)
+#define SIOCCHG6RD	(SIOCDEVPRIVATE + 11)
 #define SIOCDRVINFO	(SIOCDEVPRIVATE + 12)
 
 struct ip_tunnel_info {
-- 
1.9.3

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[David Miller]

From: Andy Gospodarek <gospo@cumulusnetworks.com>
Date: Wed, 18 Feb 2015 14:39:09 -0500

> (Dave, if you want a more official-looking post in a standalone thread I
> can do that.)

Please do so, thanks.

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[David Miller]

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Mon, 16 Feb 2015 12:03:45 -0500

> I would like to propose this is as a more complete alternative.
> 
> From: Stephen Hemminger <stephen@networkpluber.org>
> Subject: [PATCH] tun: support overriding ethtool information
> 
> Extensions to allow masqurade of ethtool info and device statistics.
> This is useful to provide correct information to SNMP and OSPF routing
> daemons when doing hw/sw offload of network device.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

We need a consistent policy regarding link attributes of encapsulating
"software" devices.

I see three realistic options:

1) Create a link state indication which means "I am a software device,
   so I don't really have a link state in the traditional sense"

2) Don't implement the link set/get operations at all on software
   devices.

   People can use ETHTOOL_GLINK to see if the thing is "up"

3) Propagate the ultimate physical transport parameters into what
   the software device advertises.

It's important to carefully pick one of these, and consistently apply
it to all of our software devices.

I don't want TUN doing one thing, ipv4 tunnels doing another, etc.

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Simon Horman]

Hi,

On Thu, Feb 19, 2015 at 03:40:41PM -0500, David Miller wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Mon, 16 Feb 2015 12:03:45 -0500
> 
> > I would like to propose this is as a more complete alternative.
> > 
> > From: Stephen Hemminger <stephen@networkpluber.org>
> > Subject: [PATCH] tun: support overriding ethtool information
> > 
> > Extensions to allow masqurade of ethtool info and device statistics.
> > This is useful to provide correct information to SNMP and OSPF routing
> > daemons when doing hw/sw offload of network device.
> > 
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> 
> We need a consistent policy regarding link attributes of encapsulating
> "software" devices.
> 
> I see three realistic options:
> 
> 1) Create a link state indication which means "I am a software device,
>    so I don't really have a link state in the traditional sense"
> 
> 2) Don't implement the link set/get operations at all on software
>    devices.
> 
>    People can use ETHTOOL_GLINK to see if the thing is "up"
> 
> 3) Propagate the ultimate physical transport parameters into what
>    the software device advertises.
> 
> It's important to carefully pick one of these, and consistently apply
> it to all of our software devices.
> 
> I don't want TUN doing one thing, ipv4 tunnels doing another, etc.

I am wondering if/how you see 3 playing out with e.g. ipv4 tunnels.
It seems to me there may be a consistent underlying device.

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Andy Gospodarek]

On Thu, Feb 19, 2015 at 03:40:41PM -0500, David Miller wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Mon, 16 Feb 2015 12:03:45 -0500
> 
> > I would like to propose this is as a more complete alternative.
> > 
> > From: Stephen Hemminger <stephen@networkpluber.org>
> > Subject: [PATCH] tun: support overriding ethtool information
> > 
> > Extensions to allow masqurade of ethtool info and device statistics.
> > This is useful to provide correct information to SNMP and OSPF routing
> > daemons when doing hw/sw offload of network device.
> > 
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> 
> We need a consistent policy regarding link attributes of encapsulating
> "software" devices.

I think this is a great point and though I like Stephen's patch due to
how useful it would be to me, I had some concerns about whether or not
others would accept it without a bit more of 'a plan' for functions like
this.

> 
> I see three realistic options:
> 
> 1) Create a link state indication which means "I am a software device,
>    so I don't really have a link state in the traditional sense"
> 
> 2) Don't implement the link set/get operations at all on software
>    devices.
> 
>    People can use ETHTOOL_GLINK to see if the thing is "up"
> 
> 3) Propagate the ultimate physical transport parameters into what
>    the software device advertises.
> 
> It's important to carefully pick one of these, and consistently apply
> it to all of our software devices.
> 
> I don't want TUN doing one thing, ipv4 tunnels doing another, etc.

I would prefer option #3 as it relates to the ability to transport
offload statistics and parameters to software devices.  This could be
useful for hardware with some form of offload vxlan/gre/etc that may be
backed by hardare statistics (a callback to the upper device's ndo op
could be made by the native hardware driver) or any other device without
a proper in-kernel driver like a userspace user of tuntap that might be
backed by something like OpenVPN.

That might help provide some more detailed, ethtool-like statistics in
the format that is more easily readable by common monitoring tools
without the need to have those applications look at anything except an
ethtool/kernel interface.

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[David Miller]

From: Andy Gospodarek <gospo@cumulusnetworks.com>
Date: Thu, 19 Feb 2015 21:35:00 -0500

> On Thu, Feb 19, 2015 at 03:40:41PM -0500, David Miller wrote:
>> I see three realistic options:
>> 
>> 1) Create a link state indication which means "I am a software device,
>>    so I don't really have a link state in the traditional sense"
>> 
>> 2) Don't implement the link set/get operations at all on software
>>    devices.
>> 
>>    People can use ETHTOOL_GLINK to see if the thing is "up"
>> 
>> 3) Propagate the ultimate physical transport parameters into what
>>    the software device advertises.
>> 
>> It's important to carefully pick one of these, and consistently apply
>> it to all of our software devices.
>> 
>> I don't want TUN doing one thing, ipv4 tunnels doing another, etc.
> 
> I would prefer option #3 as it relates to the ability to transport
> offload statistics and parameters to software devices.  This could be
> useful for hardware with some form of offload vxlan/gre/etc that may be
> backed by hardare statistics (a callback to the upper device's ndo op
> could be made by the native hardware driver) or any other device without
> a proper in-kernel driver like a userspace user of tuntap that might be
> backed by something like OpenVPN.
> 
> That might help provide some more detailed, ethtool-like statistics in
> the format that is more easily readable by common monitoring tools
> without the need to have those applications look at anything except an
> ethtool/kernel interface.

netdev_feature_t like propagation is tricky because offloading
depends upon whether the device can do the offload "even in the
presence of encapsulation X".  So I don't see it as useful for
that.

But for things that are largely advisory types of information like
"physical link state", it works in a much more straightforward manner.

Link duplex and speed being wrong on a software device doesn't stop
communication, but incorrect hw offload feature flags might.

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Andy Gospodarek]

On Fri, Feb 20, 2015 at 03:07:49PM -0500, David Miller wrote:
> From: Andy Gospodarek <gospo@cumulusnetworks.com>
> Date: Thu, 19 Feb 2015 21:35:00 -0500
> 
> > On Thu, Feb 19, 2015 at 03:40:41PM -0500, David Miller wrote:
> >> I see three realistic options:
> >> 
> >> 1) Create a link state indication which means "I am a software device,
> >>    so I don't really have a link state in the traditional sense"
> >> 
> >> 2) Don't implement the link set/get operations at all on software
> >>    devices.
> >> 
> >>    People can use ETHTOOL_GLINK to see if the thing is "up"
> >> 
> >> 3) Propagate the ultimate physical transport parameters into what
> >>    the software device advertises.
> >> 
> >> It's important to carefully pick one of these, and consistently apply
> >> it to all of our software devices.
> >> 
> >> I don't want TUN doing one thing, ipv4 tunnels doing another, etc.
> > 
> > I would prefer option #3 as it relates to the ability to transport
> > offload statistics and parameters to software devices.  This could be
> > useful for hardware with some form of offload vxlan/gre/etc that may be
> > backed by hardare statistics (a callback to the upper device's ndo op
> > could be made by the native hardware driver) or any other device without
> > a proper in-kernel driver like a userspace user of tuntap that might be
> > backed by something like OpenVPN.
> > 
> > That might help provide some more detailed, ethtool-like statistics in
> > the format that is more easily readable by common monitoring tools
> > without the need to have those applications look at anything except an
> > ethtool/kernel interface.
> 
> netdev_feature_t like propagation is tricky because offloading
> depends upon whether the device can do the offload "even in the
> presence of encapsulation X".  So I don't see it as useful for
> that.
> 
> But for things that are largely advisory types of information like
> "physical link state", it works in a much more straightforward manner.
> 
> Link duplex and speed being wrong on a software device doesn't stop
> communication, but incorrect hw offload feature flags might.

Ah yes, that is an excellent point.  Trying to get too fancy is probably
a bad idea when thinking about the exception cases.  In my example the
driver for the vxlan offload device should be the one tracking this
rather than propagating information up to a upper-layer software device.

The software devices that may not have any true hardware backing in the
kernel (OpenVPN, etc) are the best consumers for this type of
infrastructure.

RE: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[David Laight]

From: David Miller
...
> We need a consistent policy regarding link attributes of encapsulating
> "software" devices.
> 
> I see three realistic options:
> 
> 1) Create a link state indication which means "I am a software device,
>    so I don't really have a link state in the traditional sense"
> 
> 2) Don't implement the link set/get operations at all on software
>    devices.
> 
>    People can use ETHTOOL_GLINK to see if the thing is "up"
> 
> 3) Propagate the ultimate physical transport parameters into what
>    the software device advertises.
> 
> It's important to carefully pick one of these, and consistently apply
> it to all of our software devices.

You also need to be careful to not break existing 'stuff'.

We've connected a single USB ethernet port into a 'bond' (with
nothing else) in order to get a stable interface and IP address
that doesn't bounce on transient USB errors.

If the absence of the physical interface caused the state of bond0
to change and that got propagated through the routing tables then
we'd get TCP disconnects reported for things that would only see
recovered packet loss.

	David

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[roopa]

On 2/16/15, 9:03 AM, Stephen Hemminger wrote:
> I would like to propose this is as a more complete alternative.
>
> From: Stephen Hemminger <stephen@networkpluber.org>
> Subject: [PATCH] tun: support overriding ethtool information
>
> Extensions to allow masqurade of ethtool info and device statistics.
> This is useful to provide correct information to SNMP and OSPF routing
> daemons when doing hw/sw offload of network device.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> ---
>   drivers/net/tun.c              | 139 +++++++++++++++++++++++++++++++++++++----
>   include/uapi/linux/if_tunnel.h |   9 +++
>   2 files changed, 135 insertions(+), 13 deletions(-)
>
> --- a/drivers/net/tun.c	2015-02-16 11:58:00.651506008 -0500
> +++ b/drivers/net/tun.c	2015-02-16 11:59:15.560842558 -0500
> @@ -60,6 +60,7 @@
>   #include <linux/if_arp.h>
>   #include <linux/if_ether.h>
>   #include <linux/if_tun.h>
> +#include <linux/if_tunnel.h>
>   #include <linux/if_vlan.h>
>   #include <linux/crc32.h>
>   #include <linux/nsproxy.h>
> @@ -204,6 +205,9 @@ struct tun_struct {
>   	struct list_head disabled;
>   	void *security;
>   	u32 flow_count;
> +	u8 duplex;
> +	u32 speed;
> +	struct ip_tunnel_info	info;
>   };
>   
>   static inline u16 tun16_to_cpu(struct tun_struct *tun, __virtio16 val)
> @@ -866,6 +870,33 @@ static netdev_features_t tun_net_fix_fea
>   
>   	return (features & tun->set_features) | (features & ~TUN_USER_FEATURES);
>   }
> +
> +static int
> +tun_net_set_info(struct net_device *dev, const void __user *data)
> +{
> +	struct tun_struct *tun = netdev_priv(dev);
> +	struct ip_tunnel_info info;
> +
> +	if (!capable(CAP_NET_ADMIN))
> +		return -EPERM;
> +
> +	if (copy_from_user(&info, data, sizeof(info)))
> +		return -EFAULT;
> +
> +	strlcpy(tun->info.driver, info.driver, sizeof(tun->info.driver));
> +	strlcpy(tun->info.bus, info.bus, sizeof(tun->info.bus));
> +	return 0;
> +}
> +
> +static int
> +tun_net_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> +{
> +	if (cmd != SIOCDRVINFO)
> +		return -EOPNOTSUPP;
> +
> +	return tun_net_set_info(dev, ifr->ifr_ifru.ifru_data);
> +}
> +

>   #ifdef CONFIG_NET_POLL_CONTROLLER
>   static void tun_poll_controller(struct net_device *dev)
>   {
> @@ -904,6 +935,7 @@ static const struct net_device_ops tap_n
>   	.ndo_change_mtu		= tun_net_change_mtu,
>   	.ndo_fix_features	= tun_net_fix_features,
>   	.ndo_set_rx_mode	= tun_net_mclist,
> +	.ndo_do_ioctl		= tun_net_ioctl,
>   	.ndo_set_mac_address	= eth_mac_addr,
>   	.ndo_validate_addr	= eth_validate_addr,
>   	.ndo_select_queue	= tun_select_queue,
> @@ -1408,6 +1440,8 @@ static void tun_setup(struct net_device
>   
>   	tun->owner = INVALID_UID;
>   	tun->group = INVALID_GID;
> +	tun->speed = SPEED_10;
> +	tun->duplex = DUPLEX_FULL;
>   
>   	dev->ethtool_ops = &tun_ethtool_ops;
>   	dev->destructor = tun_free_netdev;
> @@ -1654,6 +1688,11 @@ static int tun_set_iff(struct net *net,
>   
>   		spin_lock_init(&tun->lock);
>   
> +		strlcpy(tun->info.driver, DRV_NAME, sizeof(tun->info.driver));
> +		strlcpy(tun->info.bus,
> +			(ifr->ifr_flags & IFF_TUN) ? "tun" : "tap",
> +			sizeof(tun->info.bus));
> +
>   		err = security_tun_dev_alloc_security(&tun->security);
>   		if (err < 0)
>   			goto err_free_dev;
> @@ -2253,10 +2292,12 @@ static struct miscdevice tun_miscdev = {
>   
>   static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
>   {
> +	struct tun_struct *tun = netdev_priv(dev);
> +
>   	cmd->supported		= 0;
>   	cmd->advertising	= 0;
> -	ethtool_cmd_speed_set(cmd, SPEED_10);
> -	cmd->duplex		= DUPLEX_FULL;
> +	ethtool_cmd_speed_set(cmd, tun->speed);
> +	cmd->duplex		= tun->duplex;
>   	cmd->port		= PORT_TP;
>   	cmd->phy_address	= 0;
>   	cmd->transceiver	= XCVR_INTERNAL;
> @@ -2266,21 +2307,24 @@ static int tun_get_settings(struct net_d
>   	return 0;
>   }
>   
> +static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
> +{
> +	struct tun_struct *tun = netdev_priv(dev);
> +
> +	tun->speed = ethtool_cmd_speed(ecmd);
> +	tun->duplex = ecmd->duplex;
> +
> +	return 0;
> +}
> +
>   static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
>   {
>   	struct tun_struct *tun = netdev_priv(dev);
>   
> -	strlcpy(info->driver, DRV_NAME, sizeof(info->driver));
> +	strlcpy(info->driver, tun->info.driver, sizeof(info->driver));
>   	strlcpy(info->version, DRV_VERSION, sizeof(info->version));
>   
> -	switch (tun->flags & TUN_TYPE_MASK) {
> -	case IFF_TUN:
> -		strlcpy(info->bus_info, "tun", sizeof(info->bus_info));
> -		break;
> -	case IFF_TAP:
> -		strlcpy(info->bus_info, "tap", sizeof(info->bus_info));
> -		break;
> -	}
> +	strlcpy(info->bus_info, tun->info.bus, sizeof(info->bus_info));
>   }
>   
>   static u32 tun_get_msglevel(struct net_device *dev)
> @@ -2303,6 +2347,7 @@ static void tun_set_msglevel(struct net_
>   
>   static const struct ethtool_ops tun_ethtool_ops = {
>   	.get_settings	= tun_get_settings,
> +	.set_settings	= tun_set_settings,
>   	.get_drvinfo	= tun_get_drvinfo,
>   	.get_msglevel	= tun_get_msglevel,
>   	.set_msglevel	= tun_set_msglevel,
> --- a/include/uapi/linux/if_tunnel.h	2015-02-16 11:58:00.651506008 -0500
> +++ b/include/uapi/linux/if_tunnel.h	2015-02-16 11:58:00.651506008 -0500
> @@ -17,6 +17,12 @@
>   #define SIOCADD6RD      (SIOCDEVPRIVATE + 9)
>   #define SIOCDEL6RD      (SIOCDEVPRIVATE + 10)
>   #define SIOCCHG6RD      (SIOCDEVPRIVATE + 11)
> +#define SIOCDRVINFO	(SIOCDEVPRIVATE + 12)
> +
> +struct ip_tunnel_info {
> +	char driver[32];
> +	char bus[32];
> +};

wondering if it would be better to add an ethtool op set_drvinfo
symmetric with get_drvinfo for this ?
>   
>   #define GRE_CSUM	__cpu_to_be16(0x8000)
>   #define GRE_ROUTING	__cpu_to_be16(0x4000)
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] tun: dynamically set speed of tun

[Zhu Yanjun]

The default speed of tun is 10M while the normal nic speed is 1000M. 
When the speed of tun is accessed by the userspace application, the
default 10M is not proper. In this case, the default tun speed is 
changed to 1000M. And this speed can be dynamically configured by
the command "ethtool -s tunX speed 10/100/1000".

Zhu Yanjun (1):
  tun: change speed from 10M to dynamically configured

 drivers/net/tun.c           | 36 +++++++++++++++++++++++++++++++++++-
 include/uapi/linux/if_tun.h |  5 +++++
 2 files changed, 40 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH 1/1] tun: change speed from 10M to dynamically configured

[Zhu Yanjun]

From: Zhu Yanjun <yanjun.zhu@windriver.com>

The default speed of normal nic is 1000M while the default speed
of tun is 10M. Now the default speed of tun is changed to 1000M.
And there are 3 options: 10M, 100M and 1000M to the speed of tun.
The command "ethtool -s tun0 speed 10/100/1000" can configure the
speed of tun dynamically.

CC: Michael S. Tsirkin <mst@redhat.com>
CC: Jason Wang <jasowang@redhat.com>
CC: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
 drivers/net/tun.c           | 36 +++++++++++++++++++++++++++++++++++-
 include/uapi/linux/if_tun.h |  5 +++++
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8c8dc16..64f4dcc 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -950,6 +950,9 @@ static void tun_net_init(struct net_device *dev)
 		dev->addr_len = 0;
 		dev->mtu = 1500;
 
+		/* Set default speed 1000M */
+		tun->flags |= TUN_CTRL_SPD_1000;
+
 		/* Zero header length */
 		dev->type = ARPHRD_NONE;
 		dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
@@ -2257,9 +2260,18 @@ static struct miscdevice tun_miscdev = {
 
 static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
+	struct tun_struct *tun = netdev_priv(dev);
+
+	/*Get the speed of tun*/
+	if (tun->flags & TUN_CTRL_SPD_1000) {
+		ethtool_cmd_speed_set(cmd, SPEED_1000);
+	} else if (tun->flags & TUN_CTRL_SPD_100) {
+		ethtool_cmd_speed_set(cmd, SPEED_100);
+	} else
+		ethtool_cmd_speed_set(cmd, SPEED_10);
+
 	cmd->supported		= 0;
 	cmd->advertising	= 0;
-	ethtool_cmd_speed_set(cmd, SPEED_10);
 	cmd->duplex		= DUPLEX_FULL;
 	cmd->port		= PORT_TP;
 	cmd->phy_address	= 0;
@@ -2287,6 +2299,27 @@ static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
 	}
 }
 
+static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+	struct tun_struct *tun = netdev_priv(dev);
+	u32 speed = ethtool_cmd_speed(cmd);
+
+	if (10 == speed) {
+		tun->flags &= ~TUN_CTRL_SPD_100;
+		tun->flags &= ~TUN_CTRL_SPD_1000;
+		tun->flags |= TUN_CTRL_SPD_10;
+	} else if (100 == speed) {
+		tun->flags &= ~TUN_CTRL_SPD_10;
+		tun->flags &= ~TUN_CTRL_SPD_1000;
+		tun->flags |= TUN_CTRL_SPD_100;
+	} else {
+		tun->flags &= ~TUN_CTRL_SPD_10;
+		tun->flags &= ~TUN_CTRL_SPD_100;
+		tun->flags |= TUN_CTRL_SPD_1000;
+	}
+	return 0;
+}
+
 static u32 tun_get_msglevel(struct net_device *dev)
 {
 #ifdef TUN_DEBUG
@@ -2307,6 +2340,7 @@ static void tun_set_msglevel(struct net_device *dev, u32 value)
 
 static const struct ethtool_ops tun_ethtool_ops = {
 	.get_settings	= tun_get_settings,
+	.set_settings	= tun_set_settings,
 	.get_drvinfo	= tun_get_drvinfo,
 	.get_msglevel	= tun_get_msglevel,
 	.set_msglevel	= tun_set_msglevel,
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index 50ae243..78a09a7 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -66,6 +66,11 @@
 #define IFF_PERSIST	0x0800
 #define IFF_NOFILTER	0x1000
 
+/*add speed control, default 1000M*/
+#define TUN_CTRL_SPD_10         0x0020
+#define TUN_CTRL_SPD_100        0x0040
+#define TUN_CTRL_SPD_1000       0x0080
+
 /* Socket options */
 #define TUN_TX_TIMESTAMP 1
 
-- 
1.9.1

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Stephen Hemminger]

On Thu, 12 Feb 2015 13:35:23 +0800
Zhu Yanjun <Yanjun.Zhu@windriver.com> wrote:

> From: Zhu Yanjun <yanjun.zhu@windriver.com>
> 
> The default speed of normal nic is 1000M while the default speed
> of tun is 10M. Now the default speed of tun is changed to 1000M.
> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
> The command "ethtool -s tun0 speed 10/100/1000" can configure the
> speed of tun dynamically.
> 
> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>

Why limit to 10/100/1000 speed?
Ethtool speed can be any value

>  

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[yzhu1]

On 02/12/2015 08:55 PM, Stephen Hemminger wrote:
> On Thu, 12 Feb 2015 13:35:23 +0800
> Zhu Yanjun <Yanjun.Zhu@windriver.com> wrote:
>
>> From: Zhu Yanjun <yanjun.zhu@windriver.com>
>>
>> The default speed of normal nic is 1000M while the default speed
>> of tun is 10M. Now the default speed of tun is changed to 1000M.
>> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
>> The command "ethtool -s tun0 speed 10/100/1000" can configure the
>> speed of tun dynamically.
>>
>> CC: Michael S. Tsirkin <mst@redhat.com>
>> CC: Jason Wang <jasowang@redhat.com>
>> CC: Al Viro <viro@zeniv.linux.org.uk>
>> Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
>> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
> Why limit to 10/100/1000 speed?
> Ethtool speed can be any value
Thanks for your comments.

Yes. But the real physical nic speed often 10M, 100M and 1000M.
This simulates the physical nic.

Zhu Yanjun
>
>>   
>
>

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Fan Du]

于 2015年02月13日 10:45, yzhu1 写道:
> On 02/12/2015 08:55 PM, Stephen Hemminger wrote:
>> On Thu, 12 Feb 2015 13:35:23 +0800
>> Zhu Yanjun <Yanjun.Zhu@windriver.com> wrote:
>>
>>> From: Zhu Yanjun <yanjun.zhu@windriver.com>
>>>
>>> The default speed of normal nic is 1000M while the default speed
>>> of tun is 10M. Now the default speed of tun is changed to 1000M.
>>> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
>>> The command "ethtool -s tun0 speed 10/100/1000" can configure the
>>> speed of tun dynamically.
>>>
>>> CC: Michael S. Tsirkin <mst@redhat.com>
>>> CC: Jason Wang <jasowang@redhat.com>
>>> CC: Al Viro <viro@zeniv.linux.org.uk>
>>> Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
>>> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
>> Why limit to 10/100/1000 speed?
>> Ethtool speed can be any value
> Thanks for your comments.
>
> Yes. But the real physical nic speed often 10M, 100M and 1000M.
> This simulates the physical nic.
    ^^^^^^^^^^^^^^^
then a speed control logical would be needed to effect the corresponding speed
when tun/tap gets/puts packets corresponding to the speed setting.

What's the benefit when changing speed from 10Mb/s to 1000Mb/s?

Just xia bibi ;)

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[yzhu1]

On 02/13/2015 11:25 AM, Fan Du wrote:
> 于 2015年02月13日 10:45, yzhu1 写道:
>> On 02/12/2015 08:55 PM, Stephen Hemminger wrote:
>>> On Thu, 12 Feb 2015 13:35:23 +0800
>>> Zhu Yanjun <Yanjun.Zhu@windriver.com> wrote:
>>>
>>>> From: Zhu Yanjun <yanjun.zhu@windriver.com>
>>>>
>>>> The default speed of normal nic is 1000M while the default speed
>>>> of tun is 10M. Now the default speed of tun is changed to 1000M.
>>>> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
>>>> The command "ethtool -s tun0 speed 10/100/1000" can configure the
>>>> speed of tun dynamically.
>>>>
>>>> CC: Michael S. Tsirkin <mst@redhat.com>
>>>> CC: Jason Wang <jasowang@redhat.com>
>>>> CC: Al Viro <viro@zeniv.linux.org.uk>
>>>> Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
>>>> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
>>> Why limit to 10/100/1000 speed?
>>> Ethtool speed can be any value
>> Thanks for your comments.
>>
>> Yes. But the real physical nic speed often 10M, 100M and 1000M.
>> This simulates the physical nic.
>    ^^^^^^^^^^^^^^^
> then a speed control logical would be needed to effect the 
> corresponding speed
> when tun/tap gets/puts packets corresponding to the speed setting.
>
> What's the benefit when changing speed from 10Mb/s to 1000Mb/s?
>
> Just xia bibi ;)
:-P
Thanks for your reply.

This speed is just for user space application. There is no any speed 
control logic here.:-(

Zhu Yanjun

>
>
>
>

Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured

[Sergei Shtylyov]

Hello.

On 2/12/2015 8:35 AM, Zhu Yanjun wrote:

> From: Zhu Yanjun <yanjun.zhu@windriver.com>

> The default speed of normal nic is 1000M while the default speed
> of tun is 10M. Now the default speed of tun is changed to 1000M.
> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
> The command "ethtool -s tun0 speed 10/100/1000" can configure the
> speed of tun dynamically.

> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
> ---
>   drivers/net/tun.c           | 36 +++++++++++++++++++++++++++++++++++-
>   include/uapi/linux/if_tun.h |  5 +++++
>   2 files changed, 40 insertions(+), 1 deletion(-)

> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 8c8dc16..64f4dcc 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
[...]
> @@ -2257,9 +2260,18 @@ static struct miscdevice tun_miscdev = {
>
>   static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
>   {
> +	struct tun_struct *tun = netdev_priv(dev);
> +
> +	/*Get the speed of tun*/

    Please add spaces after /* and before */.

[...]
> @@ -2287,6 +2299,27 @@ static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
>   	}
>   }
>
> +static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> +	struct tun_struct *tun = netdev_priv(dev);
> +	u32 speed = ethtool_cmd_speed(cmd);
> +
> +	if (10 == speed) {
> +		tun->flags &= ~TUN_CTRL_SPD_100;
> +		tun->flags &= ~TUN_CTRL_SPD_1000;

   Can't you clear both bits at once?

> +		tun->flags |= TUN_CTRL_SPD_10;
> +	} else if (100 == speed) {
> +		tun->flags &= ~TUN_CTRL_SPD_10;
> +		tun->flags &= ~TUN_CTRL_SPD_1000;
> +		tun->flags |= TUN_CTRL_SPD_100;
> +	} else {
> +		tun->flags &= ~TUN_CTRL_SPD_10;
> +		tun->flags &= ~TUN_CTRL_SPD_100;
> +		tun->flags |= TUN_CTRL_SPD_1000;
> +	}

    This is asking to be a *switch* statement.

[...]
> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index 50ae243..78a09a7 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -66,6 +66,11 @@
>   #define IFF_PERSIST	0x0800
>   #define IFF_NOFILTER	0x1000
>
> +/*add speed control, default 1000M*/

    Same remark about the comment style as above.

[...]

WBR, Sergei