* [PATCH] net: fix checking boundary of valid vlan id
From: akong @ 2012-12-30 6:28 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Amos Kong <akong@redhat.com>
4096 is not a valid vlan id.
Signed-off-by: Amos Kong <akong@redhat.com>
---
net/bridge/netfilter/ebt_vlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/netfilter/ebt_vlan.c b/net/bridge/netfilter/ebt_vlan.c
index eae67bf..b279ec0 100644
--- a/net/bridge/netfilter/ebt_vlan.c
+++ b/net/bridge/netfilter/ebt_vlan.c
@@ -121,8 +121,8 @@ static int ebt_vlan_mt_check(const struct xt_mtchk_param *par)
* if_vlan.h: VLAN_N_VID 4096. */
if (GET_BITMASK(EBT_VLAN_ID)) {
if (!!info->id) { /* if id!=0 => check vid range */
- if (info->id > VLAN_N_VID) {
- pr_debug("id %d is out of range (1-4096)\n",
+ if (info->id >= VLAN_N_VID) {
+ pr_debug("id %d is out of range (1-4095)\n",
info->id);
return -EINVAL;
}
--
1.7.11.7
^ permalink raw reply related
* [PATCH v2 net-next] team: add ethtool support
From: Flavio Leitner @ 2012-12-30 2:37 UTC (permalink / raw)
To: netdev; +Cc: Jiri Pirko, Flavio Leitner
This patch adds few ethtool operations to team driver.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
v2 - removed generic statistics from ethtool
drivers/net/team/team.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index ad86660..7665a088 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -28,6 +28,7 @@
#include <net/genetlink.h>
#include <net/netlink.h>
#include <net/sch_generic.h>
+#include <generated/utsrelease.h>
#include <linux/if_team.h>
#define DRV_NAME "team"
@@ -1731,6 +1732,21 @@ static const struct net_device_ops team_netdev_ops = {
.ndo_fix_features = team_fix_features,
};
+/***********************
+ * ethtool interface
+ ***********************/
+
+static void team_ethtool_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *drvinfo)
+{
+ strncpy(drvinfo->driver, DRV_NAME, 32);
+ strncpy(drvinfo->version, UTS_RELEASE, 32);
+}
+
+static const struct ethtool_ops team_ethtool_ops = {
+ .get_drvinfo = team_ethtool_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+};
/***********************
* rt netlink interface
@@ -1780,6 +1796,7 @@ static void team_setup(struct net_device *dev)
ether_setup(dev);
dev->netdev_ops = &team_netdev_ops;
+ dev->ethtool_ops = &team_ethtool_ops;
dev->destructor = team_destructor;
dev->tx_queue_len = 0;
dev->flags |= IFF_MULTICAST;
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH net-next] team: add ethtool support
From: Eric Dumazet @ 2012-12-30 2:31 UTC (permalink / raw)
To: Flavio Leitner; +Cc: Stephen Hemminger, netdev, Jiri Pirko
In-Reply-To: <20121230014403.GA2077@obelix.rh>
On Sat, 2012-12-29 at 23:44 -0200, Flavio Leitner wrote:
> Speaking as a support engineer, it's a lot easier to grab ethtool -S and
> see everything than grab two or more outputs.
>
I agree its very convenient.
I have a patch to add GRO statistics at the core layer, in the ethtool
-S stats.
I was about to ask netdev guys what they think of this idea ?
net-gro: Add GRO counters to ethtool -S
In order to get an idea of how effective is GRO aggregation on a machine,
we need appropriate counters. Preferably use "ethtool -S" to display them
on a per device basis, or even per RX queue.
In this implementation, I chose to not change NIC drivers.
Core network stack adds the gro counters at the end of the counters
each NIC driver provides for ethtool -S
There are 5 counters per RX queue :
gro_complete: number of time the NAPI handler did not consume its budget
(This force a flush of all GRO packets in the GRO queue)
gro_overflows: number of time a segment could not be stored in GRO queue
because current number or messages is too high
gro_nogro: number of time a segment was not stored in GRO queue.
(Because its not a TCP packet, or it includes a
SYN/FIN/RST/PSH flag)
gro_msgs: number of GRO messages (might contain 1 to 17 segments)
gro_segs: number of GRO segments
Example:
On receiver machine, with 8 RX queues :
ethtool -S eth4 | tail -n 10
gro_complete[7]: 56635
gro_overflows[7]: 0
gro_nogro[7]: 212
gro_msgs[7]: 129410
gro_segs[7]: 1434925
gro_complete: 699479
gro_overflows: 0
gro_nogro: 2455
gro_msgs: 1626470
gro_segs: 17876794
In this example, we can compute average number of segments per GRO message :
17876794/17876794 = 10.99
Or more precisely : 17876794/(17876794+2455) = 10.97
^ permalink raw reply
* Re: [PATCH net-next] team: add ethtool support
From: Flavio Leitner @ 2012-12-30 2:30 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev, jiri
In-Reply-To: <20121229.180930.2054437059250829691.davem@davemloft.net>
On Sat, Dec 29, 2012 at 06:09:30PM -0800, David Miller wrote:
> From: Flavio Leitner <fbl@redhat.com>
> Date: Sat, 29 Dec 2012 23:44:03 -0200
>
> > Right, but those statistics can be device specific as well. The tg3 and bnx2, for
> > instance, do the same reporting [rx|tx]_bytes|octets.
>
> Because those ARE PER QUEUE in multiqueue configurations, and thus
> device specific.
>
> There is no reason to report the bare single-queue generic
> netdevice stats via ethtool.
Alright, I will post another version without the statistics.
please, drop this one.
thanks,
--
fbl
^ permalink raw reply
* [PATCH] veth: extend device features
From: Eric Dumazet @ 2012-12-30 2:26 UTC (permalink / raw)
To: Michał Mirosław, David Miller
Cc: Andrew Vagin, netdev, vvs, Michał Mirosław
In-Reply-To: <CAHXqBFL+Ycw4-_LRcOCT0bjhALE3HfVMB7YfcoCruu=zW5PN-g@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
veth is lacking most modern facilities, like SG, checksums, TSO.
It makes sense to extend dev->features to get them, or GRO aggregation
is defeated by a forced segmentation.
Reported-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/net/veth.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 95814d9..ccf211f 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -259,6 +259,10 @@ static const struct net_device_ops veth_netdev_ops = {
.ndo_set_mac_address = eth_mac_addr,
};
+#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO | \
+ NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
+ NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX)
+
static void veth_setup(struct net_device *dev)
{
ether_setup(dev);
@@ -269,9 +273,10 @@ static void veth_setup(struct net_device *dev)
dev->netdev_ops = &veth_netdev_ops;
dev->ethtool_ops = &veth_ethtool_ops;
dev->features |= NETIF_F_LLTX;
+ dev->features |= VETH_FEATURES;
dev->destructor = veth_dev_free;
- dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG | NETIF_F_RXCSUM;
+ dev->hw_features = VETH_FEATURES;
}
/*
^ permalink raw reply related
* Re: [PATCH net-next] team: add ethtool support
From: David Miller @ 2012-12-30 2:09 UTC (permalink / raw)
To: fbl; +Cc: shemminger, netdev, jiri
In-Reply-To: <20121230014403.GA2077@obelix.rh>
From: Flavio Leitner <fbl@redhat.com>
Date: Sat, 29 Dec 2012 23:44:03 -0200
> Right, but those statistics can be device specific as well. The tg3 and bnx2, for
> instance, do the same reporting [rx|tx]_bytes|octets.
Because those ARE PER QUEUE in multiqueue configurations, and thus
device specific.
There is no reason to report the bare single-queue generic
netdevice stats via ethtool.
^ permalink raw reply
* [PATCH net-next] veth: reduce stat overhead
From: Eric Dumazet @ 2012-12-30 2:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
veth stats are a bit bloated. There is no need to account transmit
and receive stats, since they are absolutely symmetric.
Also use a per device atomic64_t for the dropped counter, as it
should never be used in fast path.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/veth.c | 115 ++++++++++++++----------------------
include/linux/netdevice.h | 1
2 files changed, 48 insertions(+), 68 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 95814d9..c048f8d 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -25,18 +25,15 @@
#define MIN_MTU 68 /* Min L3 MTU */
#define MAX_MTU 65535 /* Max L3 MTU (arbitrary) */
-struct veth_net_stats {
- u64 rx_packets;
- u64 rx_bytes;
- u64 tx_packets;
- u64 tx_bytes;
- u64 rx_dropped;
+struct pcpu_vstats {
+ u64 packets;
+ u64 bytes;
struct u64_stats_sync syncp;
};
struct veth_priv {
- struct net_device *peer;
- struct veth_net_stats __percpu *stats;
+ struct net_device *peer;
+ atomic64_t dropped;
};
/*
@@ -107,50 +104,30 @@ static const struct ethtool_ops veth_ethtool_ops = {
.get_ethtool_stats = veth_get_ethtool_stats,
};
-/*
- * xmit
- */
-
static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
{
- struct net_device *rcv = NULL;
- struct veth_priv *priv, *rcv_priv;
- struct veth_net_stats *stats, *rcv_stats;
- int length;
-
- priv = netdev_priv(dev);
- rcv = priv->peer;
- rcv_priv = netdev_priv(rcv);
-
- stats = this_cpu_ptr(priv->stats);
- rcv_stats = this_cpu_ptr(rcv_priv->stats);
+ struct veth_priv *priv = netdev_priv(dev);
+ struct net_device *rcv = priv->peer;
+ int length = skb->len;
/* don't change ip_summed == CHECKSUM_PARTIAL, as that
- will cause bad checksum on forwarded packets */
+ * will cause bad checksum on forwarded packets
+ */
if (skb->ip_summed == CHECKSUM_NONE &&
rcv->features & NETIF_F_RXCSUM)
skb->ip_summed = CHECKSUM_UNNECESSARY;
- length = skb->len;
- if (dev_forward_skb(rcv, skb) != NET_RX_SUCCESS)
- goto rx_drop;
-
- u64_stats_update_begin(&stats->syncp);
- stats->tx_bytes += length;
- stats->tx_packets++;
- u64_stats_update_end(&stats->syncp);
+ if (likely(dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {
+ struct pcpu_vstats *stats = this_cpu_ptr(dev->vstats);
- u64_stats_update_begin(&rcv_stats->syncp);
- rcv_stats->rx_bytes += length;
- rcv_stats->rx_packets++;
- u64_stats_update_end(&rcv_stats->syncp);
-
- return NETDEV_TX_OK;
+ u64_stats_update_begin(&stats->syncp);
+ stats->bytes += length;
+ stats->packets++;
+ u64_stats_update_end(&stats->syncp);
+ } else {
+ atomic64_inc(&priv->dropped);
+ }
-rx_drop:
- u64_stats_update_begin(&rcv_stats->syncp);
- rcv_stats->rx_dropped++;
- u64_stats_update_end(&rcv_stats->syncp);
return NETDEV_TX_OK;
}
@@ -158,32 +135,42 @@ rx_drop:
* general routines
*/
-static struct rtnl_link_stats64 *veth_get_stats64(struct net_device *dev,
- struct rtnl_link_stats64 *tot)
+static u64 veth_stats_one(struct pcpu_vstats *result, struct net_device *dev)
{
struct veth_priv *priv = netdev_priv(dev);
int cpu;
+ result->packets = 0;
+ result->bytes = 0;
for_each_possible_cpu(cpu) {
- struct veth_net_stats *stats = per_cpu_ptr(priv->stats, cpu);
- u64 rx_packets, rx_bytes, rx_dropped;
- u64 tx_packets, tx_bytes;
+ struct pcpu_vstats *stats = per_cpu_ptr(dev->vstats, cpu);
+ u64 packets, bytes;
unsigned int start;
do {
start = u64_stats_fetch_begin_bh(&stats->syncp);
- rx_packets = stats->rx_packets;
- tx_packets = stats->tx_packets;
- rx_bytes = stats->rx_bytes;
- tx_bytes = stats->tx_bytes;
- rx_dropped = stats->rx_dropped;
+ packets = stats->packets;
+ bytes = stats->bytes;
} while (u64_stats_fetch_retry_bh(&stats->syncp, start));
- tot->rx_packets += rx_packets;
- tot->tx_packets += tx_packets;
- tot->rx_bytes += rx_bytes;
- tot->tx_bytes += tx_bytes;
- tot->rx_dropped += rx_dropped;
+ result->packets += packets;
+ result->bytes += bytes;
}
+ return atomic64_read(&priv->dropped);
+}
+
+static struct rtnl_link_stats64 *veth_get_stats64(struct net_device *dev,
+ struct rtnl_link_stats64 *tot)
+{
+ struct veth_priv *priv = netdev_priv(dev);
+ struct pcpu_vstats one;
+
+ tot->tx_dropped = veth_stats_one(&one, dev);
+ tot->tx_bytes = one.bytes;
+ tot->tx_packets = one.packets;
+
+ tot->rx_dropped = veth_stats_one(&one, priv->peer);
+ tot->rx_bytes = one.bytes;
+ tot->rx_packets = one.packets;
return tot;
}
@@ -228,24 +215,16 @@ static int veth_change_mtu(struct net_device *dev, int new_mtu)
static int veth_dev_init(struct net_device *dev)
{
- struct veth_net_stats __percpu *stats;
- struct veth_priv *priv;
-
- stats = alloc_percpu(struct veth_net_stats);
- if (stats == NULL)
+ dev->vstats = alloc_percpu(struct pcpu_vstats);
+ if (!dev->vstats)
return -ENOMEM;
- priv = netdev_priv(dev);
- priv->stats = stats;
return 0;
}
static void veth_dev_free(struct net_device *dev)
{
- struct veth_priv *priv;
-
- priv = netdev_priv(dev);
- free_percpu(priv->stats);
+ free_percpu(dev->vstats);
free_netdev(dev);
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c599e47..e3f5755 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1274,6 +1274,7 @@ struct net_device {
struct pcpu_lstats __percpu *lstats; /* loopback stats */
struct pcpu_tstats __percpu *tstats; /* tunnel stats */
struct pcpu_dstats __percpu *dstats; /* dummy stats */
+ struct pcpu_vstats __percpu *vstats; /* veth stats */
};
/* GARP */
struct garp_port __rcu *garp_port;
^ permalink raw reply related
* Re: [PATCHv2 net-next] bridge: respect RFC2863 operational state
From: Flavio Leitner @ 2012-12-30 2:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <20121228201522.62a48370@nehalam.linuxnetplumber.net>
On Fri, Dec 28, 2012 at 08:15:22PM -0800, Stephen Hemminger wrote:
> The bridge link detection should follow the operational state
> of the lower device, rather than the carrier bit. This allows devices
> like tunnels that are controlled by userspace control plane to work
> with bridge STP link management.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
Although I can't test this right now, it does look good to me.
Reviewed-by: Flavio Leitner <fbl@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next] team: add ethtool support
From: Flavio Leitner @ 2012-12-30 1:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Jiri Pirko
In-Reply-To: <20121229172945.25a09fc8@nehalam.linuxnetplumber.net>
On Sat, Dec 29, 2012 at 05:29:45PM -0800, Stephen Hemminger wrote:
> On Sat, 29 Dec 2012 23:19:26 -0200
> Flavio Leitner <fbl@redhat.com> wrote:
>
> > This patch adds few ethtool operations to team driver.
> >
> > Signed-off-by: Flavio Leitner <fbl@redhat.com>
>
> What is the motivation for this? Is there an application that depends
> on ethtool (versus netlink, or /proc)?
Speaking as a support engineer, it's a lot easier to grab ethtool -S and
see everything than grab two or more outputs.
> Sorry, I see no point in providing ethtool statistics for generic data that is already
> reported by existing netlink and other infrastructure. The purpose of ethtool
> statistics is to report device specific that is not available through the normal
> generic statistics.
Right, but those statistics can be device specific as well. The tg3 and bnx2, for
instance, do the same reporting [rx|tx]_bytes|octets.
I see no harm, and it is helpful.
--
fbl
^ permalink raw reply
* Re: [PATCH net-next] team: add ethtool support
From: David Miller @ 2012-12-30 1:35 UTC (permalink / raw)
To: shemminger; +Cc: fbl, netdev, jiri
In-Reply-To: <20121229172945.25a09fc8@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 29 Dec 2012 17:29:45 -0800
> On Sat, 29 Dec 2012 23:19:26 -0200
> Flavio Leitner <fbl@redhat.com> wrote:
>
>> This patch adds few ethtool operations to team driver.
>>
>> Signed-off-by: Flavio Leitner <fbl@redhat.com>
>
> What is the motivation for this? Is there an application that depends
> on ethtool (versus netlink, or /proc)?
>
> Sorry, I see no point in providing ethtool statistics for generic data that is already
> reported by existing netlink and other infrastructure. The purpose of ethtool
> statistics is to report device specific that is not available through the normal
> generic statistics.
Agreed, ethtool stats should _ONLY_ report device specific
statistics.
^ permalink raw reply
* [PATCH net-next] team: implement carrier change
From: Flavio Leitner @ 2012-12-30 1:31 UTC (permalink / raw)
To: netdev; +Cc: Jiri Pirko, Flavio Leitner
The user space teamd daemon may need to control the
master's carrier state depending on the selected mode.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
drivers/net/team/team.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index f711039..14cb843 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1708,6 +1708,15 @@ static netdev_features_t team_fix_features(struct net_device *dev,
return features;
}
+static int team_change_carrier(struct net_device *dev, bool new_carrier)
+{
+ if (new_carrier)
+ netif_carrier_on(dev);
+ else
+ netif_carrier_off(dev);
+ return 0;
+}
+
static const struct net_device_ops team_netdev_ops = {
.ndo_init = team_init,
.ndo_uninit = team_uninit,
@@ -1730,6 +1739,7 @@ static const struct net_device_ops team_netdev_ops = {
.ndo_add_slave = team_add_slave,
.ndo_del_slave = team_del_slave,
.ndo_fix_features = team_fix_features,
+ .ndo_change_carrier = team_change_carrier,
};
/***********************
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH net-next] team: add ethtool support
From: Stephen Hemminger @ 2012-12-30 1:29 UTC (permalink / raw)
To: Flavio Leitner; +Cc: netdev, Jiri Pirko
In-Reply-To: <1356830366-991-1-git-send-email-fbl@redhat.com>
On Sat, 29 Dec 2012 23:19:26 -0200
Flavio Leitner <fbl@redhat.com> wrote:
> This patch adds few ethtool operations to team driver.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
What is the motivation for this? Is there an application that depends
on ethtool (versus netlink, or /proc)?
Sorry, I see no point in providing ethtool statistics for generic data that is already
reported by existing netlink and other infrastructure. The purpose of ethtool
statistics is to report device specific that is not available through the normal
generic statistics.
^ permalink raw reply
* [PATCH net-next] team: add ethtool support
From: Flavio Leitner @ 2012-12-30 1:19 UTC (permalink / raw)
To: netdev; +Cc: Jiri Pirko, Flavio Leitner
This patch adds few ethtool operations to team driver.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
drivers/net/team/team.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index ad86660..f711039 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -28,6 +28,7 @@
#include <net/genetlink.h>
#include <net/netlink.h>
#include <net/sch_generic.h>
+#include <generated/utsrelease.h>
#include <linux/if_team.h>
#define DRV_NAME "team"
@@ -1731,6 +1732,75 @@ static const struct net_device_ops team_netdev_ops = {
.ndo_fix_features = team_fix_features,
};
+/***********************
+ * ethtool interface
+ ***********************/
+
+static const char ethtool_stats_keys[][ETH_GSTRING_LEN] = {
+ "rx_packets",
+ "rx_bytes",
+ "rx_dropped",
+ "tx_packets",
+ "tx_bytes",
+ "tx_dropped",
+ "multicast",
+};
+
+#define TEAM_NUM_STATS ARRAY_SIZE(ethtool_stats_keys)
+
+static int team_get_sset_count(struct net_device *netdev, int sset)
+{
+ switch (sset) {
+ case ETH_SS_STATS:
+ return TEAM_NUM_STATS;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static void team_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
+{
+ switch (stringset) {
+ case ETH_SS_STATS:
+ memcpy(data, *ethtool_stats_keys, sizeof(ethtool_stats_keys));
+ break;
+ }
+}
+
+static void team_get_ethtool_stats(struct net_device *netdev,
+ struct ethtool_stats *stats,
+ u64 *data)
+{
+ struct rtnl_link_stats64 net_stats;
+ int i;
+
+ memset(&net_stats, 0, sizeof(struct rtnl_link_stats64));
+ team_get_stats64(netdev, &net_stats);
+ i = 0;
+ /* ordering based on ethtool_stats_keys */
+ data[i++] = net_stats.rx_packets;
+ data[i++] = net_stats.rx_bytes;
+ data[i++] = net_stats.rx_dropped;
+ data[i++] = net_stats.tx_packets;
+ data[i++] = net_stats.tx_bytes;
+ data[i++] = net_stats.tx_dropped;
+ data[i++] = net_stats.multicast;
+}
+
+static void team_ethtool_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *drvinfo)
+{
+ strncpy(drvinfo->driver, DRV_NAME, 32);
+ strncpy(drvinfo->version, UTS_RELEASE, 32);
+}
+
+static const struct ethtool_ops team_ethtool_ops = {
+ .get_drvinfo = team_ethtool_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+ .get_strings = team_get_strings,
+ .get_ethtool_stats = team_get_ethtool_stats,
+ .get_sset_count = team_get_sset_count,
+};
/***********************
* rt netlink interface
@@ -1780,6 +1850,7 @@ static void team_setup(struct net_device *dev)
ether_setup(dev);
dev->netdev_ops = &team_netdev_ops;
+ dev->ethtool_ops = &team_ethtool_ops;
dev->destructor = team_destructor;
dev->tx_queue_len = 0;
dev->flags |= IFF_MULTICAST;
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH v2 1/1 net-next] NET: FEC: dynamtic check DMA desc buff type
From: Frank Li @ 2012-12-30 1:01 UTC (permalink / raw)
To: Lothar Waßmann
Cc: Frank Li, netdev, s.hauer, shawn.guo, davem, linux-arm-kernel
In-Reply-To: <20701.45196.361432.80622@ipc1.ka-ro>
2012/12/28 Lothar Waßmann <LW@karo-electronics.de>:
> Frank Li writes:
>> MX6 and mx28 support enhanced DMA descript buff to support 1588
>> ptp. But MX25, MX3x, MX5x can't support enhanced DMA descript buff.
>> Check fec type and choose correct DAM descript buff type.
> ^^^
> s/DAM/DMA/
> s/descript/descriptor/g
>
> [...]
>> diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
>> index 0704bca..290f91c 100644
>> --- a/drivers/net/ethernet/freescale/fec.c
>> +++ b/drivers/net/ethernet/freescale/fec.c
>> @@ -76,6 +76,8 @@
>> #define FEC_QUIRK_USE_GASKET (1 << 2)
>> /* Controller has GBIT support */
>> #define FEC_QUIRK_HAS_GBIT (1 << 3)
>> +/* Controller has extend desc buffer */
>> +#define FEC_QUICK_HAS_BUFDESC_EX (1 << 4)
> ^^^^^
> As Sascha has already pointed out, this should be 'QUIRK' rather than
> 'QUICK' (like in the preceeding lines)!
>
>> static struct platform_device_id fec_devtype[] = {
>> {
>> @@ -93,7 +95,8 @@ static struct platform_device_id fec_devtype[] = {
>> .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
>> }, {
>> .name = "imx6q-fec",
>> - .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT,
>> + .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
>> + FEC_QUICK_HAS_BUFDESC_EX,
> ^^^^^
> same as above.
>
> [...]
>> @@ -1574,6 +1617,8 @@ fec_probe(struct platform_device *pdev)
>> fep->pdev = pdev;
>> fep->dev_id = dev_id++;
>>
>> + fep->bufdesc_ex = 0;
>> +
>> if (!fep->hwp) {
>> ret = -ENOMEM;
>> goto failed_ioremap;
>> @@ -1628,19 +1673,19 @@ fec_probe(struct platform_device *pdev)
>> goto failed_clk;
>> }
>>
>> -#ifdef CONFIG_FEC_PTP
>> fep->clk_ptp = devm_clk_get(&pdev->dev, "ptp");
>> + fep->bufdesc_ex =
>> + pdev->id_entry->driver_data & FEC_QUICK_HAS_BUFDESC_EX;
> ^^^^^
> same as above.
Okay, I will fix it after new year holiday.
>
>
> Lothar Waßmann
> --
> ___________________________________________________________
>
> Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> Geschäftsführer: Matthias Kaussen
> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>
> www.karo-electronics.de | info@karo-electronics.de
> ___________________________________________________________
^ permalink raw reply
* Re: [patch net-next 01/15] net: introduce upper device lists
From: David Miller @ 2012-12-29 23:31 UTC (permalink / raw)
To: jiri
Cc: netdev, edumazet, bhutchings, faisal.latif, shemminger, fbl,
roland, sean.hefty, hal.rosenstock, fubar, andy, divy,
jitendra.kalsaria, sony.chacko, linux-driver, kaber, ursula.braun,
blaschka, schwidefsky, heiko.carstens, ebiederm, joe, amwang,
nhorman, john.r.fastabend, pablo
In-Reply-To: <1356777522-19652-2-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sat, 29 Dec 2012 11:38:28 +0100
> + /*
> + * To prevent loops, check if dev is not upper device to upper_dev.
> + */
Please use:
/* To prevent loops, check if dev is not upper device to upper_dev. */
> +/**
> + * netdev_upper_free_rcu - Frees a upper device list item via the RCU pointer
> + * @entry: the entry's RCU field
> + *
> + * This function is designed to be used as a callback to the call_rcu()
> + * function so that the memory allocated to the netdev upper device list item
> + * can be released safely.
> + */
> +static void netdev_upper_free_rcu(struct rcu_head *entry)
> +{
> + struct netdev_upper *upper;
> +
> + upper = container_of(entry, struct netdev_upper, rcu);
> + kfree(upper);
> +}
Please use kfree_rcu().
Also, since __netdev_has_upper_dev() modifies &search_list inside
of the list traversal loop, I think you really need to use
list_for_each_entry_safe() even though you always append to the
tail of &search_list.
^ permalink raw reply
* Re: Slow speed of tcp connections in a network namespace
From: Andrew Vagin @ 2012-12-29 21:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <1356815546.21409.5277.camel@edumazet-glaptop>
On Sat, Dec 29, 2012 at 01:12:26PM -0800, Eric Dumazet wrote:
> On Sun, 2012-12-30 at 00:08 +0400, Andrew Vagin wrote:
>
> > Is it right, that a received window will be less, if packets are not sorted?
> > Looks like a bug.
>
> Not really a bug.
>
> TCP is very sensitive to packet reorders. I wont elaborate here as
> its a bit off topic.
>
> Try to reorders credits/debits on your bank account, I am pretty sure
> you'll lose some money or even get serious troubles.
>
> Of course, enabling GRO on eth0 would definitely help a bit...
>
> (once/iff veth driver features are fixed to allow GSO packets being
> forwarded without being segmented again)
>
Eric, thank you for the help.
I need time for thinking. I will ask you, if new questions will appear.
>
>
^ permalink raw reply
* Re: Slow speed of tcp connections in a network namespace
From: Andrew Vagin @ 2012-12-29 21:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <1356807516.4102.4.camel@edumazet-laptop>
On Sat, Dec 29, 2012 at 07:58:36PM +0100, Eric Dumazet wrote:
> Le samedi 29 décembre 2012 à 09:40 -0800, Eric Dumazet a écrit :
>
> >
> > Please post your new tcpdump then ;)
> >
> > also post "netstat -s" from root and test ns after your wgets
>
> Also try following bnx2 patch.
>
> It should help GRO / TCP coalesce
>
> bnx2 should be the last driver not using skb head_frag
>
This patch breaks nothing. I don't know what kind of profit I should get
with it:).
FYI:
I forgot to say, that I disable gro before collecting tcpdump, because
in this case tcpdump from veth and from eth0 can be compared easier.
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
> index a1adfaf..08a2d40 100644
> --- a/drivers/net/ethernet/broadcom/bnx2.c
> +++ b/drivers/net/ethernet/broadcom/bnx2.c
> @@ -2726,6 +2726,14 @@ bnx2_free_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
> rx_pg->page = NULL;
> }
>
> +static void bnx2_frag_free(const struct bnx2 *bp, void *data)
> +{
> + if (bp->rx_frag_size)
> + put_page(virt_to_head_page(data));
> + else
> + kfree(data);
> +}
> +
> static inline int
> bnx2_alloc_rx_data(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gfp_t gfp)
> {
> @@ -2735,7 +2743,10 @@ bnx2_alloc_rx_data(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gf
> struct bnx2_rx_bd *rxbd =
> &rxr->rx_desc_ring[BNX2_RX_RING(index)][BNX2_RX_IDX(index)];
>
> - data = kmalloc(bp->rx_buf_size, gfp);
> + if (bp->rx_frag_size)
> + data = netdev_alloc_frag(bp->rx_frag_size);
> + else
> + data = kmalloc(bp->rx_buf_size, gfp);
> if (!data)
> return -ENOMEM;
>
> @@ -2744,7 +2755,7 @@ bnx2_alloc_rx_data(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gf
> bp->rx_buf_use_size,
> PCI_DMA_FROMDEVICE);
> if (dma_mapping_error(&bp->pdev->dev, mapping)) {
> - kfree(data);
> + bnx2_frag_free(bp, data);
> return -EIO;
> }
>
> @@ -3014,9 +3025,9 @@ error:
>
> dma_unmap_single(&bp->pdev->dev, dma_addr, bp->rx_buf_use_size,
> PCI_DMA_FROMDEVICE);
> - skb = build_skb(data, 0);
> + skb = build_skb(data, bp->rx_frag_size);
> if (!skb) {
> - kfree(data);
> + bnx2_frag_free(bp, data);
> goto error;
> }
> skb_reserve(skb, ((u8 *)get_l2_fhdr(data) - data) + BNX2_RX_OFFSET);
> @@ -5358,6 +5369,10 @@ bnx2_set_rx_ring_size(struct bnx2 *bp, u32 size)
> /* hw alignment + build_skb() overhead*/
> bp->rx_buf_size = SKB_DATA_ALIGN(bp->rx_buf_use_size + BNX2_RX_ALIGN) +
> NET_SKB_PAD + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> + if (bp->rx_buf_size <= PAGE_SIZE)
> + bp->rx_frag_size = bp->rx_buf_size;
> + else
> + bp->rx_frag_size = 0;
> bp->rx_jumbo_thresh = rx_size - BNX2_RX_OFFSET;
> bp->rx_ring_size = size;
> bp->rx_max_ring = bnx2_find_max_ring(size, BNX2_MAX_RX_RINGS);
> @@ -5436,7 +5451,7 @@ bnx2_free_rx_skbs(struct bnx2 *bp)
>
> rx_buf->data = NULL;
>
> - kfree(data);
> + bnx2_frag_free(bp, data);
> }
> for (j = 0; j < bp->rx_max_pg_ring_idx; j++)
> bnx2_free_rx_page(bp, rxr, j);
> diff --git a/drivers/net/ethernet/broadcom/bnx2.h b/drivers/net/ethernet/broadcom/bnx2.h
> index 172efbe..11f5dee 100644
> --- a/drivers/net/ethernet/broadcom/bnx2.h
> +++ b/drivers/net/ethernet/broadcom/bnx2.h
> @@ -6804,6 +6804,7 @@ struct bnx2 {
>
> u32 rx_buf_use_size; /* useable size */
> u32 rx_buf_size; /* with alignment */
> + u32 rx_frag_size; /* 0 if kmalloced(), or rx_buf_size */
> u32 rx_copy_thresh;
> u32 rx_jumbo_thresh;
> u32 rx_max_ring_idx;
>
>
^ permalink raw reply
* Re: Slow speed of tcp connections in a network namespace
From: Eric Dumazet @ 2012-12-29 21:12 UTC (permalink / raw)
To: Andrew Vagin; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <20121229200848.GA3389@paralelels.com>
On Sun, 2012-12-30 at 00:08 +0400, Andrew Vagin wrote:
> Is it right, that a received window will be less, if packets are not sorted?
> Looks like a bug.
Not really a bug.
TCP is very sensitive to packet reorders. I wont elaborate here as
its a bit off topic.
Try to reorders credits/debits on your bank account, I am pretty sure
you'll lose some money or even get serious troubles.
Of course, enabling GRO on eth0 would definitely help a bit...
(once/iff veth driver features are fixed to allow GSO packets being
forwarded without being segmented again)
^ permalink raw reply
* Re: Slow speed of tcp connections in a network namespace
From: Andrew Vagin @ 2012-12-29 21:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <1356812407.21409.5116.camel@edumazet-glaptop>
On Sat, Dec 29, 2012 at 12:20:07PM -0800, Eric Dumazet wrote:
> On Sun, 2012-12-30 at 00:08 +0400, Andrew Vagin wrote:
> > On Sat, Dec 29, 2012 at 11:41:02AM -0800, Eric Dumazet wrote:
> > > On Sat, 2012-12-29 at 19:58 +0100, Eric Dumazet wrote:
> > > > Le samedi 29 décembre 2012 à 09:40 -0800, Eric Dumazet a écrit :
> > > >
> > > > >
> > > > > Please post your new tcpdump then ;)
> > > > >
> > > > > also post "netstat -s" from root and test ns after your wgets
> > > >
> > > > Also try following bnx2 patch.
> > > >
> > > > It should help GRO / TCP coalesce
> > > >
> > > > bnx2 should be the last driver not using skb head_frag
> >
> > I don't have access to the host. I'm going to test your patch tomorrow.
> > Thanks.
> >
> > >
> > > And of course, you should make sure all your bnx2 interrupts are handled
> > > by the same cpu.
> > All bnx interrupts are handled on all cpus. They are handled on the same
> > cpu, if a kernel is booted with msi_disable=1.
> >
> > Is it right, that a received window will be less, if packets are not sorted?
> > Looks like a bug.
> >
> > I want to say, that probably it works correctly, if packets are sorted.
> > But I think if packets are not sorted, it should work with the same
> > speed, cpu load and memory consumption may be a bit more.
>
> Without veth, it doesnt really matter that IRQ are spread on multiple
> cpus, because packets are handled in NAPI, and only one cpu runs the
> eth0 NAPI handler at one time.
>
> But as soon as packets are queued (by netif_rx()) for 'later'
> processing, you can have dramatic performance decrease.
>
> Thats why you really should make sure IRQ on your eth0 device
> are handled by a single cpu.
>
> It will help to get better performance in most cases.
I understand this fact, but so big difference looks strange for me.
Default configuration (with the bug):
# cat /proc/interrupts | grep eth0
68: 10187 10188 10187 10023 10190 10185
10187 10019 PCI-MSI-edge eth0
>
> echo 1 >/proc/irq/*/eth0/../smp_affinity
This doesn't help.
I tryed echo 0 > /proc/irq/68/smp_affinity_list. This doesn't help too.
>
> If it doesnt work, you might try instead :
>
> echo 1 >/proc/irq/default_smp_affinity
> <you might need to reload bnx2 module, or ifdown/ifup eth0 >
This helps, and the bug are not reproduced in this case.
# cat /proc/interrupts | grep eth0
68: 60777 0 0 0 0 0
0 0 PCI-MSI-edge eth0
Thanks.
^ permalink raw reply
* Re: Slow speed of tcp connections in a network namespace
From: Eric Dumazet @ 2012-12-29 20:20 UTC (permalink / raw)
To: Andrew Vagin; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <20121229200848.GA3389@paralelels.com>
On Sun, 2012-12-30 at 00:08 +0400, Andrew Vagin wrote:
> On Sat, Dec 29, 2012 at 11:41:02AM -0800, Eric Dumazet wrote:
> > On Sat, 2012-12-29 at 19:58 +0100, Eric Dumazet wrote:
> > > Le samedi 29 décembre 2012 à 09:40 -0800, Eric Dumazet a écrit :
> > >
> > > >
> > > > Please post your new tcpdump then ;)
> > > >
> > > > also post "netstat -s" from root and test ns after your wgets
> > >
> > > Also try following bnx2 patch.
> > >
> > > It should help GRO / TCP coalesce
> > >
> > > bnx2 should be the last driver not using skb head_frag
>
> I don't have access to the host. I'm going to test your patch tomorrow.
> Thanks.
>
> >
> > And of course, you should make sure all your bnx2 interrupts are handled
> > by the same cpu.
> All bnx interrupts are handled on all cpus. They are handled on the same
> cpu, if a kernel is booted with msi_disable=1.
>
> Is it right, that a received window will be less, if packets are not sorted?
> Looks like a bug.
>
> I want to say, that probably it works correctly, if packets are sorted.
> But I think if packets are not sorted, it should work with the same
> speed, cpu load and memory consumption may be a bit more.
Without veth, it doesnt really matter that IRQ are spread on multiple
cpus, because packets are handled in NAPI, and only one cpu runs the
eth0 NAPI handler at one time.
But as soon as packets are queued (by netif_rx()) for 'later'
processing, you can have dramatic performance decrease.
Thats why you really should make sure IRQ on your eth0 device
are handled by a single cpu.
It will help to get better performance in most cases.
echo 1 >/proc/irq/*/eth0/../smp_affinity
If it doesnt work, you might try instead :
echo 1 >/proc/irq/default_smp_affinity
<you might need to reload bnx2 module, or ifdown/ifup eth0 >
^ permalink raw reply
* Re: Slow speed of tcp connections in a network namespace
From: Andrew Vagin @ 2012-12-29 20:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <1356810062.21409.4991.camel@edumazet-glaptop>
On Sat, Dec 29, 2012 at 11:41:02AM -0800, Eric Dumazet wrote:
> On Sat, 2012-12-29 at 19:58 +0100, Eric Dumazet wrote:
> > Le samedi 29 décembre 2012 à 09:40 -0800, Eric Dumazet a écrit :
> >
> > >
> > > Please post your new tcpdump then ;)
> > >
> > > also post "netstat -s" from root and test ns after your wgets
> >
> > Also try following bnx2 patch.
> >
> > It should help GRO / TCP coalesce
> >
> > bnx2 should be the last driver not using skb head_frag
I don't have access to the host. I'm going to test your patch tomorrow.
Thanks.
>
> And of course, you should make sure all your bnx2 interrupts are handled
> by the same cpu.
All bnx interrupts are handled on all cpus. They are handled on the same
cpu, if a kernel is booted with msi_disable=1.
Is it right, that a received window will be less, if packets are not sorted?
Looks like a bug.
I want to say, that probably it works correctly, if packets are sorted.
But I think if packets are not sorted, it should work with the same
speed, cpu load and memory consumption may be a bit more.
>
> Or else, packets might be reordered because the way dev_forward_skb()
> works.
>
> (CPU X gets a bunch of packets from eth0, forward them via netif_rx() in
> the local CPU X queue, NAPI is ended on eth0)
>
> CPU Y gets a bunch of packets from eth0, forward them via netif_rx() in
> the local CPU Y queue.
>
> CPU X and Y process their local queue in // -> packets are delivered Out
> of order to TCP stack
>
> Alternative is to setup RPS on your veth1 device, to force packets being
> delivered/handled by a given cpu
>
>
>
>
>
^ permalink raw reply
* Re: Is keepalive behaving as expected in 3.7.0+/net-next?
From: Jamie Gloudon @ 2012-12-29 19:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: rick.jones2, netdev
In-Reply-To: <1356645265.30414.1542.camel@edumazet-glaptop>
On Thu, Dec 27, 2012 at 01:54:25PM -0800, Eric Dumazet wrote:
> On Fri, 2012-12-21 at 14:05 -0800, Rick Jones wrote:
> > I was looking to do a bit more documentation clean-up and thought I
> > would work on the descriptions of the "keepalive" sysctls, but first I
> > wanted to see if they behaved as the existing descriptions suggested:
> >
> > > tcp_keepalive_time - INTEGER
> > > How often TCP sends out keepalive messages when keepalive is enabled.
> > > Default: 2hours.
> > >
> > > tcp_keepalive_probes - INTEGER
> > > How many keepalive probes TCP sends out, until it decides that the
> > > connection is broken. Default value: 9.
> > >
> > > tcp_keepalive_intvl - INTEGER
> > > How frequently the probes are send out. Multiplied by
> > > tcp_keepalive_probes it is time to kill not responding connection,
> > > after probes started. Default value: 75sec i.e. connection
> > > will be aborted after ~11 minutes of retries.
> >
> > I interpreted all that that as: When a connection is idle, TCP will
> > send a keepalive probe every tcp_keepalive_time seconds. If a response
> > to a keepalive probe is not received, TCP will resend (retransmit) it
> > every tcp_keepalive_intvl seconds.
> >
> > However, what I see is that on a connection where the remote is indeed
> > still there, only the first keepalive probe is sent after
> > tcp_keepalive_time, and thereafter it is sent every tcp_keepalive_intvl
> > seconds.
> >
> > Now, some of this may relate to my being impatient - rather than wait
> > two hours for the first probe, I set tcp_keepalive_time to 3 seconds,
> > and tcp_keepalive_intvl to 7 seconds. I then kicked-off a ./configure
> > --intervals-enable netperf TCP_RR test with a burst of one and a wait
> > time of 90 seconds and got the following (trimmed) trace:
> >
> > 13:43:46.879133 IP netnextraj.43054 > netnextraj2.srvr: Flags [S], seq
> > 807869796, win 14600, options [mss 1460,sackOK,TS val 133470 ecr
> > 0,nop,wscale 7], length 0
> > 13:43:46.880091 IP netnextraj2.srvr > netnextraj.43054: Flags [S.], seq
> > 1522345902, ack 807869797, win 14480, options [mss 1460,sackOK,TS val
> > 136186 ecr 133470,nop,wscale 4], length 0
> > 13:43:46.880114 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 1, win 115, options [nop,nop,TS val 133470 ecr 136186], length 0
> > 13:43:46.880306 IP netnextraj.43054 > netnextraj2.srvr: Flags [P.], seq
> > 1:11, ack 1, win 115, options [nop,nop,TS val 133470 ecr 136186], length 10
> > 13:43:46.880948 IP netnextraj2.srvr > netnextraj.43054: Flags [.], ack
> > 11, win 905, options [nop,nop,TS val 136187 ecr 133470], length 0
> > 13:43:46.880964 IP netnextraj2.srvr > netnextraj.43054: Flags [P.], seq
> > 1:11, ack 11, win 905, options [nop,nop,TS val 136187 ecr 133470], length 10
> > 13:43:46.881161 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 11, win 115, options [nop,nop,TS val 133470 ecr 136187], length 0
> >
> > The first probe above comes after 3 seconds - tcp_keepalive_time - at
> > 13:43:49
> >
> > 13:43:49.886752 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 11, win 115, options [nop,nop,TS val 134222 ecr 136187], length 0
> >
> > And it does seem to elicit a response:
> >
> > 13:43:49.887530 IP netnextraj2.srvr > netnextraj.43054: Flags [.], ack
> > 11, win 905, options [nop,nop,TS val 136938 ecr 133470], length 0
> >
>
>
> > Now it starts sending probes every 7 seconds (tcp_keepalive_intvl):
> >
> > 13:43:56.903576 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 11, win 115, options [nop,nop,TS val 135976 ecr 136938], length 0
> > 13:43:56.904480 IP netnextraj2.srvr > netnextraj.43054: Flags [.], ack
> > 11, win 905, options [nop,nop,TS val 138693 ecr 133470], length 0
> > 13:44:03.910744 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 11, win 115, options [nop,nop,TS val 137728 ecr 138693], length 0
> > 13:44:03.911623 IP netnextraj2.srvr > netnextraj.43054: Flags [.], ack
> > 11, win 905, options [nop,nop,TS val 140444 ecr 133470], length 0
> >
> > I;ve deleted the next 9 or so probes... It continues, and doesn't
> > terminate the connection, so I assume it was happy with the responses to
> > the probes.
> >
> > 13:45:13.990746 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 11, win 115, options [nop,nop,TS val 155248 ecr 156213], length 0
> > 13:45:13.991578 IP netnextraj2.srvr > netnextraj.43054: Flags [.], ack
> > 11, win 905, options [nop,nop,TS val 157965 ecr 133470], length 0
> >
> > Now the next netperf transaction happens:
> >
> > 13:45:16.879222 IP netnextraj.43054 > netnextraj2.srvr: Flags [P.], seq
> > 11:21, ack 11, win 115, options [nop,nop,TS val 155970 ecr 157965],
> > length 10
> > 13:45:16.880033 IP netnextraj2.srvr > netnextraj.43054: Flags [P.], seq
> > 11:21, ack 21, win 905, options [nop,nop,TS val 158687 ecr 155970],
> > length 10
> > 13:45:16.880220 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 21, win 115, options [nop,nop,TS val 155970 ecr 158687], length 0
> >
> > But the next keepalive probe is tcp_keepalive_intvl seconds after the
> > last one, rather than that many, or tcp_keepalive_time seconds after the
> > connection was last "active."
> >
> > 13:45:20.998739 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 21, win 115, options [nop,nop,TS val 157000 ecr 158687], length 0
> > 13:45:20.999754 IP netnextraj2.srvr > netnextraj.43054: Flags [.], ack
> > 21, win 905, options [nop,nop,TS val 159717 ecr 155970], length 0
> > 13:45:28.006747 IP netnextraj.43054 > netnextraj2.srvr: Flags [.], ack
> > 21, win 115, options [nop,nop,TS val 158752 ecr 159717], length 0
> > 13:45:28.007624 IP netnextraj2.srvr > netnextraj.43054: Flags [.], ack
> > 21, win 905, options [nop,nop,TS val 161469 ecr 155970], length 0
> >
> > Is this the expected behaviour? If I reverse the values - make
> > tcp_keepalive_time 7 and tcp_keepalive_intvl 3, it seems that all the
> > probes are after 7 seconds.
> >
> > rick jones
>
> Not sure if it makes sense to have
> tcp_keepalive_intvl > tcp_keepalive_time
>
> time should be an order of magnitude bigger than intvl.
>
> keepalive timer is not reset each time we receive a valid frame, it
> would be very expensive.
>
> Its a long period timer.
>
> First interval is tcp_keepalive_time, and subsequent interval are
> tcp_keepalive_intvl
>
> Each time timer is fired (once every 7200 seconds), we re-arm it with
> the observed elapsed time (keepalive_time_elapsed)
>
> Fixing this would require to add a timestamp in inet socket, to remember
> time of next/last probe, and firing the timer using
> min(keepalive_time_when(tp), keepalive_intvl_when(tp))
>
> Probably not worth it.
>
>
Make a lot of sense. However, I got the impression from Rick that having tcp_keepalive_intvl > tcp_keepalive_time behaved correctly in older versions of the kernel.
Regards,
Jamie Gloudon
^ permalink raw reply
* Re: Slow speed of tcp connections in a network namespace
From: Eric Dumazet @ 2012-12-29 19:41 UTC (permalink / raw)
To: Andrew Vagin; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <1356807516.4102.4.camel@edumazet-laptop>
On Sat, 2012-12-29 at 19:58 +0100, Eric Dumazet wrote:
> Le samedi 29 décembre 2012 à 09:40 -0800, Eric Dumazet a écrit :
>
> >
> > Please post your new tcpdump then ;)
> >
> > also post "netstat -s" from root and test ns after your wgets
>
> Also try following bnx2 patch.
>
> It should help GRO / TCP coalesce
>
> bnx2 should be the last driver not using skb head_frag
And of course, you should make sure all your bnx2 interrupts are handled
by the same cpu.
Or else, packets might be reordered because the way dev_forward_skb()
works.
(CPU X gets a bunch of packets from eth0, forward them via netif_rx() in
the local CPU X queue, NAPI is ended on eth0)
CPU Y gets a bunch of packets from eth0, forward them via netif_rx() in
the local CPU Y queue.
CPU X and Y process their local queue in // -> packets are delivered Out
of order to TCP stack
Alternative is to setup RPS on your veth1 device, to force packets being
delivered/handled by a given cpu
^ permalink raw reply
* Re: Slow speed of tcp connections in a network namespace
From: Eric Dumazet @ 2012-12-29 18:58 UTC (permalink / raw)
To: Andrew Vagin; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <1356802828.21409.4623.camel@edumazet-glaptop>
Le samedi 29 décembre 2012 à 09:40 -0800, Eric Dumazet a écrit :
>
> Please post your new tcpdump then ;)
>
> also post "netstat -s" from root and test ns after your wgets
Also try following bnx2 patch.
It should help GRO / TCP coalesce
bnx2 should be the last driver not using skb head_frag
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index a1adfaf..08a2d40 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -2726,6 +2726,14 @@ bnx2_free_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
rx_pg->page = NULL;
}
+static void bnx2_frag_free(const struct bnx2 *bp, void *data)
+{
+ if (bp->rx_frag_size)
+ put_page(virt_to_head_page(data));
+ else
+ kfree(data);
+}
+
static inline int
bnx2_alloc_rx_data(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gfp_t gfp)
{
@@ -2735,7 +2743,10 @@ bnx2_alloc_rx_data(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gf
struct bnx2_rx_bd *rxbd =
&rxr->rx_desc_ring[BNX2_RX_RING(index)][BNX2_RX_IDX(index)];
- data = kmalloc(bp->rx_buf_size, gfp);
+ if (bp->rx_frag_size)
+ data = netdev_alloc_frag(bp->rx_frag_size);
+ else
+ data = kmalloc(bp->rx_buf_size, gfp);
if (!data)
return -ENOMEM;
@@ -2744,7 +2755,7 @@ bnx2_alloc_rx_data(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gf
bp->rx_buf_use_size,
PCI_DMA_FROMDEVICE);
if (dma_mapping_error(&bp->pdev->dev, mapping)) {
- kfree(data);
+ bnx2_frag_free(bp, data);
return -EIO;
}
@@ -3014,9 +3025,9 @@ error:
dma_unmap_single(&bp->pdev->dev, dma_addr, bp->rx_buf_use_size,
PCI_DMA_FROMDEVICE);
- skb = build_skb(data, 0);
+ skb = build_skb(data, bp->rx_frag_size);
if (!skb) {
- kfree(data);
+ bnx2_frag_free(bp, data);
goto error;
}
skb_reserve(skb, ((u8 *)get_l2_fhdr(data) - data) + BNX2_RX_OFFSET);
@@ -5358,6 +5369,10 @@ bnx2_set_rx_ring_size(struct bnx2 *bp, u32 size)
/* hw alignment + build_skb() overhead*/
bp->rx_buf_size = SKB_DATA_ALIGN(bp->rx_buf_use_size + BNX2_RX_ALIGN) +
NET_SKB_PAD + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+ if (bp->rx_buf_size <= PAGE_SIZE)
+ bp->rx_frag_size = bp->rx_buf_size;
+ else
+ bp->rx_frag_size = 0;
bp->rx_jumbo_thresh = rx_size - BNX2_RX_OFFSET;
bp->rx_ring_size = size;
bp->rx_max_ring = bnx2_find_max_ring(size, BNX2_MAX_RX_RINGS);
@@ -5436,7 +5451,7 @@ bnx2_free_rx_skbs(struct bnx2 *bp)
rx_buf->data = NULL;
- kfree(data);
+ bnx2_frag_free(bp, data);
}
for (j = 0; j < bp->rx_max_pg_ring_idx; j++)
bnx2_free_rx_page(bp, rxr, j);
diff --git a/drivers/net/ethernet/broadcom/bnx2.h b/drivers/net/ethernet/broadcom/bnx2.h
index 172efbe..11f5dee 100644
--- a/drivers/net/ethernet/broadcom/bnx2.h
+++ b/drivers/net/ethernet/broadcom/bnx2.h
@@ -6804,6 +6804,7 @@ struct bnx2 {
u32 rx_buf_use_size; /* useable size */
u32 rx_buf_size; /* with alignment */
+ u32 rx_frag_size; /* 0 if kmalloced(), or rx_buf_size */
u32 rx_copy_thresh;
u32 rx_jumbo_thresh;
u32 rx_max_ring_idx;
^ permalink raw reply related
* Re: Slow speed of tcp connections in a network namespace
From: Andrew Vagin @ 2012-12-29 18:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, vvs, Michał Mirosław
In-Reply-To: <1356802828.21409.4623.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]
On Sat, Dec 29, 2012 at 09:40:28AM -0800, Eric Dumazet wrote:
> On Sat, 2012-12-29 at 18:50 +0400, Andrew Vagin wrote:
> > On Sat, Dec 29, 2012 at 05:53:23AM -0800, Eric Dumazet wrote:
> > > > 3.8-rc1 is used for experiments.
> > > >
> > > > Do you have any ideas where is a problem?
> > >
> > > veth has absolutely no offload features
> > >
> > > It needs some care...
> > >
> > > At the very miminum, let TCP coalesce do its job by allowing SG
> > >
> > > CC Michał Mirosław <mirq-linux@rere.qmqm.pl> for insights.
> > >
> > > Please try following patch :
> >
> > Hello Eric,
> >
> > Thanks for your feedback.
> >
> > With this patch the results is a bit better (~4MB/s), but it's much less
> > than in the root netns.
>
> Please post your new tcpdump then ;)
I have rebooted the host and a speed in a netns is again about 1.7MB/s. I
don't know why it was 4MB/s in the previous time.
new tcpdump and netstat are attached
>
> also post "netstat -s" from root and test ns after your wgets
>
>
>
[-- Attachment #2: tcpdump.host.gz --]
[-- Type: application/x-gzip, Size: 165716 bytes --]
[-- Attachment #3: tcpdump.netns.host.gz --]
[-- Type: application/x-gzip, Size: 180703 bytes --]
[-- Attachment #4: tcpdump.netns.veth.gz --]
[-- Type: application/x-gzip, Size: 181615 bytes --]
[-- Attachment #5: netstat.host --]
[-- Type: text/plain, Size: 1821 bytes --]
Ip:
277536 total packets received
20 forwarded
0 incoming packets discarded
202326 incoming packets delivered
108228 requests sent out
30 dropped because of missing route
Icmp:
10 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 5
echo requests: 5
6 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 1
echo replies: 5
IcmpMsg:
InType3: 5
InType8: 5
OutType0: 5
OutType3: 1
Tcp:
1491 active connections openings
12 passive connection openings
14 failed connection attempts
72 connection resets received
2 connections established
201920 segments received
107815 segments send out
0 segments retransmited
0 bad segments received.
1338 resets sent
Udp:
387 packets received
0 packets to unknown port received.
0 packet receive errors
389 packets sent
UdpLite:
TcpExt:
3 invalid SYN cookies received
4 TCP sockets finished time wait in fast timer
63 delayed acks sent
9 delayed acks further delayed because of locked socket
236 packets directly queued to recvmsg prequeue.
38600456 packets directly received from backlog
298101 packets directly received from prequeue
163501 packets header predicted
27103 packets header predicted and directly queued to user
2578 acknowledgments not containing data received
1018 predicted acknowledgments
15 connections reset due to unexpected data
72 connections reset due to early user close
TCPRcvCoalesce: 123
TCPOFOQueue: 1187
IpExt:
InBcastPkts: 9
OutBcastPkts: 1
InOctets: 296395504
OutOctets: 6965311
InBcastOctets: 2789
OutBcastOctets: 165
[-- Attachment #6: netstat.netns --]
[-- Type: text/plain, Size: 1463 bytes --]
Ip:
25483 total packets received
0 forwarded
0 incoming packets discarded
25483 incoming packets delivered
14572 requests sent out
Icmp:
4 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
echo requests: 2
echo replies: 2
4 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
echo request: 2
echo replies: 2
IcmpMsg:
InType0: 2
InType8: 2
OutType0: 2
OutType8: 2
Tcp:
1 active connections openings
0 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
25473 segments received
14562 segments send out
0 segments retransmited
0 bad segments received.
77 resets sent
Udp:
6 packets received
0 packets to unknown port received.
0 packet receive errors
6 packets sent
UdpLite:
TcpExt:
38 delayed acks sent
Quick ack mode was activated 2 times
52 packets directly queued to recvmsg prequeue.
4916752 packets directly received from backlog
11584 packets directly received from prequeue
12538 packets header predicted
2649 packets header predicted and directly queued to user
1 acknowledgments not containing data received
2 DSACKs sent for old packets
1 connections reset due to unexpected data
TCPOFOQueue: 1580
IpExt:
InOctets: 38201843
OutOctets: 829966
^ 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