* Re: [PATCH 3/4] ps3_gelic: lower NAPI weight
From: Sergei Shtylyov @ 2013-08-21 18:17 UTC (permalink / raw)
To: Michal Schmidt; +Cc: David Miller, netdev, Eric Dumazet, Geoff Levand
In-Reply-To: <1377103771-1590-4-git-send-email-mschmidt@redhat.com>
On 08/21/2013 08:49 PM, Michal Schmidt wrote:
> Since commit 82dc3c63 netif_napi_add() produces an error message if
Likewise, need a summary line.
> a NAPI poll weight greater than 64 is requested.
> GELIC_NET_NAPI_WEIGHT is defined to GELIC_NET_RX_DESCRIPTORS,
> which is 128.
> Use the standard NAPI weight.
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> CC: Geoff Levand <geoff@infradead.org>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/4] netxen: lower NAPI weight
From: Sergei Shtylyov @ 2013-08-21 18:16 UTC (permalink / raw)
To: Michal Schmidt
Cc: David Miller, netdev, Eric Dumazet, Manish Chopra, Sony Chacko,
Rajesh Borundia
In-Reply-To: <1377103771-1590-3-git-send-email-mschmidt@redhat.com>
On 08/21/2013 08:49 PM, Michal Schmidt wrote:
> Since commit 82dc3c63 netif_napi_add() produces an error message if
Likewise, need summary line in parens.
> a NAPI poll weight greater than 64 is requested.
> Use the standard NAPI weight.
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> CC: Manish Chopra <manish.chopra@qlogic.com>
> CC: Sony Chacko <sony.chacko@qlogic.com>
> CC: Rajesh Borundia <rajesh.borundia@qlogic.com>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/4] jme: lower NAPI weight
From: Sergei Shtylyov @ 2013-08-21 18:15 UTC (permalink / raw)
To: Michal Schmidt; +Cc: David Miller, netdev, Eric Dumazet, Guo-Fu Tseng
In-Reply-To: <1377103771-1590-2-git-send-email-mschmidt@redhat.com>
Hello.
On 08/21/2013 08:49 PM, Michal Schmidt wrote:
> Since commit 82dc3c63 netif_napi_add() produces an error message if
Please also specify that commit's summary line in parens.
> a NAPI poll weight greater than 64 is requested.
> jme requests a quarter of the rx ring size as the NAPI weight.
> jme's rx ring size is 1 << 9 = 512.
> Use the standard NAPI weight.
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> CC: Guo-Fu Tseng <cooldavid@cooldavid.org>
WBR, Sergei
^ permalink raw reply
* Re: linux-next: build warning after merge of the net-next tree
From: David Miller @ 2013-08-21 18:15 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, dingtianhong
In-Reply-To: <20130821191041.712893827d8000c6dca8781b@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 21 Aug 2013 19:10:41 +1000
> Hi all,
>
> After merging the net-next tree, today's linux-next build (i386 defconfig
> and probably others) produced this warning:
>
> net/ipv6/addrconf.c: In function 'addrconf_notify':
> net/ipv6/addrconf.c:2793:22: warning: 'link_dev' may be used uninitialized in this function [-Wuninitialized]
> net/ipv6/addrconf.c:2802:21: note: 'link_dev' was declared here
>
> Introduced by commit df8372ca747f ("ipv6: fix checkpatch errors in
> net/ipv6/addrconf.c"). It looks like here are some missing braces.
Yes, which has since been reverted.
^ permalink raw reply
* Re: Performance regression 3.11 with macvlan between 2 linux guests (bisected)
From: Vlad Yasevich @ 2013-08-21 18:12 UTC (permalink / raw)
To: Christian Borntraeger
Cc: David S. Miller, netdev, Michael S. Tsirkin, Matthew Rosato,
Jason Wang
In-Reply-To: <52150145.7020801@redhat.com>
On 08/21/2013 02:04 PM, Vlad Yasevich wrote:
> On 08/21/2013 08:38 AM, Christian Borntraeger wrote:
>> Vlad,
>>
>> the patch
>>
>> commit 3e4f8b787370978733ca6cae452720a4f0c296b8
>> Author: Vlad Yasevich <vyasevic@redhat.com>
>> Date: Tue Jun 25 16:04:22 2013 -0400
>>
>> macvtap: Perform GSO on forwarding path.
>>
>> causes a severe performance regression for 2 Linux guests with virtio-net
>> connected via macvlan/vtap doing iperf workload. (2GBit vs. 20Gbit)
>>
>> If I understand the patch correctly, we now check for gso depending on
>> the
>> macvlan features. If the underlying hardware does not support the
>> necessary
>> offloads then we will do segmentation, even if we keep the whole
>> traffic internal
>> between two guests and even if both guests supports LRO,GSO etc.
>> ---snip---
>> [...]
>> + features = netif_skb_features(skb) & vlan->tap_features;
>> + if (netif_needs_gso(skb, features)) {
>> + struct sk_buff *segs = __skb_gso_segment(skb,
>> features, false);
>> [...]
>>
>> ---snip---
>> Shouldnt we take the features of the target device or even better do
>> the gsoing in the
>> target device driver?
>
> A corrected patch has been sent upstream. We take into consideration
> the features on the target device that the user/vm has specified.
> If the VM has enabled the TSO flags, then nothing will happen to the
> GSO packet. However, if the TSO flag is off, segmentation will be
> performed.
Particularly. This commit should fix the issue:
commit a567dd6252263c8147b7269df5d03d9e31463e11
macvtap: simplify usage of tap_features
-vlad
>
> -vlad
>
>>
>> Christian
>>
>> FYI, the underlying HW has:
>>
>> Features for eth0:
>> rx-checksumming: off [fixed]
>> tx-checksumming: off
>> tx-checksum-ipv4: off [fixed]
>> tx-checksum-ip-generic: off [fixed]
>> tx-checksum-ipv6: off [fixed]
>> tx-checksum-fcoe-crc: off [fixed]
>> tx-checksum-sctp: off [fixed]
>> scatter-gather: off
>> tx-scatter-gather: off [fixed]
>> tx-scatter-gather-fraglist: off [fixed]
>> tcp-segmentation-offload: off
>> tx-tcp-segmentation: off [fixed]
>> tx-tcp-ecn-segmentation: off [fixed]
>> tx-tcp6-segmentation: off [fixed]
>> udp-fragmentation-offload: off [fixed]
>> generic-segmentation-offload: off [requested on]
>> generic-receive-offload: on
>> large-receive-offload: off [fixed]
>> rx-vlan-offload: off [fixed]
>> tx-vlan-offload: off [fixed]
>> ntuple-filters: off [fixed]
>> receive-hashing: off [fixed]
>> highdma: off [fixed]
>> rx-vlan-filter: on [fixed]
>> vlan-challenged: off [fixed]
>> tx-lockless: off [fixed]
>> netns-local: off [fixed]
>> tx-gso-robust: off [fixed]
>> tx-fcoe-segmentation: off [fixed]
>> tx-gre-segmentation: off [fixed]
>> tx-udp_tnl-segmentation: off [fixed]
>> tx-mpls-segmentation: off [fixed]
>> fcoe-mtu: off [fixed]
>> tx-nocache-copy: off
>> loopback: off [fixed]
>> rx-fcs: off [fixed]
>> rx-all: off [fixed]
>> tx-vlan-stag-hw-insert: off [fixed]
>> rx-vlan-stag-hw-parse: off [fixed]
>> rx-vlan-stag-filter: off [fixed]
>>
>
^ permalink raw reply
* Re: Performance regression 3.11 with macvlan between 2 linux guests (bisected)
From: Vlad Yasevich @ 2013-08-21 18:04 UTC (permalink / raw)
To: Christian Borntraeger
Cc: David S. Miller, netdev, Michael S. Tsirkin, Matthew Rosato,
Jason Wang
In-Reply-To: <5214B4D4.7020806@de.ibm.com>
On 08/21/2013 08:38 AM, Christian Borntraeger wrote:
> Vlad,
>
> the patch
>
> commit 3e4f8b787370978733ca6cae452720a4f0c296b8
> Author: Vlad Yasevich <vyasevic@redhat.com>
> Date: Tue Jun 25 16:04:22 2013 -0400
>
> macvtap: Perform GSO on forwarding path.
>
> causes a severe performance regression for 2 Linux guests with virtio-net
> connected via macvlan/vtap doing iperf workload. (2GBit vs. 20Gbit)
>
> If I understand the patch correctly, we now check for gso depending on the
> macvlan features. If the underlying hardware does not support the necessary
> offloads then we will do segmentation, even if we keep the whole traffic internal
> between two guests and even if both guests supports LRO,GSO etc.
> ---snip---
> [...]
> + features = netif_skb_features(skb) & vlan->tap_features;
> + if (netif_needs_gso(skb, features)) {
> + struct sk_buff *segs = __skb_gso_segment(skb, features, false);
> [...]
>
> ---snip---
> Shouldnt we take the features of the target device or even better do the gsoing in the
> target device driver?
A corrected patch has been sent upstream. We take into consideration
the features on the target device that the user/vm has specified.
If the VM has enabled the TSO flags, then nothing will happen to the
GSO packet. However, if the TSO flag is off, segmentation will be
performed.
-vlad
>
> Christian
>
> FYI, the underlying HW has:
>
> Features for eth0:
> rx-checksumming: off [fixed]
> tx-checksumming: off
> tx-checksum-ipv4: off [fixed]
> tx-checksum-ip-generic: off [fixed]
> tx-checksum-ipv6: off [fixed]
> tx-checksum-fcoe-crc: off [fixed]
> tx-checksum-sctp: off [fixed]
> scatter-gather: off
> tx-scatter-gather: off [fixed]
> tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off [fixed]
> tx-tcp-ecn-segmentation: off [fixed]
> tx-tcp6-segmentation: off [fixed]
> udp-fragmentation-offload: off [fixed]
> generic-segmentation-offload: off [requested on]
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: off [fixed]
> tx-vlan-offload: off [fixed]
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: off [fixed]
> rx-vlan-filter: on [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: off [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: off [fixed]
> tx-gre-segmentation: off [fixed]
> tx-udp_tnl-segmentation: off [fixed]
> tx-mpls-segmentation: off [fixed]
> fcoe-mtu: off [fixed]
> tx-nocache-copy: off
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
>
^ permalink raw reply
* Re: [net-next 12/15] e1000e: cleanup whitespace in recent commit
From: Sergei Shtylyov @ 2013-08-21 18:04 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Bruce Allan, netdev, gospo, sassmann
In-Reply-To: <1377073416-7872-13-git-send-email-jeffrey.t.kirsher@intel.com>
On 08/21/2013 12:23 PM, Jeff Kirsher wrote:
> From: Bruce Allan <bruce.w.allan@intel.com>
> Commit c96ddb0b moved a define from one file to another but missed using
Please also specify that commit's summary line in parens.
> proper indentation/whitespace.
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
WBR, Sergei
^ permalink raw reply
* [PATCH RFC net-next] ipv6: avoid high order memory allocations for /proc/net/ipv6_route
From: Hannes Frederic Sowa @ 2013-08-21 17:50 UTC (permalink / raw)
To: netdev; +Cc: yoshfuji
I created this patch in a hurry while trying to get the rt6i_flags of
the routing entries on a system with lots of routes (I later cleaned it
up a bit).
The current approach for dumping routes over netlink is to redump a tree
as soon as the serialnumber on the nodes changes. Is this behavior more
preferable as to just ignore the routes for that moment? I am in favour
of not restarting the dump on /proc/net/ipv6_route.
-- >8 --
Dumping routes on a system with lots rt6_infos in the fibs causes up to
11-order allocations in seq_file (which fail). While we could switch
there to vmalloc we could just implement the streaming interface for
/proc/net/ipv6_route. This patch switches /proc/net/ipv6_route from
single_open_net to seq_open_net.
loff_t *pos tracks dst entries.
Also kill never used struct rt6_proc_arg and now unused function
fib6_clean_all_ro.
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/net/ip6_fib.h | 7 +-
net/ipv6/ip6_fib.c | 196 +++++++++++++++++++++++++++++++++++++++++++++-----
net/ipv6/route.c | 46 +-----------
3 files changed, 181 insertions(+), 68 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 48ec25a..9bd5de8 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -281,10 +281,6 @@ struct fib6_node *fib6_locate(struct fib6_node *root,
const struct in6_addr *daddr, int dst_len,
const struct in6_addr *saddr, int src_len);
-extern void fib6_clean_all_ro(struct net *net,
- int (*func)(struct rt6_info *, void *arg),
- int prune, void *arg);
-
extern void fib6_clean_all(struct net *net,
int (*func)(struct rt6_info *, void *arg),
int prune, void *arg);
@@ -306,6 +302,9 @@ extern void fib6_gc_cleanup(void);
extern int fib6_init(void);
+extern int ipv6_route_open(struct inode *inode,
+ struct file *file);
+
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
extern int fib6_rules_init(void);
extern void fib6_rules_cleanup(void);
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 73db48e..f2fd95e 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1529,25 +1529,6 @@ static void fib6_clean_tree(struct net *net, struct fib6_node *root,
fib6_walk(&c.w);
}
-void fib6_clean_all_ro(struct net *net, int (*func)(struct rt6_info *, void *arg),
- int prune, void *arg)
-{
- struct fib6_table *table;
- struct hlist_head *head;
- unsigned int h;
-
- rcu_read_lock();
- for (h = 0; h < FIB6_TABLE_HASHSZ; h++) {
- head = &net->ipv6.fib_table_hash[h];
- hlist_for_each_entry_rcu(table, head, tb6_hlist) {
- read_lock_bh(&table->tb6_lock);
- fib6_clean_tree(net, &table->tb6_root,
- func, prune, arg);
- read_unlock_bh(&table->tb6_lock);
- }
- }
- rcu_read_unlock();
-}
void fib6_clean_all(struct net *net, int (*func)(struct rt6_info *, void *arg),
int prune, void *arg)
{
@@ -1782,3 +1763,180 @@ void fib6_gc_cleanup(void)
unregister_pernet_subsys(&fib6_net_ops);
kmem_cache_destroy(fib6_node_kmem);
}
+
+#ifdef CONFIG_PROC_FS
+
+struct ipv6_route_iter {
+ struct seq_net_private p;
+ struct fib6_walker_t w;
+ loff_t skip;
+ struct fib6_table *tbl;
+};
+
+static int ipv6_route_seq_show(struct seq_file *seq, void *v)
+{
+ struct rt6_info *rt = v;
+ struct ipv6_route_iter *iter = seq->private;
+
+ seq_printf(seq, "%pi6 %02x ", &rt->rt6i_dst.addr, rt->rt6i_dst.plen);
+
+#ifdef CONFIG_IPV6_SUBTREES
+ seq_printf(seq, "%pi6 %02x ", &rt->rt6i_src.addr, rt->rt6i_src.plen);
+#else
+ seq_puts(seq, "00000000000000000000000000000000 00 ");
+#endif
+ if (rt->rt6i_flags & RTF_GATEWAY)
+ seq_printf(seq, "%pi6", &rt->rt6i_gateway);
+ else
+ seq_puts(seq, "00000000000000000000000000000000");
+
+ seq_printf(seq, " %08x %08x %08x %08x %8s\n",
+ rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
+ rt->dst.__use, rt->rt6i_flags,
+ rt->dst.dev ? rt->dst.dev->name : "");
+ iter->w.leaf = NULL;
+ return 0;
+}
+
+static int ipv6_route_yield(struct fib6_walker_t *w)
+{
+ struct ipv6_route_iter *iter = w->args;
+
+ if (!iter->skip)
+ return 1;
+
+ do {
+ iter->w.leaf = iter->w.leaf->dst.rt6_next;
+ iter->skip--;
+ if (!iter->skip && iter->w.leaf)
+ return 1;
+ } while (iter->w.leaf);
+
+ return 0;
+}
+
+static void ipv6_route_seq_setup_walk(struct ipv6_route_iter *iter)
+{
+ memset(&iter->w, 0, sizeof(iter->w));
+ iter->w.func = ipv6_route_yield;
+ iter->w.root = &iter->tbl->tb6_root;
+ iter->w.state = FWS_INIT;
+ iter->w.node = iter->w.root;
+ iter->w.args = iter;
+ INIT_LIST_HEAD(&iter->w.lh);
+}
+
+static struct fib6_table *ipv6_route_seq_next_table(struct fib6_table *tbl,
+ struct net *net)
+{
+ unsigned int h;
+ struct hlist_node *node;
+
+ if (tbl) {
+ h = (tbl->tb6_id & (FIB6_TABLE_HASHSZ - 1)) + 1;
+ node = rcu_dereference(hlist_next_rcu(&tbl->tb6_hlist));
+ } else {
+ node = NULL;
+ h = 0;
+ }
+
+ while (!node && h < FIB6_TABLE_HASHSZ) {
+ node = rcu_dereference(
+ hlist_first_rcu(&net->ipv6.fib_table_hash[h++]));
+ }
+ return hlist_entry_safe(node, struct fib6_table, tb6_hlist);
+}
+
+static void *ipv6_route_seq_start(struct seq_file *seq, loff_t *pos)
+ __acquires(RCU_BH)
+{
+ int r;
+ struct net *net = seq_file_net(seq);
+ struct ipv6_route_iter *iter = seq->private;
+
+ rcu_read_lock_bh();
+ iter->skip = *pos;
+ iter->tbl = ipv6_route_seq_next_table(NULL, net);
+ while (iter->tbl) {
+ ipv6_route_seq_setup_walk(iter);
+ read_lock(&iter->tbl->tb6_lock);
+ r = fib6_walk_continue(&iter->w);
+ read_unlock(&iter->tbl->tb6_lock);
+ if (r == 0) {
+ fib6_walker_unlink(&iter->w);
+ } else if (r > 0) {
+ return iter->w.leaf;
+ } else {
+ fib6_walker_unlink(&iter->w);
+ return NULL;
+ }
+ iter->tbl = ipv6_route_seq_next_table(iter->tbl, net);
+ }
+ return NULL;
+}
+
+static void *ipv6_route_seq_next(struct seq_file *seq, void *v, loff_t *pos)
+{
+ int r;
+ struct rt6_info *n = v;
+ struct net *net = seq_file_net(seq);
+ struct ipv6_route_iter *iter = seq->private;
+
+ n = n->dst.rt6_next;
+ if (n) {
+ ++*pos;
+ return n;
+ }
+
+next_table:
+ read_lock(&iter->tbl->tb6_lock);
+ r = fib6_walk_continue(&iter->w);
+ read_unlock(&iter->tbl->tb6_lock);
+ if (r > 0) {
+ ++*pos;
+ return iter->w.leaf;
+ } else if (r < 0) {
+ fib6_walker_unlink(&iter->w);
+ return NULL;
+ }
+ fib6_walker_unlink(&iter->w);
+
+ iter->tbl = ipv6_route_seq_next_table(iter->tbl, net);
+ if (!iter->tbl)
+ return NULL;
+
+ ipv6_route_seq_setup_walk(iter);
+ goto next_table;
+}
+
+static bool ipv6_route_iter_active(struct ipv6_route_iter *iter)
+{
+ struct fib6_walker_t *w = &iter->w;
+ return w->node && !(w->state == FWS_U && w->node == w->root);
+}
+
+static void ipv6_route_seq_stop(struct seq_file *seq, void *v)
+ __releases(RCU_BH)
+{
+ struct ipv6_route_iter *iter = seq->private;
+
+ if (ipv6_route_iter_active(iter))
+ fib6_walker_unlink(&iter->w);
+
+ rcu_read_unlock_bh();
+}
+
+static const struct seq_operations ipv6_route_seq_ops = {
+ .start = ipv6_route_seq_start,
+ .next = ipv6_route_seq_next,
+ .stop = ipv6_route_seq_stop,
+ .show = ipv6_route_seq_show
+};
+
+int ipv6_route_open(struct inode *inode, struct file *file)
+{
+ return seq_open_net(inode, file, &ipv6_route_seq_ops,
+ sizeof(struct fib6_walker_t));
+}
+
+#endif /* CONFIG_PROC_FS */
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index e22c4db..42cb227 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2729,56 +2729,12 @@ static int ip6_route_dev_notify(struct notifier_block *this,
#ifdef CONFIG_PROC_FS
-struct rt6_proc_arg
-{
- char *buffer;
- int offset;
- int length;
- int skip;
- int len;
-};
-
-static int rt6_info_route(struct rt6_info *rt, void *p_arg)
-{
- struct seq_file *m = p_arg;
-
- seq_printf(m, "%pi6 %02x ", &rt->rt6i_dst.addr, rt->rt6i_dst.plen);
-
-#ifdef CONFIG_IPV6_SUBTREES
- seq_printf(m, "%pi6 %02x ", &rt->rt6i_src.addr, rt->rt6i_src.plen);
-#else
- seq_puts(m, "00000000000000000000000000000000 00 ");
-#endif
- if (rt->rt6i_flags & RTF_GATEWAY) {
- seq_printf(m, "%pi6", &rt->rt6i_gateway);
- } else {
- seq_puts(m, "00000000000000000000000000000000");
- }
- seq_printf(m, " %08x %08x %08x %08x %8s\n",
- rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
- rt->dst.__use, rt->rt6i_flags,
- rt->dst.dev ? rt->dst.dev->name : "");
- return 0;
-}
-
-static int ipv6_route_show(struct seq_file *m, void *v)
-{
- struct net *net = (struct net *)m->private;
- fib6_clean_all_ro(net, rt6_info_route, 0, m);
- return 0;
-}
-
-static int ipv6_route_open(struct inode *inode, struct file *file)
-{
- return single_open_net(inode, file, ipv6_route_show);
-}
-
static const struct file_operations ipv6_route_proc_fops = {
.owner = THIS_MODULE,
.open = ipv6_route_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = single_release_net,
+ .release = seq_release_net,
};
static int rt6_stats_seq_show(struct seq_file *seq, void *v)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 3/3] net: tcp_probe: add IPv6 support
From: Daniel Borkmann @ 2013-08-21 17:48 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1377107280-31091-1-git-send-email-dborkman@redhat.com>
The tcp_probe currently only supports analysis of IPv4 connections.
Therefore, it would be nice to have IPv6 supported as well. Since we
have the recently added %pISpc specifier that is IPv4/IPv6 generic,
build related sockaddress structures from the flow information and
pass this to our format string. Tested with SSH and HTTP sessions
on IPv4 and IPv6.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/ipv4/tcp_probe.c | 54 ++++++++++++++++++++++++++++++++++++++++---------
1 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
index a2392f4..301a3ef 100644
--- a/net/ipv4/tcp_probe.c
+++ b/net/ipv4/tcp_probe.c
@@ -54,8 +54,11 @@ static const char procname[] = "tcpprobe";
struct tcp_log {
ktime_t tstamp;
- __be32 saddr, daddr;
- __be16 sport, dport;
+ union {
+ struct sockaddr raw;
+ struct sockaddr_in v4;
+ struct sockaddr_in6 v6;
+ } src, dst;
u16 length;
u32 snd_nxt;
u32 snd_una;
@@ -87,6 +90,30 @@ static inline int tcp_probe_avail(void)
return bufsize - tcp_probe_used() - 1;
}
+#define tcp_probe_copy_fl_to_si4(inet, si4, mem) \
+ do { \
+ si4.sin_family = AF_INET; \
+ si4.sin_port = inet->inet_##mem##port; \
+ si4.sin_addr.s_addr = inet->inet_##mem##addr; \
+ } while (0) \
+
+#if IS_ENABLED(CONFIG_IPV6)
+#define tcp_probe_copy_fl_to_si6(inet, si6, mem) \
+ do { \
+ struct ipv6_pinfo *pi6 = inet->pinet6; \
+ si6.sin6_family = AF_INET6; \
+ si6.sin6_port = inet->inet_##mem##port; \
+ si6.sin6_addr = pi6->mem##addr; \
+ si6.sin6_flowinfo = 0; /* No need here. */ \
+ si6.sin6_scope_id = 0; /* No need here. */ \
+ } while (0)
+#else
+#define tcp_probe_copy_fl_to_si6(fl, si6, mem) \
+ do { \
+ memset(&si6, 0, sizeof(si6)); \
+ } while (0)
+#endif
+
/*
* Hook inserted to be called before each receive packet.
* Note: arguments must match tcp_rcv_established()!
@@ -108,10 +135,19 @@ static int jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
struct tcp_log *p = tcp_probe.log + tcp_probe.head;
p->tstamp = ktime_get();
- p->saddr = inet->inet_saddr;
- p->sport = inet->inet_sport;
- p->daddr = inet->inet_daddr;
- p->dport = inet->inet_dport;
+ switch (sk->sk_family) {
+ case AF_INET:
+ tcp_probe_copy_fl_to_si4(inet, p->src.v4, s);
+ tcp_probe_copy_fl_to_si4(inet, p->dst.v4, d);
+ break;
+ case AF_INET6:
+ tcp_probe_copy_fl_to_si6(inet, p->src.v6, s);
+ tcp_probe_copy_fl_to_si6(inet, p->dst.v6, d);
+ break;
+ default:
+ BUG();
+ }
+
p->length = skb->len;
p->snd_nxt = tp->snd_nxt;
p->snd_una = tp->snd_una;
@@ -159,12 +195,10 @@ static int tcpprobe_sprint(char *tbuf, int n)
= ktime_to_timespec(ktime_sub(p->tstamp, tcp_probe.start));
return scnprintf(tbuf, n,
- "%lu.%09lu %pI4:%u %pI4:%u %d %#x %#x %u %u %u %u %u\n",
+ "%lu.%09lu %pISpc %pISpc %d %#x %#x %u %u %u %u %u\n",
(unsigned long) tv.tv_sec,
(unsigned long) tv.tv_nsec,
- &p->saddr, ntohs(p->sport),
- &p->daddr, ntohs(p->dport),
- p->length, p->snd_nxt, p->snd_una,
+ &p->src, &p->dst, p->length, p->snd_nxt, p->snd_una,
p->snd_cwnd, p->ssthresh, p->snd_wnd, p->srtt, p->rcv_wnd);
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/3] net: tcp_probe: kprobes: adapt jtcp_rcv_established signature
From: Daniel Borkmann @ 2013-08-21 17:47 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1377107280-31091-1-git-send-email-dborkman@redhat.com>
This patches fixes a rather unproblematic function signature mismatch
as the const specifier was missing for the th variable; and next to
that it adds a build-time assertion so that future function signature
mismatches for kprobes will not end badly, similarly as commit 22222997
("net: sctp: add build check for sctp_sf_eat_sack_6_2/jsctp_sf_eat_sack")
did it for SCTP.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/ipv4/tcp_probe.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
index fae788b..a2392f4 100644
--- a/net/ipv4/tcp_probe.c
+++ b/net/ipv4/tcp_probe.c
@@ -92,7 +92,7 @@ static inline int tcp_probe_avail(void)
* Note: arguments must match tcp_rcv_established()!
*/
static int jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
- struct tcphdr *th, unsigned int len)
+ const struct tcphdr *th, unsigned int len)
{
const struct tcp_sock *tp = tcp_sk(sk);
const struct inet_sock *inet = inet_sk(sk);
@@ -225,6 +225,13 @@ static __init int tcpprobe_init(void)
{
int ret = -ENOMEM;
+ /* Warning: if the function signature of tcp_rcv_established,
+ * has been changed, you also have to change the signature of
+ * jtcp_rcv_established, otherwise you end up right here!
+ */
+ BUILD_BUG_ON(__same_type(tcp_rcv_established,
+ jtcp_rcv_established) == 0);
+
init_waitqueue_head(&tcp_probe.wait);
spin_lock_init(&tcp_probe.lock);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 1/3] net: tcp_probe: also include rcv_wnd next to snd_wnd
From: Daniel Borkmann @ 2013-08-21 17:47 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1377107280-31091-1-git-send-email-dborkman@redhat.com>
It is helpful to sometimes know the TCP window sizes of an established
socket e.g. to confirm that window scaling is working or to tweak the
window size to improve high-latency connections, etc etc. Currently the
TCP snooper only exports the send window size, but not the receive window
size. Therefore, also add the receive window size to the end of the
output line.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/ipv4/tcp_probe.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
index d4943f6..fae788b 100644
--- a/net/ipv4/tcp_probe.c
+++ b/net/ipv4/tcp_probe.c
@@ -60,6 +60,7 @@ struct tcp_log {
u32 snd_nxt;
u32 snd_una;
u32 snd_wnd;
+ u32 rcv_wnd;
u32 snd_cwnd;
u32 ssthresh;
u32 srtt;
@@ -116,6 +117,7 @@ static int jtcp_rcv_established(struct sock *sk, struct sk_buff *skb,
p->snd_una = tp->snd_una;
p->snd_cwnd = tp->snd_cwnd;
p->snd_wnd = tp->snd_wnd;
+ p->rcv_wnd = tp->rcv_wnd;
p->ssthresh = tcp_current_ssthresh(sk);
p->srtt = tp->srtt >> 3;
@@ -157,13 +159,13 @@ static int tcpprobe_sprint(char *tbuf, int n)
= ktime_to_timespec(ktime_sub(p->tstamp, tcp_probe.start));
return scnprintf(tbuf, n,
- "%lu.%09lu %pI4:%u %pI4:%u %d %#x %#x %u %u %u %u\n",
+ "%lu.%09lu %pI4:%u %pI4:%u %d %#x %#x %u %u %u %u %u\n",
(unsigned long) tv.tv_sec,
(unsigned long) tv.tv_nsec,
&p->saddr, ntohs(p->sport),
&p->daddr, ntohs(p->dport),
p->length, p->snd_nxt, p->snd_una,
- p->snd_cwnd, p->ssthresh, p->snd_wnd, p->srtt);
+ p->snd_cwnd, p->ssthresh, p->snd_wnd, p->srtt, p->rcv_wnd);
}
static ssize_t tcpprobe_read(struct file *file, char __user *buf,
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 0/3] Various tcp_probe module improvements
From: Daniel Borkmann @ 2013-08-21 17:47 UTC (permalink / raw)
To: davem; +Cc: netdev
Future follow-up work could include a small, generic user space helper
utility for iproute2's misc folder that would add a top-like display of
both, TCP and SCTP's kprobe-based snoop modules.
Daniel Borkmann (3):
net: tcp_probe: also include rcv_wnd next to snd_wnd
net: tcp_probe: kprobes: adapt jtcp_rcv_established signature
net: tcp_probe: add IPv6 support
net/ipv4/tcp_probe.c | 67 +++++++++++++++++++++++++++++++++++++++++---------
1 files changed, 55 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] net: netem: always adjust now/delay when not reordering
From: Stephen Hemminger @ 2013-08-21 17:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ferry Huberts, Johannes Naab, netdev, hagen
In-Reply-To: <1377104417.4226.133.camel@edumazet-glaptop>
On Wed, 21 Aug 2013 10:00:17 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2013-08-21 at 18:14 +0200, Ferry Huberts wrote:
>
> > Well no. We expected no reordering because reordering is not enabled.
>
>
> Sending packets with random delays happening in the 'network' _will_
> reorder packets at the receiver.
>
> The 'reorder' netem attribute is quite limited and not practical,
> because it only queues the packet at the head of the queue instead of
> tail. This is not what happens on the networks.
>
> You want something very special, and this needs a new parameter to netem
> qdisc, or a new qdisc.
>
> If I setup "netem rate 1Mbit delay 1000ms 50ms", and send a burst of 100
> small packets, I expect these _all_ packets reach the destination in
> less than 1050ms.
>
> I do not want packet1 being delivered at t0+1020ms,
> packet2 being delivered at t0+1020+1030ms
> packet100 being delivered at t0+1020+1030++...+ = t0+~100sec
>
> If your patch solves the problem, good, but I see no clear test of this.
The current behavior followed what NISTnet did. At the time, I wanted
NISTnet users to be able to use netem without a lot of surprises.
http://www-x.antd.nist.gov/nistnet/
^ permalink raw reply
* Re: ADSL/ATM linklayer tc shaping regression fix commits for stable
From: Dave Taht @ 2013-08-21 17:10 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
stable-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, bufferbloat-list,
David Miller
In-Reply-To: <20130821140350.2b953007-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2182 bytes --]
On Wed, Aug 21, 2013 at 5:03 AM, Jesper Dangaard Brouer
<brouer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>wrote:
>
> On Tue, 20 Aug 2013 08:16:50 -0700
> Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> > On Tue, Aug 20, 2013 at 01:26:29PM +0200, Jesper Dangaard Brouer wrote:
> [...]
>
> > If there are issues with 3.10, that's a different story.
> >
> > > Refactor improvements (v3.11-rc1):
> > > commit 130d3d68b52 (net_sched: psched_ratecfg_precompute()
> improvements)
>
> Needed because it fixes the accuracy of the rate calc.
>
> > > The linklayer ATM/ADSL fix, reached 3.11-rc6:
> > > commit 8a8e3d84b17 (net_sched: restore "linklayer atm" handling)
>
> Needed because we broke userspace interface.
>
> > David sends me the networking patches for the stable tree, and if he
> > thinks these are applicable, then I'll take them.
>
> DaveM, please? What do you want me to do, submit this req/patches somehow?
>
> (Can see that is not currently on your stable queue via:
> http://patchwork.ozlabs.org/bundle/davem/stable/?state=*)
>
>
+1 Dealing with the busted DSL stuff since 3.8 has been no fun and it would
be nice if these last fixes made it into 3.10.X at least so router/fw
distros can pick them up more easily. The difference in dsl behavior since
the bustage in 3.8 to the saner now is remarkable.
Probably not meeting the criteria for 3.10-stable inclusion (as they aren't
exactly bugfixes) are the tiny improvements to the flow dissector made in
3.11 for better ipip, ipv6 encapsulation, and 802.1ad support, but I
thought I'd mention them so other fq_codel folk pick them up that need them.
Not ready for any tree and increasingly doubtful for 3.12 are some
improvements under test to codel and cisco's sch_pie, if anyone wants to
play with them, let me know off list.
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Sr. Network Kernel Developer at Red Hat
> Author of http://www.iptv-analyzer.org
> LinkedIn: http://www.linkedin.com/in/brouer
>
--
Dave Täht
Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
[-- Attachment #1.2: Type: text/html, Size: 3345 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Bloat mailing list
Bloat-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org
https://lists.bufferbloat.net/listinfo/bloat
^ permalink raw reply
* Re: [PATCH 2/2] net: netem: always adjust now/delay when not reordering
From: Eric Dumazet @ 2013-08-21 17:00 UTC (permalink / raw)
To: Ferry Huberts; +Cc: Johannes Naab, netdev, hagen
In-Reply-To: <5214E774.8060400@hupie.com>
On Wed, 2013-08-21 at 18:14 +0200, Ferry Huberts wrote:
> Well no. We expected no reordering because reordering is not enabled.
Sending packets with random delays happening in the 'network' _will_
reorder packets at the receiver.
The 'reorder' netem attribute is quite limited and not practical,
because it only queues the packet at the head of the queue instead of
tail. This is not what happens on the networks.
You want something very special, and this needs a new parameter to netem
qdisc, or a new qdisc.
If I setup "netem rate 1Mbit delay 1000ms 50ms", and send a burst of 100
small packets, I expect these _all_ packets reach the destination in
less than 1050ms.
I do not want packet1 being delivered at t0+1020ms,
packet2 being delivered at t0+1020+1030ms
packet100 being delivered at t0+1020+1030++...+ = t0+~100sec
If your patch solves the problem, good, but I see no clear test of this.
^ permalink raw reply
* [PATCH 3/4] ps3_gelic: lower NAPI weight
From: Michal Schmidt @ 2013-08-21 16:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet, Geoff Levand
In-Reply-To: <1377103771-1590-1-git-send-email-mschmidt@redhat.com>
Since commit 82dc3c63 netif_napi_add() produces an error message if
a NAPI poll weight greater than 64 is requested.
GELIC_NET_NAPI_WEIGHT is defined to GELIC_NET_RX_DESCRIPTORS,
which is 128.
Use the standard NAPI weight.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
CC: Geoff Levand <geoff@infradead.org>
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 3 +--
drivers/net/ethernet/toshiba/ps3_gelic_net.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index ad32af6..9c805e0 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -1466,8 +1466,7 @@ static void gelic_ether_setup_netdev_ops(struct net_device *netdev,
{
netdev->watchdog_timeo = GELIC_NET_WATCHDOG_TIMEOUT;
/* NAPI */
- netif_napi_add(netdev, napi,
- gelic_net_poll, GELIC_NET_NAPI_WEIGHT);
+ netif_napi_add(netdev, napi, gelic_net_poll, NAPI_POLL_WEIGHT);
netdev->ethtool_ops = &gelic_ether_ethtool_ops;
netdev->netdev_ops = &gelic_netdevice_ops;
}
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.h b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
index a93df6a..309abb4 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.h
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
@@ -37,7 +37,6 @@
#define GELIC_NET_RXBUF_ALIGN 128
#define GELIC_CARD_RX_CSUM_DEFAULT 1 /* hw chksum */
#define GELIC_NET_WATCHDOG_TIMEOUT 5*HZ
-#define GELIC_NET_NAPI_WEIGHT (GELIC_NET_RX_DESCRIPTORS)
#define GELIC_NET_BROADCAST_ADDR 0xffffffffffffL
#define GELIC_NET_MC_COUNT_MAX 32 /* multicast address list */
--
1.8.3.1
^ permalink raw reply related
* [PATCH 4/4] qlcnic: use standard NAPI weights
From: Michal Schmidt @ 2013-08-21 16:49 UTC (permalink / raw)
To: David Miller
Cc: netdev, Eric Dumazet, Himanshu Madhani, Rajesh Borundia,
Shahed Shaikh, Jitendra Kalsaria, Sony Chacko,
Sucheta Chakraborty, linux-driver
In-Reply-To: <1377103771-1590-1-git-send-email-mschmidt@redhat.com>
Since commit 82dc3c63 netif_napi_add() produces an error message if
a NAPI poll weight greater than 64 is requested.
qlcnic requests the weight as large as 256 for some of its rings, and
smaller values for other rings. For instance in qlcnic_82xx_napi_add()
I think the intention was to give the tx+rx ring a bigger weight than
to rx-only rings, but it's actually doing the opposite. So I'm assuming
the weights do not really matter much.
Just use the standard NAPI weights for all rings.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
CC: Himanshu Madhani <himanshu.madhani@qlogic.com>
CC: Rajesh Borundia <rajesh.borundia@qlogic.com>
CC: Shahed Shaikh <shahed.shaikh@qlogic.com>
CC: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
CC: Sony Chacko <sony.chacko@qlogic.com>
CC: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
CC: linux-driver@qlogic.com
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 1 -
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 25 ++++++++++---------------
2 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 3dcc666..47876a5 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -926,7 +926,6 @@ struct qlcnic_ipaddr {
#define QLCNIC_PCI_REG_MSIX_TBL 0x44
#define QLCNIC_MSIX_TBL_PGSIZE 4096
-#define QLCNIC_NETDEV_WEIGHT 128
#define QLCNIC_ADAPTER_UP_MAGIC 777
#define __QLCNIC_FW_ATTACHED 0
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index cec0908..1a5915d 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -1408,23 +1408,21 @@ void qlcnic_82xx_process_rcv_ring_diag(struct qlcnic_host_sds_ring *sds_ring)
int qlcnic_82xx_napi_add(struct qlcnic_adapter *adapter,
struct net_device *netdev)
{
- int ring, max_sds_rings;
+ int ring;
struct qlcnic_host_sds_ring *sds_ring;
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
if (qlcnic_alloc_sds_rings(recv_ctx, adapter->max_sds_rings))
return -ENOMEM;
- max_sds_rings = adapter->max_sds_rings;
-
for (ring = 0; ring < adapter->max_sds_rings; ring++) {
sds_ring = &recv_ctx->sds_rings[ring];
if (ring == adapter->max_sds_rings - 1)
netif_napi_add(netdev, &sds_ring->napi, qlcnic_poll,
- QLCNIC_NETDEV_WEIGHT / max_sds_rings);
+ NAPI_POLL_WEIGHT);
else
netif_napi_add(netdev, &sds_ring->napi, qlcnic_rx_poll,
- QLCNIC_NETDEV_WEIGHT*2);
+ NAPI_POLL_WEIGHT);
}
if (qlcnic_alloc_tx_rings(adapter, netdev)) {
@@ -1861,7 +1859,7 @@ void qlcnic_83xx_napi_disable(struct qlcnic_adapter *adapter)
int qlcnic_83xx_napi_add(struct qlcnic_adapter *adapter,
struct net_device *netdev)
{
- int ring, max_sds_rings, temp;
+ int ring;
struct qlcnic_host_sds_ring *sds_ring;
struct qlcnic_host_tx_ring *tx_ring;
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
@@ -1869,25 +1867,22 @@ int qlcnic_83xx_napi_add(struct qlcnic_adapter *adapter,
if (qlcnic_alloc_sds_rings(recv_ctx, adapter->max_sds_rings))
return -ENOMEM;
- max_sds_rings = adapter->max_sds_rings;
for (ring = 0; ring < adapter->max_sds_rings; ring++) {
sds_ring = &recv_ctx->sds_rings[ring];
if (adapter->flags & QLCNIC_MSIX_ENABLED) {
- if (!(adapter->flags & QLCNIC_TX_INTR_SHARED)) {
+ if (!(adapter->flags & QLCNIC_TX_INTR_SHARED))
netif_napi_add(netdev, &sds_ring->napi,
qlcnic_83xx_rx_poll,
- QLCNIC_NETDEV_WEIGHT * 2);
- } else {
- temp = QLCNIC_NETDEV_WEIGHT / max_sds_rings;
+ NAPI_POLL_WEIGHT);
+ else
netif_napi_add(netdev, &sds_ring->napi,
qlcnic_83xx_msix_sriov_vf_poll,
- temp);
- }
+ NAPI_POLL_WEIGHT);
} else {
netif_napi_add(netdev, &sds_ring->napi,
qlcnic_83xx_poll,
- QLCNIC_NETDEV_WEIGHT / max_sds_rings);
+ NAPI_POLL_WEIGHT);
}
}
@@ -1902,7 +1897,7 @@ int qlcnic_83xx_napi_add(struct qlcnic_adapter *adapter,
tx_ring = &adapter->tx_ring[ring];
netif_napi_add(netdev, &tx_ring->napi,
qlcnic_83xx_msix_tx_poll,
- QLCNIC_NETDEV_WEIGHT);
+ NAPI_POLL_WEIGHT);
}
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/4] netxen: lower NAPI weight
From: Michal Schmidt @ 2013-08-21 16:49 UTC (permalink / raw)
To: David Miller
Cc: netdev, Eric Dumazet, Manish Chopra, Sony Chacko, Rajesh Borundia
In-Reply-To: <1377103771-1590-1-git-send-email-mschmidt@redhat.com>
Since commit 82dc3c63 netif_napi_add() produces an error message if
a NAPI poll weight greater than 64 is requested.
Use the standard NAPI weight.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
CC: Manish Chopra <manish.chopra@qlogic.com>
CC: Sony Chacko <sony.chacko@qlogic.com>
CC: Rajesh Borundia <rajesh.borundia@qlogic.com>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic.h | 1 -
drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
index 3fe09ab..32675e1 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
@@ -1171,7 +1171,6 @@ typedef struct {
#define NETXEN_DB_MAPSIZE_BYTES 0x1000
-#define NETXEN_NETDEV_WEIGHT 128
#define NETXEN_ADAPTER_UP_MAGIC 777
#define NETXEN_NIC_PEG_TUNE 0
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index 1046e94..cbd75f9 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -197,7 +197,7 @@ netxen_napi_add(struct netxen_adapter *adapter, struct net_device *netdev)
for (ring = 0; ring < adapter->max_sds_rings; ring++) {
sds_ring = &recv_ctx->sds_rings[ring];
netif_napi_add(netdev, &sds_ring->napi,
- netxen_nic_poll, NETXEN_NETDEV_WEIGHT);
+ netxen_nic_poll, NAPI_POLL_WEIGHT);
}
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/4] jme: lower NAPI weight
From: Michal Schmidt @ 2013-08-21 16:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet, Guo-Fu Tseng
In-Reply-To: <1377103771-1590-1-git-send-email-mschmidt@redhat.com>
Since commit 82dc3c63 netif_napi_add() produces an error message if
a NAPI poll weight greater than 64 is requested.
jme requests a quarter of the rx ring size as the NAPI weight.
jme's rx ring size is 1 << 9 = 512.
Use the standard NAPI weight.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
CC: Guo-Fu Tseng <cooldavid@cooldavid.org>
---
drivers/net/ethernet/jme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 7fbe6ab..23de82a 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -3069,7 +3069,7 @@ jme_init_one(struct pci_dev *pdev,
jwrite32(jme, JME_APMC, apmc);
}
- NETIF_NAPI_SET(netdev, &jme->napi, jme_poll, jme->rx_ring_size >> 2)
+ NETIF_NAPI_SET(netdev, &jme->napi, jme_poll, NAPI_POLL_WEIGHT)
spin_lock_init(&jme->phy_lock);
spin_lock_init(&jme->macaddr_lock);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 0/4] drivers/net: fix too big NAPI weights
From: Michal Schmidt @ 2013-08-21 16:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
Some drivers request too big NAPI weights and would trigger the error
message in netif_napi_add() added in commit 82dc3c63. Let's fix them.
Michal Schmidt (4):
jme: lower NAPI weight
netxen: lower NAPI weight
ps3_gelic: lower NAPI weight
qlcnic: use standard NAPI weights
drivers/net/ethernet/jme.c | 2 +-
drivers/net/ethernet/qlogic/netxen/netxen_nic.h | 1 -
.../net/ethernet/qlogic/netxen/netxen_nic_main.c | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 1 -
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 25 +++++++++-------------
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 3 +--
drivers/net/ethernet/toshiba/ps3_gelic_net.h | 1 -
7 files changed, 13 insertions(+), 22 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH 1/2] hso: Earlier catch of error condition
From: Greg KH @ 2013-08-21 16:25 UTC (permalink / raw)
To: Daniel Gimpelevich; +Cc: j.dumon, linux-usb, netdev, linux-kernel
In-Reply-To: <1377074587.4530.8.camel@chimera>
On Wed, Aug 21, 2013 at 01:43:07AM -0700, Daniel Gimpelevich wrote:
> There is no need to get an interface specification if we know it's the
> wrong one.
>
> Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH 2/2] hso: Fix stack corruption on some architectures
From: Greg KH @ 2013-08-21 16:24 UTC (permalink / raw)
To: Daniel Gimpelevich; +Cc: j.dumon, linux-usb, netdev, linux-kernel
In-Reply-To: <1377074599.4530.9.camel@chimera>
On Wed, Aug 21, 2013 at 01:43:19AM -0700, Daniel Gimpelevich wrote:
> As Sergei Shtylyov explained in the #mipslinux IRC channel:
> [Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
> [Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
> [Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
> [Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
> [Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
> [Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)
>
> Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: Re: [PATCH-SR9700] Merge USB 1.1 Ethernet Adapter SR9700 DeviceDriver into the Linux Kernel
From: Greg KH @ 2013-08-21 16:20 UTC (permalink / raw)
To: liujunliang_ljl
Cc: Francois Romieu, sunhecheng, linux-usb, netdev, linux-kernel
In-Reply-To: <201308211805574844059@163.com>
On Wed, Aug 21, 2013 at 06:06:02PM +0800, liujunliang_ljl wrote:
> Dear Francois Romieu :
>
> 1, all the format problems have been fixed
>
> 2, sr9700.h registers definition is re-written
>
> 3, Thanks for your detail checking and I have beed scripts/checkpatch.pl the patch and please check it.
>
> [PATCH] :
You still aren't sending the patch in a format in which we can apply it
in. Please read the file, Documentation/SubmittingPatches, specifically
the part about the "Signed-off-by:" line, and provding a proper body of
the patch for the changelog.
thanks,
greg k-h
^ permalink raw reply
* Fwd: Potential use-after-free in e1000_clean_tx_irq
From: Andrey Konovalov @ 2013-08-21 16:14 UTC (permalink / raw)
To: e1000-devel
Cc: netdev, Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov,
Alexander Potapenko
In-Reply-To: <CAAeHK+yxpbkSuzRNBis++q002sxW8TWv2f6tStOq5Z7cRBkkAg@mail.gmail.com>
Hi,
I'm working on a memory error detector AddressSanitizer for Linux
kernel (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel),
which can detect use-after-free and buffer-overflow errors.
Currently the tool is in very early stage and it can contain bugs.
I was running a system call fuzzer and got some reports:
[ 64.143848] =========================================================================
[ 64.144763] ERROR: AddressSanitizer: heap-use-after-free on address
ffff88002a3dae60
[ 64.145945] Stack trace:
[ 64.146302] [<ffffffff810dd1f5>] asan_report_error+0x85/0x2c0
[ 64.147112] [<ffffffff810dc700>] asan_check_region+0x30/0x40
[ 64.147966] [<ffffffff810dd4b3>] __tsan_read4+0x13/0x20
[ 64.148808] [<ffffffffa00804d0>] e1000_clean+0x1d0/0x11b0 [e1000]
[ 64.149742] [<ffffffff817f8e1a>] net_rx_action+0x1aa/0x380
[ 64.150574] [<ffffffff810ee9d2>] __do_softirq+0x182/0x3a0
[ 64.151391] [<ffffffff8192629c>] call_softirq+0x1c/0x30
[ 64.152179] [<ffffffff8108040d>] do_softirq+0x5d/0xc0
[ 64.152926] [<ffffffff810ed3d7>] local_bh_enable+0x127/0x130
[ 64.153717] [<ffffffff8185d775>] ip_finish_output+0x365/0x640
[ 64.154653] [<ffffffff8185fc79>] ip_output+0xb9/0x100
[ 64.155423] [<ffffffff8185ed1c>] ip_local_out+0x4c/0x60
[ 64.156216] [<ffffffff818611b3>] ip_send_skb+0x23/0x70
[ 64.156951] [<ffffffff818a4bf4>] udp_send_skb+0x584/0x6e0
[ 64.157761] [<ffffffff818a681c>] udp_sendmsg+0x4dc/0xfd0
[ 64.158581] [<ffffffff818b93e8>] inet_sendmsg+0x108/0x160
[ 64.159401] [<ffffffff817d0f43>] sock_sendmsg+0x133/0x170
[ 64.160143] [<ffffffff817d1669>] SYSC_sendto+0x1e9/0x2d0
[ 64.160932] [<ffffffff817d2329>] SyS_sendto+0x49/0x70
[ 64.161710] [<ffffffff81826e55>] compat_sys_socketcall+0x305/0x530
[ 64.162634] [<ffffffff81926335>] sysenter_dispatch+0x7/0x1a
[ 64.163471] [<ffffffffffffffff>] 0xffffffffffffffff
[ 64.164213] Free stack trace:
[ 64.164660] [<ffffffff810dc831>] asan_slab_free+0x61/0xb0
[ 64.165466] [<ffffffff8127f955>] kmem_cache_free+0x55/0x2e0
[ 64.166261] [<ffffffff817db68b>] kfree_skbmem+0x5b/0xd0
[ 64.167046] [<ffffffff817e003c>] consume_skb+0x4c/0xd0
[ 64.167811] [<ffffffff817f3f90>] dev_kfree_skb_any+0x60/0x70
[ 64.168710] [<ffffffffa007c6ba>]
e1000_unmap_and_free_tx_resource.isra.45+0xda/0x130 [e1000]
[ 64.169954] [<ffffffffa00804e9>] e1000_clean+0x1e9/0x11b0 [e1000]
[ 64.170859] [<ffffffff817f8e1a>] net_rx_action+0x1aa/0x380
[ 64.171685] [<ffffffff810ee9d2>] __do_softirq+0x182/0x3a0
[ 64.172491] [<ffffffff8192629c>] call_softirq+0x1c/0x30
[ 64.173276] [<ffffffff8108040d>] do_softirq+0x5d/0xc0
[ 64.174041] [<ffffffff810ed3d7>] local_bh_enable+0x127/0x130
[ 64.174868] [<ffffffff8185d775>] ip_finish_output+0x365/0x640
[ 64.175734] [<ffffffff8185fc79>] ip_output+0xb9/0x100
[ 64.176518] [<ffffffff8185ed1c>] ip_local_out+0x4c/0x60
[ 64.177315] [<ffffffff818611b3>] ip_send_skb+0x23/0x70
[ 64.178087] [<ffffffff818a4bf4>] udp_send_skb+0x584/0x6e0
[ 64.178910] [<ffffffff818a681c>] udp_sendmsg+0x4dc/0xfd0
[ 64.179713] [<ffffffff818b93e8>] inet_sendmsg+0x108/0x160
[ 64.180524] [<ffffffff817d0f43>] sock_sendmsg+0x133/0x170
[ 64.181332] [<ffffffff817d1669>] SYSC_sendto+0x1e9/0x2d0
[ 64.182001] [<ffffffff817d2329>] SyS_sendto+0x49/0x70
[ 64.182771] [<ffffffff817d238b>] SyS_send+0x3b/0x50
[ 64.183508] Shadow bytes around the buggy address:
[ 64.184258] ffff88003ba7b570: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.185109] ffff88003ba7b580: fa fa fa fa fa fa fa fa fd fd fd fd
fd fd fd fd
[ 64.186184] ffff88003ba7b590: fd fd fd fd fd fd fd fd fd fd fd fd
fd fd fd fd
[ 64.187257] ffff88003ba7b5a0: fd fd fd fd fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.188442] ffff88003ba7b5b0: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.189520] =>ffff88003ba7b5c0: fd fd fd fd fd fd fd fd fd fd fd
fd[fd]fd fd fd
[ 64.190600] ffff88003ba7b5d0: fd fd fd fd fd fd fd fd fd fd fd fd
fa fa fa fa
[ 64.191676] ffff88003ba7b5e0: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.192730] ffff88003ba7b5f0: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.193822] ffff88003ba7b600: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.194903] ffff88003ba7b610: fa fa fa fa fa fa fa fa 00 00 00 00
fa fa fa fa
[ 64.195954] Shadow byte legend (one shadow byte represents 8
application bytes):
[ 64.197039] Addressable: 00
[ 64.197585] Partially addressable: 01 02 03 04 05 06 07
[ 64.198407] Heap redzone: fa
[ 64.198955] Freed heap region: fd
[ 64.199519] =========================================================================
[ 64.200424] =========================================================================
[ 64.201539] ERROR: AddressSanitizer: heap-use-after-free on address
ffff88002a3daedc
[ 64.202432] Stack trace:
[ 64.202814] [<ffffffff810dd1f5>] asan_report_error+0x85/0x2c0
[ 64.203636] [<ffffffff810dc700>] asan_check_region+0x30/0x40
[ 64.204481] [<ffffffff810dd4b3>] __tsan_read4+0x13/0x20
[ 64.205267] [<ffffffff817e001b>] consume_skb+0x2b/0xd0
[ 64.206066] [<ffffffff817f3f90>] dev_kfree_skb_any+0x60/0x70
[ 64.206923] [<ffffffffa007c6ba>]
e1000_unmap_and_free_tx_resource.isra.45+0xda/0x130 [e1000]
[ 64.208144] [<ffffffffa00804e9>] e1000_clean+0x1e9/0x11b0 [e1000]
[ 64.209067] [<ffffffff817f8e1a>] net_rx_action+0x1aa/0x380
[ 64.209866] [<ffffffff810ee9d2>] __do_softirq+0x182/0x3a0
[ 64.210671] [<ffffffff8192629c>] call_softirq+0x1c/0x30
[ 64.211463] [<ffffffff8108040d>] do_softirq+0x5d/0xc0
[ 64.212227] [<ffffffff810ed3d7>] local_bh_enable+0x127/0x130
[ 64.213074] [<ffffffff8185d775>] ip_finish_output+0x365/0x640
[ 64.213910] [<ffffffff8185fc79>] ip_output+0xb9/0x100
[ 64.214661] [<ffffffff8185ed1c>] ip_local_out+0x4c/0x60
[ 64.215451] [<ffffffff818611b3>] ip_send_skb+0x23/0x70
[ 64.216249] [<ffffffff818a4bf4>] udp_send_skb+0x584/0x6e0
[ 64.217064] [<ffffffff818a681c>] udp_sendmsg+0x4dc/0xfd0
[ 64.217838] [<ffffffff818b93e8>] inet_sendmsg+0x108/0x160
[ 64.218687] [<ffffffff817d0f43>] sock_sendmsg+0x133/0x170
[ 64.219496] [<ffffffff817d1669>] SYSC_sendto+0x1e9/0x2d0
[ 64.220297] [<ffffffff817d2329>] SyS_sendto+0x49/0x70
[ 64.221069] [<ffffffff81826e55>] compat_sys_socketcall+0x305/0x530
[ 64.222053] [<ffffffff81926335>] sysenter_dispatch+0x7/0x1a
[ 64.222867] [<ffffffffffffffff>] 0xffffffffffffffff
[ 64.223592] Free stack trace:
[ 64.224050] [<ffffffff810dc831>] asan_slab_free+0x61/0xb0
[ 64.224841] [<ffffffff8127f955>] kmem_cache_free+0x55/0x2e0
[ 64.225559] [<ffffffff817db68b>] kfree_skbmem+0x5b/0xd0
[ 64.226342] [<ffffffff817e003c>] consume_skb+0x4c/0xd0
[ 64.227121] [<ffffffff817f3f90>] dev_kfree_skb_any+0x60/0x70
[ 64.227958] [<ffffffffa007c6ba>]
e1000_unmap_and_free_tx_resource.isra.45+0xda/0x130 [e1000]
[ 64.229240] [<ffffffffa00804e9>] e1000_clean+0x1e9/0x11b0 [e1000]
[ 64.230149] [<ffffffff817f8e1a>] net_rx_action+0x1aa/0x380
[ 64.230947] [<ffffffff810ee9d2>] __do_softirq+0x182/0x3a0
[ 64.231706] [<ffffffff8192629c>] call_softirq+0x1c/0x30
[ 64.232451] [<ffffffff8108040d>] do_softirq+0x5d/0xc0
[ 64.233219] [<ffffffff810ed3d7>] local_bh_enable+0x127/0x130
[ 64.234012] [<ffffffff8185d775>] ip_finish_output+0x365/0x640
[ 64.234842] [<ffffffff8185fc79>] ip_output+0xb9/0x100
[ 64.235621] [<ffffffff8185ed1c>] ip_local_out+0x4c/0x60
[ 64.236431] [<ffffffff818611b3>] ip_send_skb+0x23/0x70
[ 64.237221] [<ffffffff818a4bf4>] udp_send_skb+0x584/0x6e0
[ 64.237991] [<ffffffff818a681c>] udp_sendmsg+0x4dc/0xfd0
[ 64.238788] [<ffffffff818b93e8>] inet_sendmsg+0x108/0x160
[ 64.239604] [<ffffffff817d0f43>] sock_sendmsg+0x133/0x170
[ 64.240413] [<ffffffff817d1669>] SYSC_sendto+0x1e9/0x2d0
[ 64.241213] [<ffffffff817d2329>] SyS_sendto+0x49/0x70
[ 64.241954] [<ffffffff817d238b>] SyS_send+0x3b/0x50
[ 64.242681] Shadow bytes around the buggy address:
[ 64.243422] ffff88003ba7b580: fa fa fa fa fa fa fa fa fd fd fd fd
fd fd fd fd
[ 64.244534] ffff88003ba7b590: fd fd fd fd fd fd fd fd fd fd fd fd
fd fd fd fd
[ 64.245615] ffff88003ba7b5a0: fd fd fd fd fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.246691] ffff88003ba7b5b0: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.247768] ffff88003ba7b5c0: fd fd fd fd fd fd fd fd fd fd fd fd
fd fd fd fd
[ 64.248886] =>ffff88003ba7b5d0: fd fd fd fd fd fd fd fd fd fd
fd[fd]fa fa fa fa
[ 64.250001] ffff88003ba7b5e0: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.251084] ffff88003ba7b5f0: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.252162] ffff88003ba7b600: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.253236] ffff88003ba7b610: fa fa fa fa fa fa fa fa 00 00 00 00
fa fa fa fa
[ 64.254312] ffff88003ba7b620: fa fa fa fa fa fa fa fa fa fa fa fa
fa fa fa fa
[ 64.255431] Shadow byte legend (one shadow byte represents 8
application bytes):
[ 64.256500] Addressable: 00
[ 64.257083] Partially addressable: 01 02 03 04 05 06 07
[ 64.257851] Heap redzone: fa
[ 64.258397] Freed heap region: fd
[ 64.258942] =========================================================================
There were more use-after-free reports after these two.
The first use-after-free was caused by accessing 'len' field in
'buffer_info->skb' in 'e1000_clean_tx_irq' (line 3835).
Our guess is that 'buffer_info->skb' had been freed in another thread
(the bottom frames of the stack traces are different) by
'e1000_unmap_and_free_tx_resource' (line 1972) but wasn't assigned to
'NULL' yet (line 1973).
The kernel version is 3.11-rc4 (last commit:
b7bc9e7d808ba55729bd263b0210cda36965be32).
e100_clean_tx_irq:
http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/e1000/e1000_main.c#L3835
e1000_unmap_and_free_tx_resource:
http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/e1000/e1000_main.c#L1958
Since these reports were caused by a system call fuzzer I don't know
how to reproduce them.
Could you confirm if this is a real bug?
Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] net: netem: always adjust now/delay when not reordering
From: Ferry Huberts @ 2013-08-21 16:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Johannes Naab, netdev, hagen
In-Reply-To: <1377099575.4226.120.camel@edumazet-glaptop>
On 21/08/13 17:39, Eric Dumazet wrote:
> On Wed, 2013-08-21 at 17:17 +0200, Johannes Naab wrote:
>> On 08/20/2013 05:11 PM, Ferry Huberts wrote:
>>> From: Ferry Huberts <ferry.huberts@pelagic.nl>
>>>
>>> Not doing this (current behaviour) introduces reordering.
>>>
>>> The packet_len_2_sched_time call is the only thing that logically
>>> depends on q->rate, so move the now/delay adjustment out of the if.
>>>
>>> Signed-off-by: Ferry Huberts <ferry.huberts@pelagic.nl>
>>> ---
>>
>> Hi,
>>
>> The documentation for netem does explicitly mention the reordering with
>> jitter, and gives instructions on how to avoid it. (I have not tested if
>> it works as intended).
>
>
> Yes.
>
> The user specifically adds a random delay of 0 to 510 ms to packets,
> and expect netem to not reorder packets sent every 100ms.
>
> They see netem as a single medium between two endpoints with a guarantee
> of no reordering, and cumulative delays.
Well no. We expected no reordering because reordering is not enabled.
The documentation is very confusing if you compare it to the source
code, and even incorrect.
What the code does is (when reordering is disabled):
- reorders if the rate is NOT set
- does NOT reorder if the rate is set
That is quite different, the documentation doesn't even mention the rate
nor the reordering setting in this context.
I'm confused on how to proceed now, so CC-ing Hagen Paul Pfeifer
I'll also discuss this with Teco, who asked me to write up a patch.
>
> So if you send a burst of 100 packets, they might expect the last packet
> will be send after ~50 seconds.
>
> This clearly needs a new option to netem, because this is not the
> default behavior we want.
>
>
>
> --
> 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
>
--
Ferry Huberts
^ 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