* Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured
From: yzhu1 @ 2015-02-13 2:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, mst, jasowang, viro, davem
In-Reply-To: <20150212045558.5091262a@uryu.home.lan>
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
>
>>
>
>
^ permalink raw reply
* Re: [PATCH RFC v5 net-next 4/6] virtio-net: add basic interrupt coalescing support
From: Rusty Russell @ 2015-02-13 2:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, netdev, linux-kernel, virtualization, pagupta,
Pawel Moll, Cornelia Huck
In-Reply-To: <20150210104019.GD9505@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Tue, Feb 10, 2015 at 12:02:37PM +1030, Rusty Russell wrote:
>> Jason Wang <jasowang@redhat.com> writes:
>> > This patch enables the interrupt coalescing setting through ethtool.
>>
>> The problem is that there's nothing network specific about interrupt
>> coalescing. I can see other devices wanting exactly the same thing,
>> which means we'd deprecate this in the next virtio standard.
>>
>> I think the right answer is to extend like we did with
>> vring_used_event(), eg:
>>
>> 1) Add a new feature VIRTIO_F_RING_COALESCE.
>> 2) Add another a 32-bit field after vring_used_event(), eg:
>> #define vring_used_delay(vr) (*(u32 *)((vr)->avail->ring[(vr)->num + 2]))
>>
>> This loses the ability to coalesce by number of frames, but we can still
>> do number of sg entries, as we do now with used_event, and we could
>> change virtqueue_enable_cb_delayed() to take a precise number if we
>> wanted.
>
> But do we expect delay to be update dynamically?
> If not, why not stick it in config space?
Hmm, we could update it dynamically (and will, in the case of ethtool).
But it won't be common, so we could append a field to
virtio_pci_common_cfg for PCI.
I think MMIO and CCW would be easy to extend too, but CC'd to check.
>> My feeling is that this should be a v1.0-only feature though
>> (eg. feature bit 33).
>
> Yes, e.g. we can't extend config space for legacy virtio pci.
Thanks,
Rusty.
^ permalink raw reply
* Re: Possible Bug in gnet_start_copy_compat for the file,gen_stats.c
From: Cong Wang @ 2015-02-13 3:01 UTC (permalink / raw)
To: nick
Cc: David Miller, john fastabend, standby24x7, rdunlap,
Linux Kernel Network Developers, LKML
In-Reply-To: <54DD626C.80505@gmail.com>
On Thu, Feb 12, 2015 at 6:33 PM, nick <xerofoify@gmail.com> wrote:
> Greets to Everyone,
> I am wondering after running sparse on the latest mainline tree why we are not unlocking the spinlock_bh,lock when calling the function,
> gnet_stats_start_copy_compat at the end of this function's body. Unless someone can explain to me why there is a very good reason for not
> unlocking the spinlock_bh,lock at the end of this function I will send in a patch fixing this. I am assuming this is a bug due to us infinitely
> looping in the spinlock_bh and deadlocking unless we exit this lock external to the call to the function,gnet_start_copy_compat.
The last time I looked at this, there is some place calling unlock,
you need to find it out. I don't think anyone touched it ever since
that time.
Let me know if you still can't find it. And yes, that code is kinda
messy, I _do_ have a patch to clean it up (not sent out yet).
^ permalink raw reply
* Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured
From: Fan Du @ 2015-02-13 3:25 UTC (permalink / raw)
To: yzhu1; +Cc: Stephen Hemminger, netdev, mst, jasowang, viro, davem
In-Reply-To: <54DD655E.5020301@windriver.com>
于 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 ;)
^ permalink raw reply
* [PATCH V2 1/1] tun: change speed from 10M to dynamically configured
From: Zhu Yanjun @ 2015-02-13 3:35 UTC (permalink / raw)
To: netdev, mst, jasowang, viro, davem, sergei.shtylyov
In-Reply-To: <1423798552-7091-1-git-send-email-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>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
drivers/net/tun.c | 42 +++++++++++++++++++++++++++++++++++++++++-
include/uapi/linux/if_tun.h | 5 +++++
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8c8dc16..0ee36f1 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,33 @@ 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);
+
+ /* Clear speed flag */
+ tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_100 |
+ TUN_CTRL_SPD_1000);
+
+ /* Set speed flag */
+ switch (speed) {
+ case 10:
+ tun->flags |= TUN_CTRL_SPD_10;
+ break;
+ case 100:
+ tun->flags |= TUN_CTRL_SPD_100;
+ break;
+ case 1000:
+ tun->flags |= TUN_CTRL_SPD_1000;
+ break;
+ default:
+ tun_debug(KERN_INFO, tun, "wrong speed!\n");
+ }
+
+ return 0;
+}
+
static u32 tun_get_msglevel(struct net_device *dev)
{
#ifdef TUN_DEBUG
@@ -2307,6 +2346,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
^ permalink raw reply related
* Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured
From: yzhu1 @ 2015-02-13 3:34 UTC (permalink / raw)
To: Fan Du; +Cc: Stephen Hemminger, netdev, mst, jasowang, viro, davem
In-Reply-To: <54DD6EBC.2030203@gmail.com>
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
>
>
>
>
^ permalink raw reply
* [PATCH V2 0/1] tun: dynamically set speed of tun
From: Zhu Yanjun @ 2015-02-13 3:35 UTC (permalink / raw)
To: netdev, mst, jasowang, viro, davem, sergei.shtylyov
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
^ permalink raw reply
* Re: [PATCH V2 1/1] tun: change speed from 10M to dynamically configured
From: Jonathon Reinhart @ 2015-02-13 3:44 UTC (permalink / raw)
To: Zhu Yanjun; +Cc: netdev, mst, jasowang, viro, davem, sergei.shtylyov
In-Reply-To: <1423798552-7091-2-git-send-email-Yanjun.Zhu@windriver.com>
Shouldn't the default case of tun_set_settings() return -EINVAL instead of zero?
On Thu, Feb 12, 2015 at 10:35 PM, Zhu Yanjun <Yanjun.Zhu@windriver.com> 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>
> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
> ---
> drivers/net/tun.c | 42 +++++++++++++++++++++++++++++++++++++++++-
> include/uapi/linux/if_tun.h | 5 +++++
> 2 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 8c8dc16..0ee36f1 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,33 @@ 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);
> +
> + /* Clear speed flag */
> + tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_100 |
> + TUN_CTRL_SPD_1000);
> +
> + /* Set speed flag */
> + switch (speed) {
> + case 10:
> + tun->flags |= TUN_CTRL_SPD_10;
> + break;
> + case 100:
> + tun->flags |= TUN_CTRL_SPD_100;
> + break;
> + case 1000:
> + tun->flags |= TUN_CTRL_SPD_1000;
> + break;
> + default:
> + tun_debug(KERN_INFO, tun, "wrong speed!\n");
> + }
> +
> + return 0;
> +}
> +
> static u32 tun_get_msglevel(struct net_device *dev)
> {
> #ifdef TUN_DEBUG
> @@ -2307,6 +2346,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
>
> --
> 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
--
Computers are incredibly fast, accurate and stupid. Human beings are
incredibly slow, inaccurate and brilliant. Together they are powerful
beyond imagination.
A. Einstein
^ permalink raw reply
* Re: [PATCH] net: ipv6: Make address flushing on ifdown optional - v3
From: David Ahern @ 2015-02-13 3:47 UTC (permalink / raw)
To: nicolas.dichtel, netdev; +Cc: Hannes Frederic Sowa
In-Reply-To: <54DCDB80.9090601@6wind.com>
On 2/12/15 9:57 AM, Nicolas Dichtel wrote:
> Le 12/02/2015 05:27, David Ahern a écrit :
>> Currently, all ipv6 addresses are flushed when the interface is
>> configured
>> down, even static address:
>>
> [snip]
>>
>> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
>> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
>> [root@f20 ~]# ip addr show dev eth1
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN
>> group default qlen 1000
>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>> inet6 2000:11:1:1::1/64 scope global tentative
>> valid_lft forever preferred_lft forever
>> [root@f20 ~]# ip link set dev eth1 up
>> [root@f20 ~]# ip link set dev eth1 down
>> [root@f20 ~]# ip addr show dev eth1
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN
>> group default qlen 1000
>> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
>> inet6 2000:11:1:1::1/64 scope global
>> valid_lft forever preferred_lft forever
>> inet6 fe80::4:11ff:fe22:3301/64 scope link
>> valid_lft forever preferred_lft forever
> Can you show an output of 'ip -6 route list table local' and 'ip -6
> route' ?
hmmmm.... interesting. once again ipv6 behavior is radically different
from ipv4.
This is *after* a configure, up, down cycle:
[root@f21 ~]# ip -6 route list table local
local ::1 dev lo proto none metric 0
local 2000:11:1:1::1 dev lo proto none metric 0
local fe80::11:22ff:fe33:4402 dev lo proto none metric 0
ff00::/8 dev eth0 metric 256
[root@f21 ~]# ip -6 route ls
unreachable ::/96 dev lo metric 1024 error -101
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101
unreachable 2002:a00::/24 dev lo metric 1024 error -101
unreachable 2002:7f00::/24 dev lo metric 1024 error -101
unreachable 2002:a9fe::/32 dev lo metric 1024 error -101
unreachable 2002:ac10::/28 dev lo metric 1024 error -101
unreachable 2002:c0a8::/32 dev lo metric 1024 error -101
unreachable 2002:e000::/19 dev lo metric 1024 error -101
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101
fe80::/64 dev eth0 proto kernel metric 256
(the ipv6 addresses on lo show up on stock 3.18.3-201.fc21.x86_64; no
idea why)
But on a subsequent ifconfig up the route is not inserted:
[root@f21 ~]# ifconfig eth1 up
[root@f21 ~]# ip -6 route ls
unreachable ::/96 dev lo metric 1024 error -101
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101
unreachable 2002:a00::/24 dev lo metric 1024 error -101
unreachable 2002:7f00::/24 dev lo metric 1024 error -101
unreachable 2002:a9fe::/32 dev lo metric 1024 error -101
unreachable 2002:ac10::/28 dev lo metric 1024 error -101
unreachable 2002:c0a8::/32 dev lo metric 1024 error -101
unreachable 2002:e000::/19 dev lo metric 1024 error -101
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
So I need to look into why.
This is what happens on that stock kernel:
[root@f21 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
[root@f21 ~]# ifconfig eth1
eth1: flags=4098<BROADCAST,MULTICAST> mtu 1500
inet6 2000:11:1:1::1 prefixlen 64 scopeid 0x0<global>
ether 02:01:02:03:04:02 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Interface in down state and address configured.
[root@f21 ~]# ip -6 route list table local
local ::1 dev lo proto none metric 0
local fe80::11:22ff:fe33:4402 dev lo proto none metric 0
ff00::/8 dev eth0 metric 256
ff00::/8 dev eth1 metric 256
[root@f21 ~]# ip -6 route ls
unreachable ::/96 dev lo metric 1024 error -101
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101
2000:11:1:1::/64 dev eth1 proto kernel metric 256
unreachable 2002:a00::/24 dev lo metric 1024 error -101
unreachable 2002:7f00::/24 dev lo metric 1024 error -101
unreachable 2002:a9fe::/32 dev lo metric 1024 error -101
unreachable 2002:ac10::/28 dev lo metric 1024 error -101
unreachable 2002:c0a8::/32 dev lo metric 1024 error -101
unreachable 2002:e000::/19 dev lo metric 1024 error -101
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101
fe80::/64 dev eth0 proto kernel metric 256
And there is an entry in the FIB which just seems wrong. It's cleaned
out on an up/down cycle.
David
^ permalink raw reply
* Re: [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
From: Hiroshi Shimamoto @ 2015-02-13 4:44 UTC (permalink / raw)
To: Skidmore, Donald C, Kirsher, Jeffrey T
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, linux-kernel@vger.kernel.org, David Laight,
Hayato Momma, Bjørn Mork
In-Reply-To: <F6FB0E698C9B3143BDF729DF22286646912A1339@ORSMSX110.amr.corp.intel.com>
> > > -----Original Message-----
> > > From: Hiroshi Shimamoto [mailto:h-shimamoto@ct.jp.nec.com]
> > > Sent: Monday, February 09, 2015 6:29 PM
> > > To: Kirsher, Jeffrey T
> > > Cc: Alexander Duyck; Skidmore, Donald C; Bjørn Mork; e1000-
> > > devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi, Sy Jong; linux-
> > > kernel@vger.kernel.org; David Laight; Hayato Momma
> > > Subject: RE: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to
> > > enable MC promiscuous mode
> > >
> > > > > > > Can you please fix up your patches based on my tree:
> > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/queue.git
> > > > > >
> > > > > > Yes. I haven't noticed your tree.
> > > > > > Will resend patches against it.
> > > > > >
> > > > >
> > > > > I encountered an issue with your tree, the commit id is below.
> > > > >
> > > > > $ git log | head
> > > > > commit e6f1649780f8f5a87299bf6af04453f93d1e3d5e
> > > > > Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> > > > > Date: Fri Jan 23 20:43:14 2015 -0800
> > > > >
> > > > > ethernet: fm10k: Actually drop 4 bits
> > > > >
> > > > > The comment explains the intention, but vid has type u16. Before the
> > > > > inner shift, it is promoted to int, which has plenty of space for all
> > > > > vid's bits, so nothing is dropped. Use a simple mask instead.
> > > > >
> > > > >
> > > > > I use the kernel from your tree in both host and guest.
> > > > >
> > > > > Assign an IPv6 for VF in guest.
> > > > > # ip -6 addr add 2001:db8::18:1/64 dev ens0
> > > > >
> > > > > Send ping packet from other server to the VM.
> > > > > # ping6 2001:db8::18:1 -I eth0
> > > > >
> > > > > The following message was shown.
> > > > > ixgbevf 0000:00:08.0: partial checksum but l4 proto=3a!
> > > > >
> > > > > If I did the same operation in the host, I saw the same error message in
> > > host too.
> > > > > ixgbe 0000:2d:00.0: partial checksum but l4 proto=3a!
> > > > >
> > > > > Do you have any idea about that?
> > > >
> > > > Ah, sorry about that, try this tree again:
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/queue.git
> > > >
> > > > That patch was dropped for favor of a patch that Matthew Vick put
> > > > together (and recently got pushed upstream). So my queue no longer
> > > > has that patch in the queue, since it got dropped.
> > >
> > > I still see the same error, the head id is the below
> > >
> > > $ git log | head
> > > commit a072afb0b45904022b76deef3b770ee9a93cb13a
> > > Author: Nicholas Krause <xerofoify@gmail.com>
> > > Date: Mon Feb 9 00:27:00 2015 -0800
> > >
> > > igb: Remove outdated fix me comment in the
> > > function,gb_acquire_swfw_sync_i210
> > >
> > >
> > > thanks,
> > > Hiroshi
> >
> > I'm having our validation see if they can recreate the same issue internally. When they get back to me I'll let you
> know
> > what we found.
>
> We did bisect, and the below looks the culprit;
>
> 32dce968dd987adfb0c00946d78dad9154f64759 is the first bad commit
> commit 32dce968dd987adfb0c00946d78dad9154f64759
> Author: Vlad Yasevich <vyasevich@gmail.com>
> Date: Sat Jan 31 10:40:18 2015 -0500
>
> ipv6: Allow for partial checksums on non-ufo packets
>
> Currntly, if we are not doing UFO on the packet, all UDP
> packets will start with CHECKSUM_NONE and thus perform full
> checksum computations in software even if device support
> IPv6 checksum offloading.
>
> Let's start start with CHECKSUM_PARTIAL if the device
> supports it and we are sending only a single packet at
> or below mtu size.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> :040000 040000 4437eaf7e944f5a6136ebf668a256fee688fda3d fade8da998d35c8da97a15f0556949ad371e5347 M net
When I reverted the commit, the issue was solved.
thanks,
Hiroshi
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH V2 1/1] tun: change speed from 10M to dynamically configured
From: yzhu1 @ 2015-02-13 5:31 UTC (permalink / raw)
To: Jonathon Reinhart; +Cc: netdev, mst, jasowang, viro, davem, sergei.shtylyov
In-Reply-To: <CAPFHKzdWJjqJnkzrFHUvL+x8keiBH588j9p7h4o35TN4Wz9Qjw@mail.gmail.com>
On 02/13/2015 11:44 AM, Jonathon Reinhart wrote:
> Shouldn't the default case of tun_set_settings() return -EINVAL instead of zero?
I agree with you.
Zhu Yanjun
>
> On Thu, Feb 12, 2015 at 10:35 PM, Zhu Yanjun <Yanjun.Zhu@windriver.com> 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>
>> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
>> ---
>> drivers/net/tun.c | 42 +++++++++++++++++++++++++++++++++++++++++-
>> include/uapi/linux/if_tun.h | 5 +++++
>> 2 files changed, 46 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 8c8dc16..0ee36f1 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,33 @@ 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);
>> +
>> + /* Clear speed flag */
>> + tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_100 |
>> + TUN_CTRL_SPD_1000);
>> +
>> + /* Set speed flag */
>> + switch (speed) {
>> + case 10:
>> + tun->flags |= TUN_CTRL_SPD_10;
>> + break;
>> + case 100:
>> + tun->flags |= TUN_CTRL_SPD_100;
>> + break;
>> + case 1000:
>> + tun->flags |= TUN_CTRL_SPD_1000;
>> + break;
>> + default:
>> + tun_debug(KERN_INFO, tun, "wrong speed!\n");
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static u32 tun_get_msglevel(struct net_device *dev)
>> {
>> #ifdef TUN_DEBUG
>> @@ -2307,6 +2346,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
>>
>> --
>> 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
>
>
>
^ permalink raw reply
* Re: [PATCH V2 1/1] tun: change speed from 10M to dynamically configured
From: Jonathon Reinhart @ 2015-02-13 5:42 UTC (permalink / raw)
To: yzhu1; +Cc: netdev, mst, jasowang, viro, davem, sergei.shtylyov
In-Reply-To: <54DD8C16.8080605@windriver.com>
Also in the default case, you've already cleared the existing
TUN_CTRL_SPD flags,
which probably isn't what a user would expect if he passed an invalid value.
On Fri, Feb 13, 2015 at 12:31 AM, yzhu1 <Yanjun.Zhu@windriver.com> wrote:
> On 02/13/2015 11:44 AM, Jonathon Reinhart wrote:
>>
>> Shouldn't the default case of tun_set_settings() return -EINVAL instead of
>> zero?
>
> I agree with you.
>
> Zhu Yanjun
>
>
>>
>> On Thu, Feb 12, 2015 at 10:35 PM, Zhu Yanjun <Yanjun.Zhu@windriver.com>
>> 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>
>>> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
>>> ---
>>> drivers/net/tun.c | 42
>>> +++++++++++++++++++++++++++++++++++++++++-
>>> include/uapi/linux/if_tun.h | 5 +++++
>>> 2 files changed, 46 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>> index 8c8dc16..0ee36f1 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,33 @@ 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);
>>> +
>>> + /* Clear speed flag */
>>> + tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_100 |
>>> + TUN_CTRL_SPD_1000);
>>> +
>>> + /* Set speed flag */
>>> + switch (speed) {
>>> + case 10:
>>> + tun->flags |= TUN_CTRL_SPD_10;
>>> + break;
>>> + case 100:
>>> + tun->flags |= TUN_CTRL_SPD_100;
>>> + break;
>>> + case 1000:
>>> + tun->flags |= TUN_CTRL_SPD_1000;
>>> + break;
>>> + default:
>>> + tun_debug(KERN_INFO, tun, "wrong speed!\n");
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static u32 tun_get_msglevel(struct net_device *dev)
>>> {
>>> #ifdef TUN_DEBUG
>>> @@ -2307,6 +2346,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
>>>
>>> --
>>> 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
>>
>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH V2 1/1] tun: change speed from 10M to dynamically configured
From: yzhu1 @ 2015-02-13 5:56 UTC (permalink / raw)
To: Jonathon Reinhart; +Cc: netdev, mst, jasowang, viro, davem, sergei.shtylyov
In-Reply-To: <CAPFHKzcUJKBEtshWuxr5arYG5Pz_CaeYkiqATEjx8FFzCiq8nw@mail.gmail.com>
Yeah. my fault. I will correct it.
On 02/13/2015 01:42 PM, Jonathon Reinhart wrote:
> Also in the default case, you've already cleared the existing
> TUN_CTRL_SPD flags,
> which probably isn't what a user would expect if he passed an invalid value.
>
> On Fri, Feb 13, 2015 at 12:31 AM, yzhu1 <Yanjun.Zhu@windriver.com> wrote:
>> On 02/13/2015 11:44 AM, Jonathon Reinhart wrote:
>>> Shouldn't the default case of tun_set_settings() return -EINVAL instead of
>>> zero?
>> I agree with you.
>>
>> Zhu Yanjun
>>
>>
>>> On Thu, Feb 12, 2015 at 10:35 PM, Zhu Yanjun <Yanjun.Zhu@windriver.com>
>>> 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>
>>>> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
>>>> ---
>>>> drivers/net/tun.c | 42
>>>> +++++++++++++++++++++++++++++++++++++++++-
>>>> include/uapi/linux/if_tun.h | 5 +++++
>>>> 2 files changed, 46 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>>> index 8c8dc16..0ee36f1 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,33 @@ 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);
>>>> +
>>>> + /* Clear speed flag */
>>>> + tun->flags &= ~(TUN_CTRL_SPD_10 | TUN_CTRL_SPD_100 |
>>>> + TUN_CTRL_SPD_1000);
>>>> +
>>>> + /* Set speed flag */
>>>> + switch (speed) {
>>>> + case 10:
>>>> + tun->flags |= TUN_CTRL_SPD_10;
>>>> + break;
>>>> + case 100:
>>>> + tun->flags |= TUN_CTRL_SPD_100;
>>>> + break;
>>>> + case 1000:
>>>> + tun->flags |= TUN_CTRL_SPD_1000;
>>>> + break;
>>>> + default:
>>>> + tun_debug(KERN_INFO, tun, "wrong speed!\n");
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> static u32 tun_get_msglevel(struct net_device *dev)
>>>> {
>>>> #ifdef TUN_DEBUG
>>>> @@ -2307,6 +2346,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
>>>>
>>>> --
>>>> 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
>>>
>>>
>>>
>
^ permalink raw reply
* [PATCH V3 0/1] tun: dynamically set speed of tun
From: Zhu Yanjun @ 2015-02-13 6:19 UTC (permalink / raw)
To: netdev, mst, jasowang, viro, davem, sergei.shtylyov,
jonathon.reinhart
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
^ permalink raw reply
* [PATCH 1/1] tun: change speed from 10M to dynamically configured
From: Zhu Yanjun @ 2015-02-13 6:19 UTC (permalink / raw)
To: netdev, mst, jasowang, viro, davem, sergei.shtylyov,
jonathon.reinhart
In-Reply-To: <1423808353-8722-1-git-send-email-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>
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
^ permalink raw reply related
* Re: [PATCH] iwl4965: Enable checking of format strings
From: Mark Rustad @ 2015-02-13 7:55 UTC (permalink / raw)
To: Rasmus Villemoes, Rustad, Mark D
Cc: Stanislaw Gruszka, Kalle Valo, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <87vbj7zb0e.fsf@rasmusvillemoes.dk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2/12/15 2:20 AM, Rasmus Villemoes wrote:
> Rather weak arguments, but I have three of them :-)
Yes, weak. All three.
> (1) If I'm reading some code and spot a non-constant format
> argument, I sometimes track back to see how e.g. fmt_value is
> defined. If I then see it's a macro, I immediately think "ok, the
> compiler is doing type-checking". If it is a const char[], I have
> to remember that gcc also does it in that case (as opposed to for
> example const char*const).
GCC should check in both cases. The case you are replacing was not
const char * const, but only const char *. Still, the compiler really
should check either form, even though theoretically the pointer in the
latter case could be changed, but the initial const value should be a
good indication of what the parameters are expected to be. No real
reason for the compiler not to check it.
> (2) The names of these variables themselves may end up wasting a
> few bytes in the image.
Maybe in a debug image, but they should be stripped from any normal
image. Really not a factor.
> (3) gcc/the linker doesn't merge identical const char[] arrays
> across translation units. It also doesn't consider their tails for
> merging with string literals. So although these specific strings
> are unlikely to appear elsewhere, a string such as "%10u\n" or
> "max\n" couldn't be merged with one of the above.
I haven't checked, but there is no theoretical reason that const char
[] items could not be merged exactly as the literals are. Considering
the boundaries the compiler guys push on optimization, doing such
merging would be tame by comparison (speculative stores make me crazy).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJU3a3+AAoJEDwO/+eO4+5unvMP/jwxA4GmwC0d3VdGsVTJkMVd
zg+jwbkhnMiaEj6uPAwV5LXV/IGyuYFgNjoiNDg9RD3trV9/3YAxdAKw1ffO+PWe
lnmXSxaapLlCTapOsUdXPg88z9muQKrcfhnGyi+jt3BFeccXgtlHLsR0qVa4ddJw
KVHByPg+AlTSNzSnROxHH3UAbxEuZmDy+g+xfbEFLCKNCgtrSX5jGyG2vJIY3lhF
40VIdriUHz1QW4C1YYeJWMKwzml7Kln3u0T5MfDEtDfy6n7hiBhHczEgPjf7dnzd
aY4+VtKTyjPWLRhyDoJfR9maaV9TsYHpheSuUVzAGwvb85wH32ugdfmcW2RPnRfC
n9ThhtWd1WdJJpmq0xhLjc9bc3nrxJO8b2J/GMsT6SjGBhPGaaJSWY37UPhhOJOj
akKkA6QwD0u6Yoc3de7unGsiKWayD7e2k3w3bus+kCSspmyn/OnkzZRc0X3nXd20
suAWNZTalLWioqvI/hyvH3GMZxIuHTJoLRpTm+K7BQs7gBM9pD7OJOpn7XLtk2PM
zPfEj8fAUMV17lzFdBP+M+pGT3HzjWVwTIUgujdA4vL6eqB1W+3fR7kqjUuQYc69
aBaMde//i+HUPzTHZht2qXEb6K9EvSsz/XlhQrtAyu2gYY8PwchdZXH0NbAGqJ9C
4BEAO4HYJijd4vVSNBFO
=utge
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"
From: Robert Jarzmik @ 2015-02-13 8:12 UTC (permalink / raw)
To: Linus Walleij
Cc: Nicolas Pitre, David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdZGze_2=hWe414Eum_9hpNXgog5vmu6Y4R_zhg0x2z0SQ@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> On Fri, Feb 13, 2015 at 12:59 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> But isn't the real problem that in the device tree case,
> irq_get_irq_data(ndev->irq) will work becaus parsing an interrupt
> from the device tree populates it correctly in platform_get_irq()
> whereas for the legacy lookup it just fetches the number.
>
> So to me it seems like a weakness in the platform_get_irq()
> helper altogether.
>
> Does the following work? (I can send as a separate patch for
> testing if you like).
I will test this evening (GMT+1 time), I feel this will work, and that this
solution looks better to me than the sheer revert. I don't ask for a separate
patch, yet if it is confirmed that it works, you'll have to submit it anyway :)
Cheers.
--
Robert
^ permalink raw reply
* [PATCH net-next 0/3] Small fix for TCP PMTU
From: Fan Du @ 2015-02-13 8:16 UTC (permalink / raw)
To: davem; +Cc: netdev, fengyuleidian0615
This patchset perform some small fix for current TCP PMTU
as per RFC4821 with below changes:
Patch1/3: Set probe mss base to 1024 Bytes
Patch2/3: Do not double probe_size for each probing,
use a simple binary search to gain maximum performance.
Patch3/3: Create a probe timer to detect enlarged path MTU.
Fan Du (3):
ipv4: Raise tcp PMTU probe mss base size
ipv4: Use binary search to choose tcp PMTU probe_size
ipv4: Create probe timer for tcp PMTU as per RFC4821
include/net/inet_connection_sock.h | 5 +++++
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 5 ++++-
net/ipv4/sysctl_net_ipv4.c | 7 +++++++
net/ipv4/tcp.c | 2 ++
net/ipv4/tcp_input.c | 5 ++++-
net/ipv4/tcp_ipv4.c | 1 +
net/ipv4/tcp_output.c | 35 +++++++++++++++++++++++++++++++----
net/ipv4/tcp_timer.c | 2 +-
9 files changed, 56 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH net-next 1/3] ipv4: Raise tcp PMTU probe mss base size
From: Fan Du @ 2015-02-13 8:16 UTC (permalink / raw)
To: davem; +Cc: netdev, fengyuleidian0615
In-Reply-To: <1423815405-32644-1-git-send-email-fan.du@intel.com>
Quotes from RFC4821 7.2. Selecting Initial Values
It is RECOMMENDED that search_low be initially set to an MTU size
that is likely to work over a very wide range of environments. Given
today's technologies, a value of 1024 bytes is probably safe enough.
The initial value for search_low SHOULD be configurable.
Moreover, set a small value will introduce extra time for the search
to converge. So set the initial probe base mss size to 1024 Bytes.
Signed-off-by: Fan Du <fan.du@intel.com>
---
include/net/tcp.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 8d6b983..7b57e5b 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -65,7 +65,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
#define TCP_MIN_MSS 88U
/* The least MTU to use for probing */
-#define TCP_BASE_MSS 512
+#define TCP_BASE_MSS 1024
/* After receiving this amount of duplicate ACKs fast retransmit starts. */
#define TCP_FASTRETRANS_THRESH 3
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 3/3] ipv4: Create probe timer for tcp PMTU as per RFC4821
From: Fan Du @ 2015-02-13 8:16 UTC (permalink / raw)
To: davem; +Cc: netdev, fengyuleidian0615
In-Reply-To: <1423815405-32644-1-git-send-email-fan.du@intel.com>
As per RFC4821 7.3. Selecting Probe Size, a probe timer should
be armed once probing has converged. Once this timer expired,
probing again to take advantage of any path PMTU change. The
recommended probing interval is 10 minutes per RFC1981.
Signed-off-by: Fan Du <fan.du@intel.com>
---
include/net/inet_connection_sock.h | 2 ++
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 3 +++
net/ipv4/sysctl_net_ipv4.c | 7 +++++++
net/ipv4/tcp.c | 2 ++
net/ipv4/tcp_ipv4.c | 1 +
net/ipv4/tcp_output.c | 23 ++++++++++++++++++++++-
7 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index 3d0932e..e78e5ab 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -126,6 +126,8 @@ struct inet_connection_sock {
int search_high_sav;
int search_low_sav;
+
+ struct timer_list probe_timer;
/* Information on the current probe. */
int probe_size;
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index dbe2254..bb2c2d1 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -84,6 +84,7 @@ struct netns_ipv4 {
int sysctl_tcp_fwmark_accept;
int sysctl_tcp_mtu_probing;
int sysctl_tcp_base_mss;
+ u32 sysctl_tcp_probe_interval;
struct ping_group_range ping_group_range;
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 7b57e5b..16fa2e6 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -67,6 +67,9 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
/* The least MTU to use for probing */
#define TCP_BASE_MSS 1024
+/* probing interval, default to 10 minutes as per RFC4821 */
+#define TCP_PROBE_INTERVAL 600
+
/* After receiving this amount of duplicate ACKs fast retransmit starts. */
#define TCP_FASTRETRANS_THRESH 3
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index d151539..4fa5d31 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -883,6 +883,13 @@ static struct ctl_table ipv4_net_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+ {
+ .procname = "tcp_probe_interval",
+ .data = &init_net.ipv4.sysctl_tcp_probe_interval,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
{ }
};
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 9d72a0f..46413ee 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1986,6 +1986,7 @@ void tcp_close(struct sock *sk, long timeout)
struct sk_buff *skb;
int data_was_unread = 0;
int state;
+ struct inet_connection_sock *icsk = inet_csk(sk);
lock_sock(sk);
sk->sk_shutdown = SHUTDOWN_MASK;
@@ -2149,6 +2150,7 @@ adjudge_to_death:
/* Otherwise, socket is reprieved until protocol close. */
out:
+ del_timer(&icsk->icsk_mtup.probe_timer);
bh_unlock_sock(sk);
local_bh_enable();
sock_put(sk);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5a2dfed..3cc71b3 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2460,6 +2460,7 @@ static int __net_init tcp_sk_init(struct net *net)
}
net->ipv4.sysctl_tcp_ecn = 2;
net->ipv4.sysctl_tcp_base_mss = TCP_BASE_MSS;
+ net->ipv4.sysctl_tcp_probe_interval = TCP_PROBE_INTERVAL;
return 0;
fail:
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 0a60deb..461b4a4 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1342,6 +1342,18 @@ int tcp_mss_to_mtu(struct sock *sk, int mss)
return mtu;
}
+static void icsk_mtup_probe_timer(unsigned long arg)
+{
+ struct sock *sk = (struct sock *)arg;
+ struct net *net = sock_net(sk);
+ struct inet_connection_sock *icsk = inet_csk(sk);
+
+ /* Restore orignal search range */
+ icsk->icsk_mtup.search_high = icsk->icsk_mtup.search_high_sav;
+ icsk->icsk_mtup.search_low = icsk->icsk_mtup.search_low_sav;
+ icsk->icsk_mtup.probe_size = 0;
+}
+
/* MTU probing init per socket */
void tcp_mtup_init(struct sock *sk)
{
@@ -1357,6 +1369,9 @@ void tcp_mtup_init(struct sock *sk)
icsk->icsk_mtup.search_high_sav = icsk->icsk_mtup.search_high;
icsk->icsk_mtup.search_low_sav = icsk->icsk_mtup.search_low;
icsk->icsk_mtup.probe_size = 0;
+
+ setup_timer(&icsk->icsk_mtup.probe_timer, icsk_mtup_probe_timer,
+ (unsigned long)sk);
}
EXPORT_SYMBOL(tcp_mtup_init);
@@ -1840,6 +1855,7 @@ static int tcp_mtu_probe(struct sock *sk)
struct tcp_sock *tp = tcp_sk(sk);
struct inet_connection_sock *icsk = inet_csk(sk);
struct sk_buff *skb, *nskb, *next;
+ struct net *net = sock_net(sk);
int len;
int probe_size;
int size_needed;
@@ -1865,7 +1881,12 @@ static int tcp_mtu_probe(struct sock *sk)
probe_size = (icsk->icsk_mtup.search_high + icsk->icsk_mtup.search_low) >> 1;
size_needed = probe_size + (tp->reordering + 1) * tp->mss_cache;
if (probe_size > tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_high)) {
- /* TODO: set timer for probe_converge_event */
+ u32 probe_interval = net->ipv4.sysctl_tcp_probe_interval;
+
+ /* Search has been converged, start the timer,
+ * take advantage of path changing */
+ mod_timer(&icsk->icsk_mtup.probe_timer,
+ jiffies + msecs_to_jiffies(1000*probe_interval));
return -1;
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/3] ipv4: Use binary search to choose tcp PMTU probe_size
From: Fan Du @ 2015-02-13 8:16 UTC (permalink / raw)
To: davem; +Cc: netdev, fengyuleidian0615
In-Reply-To: <1423815405-32644-1-git-send-email-fan.du@intel.com>
Current probe_size is chosen by doubling mss_cache,
the initial mss base is 512 Bytes, as a result the
converged probe_size will only be 1024 Bytes, there
is still big gap between 1024 and common 1500 bytes
of mtu.
Use binary search to choose probe_size in a fine
granularity manner, an optimal mss will be found
to boost performance as its maxmium.
Test env:
Docker instance with vxlan encapuslation(82599EB)
iperf -c 10.0.0.24 -t 60
before this patch:
1.26 Gbits/sec
After this patch: increase 26%
1.59 Gbits/sec
Signed-off-by: Fan Du <fan.du@intel.com>
---
include/net/inet_connection_sock.h | 3 +++
net/ipv4/tcp_input.c | 5 ++++-
net/ipv4/tcp_output.c | 12 +++++++++---
net/ipv4/tcp_timer.c | 2 +-
4 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index 5976bde..3d0932e 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -124,6 +124,9 @@ struct inet_connection_sock {
int search_high;
int search_low;
+ int search_high_sav;
+ int search_low_sav;
+
/* Information on the current probe. */
int probe_size;
} icsk_mtup;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 8fdd27b..20b28e9 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2613,7 +2613,10 @@ static void tcp_mtup_probe_success(struct sock *sk)
tp->snd_cwnd_stamp = tcp_time_stamp;
tp->snd_ssthresh = tcp_current_ssthresh(sk);
- icsk->icsk_mtup.search_low = icsk->icsk_mtup.probe_size;
+ if (icsk->icsk_mtup.search_low == icsk->icsk_mtup.probe_size)
+ icsk->icsk_mtup.search_low = icsk->icsk_mtup.search_high;
+ else
+ icsk->icsk_mtup.search_low = icsk->icsk_mtup.probe_size;
icsk->icsk_mtup.probe_size = 0;
tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
}
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index a2a796c..0a60deb 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1349,10 +1349,13 @@ void tcp_mtup_init(struct sock *sk)
struct inet_connection_sock *icsk = inet_csk(sk);
struct net *net = sock_net(sk);
- icsk->icsk_mtup.enabled = net->ipv4.sysctl_tcp_mtu_probing > 1;
+ icsk->icsk_mtup.enabled = net->ipv4.sysctl_tcp_mtu_probing;
icsk->icsk_mtup.search_high = tp->rx_opt.mss_clamp + sizeof(struct tcphdr) +
icsk->icsk_af_ops->net_header_len;
icsk->icsk_mtup.search_low = tcp_mss_to_mtu(sk, net->ipv4.sysctl_tcp_base_mss);
+
+ icsk->icsk_mtup.search_high_sav = icsk->icsk_mtup.search_high;
+ icsk->icsk_mtup.search_low_sav = icsk->icsk_mtup.search_low;
icsk->icsk_mtup.probe_size = 0;
}
EXPORT_SYMBOL(tcp_mtup_init);
@@ -1854,9 +1857,12 @@ static int tcp_mtu_probe(struct sock *sk)
tp->rx_opt.num_sacks || tp->rx_opt.dsack)
return -1;
- /* Very simple search strategy: just double the MSS. */
+ /* Use binary search for probe_size bewteen tcp_mss_base
+ * and current mss_clamp.
+ */
mss_now = tcp_current_mss(sk);
- probe_size = 2 * tp->mss_cache;
+
+ probe_size = (icsk->icsk_mtup.search_high + icsk->icsk_mtup.search_low) >> 1;
size_needed = probe_size + (tp->reordering + 1) * tp->mss_cache;
if (probe_size > tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_high)) {
/* TODO: set timer for probe_converge_event */
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 0732b78..9d1cfe0 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -113,7 +113,7 @@ static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk)
struct tcp_sock *tp = tcp_sk(sk);
int mss;
- mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low) >> 1;
+ mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low);
mss = min(net->ipv4.sysctl_tcp_base_mss, mss);
mss = max(mss, 68 - tp->tcp_header_len);
icsk->icsk_mtup.search_low = tcp_mss_to_mtu(sk, mss);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next 1/3] ipv4: Raise tcp PMTU probe mss base size
From: yzhu1 @ 2015-02-13 9:49 UTC (permalink / raw)
To: Fan Du, davem; +Cc: netdev, fengyuleidian0615
In-Reply-To: <1423815405-32644-2-git-send-email-fan.du@intel.com>
backward compatible? :-D
Zhu Yanjun
On 02/13/2015 04:16 PM, Fan Du wrote:
> Quotes from RFC4821 7.2. Selecting Initial Values
>
> It is RECOMMENDED that search_low be initially set to an MTU size
> that is likely to work over a very wide range of environments. Given
> today's technologies, a value of 1024 bytes is probably safe enough.
> The initial value for search_low SHOULD be configurable.
>
> Moreover, set a small value will introduce extra time for the search
> to converge. So set the initial probe base mss size to 1024 Bytes.
>
> Signed-off-by: Fan Du <fan.du@intel.com>
> ---
> include/net/tcp.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 8d6b983..7b57e5b 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -65,7 +65,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
> #define TCP_MIN_MSS 88U
>
> /* The least MTU to use for probing */
> -#define TCP_BASE_MSS 512
> +#define TCP_BASE_MSS 1024
>
> /* After receiving this amount of duplicate ACKs fast retransmit starts. */
> #define TCP_FASTRETRANS_THRESH 3
^ permalink raw reply
* If bridge have no sub-interfaces, it's status may be still with 'RUNNING'
From: yzhu1 @ 2015-02-13 9:57 UTC (permalink / raw)
To: netdev, Wu, Kuaikuai, Tao, Yue
Hi, all
I made this test on ubuntu 14.04 with kernel 3,19-rc7:
1. brctl addbr br0
2. ifconfig br0 up
3. ifconfig br0 (br0's status is with 'RUNNING')
4. brctl addif br0 eth0
5. brctl delif br0 eth0
6. ifconfig br0 (br0's status is without 'RUNNING')
When there is no sub-interface, the flag "RUNNING" is missing after the
last sub-interface is removed.
As such, should we keep "RUNNING" flag after the last sub-interface is
removed?
Thanks a lot.
Zhu Yanjun
^ permalink raw reply
* Re: If bridge have no sub-interfaces, it's status may be still with 'RUNNING'
From: yzhu1 @ 2015-02-13 10:00 UTC (permalink / raw)
To: netdev, Wu, Kuaikuai, Tao, Yue,
stephen@networkplumber.org >> Stephen Hemminger
In-Reply-To: <54DDCA99.4040401@windriver.com>
Add the maintainer of bridge.
Any reply is appreciated.
Zhu Yanjun
On 02/13/2015 05:57 PM, yzhu1 wrote:
> Hi, all
>
> I made this test on ubuntu 14.04 with kernel 3,19-rc7:
>
> 1. brctl addbr br0
>
> 2. ifconfig br0 up
>
> 3. ifconfig br0 (br0's status is with 'RUNNING')
>
> 4. brctl addif br0 eth0
>
> 5. brctl delif br0 eth0
>
> 6. ifconfig br0 (br0's status is without 'RUNNING')
>
> When there is no sub-interface, the flag "RUNNING" is missing after
> the last sub-interface is removed.
>
> As such, should we keep "RUNNING" flag after the last sub-interface is
> removed?
>
> Thanks a lot.
> Zhu Yanjun
> --
> 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
>
>
^ permalink raw reply
* Re: [PATCH net-next 3/3] ipv4: Create probe timer for tcp PMTU as per RFC4821
From: Ying Xue @ 2015-02-13 9:59 UTC (permalink / raw)
To: Fan Du, davem; +Cc: netdev, fengyuleidian0615
In-Reply-To: <1423815405-32644-4-git-send-email-fan.du@intel.com>
On 02/13/2015 04:16 PM, Fan Du wrote:
> As per RFC4821 7.3. Selecting Probe Size, a probe timer should
> be armed once probing has converged. Once this timer expired,
> probing again to take advantage of any path PMTU change. The
> recommended probing interval is 10 minutes per RFC1981.
>
> Signed-off-by: Fan Du <fan.du@intel.com>
> ---
> include/net/inet_connection_sock.h | 2 ++
> include/net/netns/ipv4.h | 1 +
> include/net/tcp.h | 3 +++
> net/ipv4/sysctl_net_ipv4.c | 7 +++++++
> net/ipv4/tcp.c | 2 ++
> net/ipv4/tcp_ipv4.c | 1 +
> net/ipv4/tcp_output.c | 23 ++++++++++++++++++++++-
> 7 files changed, 38 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
> index 3d0932e..e78e5ab 100644
> --- a/include/net/inet_connection_sock.h
> +++ b/include/net/inet_connection_sock.h
> @@ -126,6 +126,8 @@ struct inet_connection_sock {
>
> int search_high_sav;
> int search_low_sav;
> +
> + struct timer_list probe_timer;
>
> /* Information on the current probe. */
> int probe_size;
> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
> index dbe2254..bb2c2d1 100644
> --- a/include/net/netns/ipv4.h
> +++ b/include/net/netns/ipv4.h
> @@ -84,6 +84,7 @@ struct netns_ipv4 {
> int sysctl_tcp_fwmark_accept;
> int sysctl_tcp_mtu_probing;
> int sysctl_tcp_base_mss;
> + u32 sysctl_tcp_probe_interval;
>
> struct ping_group_range ping_group_range;
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 7b57e5b..16fa2e6 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -67,6 +67,9 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
> /* The least MTU to use for probing */
> #define TCP_BASE_MSS 1024
>
> +/* probing interval, default to 10 minutes as per RFC4821 */
> +#define TCP_PROBE_INTERVAL 600
> +
> /* After receiving this amount of duplicate ACKs fast retransmit starts. */
> #define TCP_FASTRETRANS_THRESH 3
>
> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index d151539..4fa5d31 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -883,6 +883,13 @@ static struct ctl_table ipv4_net_table[] = {
> .mode = 0644,
> .proc_handler = proc_dointvec,
> },
> + {
> + .procname = "tcp_probe_interval",
> + .data = &init_net.ipv4.sysctl_tcp_probe_interval,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> { }
> };
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 9d72a0f..46413ee 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1986,6 +1986,7 @@ void tcp_close(struct sock *sk, long timeout)
> struct sk_buff *skb;
> int data_was_unread = 0;
> int state;
> + struct inet_connection_sock *icsk = inet_csk(sk);
>
> lock_sock(sk);
> sk->sk_shutdown = SHUTDOWN_MASK;
> @@ -2149,6 +2150,7 @@ adjudge_to_death:
> /* Otherwise, socket is reprieved until protocol close. */
>
> out:
> + del_timer(&icsk->icsk_mtup.probe_timer);
> bh_unlock_sock(sk);
> local_bh_enable();
> sock_put(sk);
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 5a2dfed..3cc71b3 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -2460,6 +2460,7 @@ static int __net_init tcp_sk_init(struct net *net)
> }
> net->ipv4.sysctl_tcp_ecn = 2;
> net->ipv4.sysctl_tcp_base_mss = TCP_BASE_MSS;
> + net->ipv4.sysctl_tcp_probe_interval = TCP_PROBE_INTERVAL;
> return 0;
>
> fail:
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 0a60deb..461b4a4 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1342,6 +1342,18 @@ int tcp_mss_to_mtu(struct sock *sk, int mss)
> return mtu;
> }
>
> +static void icsk_mtup_probe_timer(unsigned long arg)
> +{
> + struct sock *sk = (struct sock *)arg;
> + struct net *net = sock_net(sk);
> + struct inet_connection_sock *icsk = inet_csk(sk);
> +
> + /* Restore orignal search range */
> + icsk->icsk_mtup.search_high = icsk->icsk_mtup.search_high_sav;
> + icsk->icsk_mtup.search_low = icsk->icsk_mtup.search_low_sav;
> + icsk->icsk_mtup.probe_size = 0;
> +}
> +
As icsk_mtup_probe_timer() is run asynchronously, we may touch an invalid socket
instance if we don't hold socket's refcount before launching the timer.
Therefore, in general we use the standard interfaces like sk_reset_timer() and
sk_stop_timer() to operate timers associated with socket. So, the usage about
timer in the patch seems unsafe for us. For instance, you can study how
icsk_retransmit_timer, icsk_delack_timer and sk_timer, are implemented.
Regards,
Ying
> /* MTU probing init per socket */
> void tcp_mtup_init(struct sock *sk)
> {
> @@ -1357,6 +1369,9 @@ void tcp_mtup_init(struct sock *sk)
> icsk->icsk_mtup.search_high_sav = icsk->icsk_mtup.search_high;
> icsk->icsk_mtup.search_low_sav = icsk->icsk_mtup.search_low;
> icsk->icsk_mtup.probe_size = 0;
> +
> + setup_timer(&icsk->icsk_mtup.probe_timer, icsk_mtup_probe_timer,
> + (unsigned long)sk);
> }
> EXPORT_SYMBOL(tcp_mtup_init);
>
> @@ -1840,6 +1855,7 @@ static int tcp_mtu_probe(struct sock *sk)
> struct tcp_sock *tp = tcp_sk(sk);
> struct inet_connection_sock *icsk = inet_csk(sk);
> struct sk_buff *skb, *nskb, *next;
> + struct net *net = sock_net(sk);
> int len;
> int probe_size;
> int size_needed;
> @@ -1865,7 +1881,12 @@ static int tcp_mtu_probe(struct sock *sk)
> probe_size = (icsk->icsk_mtup.search_high + icsk->icsk_mtup.search_low) >> 1;
> size_needed = probe_size + (tp->reordering + 1) * tp->mss_cache;
> if (probe_size > tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_high)) {
> - /* TODO: set timer for probe_converge_event */
> + u32 probe_interval = net->ipv4.sysctl_tcp_probe_interval;
> +
> + /* Search has been converged, start the timer,
> + * take advantage of path changing */
> + mod_timer(&icsk->icsk_mtup.probe_timer,
> + jiffies + msecs_to_jiffies(1000*probe_interval));
> return -1;
> }
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox