* Re: [PATCH] iucv: Remove SKB list assumptions.
From: Sergei Shtylyov @ 2018-11-11 8:48 UTC (permalink / raw)
To: David Miller, netdev
In-Reply-To: <20181110.165545.1492330402009389392.davem@davemloft.net>
Hello!
On 11.11.2018 3:55, David Miller wrote:
> Eliminate the assumption that SKBs and SKB list heads can
> be cast to eachother in SKB list handling code.
Each other? My spellchecker trips here.
> This change also appears to fix a bug since the list->next pointer is
> sampled outside of holding the SKB queue lock.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
[...]
MBR, Sergei
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Jesper Dangaard Brouer @ 2018-11-11 8:56 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Saeed Mahameed, netdev@vger.kernel.org, brouer
In-Reply-To: <78c37b54-dfd8-d528-1152-abe9ddbb08b2@itcare.pl>
On Sat, 10 Nov 2018 22:53:53 +0100 Paweł Staszewski <pstaszewski@itcare.pl> wrote:
> Now im messing with ring configuration for connectx5 nics.
> And after reading that paper:
> https://netdevconf.org/2.1/slides/apr6/network-performance/04-amir-RX_and_TX_bulking_v2.pdf
>
Do notice that some of the ideas in that slide deck, was never
implemented. But they are still on my todo list ;-).
Notice how that it show that TX bulking is very important, but based on
your ethtool_stats.pl, I can see that not much TX bulking is happening
in your case. This is indicated via the xmit_more counters.
Ethtool(enp175s0) stat: 2630 ( 2,630) <= tx_xmit_more /sec
Ethtool(enp175s0) stat: 4956995 ( 4,956,995) <= tx_packets /sec
And the per queue levels are also avail:
Ethtool(enp175s0) stat: 184845 ( 184,845) <= tx7_packets /sec
Ethtool(enp175s0) stat: 78 ( 78) <= tx7_xmit_more /sec
This means that you are doing too many doorbell's to the NIC hardware
at TX time, which I worry could be what cause the NIC and PCIe hardware
not to operate at optimal speeds.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* WARN_ON() in netconsole with PREEMPT_RT
From: Oleksandr Natalenko @ 2018-11-11 19:13 UTC (permalink / raw)
To: David S. Miller
Cc: Steven Rostedt, Sebastian Andrzej Siewior, Thomas Gleixner,
Eric Dumazet, Dave Jones, netdev, linux-rt-users, linux-kernel
Hi.
I was just curious about PREEMPT_RT and decided to give it a (small)
shot on my laptop. As a safety measure, I've enabled netconsole to catch
all the weird stuff that can pop up, and immediately it indeed did… in
the netconsole code itself (irony):
===
[ 64.018949] WARNING: CPU: 0 PID: 1204 at net/core/netpoll.c:372
netpoll_send_udp+0x3e8/0x3ef
…
[ 64.019057] CPU: 0 PID: 1204 Comm: bash Not tainted 4.19.0-ig1 #1
[ 64.019058] Hardware name: Dell Inc. Vostro 3360/0F5DWF,
BIOS A18 09/25/2013
[ 64.019063] RIP: 0010:netpoll_send_udp+0x3e8/0x3ef
[
64.019066] Code: dd ff ff 41 ba 86 dd ff ff 49 2b 96 d0 00 00 00 66 41
89 96 c6 00 00 00 66 44 89 48 0c 66 45 89 96 c0 00 00 00 e9
93 fe ff ff <0f> 0b e9 40 fc ff ff 0f 1f 44 00 00 53 0f b7 57 42 48 89
fb 48 8b
[ 64.019068] RSP: 0018:ffffaa6743f87c98 EFLAGS: 00010202
[ 64.019070] RAX: 0000000000000292 RBX: 0000000000000014 RCX:
0000000000000028
[ 64.019072] RDX: 0000000000000014 RSI: ffffffffb1e6a300 RDI:
ffff95973d905668
[ 64.019073] RBP: ffffaa6743f87cd8 R08: ffffffffc11f6ba0 R09:
0000000000000000
[ 64.019075] R10: 0000000000000008 R11: 0000000000000000 R12:
00000000000003e8
[ 64.019076] R13: ffff95973d905668 R14: 0000000000000014 R15:
ffff95973d905668
[ 64.019079] FS: 00007f2f8b809b80(0000) GS:ffff95976f000000(0000)
knlGS:0000000000000000
[ 64.019081] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 64.019083] CR2: 000055b8e126fbc8 CR3: 0000000415440006 CR4:
00000000001606f0
[ 64.019084] Call Trace:
[ 64.019098] write_msg+0xd1/0xe0 [netconsole]
[ 64.019107] console_unlock.part.6+0x55b/0x5a0
[ 64.019115] ? _raw_spin_unlock_irqrestore+0x20/0x60
[ 64.019120] vprintk_emit+0x16a/0x1a0
[ 64.019125] printk_emit+0x44/0x5b
[ 64.019130] ? _raw_spin_trylock+0x13/0x80
[ 64.019134] devkmsg_write.cold.16+0x21/0x4e
[ 64.019140] __vfs_write+0x136/0x1a0
[ 64.019145] vfs_write+0xa9/0x1a0
[ 64.019149] ksys_write+0x52/0xc0
[ 64.019156] do_syscall_64+0x5b/0x170
[ 64.019160] entry_SYSCALL_64_after_hwframe+0x44/0xa9
…
===
This is a v4.19.1-rt3-based kernel.
The WARN_ON() is:
362 void netpoll_send_udp(struct netpoll *np, const char *msg, int len)
363 {
…
372 WARN_ON_ONCE(!irqs_disabled());
…
If that matters, I have "threadirqs" passed to the kernel.
Netconsole seems to work even after this warning. Is this OK/expected?
Thanks.
--
Oleksandr Natalenko (post-factum)
^ permalink raw reply
* [PATCH tip/core/rcu 11/41] ethernet/sis: Replace synchronize_sched() with synchronize_rcu()
From: Paul E. McKenney @ 2018-11-11 19:43 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg, joel,
Paul E. McKenney, Francois Romieu, David S. Miller, netdev
In-Reply-To: <20181111194104.GA4787@linux.ibm.com>
Now that synchronize_rcu() waits for preempt-disable regions of code
as well as RCU read-side critical sections, synchronize_sched() can be
replaced by synchronize_rcu(). This commit therefore makes this change.
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Cc: Francois Romieu <romieu@fr.zoreil.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>
---
drivers/net/ethernet/sis/sis190.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sis/sis190.c b/drivers/net/ethernet/sis/sis190.c
index c2c50522b96d..808cf9816673 100644
--- a/drivers/net/ethernet/sis/sis190.c
+++ b/drivers/net/ethernet/sis/sis190.c
@@ -1142,7 +1142,7 @@ static void sis190_down(struct net_device *dev)
if (!poll_locked)
poll_locked++;
- synchronize_sched();
+ synchronize_rcu();
} while (SIS_R32(IntrMask));
--
2.17.1
^ permalink raw reply related
* [PATCH tip/core/rcu 14/41] drivers/vhost: Replace synchronize_rcu_bh() with synchronize_rcu()
From: Paul E. McKenney @ 2018-11-11 19:43 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg, joel,
Paul E. McKenney, Michael S. Tsirkin, Jason Wang, kvm,
virtualization, netdev
In-Reply-To: <20181111194104.GA4787@linux.ibm.com>
Now that synchronize_rcu() waits for bh-disable regions of code as well
as RCU read-side critical sections, synchronize_rcu_bh() can be replaced
by synchronize_rcu(). This commit therefore makes this change.
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: <kvm@vger.kernel.org>
Cc: <virtualization@lists.linux-foundation.org>
Cc: <netdev@vger.kernel.org>
---
drivers/vhost/net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ab11b2bee273..564ead864028 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1359,7 +1359,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)
if (rx_sock)
sockfd_put(rx_sock);
/* Make sure no callbacks are outstanding */
- synchronize_rcu_bh();
+ synchronize_rcu();
/* We do an extra flush before freeing memory,
* since jobs can re-queue themselves. */
vhost_net_flush(n);
--
2.17.1
^ permalink raw reply related
* [PATCH tip/core/rcu 30/41] netfilter: Replace call_rcu_bh(), rcu_barrier_bh(), and synchronize_rcu_bh()
From: Paul E. McKenney @ 2018-11-11 19:43 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg, joel,
Paul E. McKenney, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, netfilter-devel, coreteam, netdev
In-Reply-To: <20181111194104.GA4787@linux.ibm.com>
Now that call_rcu()'s callback is not invoked until after bh-disable
regions of code have completed (in addition to explicitly marked
RCU read-side critical sections), call_rcu() can be used in place
of call_rcu_bh(). Similarly, rcu_barrier() can be used in place of
rcu_barrier_bh() and synchronize_rcu() in place of synchronize_rcu_bh().
This commit therefore makes these changes.
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Florian Westphal <fw@strlen.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: <netfilter-devel@vger.kernel.org>
Cc: <coreteam@netfilter.org>
Cc: <netdev@vger.kernel.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 6 +++---
net/netfilter/ipset/ip_set_hash_gen.h | 4 ++--
net/netfilter/nfnetlink_log.c | 2 +-
net/netfilter/xt_hashlimit.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index 2c8d313ae216..5b0c1ee6ae26 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -94,7 +94,7 @@ static inline void
clusterip_config_put(struct clusterip_config *c)
{
if (refcount_dec_and_test(&c->refcount))
- call_rcu_bh(&c->rcu, clusterip_config_rcu_free);
+ call_rcu(&c->rcu, clusterip_config_rcu_free);
}
/* decrease the count of entries using/referencing this config. If last
@@ -876,8 +876,8 @@ static void __exit clusterip_tg_exit(void)
xt_unregister_target(&clusterip_tg_reg);
unregister_pernet_subsys(&clusterip_net_ops);
- /* Wait for completion of call_rcu_bh()'s (clusterip_config_rcu_free) */
- rcu_barrier_bh();
+ /* Wait for completion of call_rcu()'s (clusterip_config_rcu_free) */
+ rcu_barrier();
}
module_init(clusterip_tg_init);
diff --git a/net/netfilter/ipset/ip_set_hash_gen.h b/net/netfilter/ipset/ip_set_hash_gen.h
index e287da68d5fa..2c9609929c71 100644
--- a/net/netfilter/ipset/ip_set_hash_gen.h
+++ b/net/netfilter/ipset/ip_set_hash_gen.h
@@ -67,7 +67,7 @@ tune_ahash_max(u8 curr, u32 multi)
/* A hash bucket */
struct hbucket {
- struct rcu_head rcu; /* for call_rcu_bh */
+ struct rcu_head rcu; /* for call_rcu */
/* Which positions are used in the array */
DECLARE_BITMAP(used, AHASH_MAX_TUNED);
u8 size; /* size of the array */
@@ -664,7 +664,7 @@ mtype_resize(struct ip_set *set, bool retried)
spin_unlock_bh(&set->lock);
/* Give time to other readers of the set */
- synchronize_rcu_bh();
+ synchronize_rcu();
pr_debug("set %s resized from %u (%p) to %u (%p)\n", set->name,
orig->htable_bits, orig, t->htable_bits, t);
diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
index 332c69d27b47..b1f9c5303f02 100644
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -148,7 +148,7 @@ static void
instance_put(struct nfulnl_instance *inst)
{
if (inst && refcount_dec_and_test(&inst->use))
- call_rcu_bh(&inst->rcu, nfulnl_instance_free_rcu);
+ call_rcu(&inst->rcu, nfulnl_instance_free_rcu);
}
static void nfulnl_timer(struct timer_list *t);
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 3e7d259e5d8d..8138b68a9a44 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -260,7 +260,7 @@ static inline void
dsthash_free(struct xt_hashlimit_htable *ht, struct dsthash_ent *ent)
{
hlist_del_rcu(&ent->node);
- call_rcu_bh(&ent->rcu, dsthash_free_rcu);
+ call_rcu(&ent->rcu, dsthash_free_rcu);
ht->count--;
}
static void htable_gc(struct work_struct *work);
@@ -1329,7 +1329,7 @@ static void __exit hashlimit_mt_exit(void)
xt_unregister_matches(hashlimit_mt_reg, ARRAY_SIZE(hashlimit_mt_reg));
unregister_pernet_subsys(&hashlimit_net_ops);
- rcu_barrier_bh();
+ rcu_barrier();
kmem_cache_destroy(hashlimit_cachep);
}
--
2.17.1
^ permalink raw reply related
* [PATCH tip/core/rcu 32/41] net/core: Replace call_rcu_bh() and synchronize_rcu_bh()
From: Paul E. McKenney @ 2018-11-11 19:44 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, jiangshanlai, dipankar, akpm, mathieu.desnoyers, josh,
tglx, peterz, rostedt, dhowells, edumazet, fweisbec, oleg, joel,
Paul E. McKenney, David S. Miller, netdev
In-Reply-To: <20181111194104.GA4787@linux.ibm.com>
Now that call_rcu()'s callback is not invoked until after all bh-disable
regions of code have completed (in addition to explicitly marked
RCU read-side critical sections), call_rcu() can be used in place of
call_rcu_bh(). Similarly, synchronize_rcu() can be used in place of
synchronize_rcu_bh(). This commit therefore makes these changes.
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: <netdev@vger.kernel.org>
---
net/core/netpoll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 5da9552b186b..677d3f332172 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -800,7 +800,7 @@ void __netpoll_cleanup(struct netpoll *np)
ops->ndo_netpoll_cleanup(np->dev);
RCU_INIT_POINTER(np->dev->npinfo, NULL);
- call_rcu_bh(&npinfo->rcu, rcu_cleanup_netpoll_info);
+ call_rcu(&npinfo->rcu, rcu_cleanup_netpoll_info);
} else
RCU_INIT_POINTER(np->dev->npinfo, NULL);
}
@@ -811,7 +811,7 @@ void __netpoll_free(struct netpoll *np)
ASSERT_RTNL();
/* Wait for transmitting packets to finish before freeing. */
- synchronize_rcu_bh();
+ synchronize_rcu();
__netpoll_cleanup(np);
kfree(np);
}
--
2.17.1
^ permalink raw reply related
* [PATCH 3.16 304/366] netlink: Do not subscribe to non-existent groups
From: Ben Hutchings @ 2018-11-11 19:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: akpm, Herbert Xu, Dmitry Safonov, David S. Miller, netdev,
Steffen Klassert
In-Reply-To: <lsq.1541965744.387173642@decadent.org.uk>
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <dima@arista.com>
commit 7acf9d4237c46894e0fa0492dd96314a41742e84 upstream.
Make ABI more strict about subscribing to group > ngroups.
Code doesn't check for that and it looks bogus.
(one can subscribe to non-existing group)
Still, it's possible to bind() to all possible groups with (-1)
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/netlink/af_netlink.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -927,6 +927,7 @@ static int netlink_bind(struct socket *s
if (err)
return err;
}
+ groups &= (1UL << nlk->ngroups) - 1;
if (nlk->portid)
if (nladdr->nl_pid != nlk->portid)
^ permalink raw reply
* [PATCH 3.16 345/366] p54: memset(0) whole array
From: Ben Hutchings @ 2018-11-11 19:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: akpm, linux-wireless, netdev, Jiri Slaby, Kalle Valo,
Christian Lamparter
In-Reply-To: <lsq.1541965744.387173642@decadent.org.uk>
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream.
gcc 7 complains:
drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
Fix that by passing the correct size to memset.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/wireless/p54/fwio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -486,7 +486,7 @@ int p54_scan(struct p54_common *priv, u1
entry += sizeof(__le16);
chan->pa_points_per_curve = 8;
- memset(chan->curve_data, 0, sizeof(*chan->curve_data));
+ memset(chan->curve_data, 0, sizeof(chan->curve_data));
memcpy(chan->curve_data, entry,
sizeof(struct p54_pa_curve_data_sample) *
min((u8)8, curve_data->points_per_channel));
^ permalink raw reply
* [PATCH 3.16 310/366] netlink: Don't shift on 64 for ngroups
From: Ben Hutchings @ 2018-11-11 19:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: akpm, Herbert Xu, Dmitry Safonov, netdev, David S. Miller,
Steffen Klassert
In-Reply-To: <lsq.1541965744.387173642@decadent.org.uk>
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <dima@arista.com>
commit 91874ecf32e41b5d86a4cb9d60e0bee50d828058 upstream.
It's legal to have 64 groups for netlink_sock.
As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
only to first 32 groups.
The check for correctness of .bind() userspace supplied parameter
is done by applying mask made from ngroups shift. Which broke Android
as they have 64 groups and the shift for mask resulted in an overflow.
Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups")
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
net/netlink/af_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -930,8 +930,8 @@ static int netlink_bind(struct socket *s
if (nlk->ngroups == 0)
groups = 0;
- else
- groups &= (1ULL << nlk->ngroups) - 1;
+ else if (nlk->ngroups < 8*sizeof(groups))
+ groups &= (1UL << nlk->ngroups) - 1;
if (nlk->portid)
if (nladdr->nl_pid != nlk->portid)
^ permalink raw reply
* Re: [PATCH net-next 1/2] PCI: add USR vendor id
From: kbuild test robot @ 2018-11-11 10:08 UTC (permalink / raw)
To: Heiner Kallweit
Cc: kbuild-all, Bjorn Helgaas, David Miller, netdev@vger.kernel.org,
linux-pci@vger.kernel.org
In-Reply-To: <71caf048-3f24-6241-b39c-ad1f5bd086c9@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]
Hi Heiner,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Heiner-Kallweit/r8169-add-USR-PCI-vendor-id/20181111-155553
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=ia64
All errors (new ones prefixed by >>):
>> drivers/isdn//hardware/mISDN/w6692.c:1404:23: error: 'PCI_DEVICE_ID_USR_6692' undeclared here (not in a function); did you mean 'PCI_DEVICE_ID_SI_6202'?
PCI_VENDOR_ID_USR, PCI_DEVICE_ID_USR_6692, 0, 0,
^~~~~~~~~~~~~~~~~~~~~~
PCI_DEVICE_ID_SI_6202
vim +1404 drivers/isdn//hardware/mISDN/w6692.c
707b2ce6 Karsten Keil 2009-07-22 1399
e8336ed0 Arvind Yadav 2017-07-15 1400 static const struct pci_device_id w6692_ids[] = {
707b2ce6 Karsten Keil 2009-07-22 1401 { PCI_VENDOR_ID_DYNALINK, PCI_DEVICE_ID_DYNALINK_IS64PH,
707b2ce6 Karsten Keil 2009-07-22 1402 PCI_ANY_ID, PCI_ANY_ID, 0, 0, (ulong)&w6692_map[0]},
707b2ce6 Karsten Keil 2009-07-22 1403 { PCI_VENDOR_ID_WINBOND2, PCI_DEVICE_ID_WINBOND2_6692,
707b2ce6 Karsten Keil 2009-07-22 @1404 PCI_VENDOR_ID_USR, PCI_DEVICE_ID_USR_6692, 0, 0,
707b2ce6 Karsten Keil 2009-07-22 1405 (ulong)&w6692_map[2]},
707b2ce6 Karsten Keil 2009-07-22 1406 { PCI_VENDOR_ID_WINBOND2, PCI_DEVICE_ID_WINBOND2_6692,
707b2ce6 Karsten Keil 2009-07-22 1407 PCI_ANY_ID, PCI_ANY_ID, 0, 0, (ulong)&w6692_map[1]},
707b2ce6 Karsten Keil 2009-07-22 1408 { }
707b2ce6 Karsten Keil 2009-07-22 1409 };
707b2ce6 Karsten Keil 2009-07-22 1410 MODULE_DEVICE_TABLE(pci, w6692_ids);
707b2ce6 Karsten Keil 2009-07-22 1411
:::::: The code at line 1404 was first introduced by commit
:::::: 707b2ce6c1f4f1261788f2ff09ad82c35e0e6240 mISDN: Add driver for Winbond cards
:::::: TO: Karsten Keil <keil@b1-systems.de>
:::::: CC: Karsten Keil <keil@b1-systems.de>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 52329 bytes --]
^ permalink raw reply
* RE,
From: Miss Juliet Muhammad @ 2018-11-11 10:10 UTC (permalink / raw)
To: Recipients
Hello,
My Name is Juliet Muhammad from Turkey, I very happy to contact you because i want to be your friend and business partner hope you don't mind writing me back I came across your e-mail contact prior a private search while in need of your assistance.
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Paweł Staszewski @ 2018-11-11 10:26 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <20181111090350.5d0c230f@redhat.com>
W dniu 11.11.2018 o 09:03, Jesper Dangaard Brouer pisze:
> On Sat, 10 Nov 2018 23:19:50 +0100
> Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>
>> W dniu 10.11.2018 o 23:06, Jesper Dangaard Brouer pisze:
>>> On Sat, 10 Nov 2018 20:56:02 +0100
>>> Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>>>
>>>> W dniu 10.11.2018 o 20:49, Paweł Staszewski pisze:
>>>>> W dniu 10.11.2018 o 20:34, Jesper Dangaard Brouer pisze:
>>>>>> On Fri, 9 Nov 2018 23:20:38 +0100 Paweł Staszewski
>>>>>> <pstaszewski@itcare.pl> wrote:
>>>>>>
>>>>>>> W dniu 08.11.2018 o 20:12, Paweł Staszewski pisze:
> [...]
>>> Do notice, the per CPU squeeze is not too large.
>> Yes - but im searching invisible thing now :) something invisible is
>> slowing down packet processing :)
>> So trying to find any counter that have something to do with packet
>> processing.
> NOTICE, I have given you the counters you need (below)
Yes noticed this :)
>>> [...]
>>>>>>> Remember those tests are now on two separate connectx5 connected to
>>>>>>> two separate pcie x16 gen 3.0
>>>>>> That is strange... I still suspect some HW NIC issue, can you provide
>>>>>> ethtool stats info via tool:
>>>>>>
>>>>>> https://github.com/netoptimizer/network-testing/blob/master/bin/ethtool_stats.pl
>>>>>>
>>>>>> $ ethtool_stats.pl --dev enp175s0 --dev enp216s0
>>>>>>
>>>>>> The tool remove zero-stats counters and report per sec stats. It makes
>>>>>> it easier to spot that is relevant for the given workload.
>>>>> yes mlnx have just too many counters that are always 0 for my case :)
>>>>> Will try this also
>>>>>
>>>> But still alot of non 0 counters
>>>> Show adapter(s) (enp175s0 enp216s0) statistics (ONLY that changed!)
>>>> Ethtool(enp175s0) stat: 8891 ( 8,891) <= ch0_arm /sec
>>> [...]
>>>
>>> I have copied the stats over in another document so I can better looks
>>> at it... and I've found some interesting stats.
>>>
>>> E.g. we can see that the NIC hardware is dropping packets.
>>>
>>> RX-drops on enp175s0:
>>>
>>> (enp175s0) stat: 4850734036 ( 4,850,734,036) <= rx_bytes /sec
>>> (enp175s0) stat: 5069043007 ( 5,069,043,007) <= rx_bytes_phy /sec
>>> -218308971 ( -218,308,971) Dropped bytes /sec
>>>
>>> (enp175s0) stat: 139602 ( 139,602) <= rx_discards_phy /sec
>>>
>>> (enp175s0) stat: 3717148 ( 3,717,148) <= rx_packets /sec
>>> (enp175s0) stat: 3862420 ( 3,862,420) <= rx_packets_phy /sec
>>> -145272 ( -145,272) Dropped packets /sec
>>>
>>>
>>> RX-drops on enp216s0 is less:
>>>
>>> (enp216s0) stat: 2592286809 ( 2,592,286,809) <= rx_bytes /sec
>>> (enp216s0) stat: 2633575771 ( 2,633,575,771) <= rx_bytes_phy /sec
>>> -41288962 ( -41,288,962) Dropped bytes /sec
>>>
>>> (enp216s0) stat: 464 (464) <= rx_discards_phy /sec
>>>
>>> (enp216s0) stat: 4971677 ( 4,971,677) <= rx_packets /sec
>>> (enp216s0) stat: 4975563 ( 4,975,563) <= rx_packets_phy /sec
>>> -3886 ( -3,886) Dropped packets /sec
>>>
>
> I would recommend, that you use ethtool stats and monitor rx_discards_phy.
> The PHY are the counters from the hardware, and it shows that packets
> are getting dropped at HW level. This can be because software is not
> fast enough to empty RX-queue, but in this case where CPUs are mostly
> idle I don't think that is the case.
>
That is why i was searching some counter for software - where is
something wrong.
Cause in earlier reports from ethtool there was also phy drops reported
- just when cpu's was saturated that was normal for me that phy can drop
packets if no more cpu cycles available to pickup them from hw
But in case where i have 50% idle cpu's - there should be no problem -
that is why i start to modify ethtool params for tx/rx ring and coalescence
Currently waiting for more traffic with new ethtool settings:
ethtool -g enp175s0
Ring parameters for enp175s0:
Pre-set maximums:
RX: 8192
RX Mini: 0
RX Jumbo: 0
TX: 8192
Current hardware settings:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 128
ethtool -c enp175s0
Coalesce parameters for enp175s0:
Adaptive RX: off TX: on
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
dmac: 32517
rx-usecs: 64
rx-frames: 128
rx-usecs-irq: 0
rx-frames-irq: 0
tx-usecs: 8
tx-frames: 128
tx-usecs-irq: 0
tx-frames-irq: 0
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
Both ports same settings.
Current traffic:
bwm-ng v0.6.1 (probing every 1.000s), press 'h' for help
input: /proc/net/dev type: rate
| iface Rx Tx Total
==============================================================================
enp175s0: 37.85 Gb/s 7.77 Gb/s
45.62 Gb/s
enp216s0: 7.80 Gb/s 37.90 Gb/s
45.70 Gb/s
------------------------------------------------------------------------------
total: 45.61 Gb/s 45.63 Gb/s
91.24 Gb/s
and mpstat for cpu's
Average: CPU %usr %nice %sys %iowait %irq %soft %steal
%guest %gnice %idle
Average: all 0.33 0.00 1.48 0.01 0.00 12.11 0.00
0.00 0.00 86.06
Average: 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 1 0.00 0.00 0.90 0.00 0.00 0.00 0.00
0.00 0.00 99.10
Average: 2 0.10 0.00 0.20 0.80 0.00 0.00 0.00
0.00 0.00 98.90
Average: 3 0.10 0.00 0.30 0.00 0.00 0.00 0.00
0.00 0.00 99.60
Average: 4 14.10 0.00 1.00 0.00 0.00 0.00 0.00
0.00 0.00 84.90
Average: 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 6 0.00 0.00 1.50 0.00 0.00 0.00 0.00
0.00 0.00 98.50
Average: 7 0.20 0.00 2.00 0.00 0.00 0.00 0.00
0.00 0.00 97.80
Average: 8 0.10 0.00 0.40 0.00 0.00 0.00 0.00
0.00 0.00 99.50
Average: 9 0.00 0.00 0.60 0.00 0.00 0.00 0.00
0.00 0.00 99.40
Average: 10 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 11 0.00 0.00 5.60 0.00 0.00 0.00 0.00
0.00 0.00 94.40
Average: 12 0.00 0.00 4.10 0.00 0.00 0.00 0.00
0.00 0.00 95.90
Average: 13 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 14 0.00 0.00 1.90 0.00 0.00 27.30 0.00
0.00 0.00 70.80
Average: 15 0.00 0.00 2.10 0.00 0.00 26.00 0.00
0.00 0.00 71.90
Average: 16 0.00 0.00 2.10 0.00 0.00 25.40 0.00
0.00 0.00 72.50
Average: 17 0.20 0.00 1.80 0.00 0.00 23.10 0.00
0.00 0.00 74.90
Average: 18 0.00 0.00 2.00 0.00 0.00 25.50 0.00
0.00 0.00 72.50
Average: 19 0.00 0.00 1.90 0.00 0.00 20.20 0.00
0.00 0.00 77.90
Average: 20 0.10 0.00 1.00 0.00 0.00 26.90 0.00
0.00 0.00 72.00
Average: 21 0.10 0.00 2.80 0.00 0.00 24.70 0.00
0.00 0.00 72.40
Average: 22 0.80 0.00 3.30 0.00 0.00 24.30 0.00
0.00 0.00 71.60
Average: 23 0.10 0.00 1.80 0.00 0.00 26.60 0.00
0.00 0.00 71.50
Average: 24 0.10 0.00 1.20 0.00 0.00 23.60 0.00
0.00 0.00 75.10
Average: 25 0.00 0.00 1.80 0.00 0.00 26.60 0.00
0.00 0.00 71.60
Average: 26 0.00 0.00 1.50 0.00 0.00 26.70 0.00
0.00 0.00 71.80
Average: 27 0.10 0.00 0.70 0.00 0.00 26.70 0.00
0.00 0.00 72.50
Average: 28 0.70 0.00 0.30 0.00 0.00 0.00 0.00
0.00 0.00 99.00
Average: 29 0.20 0.00 1.50 0.00 0.00 0.00 0.00
0.00 0.00 98.30
Average: 30 0.10 0.00 0.60 0.00 0.00 0.00 0.00
0.00 0.00 99.30
Average: 31 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 32 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 33 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 34 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 35 0.10 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 99.90
Average: 36 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 37 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 38 0.00 0.00 2.80 0.00 0.00 0.00 0.00
0.00 0.00 97.20
Average: 39 0.00 0.00 7.40 0.00 0.00 0.00 0.00
0.00 0.00 92.60
Average: 40 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 41 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 100.00
Average: 42 0.00 0.00 2.10 0.00 0.00 28.40 0.00
0.00 0.00 69.50
Average: 43 0.00 0.00 1.60 0.00 0.00 25.00 0.00
0.00 0.00 73.40
Average: 44 0.10 0.00 1.60 0.00 0.00 23.90 0.00
0.00 0.00 74.40
Average: 45 0.00 0.00 1.60 0.00 0.00 21.00 0.00
0.00 0.00 77.40
Average: 46 0.00 0.00 2.20 0.00 0.00 28.00 0.00
0.00 0.00 69.80
Average: 47 0.00 0.00 2.80 0.00 0.00 20.30 0.00
0.00 0.00 76.90
Average: 48 0.00 0.00 2.50 0.00 0.00 21.60 0.00
0.00 0.00 75.90
Average: 49 0.00 0.00 0.80 0.00 0.00 22.50 0.00
0.00 0.00 76.70
Average: 50 0.40 0.00 3.00 0.00 0.00 23.50 0.00
0.00 0.00 73.10
Average: 51 0.60 0.00 2.50 0.00 0.00 25.00 0.00
0.00 0.00 71.90
Average: 52 0.10 0.00 1.30 0.00 0.00 20.70 0.00
0.00 0.00 77.90
Average: 53 0.00 0.00 2.20 0.00 0.00 22.80 0.00
0.00 0.00 75.00
Average: 54 0.00 0.00 1.40 0.00 0.00 20.80 0.00
0.00 0.00 77.80
Average: 55 0.00 0.00 2.10 0.00 0.00 21.30 0.00
0.00 0.00 76.60
^ permalink raw reply
* [PATCH net-next v2] PCI: add USR vendor id and use it in r8169 and w6692 driver
From: Heiner Kallweit @ 2018-11-11 10:50 UTC (permalink / raw)
To: Bjorn Helgaas, David Miller, Karsten Keil
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <9af6abf5-ba01-155f-17d1-ca4b71b74fa6@gmail.com>
The PCI vendor id of U.S. Robotics isn't defined in pci_ids.h so far,
only ISDN driver w6692 has a private definition. Move the definition
to pci_ids.h and use it also in the r8169 driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- The original patch caused a build failure in w6692 driver because
it broke the private PCI device id definition.
I hope it's ok to submit this through the netdev tree.
---
drivers/isdn/hardware/mISDN/w6692.c | 5 -----
drivers/net/ethernet/realtek/r8169.c | 2 +-
include/linux/pci_ids.h | 4 ++++
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/w6692.c b/drivers/isdn/hardware/mISDN/w6692.c
index 5acf6ab67..f6b4f4f11 100644
--- a/drivers/isdn/hardware/mISDN/w6692.c
+++ b/drivers/isdn/hardware/mISDN/w6692.c
@@ -52,11 +52,6 @@ static const struct w6692map w6692_map[] =
{W6692_USR, "USR W6692"}
};
-#ifndef PCI_VENDOR_ID_USR
-#define PCI_VENDOR_ID_USR 0x16ec
-#define PCI_DEVICE_ID_USR_6692 0x3409
-#endif
-
struct w6692_ch {
struct bchannel bch;
u32 addr;
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 1fd01688d..366a690eb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -224,7 +224,7 @@ static const struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4302), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_AT, 0xc107), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_USR, 0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS, 0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
{ 0x0001, 0x8168,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 69f0abe1b..1fac231fe 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2359,6 +2359,10 @@
#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_VENDOR_ID_USR 0x16ec
+#define PCI_DEVICE_ID_USR_997902 0x0116
+#define PCI_DEVICE_ID_USR_6692 0x3409
+
#define PCI_VENDOR_ID_VITESSE 0x1725
#define PCI_DEVICE_ID_VITESSE_VSC7174 0x7174
--
2.19.1
^ permalink raw reply related
* Re: [PATCH iproute2] testsuite: ss: Fix spacing in expected output for ssfilter.t
From: Stefano Brivio @ 2018-11-11 11:50 UTC (permalink / raw)
To: Phil Sutter; +Cc: Stephen Hemminger, Yoann P., netdev
In-Reply-To: <20181110214844.GL6440@orbyte.nwl.cc>
Hi Phil,
On Sat, 10 Nov 2018 22:48:44 +0100
Phil Sutter <phil@nwl.cc> wrote:
> On Sat, Nov 10, 2018 at 10:21:59AM +0100, Stefano Brivio wrote:
>
> > @@ -12,37 +12,37 @@ export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
> > ts_log "[Testing ssfilter]"
> >
> > ts_ss "$0" "Match dport = 22" -Htna dport = 22
> > -test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> > +test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
>
> How about using a regular expression ('test_on' calls grep with '-E')?
> E.g. this instead of the above:
>
> | test_on "ESTAB *0 *0 *10.0.0.1:36266 *10.0.0.1:22"
I also thought about something similar (perhaps uglier: piping the
output through tr -s ' ' in ts_ss()).
But then I thought we might like to use this test to also check that we
don't accidentally modify spacing, so I'd rather leave it as it is,
with this patch on top.
--
Stefano
^ permalink raw reply
* Re: [PATCH iproute2] testsuite: ss: Fix spacing in expected output for ssfilter.t
From: Phil Sutter @ 2018-11-11 12:12 UTC (permalink / raw)
To: Stefano Brivio; +Cc: Stephen Hemminger, Yoann P., netdev
In-Reply-To: <20181111125039.639dd608@redhat.com>
Hi Stefano,
On Sun, Nov 11, 2018 at 12:50:39PM +0100, Stefano Brivio wrote:
> On Sat, 10 Nov 2018 22:48:44 +0100
> Phil Sutter <phil@nwl.cc> wrote:
>
> > On Sat, Nov 10, 2018 at 10:21:59AM +0100, Stefano Brivio wrote:
> >
> > > @@ -12,37 +12,37 @@ export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
> > > ts_log "[Testing ssfilter]"
> > >
> > > ts_ss "$0" "Match dport = 22" -Htna dport = 22
> > > -test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> > > +test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> >
> > How about using a regular expression ('test_on' calls grep with '-E')?
> > E.g. this instead of the above:
> >
> > | test_on "ESTAB *0 *0 *10.0.0.1:36266 *10.0.0.1:22"
>
> I also thought about something similar (perhaps uglier: piping the
> output through tr -s ' ' in ts_ss()).
>
> But then I thought we might like to use this test to also check that we
> don't accidentally modify spacing, so I'd rather leave it as it is,
> with this patch on top.
Fair enough, no objections from my side.
Thanks, Phil
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-11-11 22:26 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
One last pull request before heading to Vancouver for LPC, here we have:
1) Don't forget to free VSI contexts during ice driver unload, from
Victor Raj.
2) Don't forget napi delete calls during device remove in ice driver,
from Dave Ertman.
3) Don't request VLAN tag insertion of ibmvnic device when SKB doesn't
have VLAN tags at all.
4) IPV4 frag handling code has to accomodate the situation where two
threads try to insert the same fragment into the hash table at the
same time. From Eric Dumazet.
5) Relatedly, don't flow separate on protocol ports for fragmented
frames, also from Eric Dumazet.
6) Memory leaks in qed driver, from Denis Bolotin.
7) Correct valid MTU range in smsc95xx driver, from Stefan Wahren.
8) Validate cls_flower nested policies properly, from Jakub Kicinski.
9) Clearing of stats counters in mc88e6xxx driver doesn't retain
important bits in the G1_STATS_OP register causing the chip to
hang. Fix from Andrew Lunn.
Please pull, thanks a lot!
The following changes since commit 8053e5b93eca9b011f7b79bb019bf1eeaaf96c4b:
Merge tag 'trace-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2018-11-06 08:12:10 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 7236ead1b14923f3ba35cd29cce13246be83f451:
act_mirred: clear skb->tstamp on redirect (2018-11-11 10:21:31 -0800)
----------------------------------------------------------------
Akeem G Abodunrin (1):
ice: Fix dead device link issue with flow control
Alexandre Belloni (1):
net: mvneta: correct typo
Andrew Lunn (1):
net: dsa: mv88e6xxx: Fix clearing of stats counters
Anirudh Venkataramanan (4):
ice: Set carrier state and start/stop queues in rebuild
ice: Check for reset in progress during remove
ice: Remove duplicate addition of VLANs in replay path
ice: Fix typo in error message
Brett Creeley (2):
ice: Fix tx_timeout in PF driver
ice: Fix the bytecount sent to netdev_tx_sent_queue
Chinh T Cao (1):
ice: Change req_speeds to be u16
Dave Ertman (1):
ice: Fix napi delete calls for remove
David S. Miller (4):
Merge branch '100GbE' of git://git.kernel.org/.../jkirsher/net-queue
Merge branch 'FDDI-defza-Fix-a-bunch-of-small-issues'
Merge branch 'qed-Slowpath-Queue-bug-fixes'
Merge branch 'aquantia-fixes'
Denis Bolotin (3):
qed: Fix memory/entry leak in qed_init_sp_request()
qed: Fix blocking/unlimited SPQ entries leak
qed: Fix SPQ entries not returned to pool in error flows
Dmitry Bogdanov (3):
net: aquantia: fix potential IOMMU fault after driver unbind
net: aquantia: invalid checksumm offload implementation
net: aquantia: allow rx checksum offload configuration
Eric Dumazet (2):
inet: frags: better deal with smp races
act_mirred: clear skb->tstamp on redirect
Huazhong Tan (1):
net: hns3: bugfix for not checking return value
Igor Russkikh (2):
net: aquantia: synchronized flow control between mac/phy
net: aquantia: fixed enable unicast on 32 macvlan
Jacob Keller (2):
i40e: restore NETIF_F_GSO_IPXIP[46] to netdev features
i40e: enable NETIF_F_NTUPLE and NETIF_F_HW_TC at driver load
Jakub Kicinski (1):
net: sched: cls_flower: validate nested enc_opts_policy to avoid warning
Jon Maloy (1):
tipc: fix link re-establish failure
Maciej W. Rozycki (4):
FDDI: defza: Fix SPDX annotation
FDDI: defza: Add missing comment closing
FDDI: defza: Move SMT Tx data buffer declaration next to its skb
FDDI: defza: Make the driver version string constant
Md Fahad Iqbal Polash (1):
ice: Fix flags for port VLAN
Michał Mirosław (2):
ibmvnic: fix accelerated VLAN handling
qlcnic: remove assumption that vlan_tci != 0
Miroslav Lichvar (1):
igb: shorten maximum PHC timecounter update interval
Sagiv Ozeri (1):
qed: Fix potential memory corruption
Stefan Wahren (1):
net: smsc95xx: Fix MTU range
Subash Abhinov Kasiviswanathan (1):
net: qualcomm: rmnet: Fix incorrect assignment of real_dev
Tao Ren (1):
net: phy: Allow BCM54616S PHY to setup internal TX/RX clock delay
Thor Thayer (1):
net: stmmac: Fix RX packet size > 8191
Victor Raj (1):
ice: Free VSI contexts during for unload
배석진 (1):
flow_dissector: do not dissect l4 ports for fragments
drivers/net/dsa/mv88e6xxx/global1.c | 2 ++
drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c | 8 ++++----
drivers/net/ethernet/aquantia/atlantic/aq_hw.h | 6 ++++++
drivers/net/ethernet/aquantia/atlantic/aq_main.c | 10 ++++++++--
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 18 +++++++++++++++---
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 2 +-
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 35 +++++++++++++++++++++++------------
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 61 ++++++++++++++++++++++++++++++++++++++-----------------------
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c | 8 ++++++++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h | 3 +++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h | 18 ++++++++++++++++++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c | 21 +++++++++++++++++++++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++-
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +++++---
drivers/net/ethernet/intel/ice/ice.h | 4 +++-
drivers/net/ethernet/intel/ice/ice_common.c | 3 +++
drivers/net/ethernet/intel/ice/ice_ethtool.c | 7 ++++++-
drivers/net/ethernet/intel/ice/ice_hw_autogen.h | 2 ++
drivers/net/ethernet/intel/ice/ice_lib.c | 3 ++-
drivers/net/ethernet/intel/ice/ice_main.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------
drivers/net/ethernet/intel/ice/ice_switch.c | 12 ++++++++++++
drivers/net/ethernet/intel/ice/ice_switch.h | 2 ++
drivers/net/ethernet/intel/ice/ice_txrx.c | 11 ++++++-----
drivers/net/ethernet/intel/ice/ice_txrx.h | 17 +++++++++++++++--
drivers/net/ethernet/intel/ice/ice_type.h | 2 +-
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 4 +---
drivers/net/ethernet/intel/igb/igb_ptp.c | 12 +++++++-----
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_fcoe.c | 11 ++++++++---
drivers/net/ethernet/qlogic/qed/qed_iscsi.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_l2.c | 12 ++++++++----
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_roce.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_sp.h | 14 ++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 22 ++++++++++++++++++++--
drivers/net/ethernet/qlogic/qed/qed_spq.c | 69 +++++++++++++++++++++++++++++++++++----------------------------------
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 1 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 8 +++++---
drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c | 6 +++---
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/descs_com.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 2 +-
drivers/net/fddi/defza.c | 7 ++++---
drivers/net/fddi/defza.h | 3 ++-
drivers/net/phy/broadcom.c | 18 ++++++++++++++++--
drivers/net/usb/smsc95xx.c | 2 ++
net/core/flow_dissector.c | 4 ++--
net/ipv4/inet_fragment.c | 29 +++++++++++++++--------------
net/sched/act_mirred.c | 3 ++-
net/sched/cls_flower.c | 14 +++++++++++++-
net/sched/sch_netem.c | 9 ---------
net/tipc/link.c | 11 +++++++----
54 files changed, 430 insertions(+), 199 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] mm/page_alloc: free order-0 pages through PCP in page_frag_free()
From: Alexander Duyck @ 2018-11-11 23:05 UTC (permalink / raw)
To: Paweł Staszewski
Cc: aaron.lu, linux-mm, LKML, Netdev, Andrew Morton,
Jesper Dangaard Brouer, Eric Dumazet, Tariq Toukan,
ilias.apalodimas, yoel, Mel Gorman, Saeed Mahameed, Michal Hocko,
Vlastimil Babka, dave.hansen
In-Reply-To: <b8b1fbb7-9139-9455-69b8-8c1bed4f7c74@itcare.pl>
On Sat, Nov 10, 2018 at 3:54 PM Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>
>
>
> W dniu 05.11.2018 o 16:44, Alexander Duyck pisze:
> > On Mon, Nov 5, 2018 at 12:58 AM Aaron Lu <aaron.lu@intel.com> wrote:
> >> page_frag_free() calls __free_pages_ok() to free the page back to
> >> Buddy. This is OK for high order page, but for order-0 pages, it
> >> misses the optimization opportunity of using Per-Cpu-Pages and can
> >> cause zone lock contention when called frequently.
> >>
> >> Paweł Staszewski recently shared his result of 'how Linux kernel
> >> handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer
> >> found the lock contention comes from page allocator:
> >>
> >> mlx5e_poll_tx_cq
> >> |
> >> --16.34%--napi_consume_skb
> >> |
> >> |--12.65%--__free_pages_ok
> >> | |
> >> | --11.86%--free_one_page
> >> | |
> >> | |--10.10%--queued_spin_lock_slowpath
> >> | |
> >> | --0.65%--_raw_spin_lock
> >> |
> >> |--1.55%--page_frag_free
> >> |
> >> --1.44%--skb_release_data
> >>
> >> Jesper explained how it happened: mlx5 driver RX-page recycle
> >> mechanism is not effective in this workload and pages have to go
> >> through the page allocator. The lock contention happens during
> >> mlx5 DMA TX completion cycle. And the page allocator cannot keep
> >> up at these speeds.[2]
> >>
> >> I thought that __free_pages_ok() are mostly freeing high order
> >> pages and thought this is an lock contention for high order pages
> >> but Jesper explained in detail that __free_pages_ok() here are
> >> actually freeing order-0 pages because mlx5 is using order-0 pages
> >> to satisfy its page pool allocation request.[3]
> >>
> >> The free path as pointed out by Jesper is:
> >> skb_free_head()
> >> -> skb_free_frag()
> >> -> skb_free_frag()
> >> -> page_frag_free()
> >> And the pages being freed on this path are order-0 pages.
> >>
> >> Fix this by doing similar things as in __page_frag_cache_drain() -
> >> send the being freed page to PCP if it's an order-0 page, or
> >> directly to Buddy if it is a high order page.
> >>
> >> With this change, Paweł hasn't noticed lock contention yet in
> >> his workload and Jesper has noticed a 7% performance improvement
> >> using a micro benchmark and lock contention is gone.
> >>
> >> [1]: https://www.spinics.net/lists/netdev/msg531362.html
> >> [2]: https://www.spinics.net/lists/netdev/msg531421.html
> >> [3]: https://www.spinics.net/lists/netdev/msg531556.html
> >> Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
> >> Analysed-by: Jesper Dangaard Brouer <brouer@redhat.com>
> >> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> >> ---
> >> mm/page_alloc.c | 10 ++++++++--
> >> 1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >> index ae31839874b8..91a9a6af41a2 100644
> >> --- a/mm/page_alloc.c
> >> +++ b/mm/page_alloc.c
> >> @@ -4555,8 +4555,14 @@ void page_frag_free(void *addr)
> >> {
> >> struct page *page = virt_to_head_page(addr);
> >>
> >> - if (unlikely(put_page_testzero(page)))
> >> - __free_pages_ok(page, compound_order(page));
> >> + if (unlikely(put_page_testzero(page))) {
> >> + unsigned int order = compound_order(page);
> >> +
> >> + if (order == 0)
> >> + free_unref_page(page);
> >> + else
> >> + __free_pages_ok(page, order);
> >> + }
> >> }
> >> EXPORT_SYMBOL(page_frag_free);
> >>
> > One thing I would suggest for Pawel to try would be to reduce the Tx
> > qdisc size on his transmitting interfaces, Reduce the Tx ring size,
> > and possibly increase the Tx interrupt rate. Ideally we shouldn't have
> > too many packets in-flight and I suspect that is the issue that Pawel
> > is seeing that is leading to the page pool allocator freeing up the
> > memory. I know we like to try to batch things but the issue is
> > processing too many Tx buffers in one batch leads to us eating up too
> > much memory and causing evictions from the cache. Ideally the Rx and
> > Tx rings and queues should be sized as small as possible while still
> > allowing us to process up to our NAPI budget. Usually I run things
> > with a 128 Rx / 128 Tx setup and then reduce the Tx queue length so we
> > don't have more buffers stored there than we can place in the Tx ring.
> > Then we can avoid the extra thrash of having to pull/push memory into
> > and out of the freelists. Essentially the issue here ends up being
> > another form of buffer bloat.
> Thanks Aleksandar - yes it can be - but in my scenario setting RX buffer
> <4096 producing more interface rx drops - and no_rx_buffer on network
> controller that is receiving more packets
> So i need to stick with 3000-4000 on RX - and yes i was trying to lower
> the TX buff on connectx4 - but that changed nothing before Aaron patch
>
> After Aaron patch - decreasing TX buffer influencing total bandwidth
> that can be handled by the router/server
> Dono why before this patch there was no difference there no matter what
> i set there there was always page_alloc/slowpath on top in perf
>
>
> Currently testing RX4096/TX256 - this helps with bandwidth like +10%
> more bandwidth with less interrupts...
The problem is if you are going for less interrupts you are setting
yourself up for buffer bloat. Basically you are going to use much more
cache and much more memory then you actually need and if things are
properly configured NAPI should take care of the interrupts anyway
since under maximum load you shouldn't stop polling normally.
One issue I have seen is people delay interrupts for as long as
possible which isn't really a good thing since most network
controllers will use NAPI which will disable the interrupts and leave
them disabled whenever the system is under heavy stress so you should
be able to get the maximum performance by configuring an adapter with
small ring sizes and for high interrupt rates.
It is easiest to think of it this way. Your total packet rate is equal
to your interrupt rate times the number of buffers you will store in
the ring. So if you have some fixed rate "X" for packets and an
interrupt rate of "i" then your optimal ring size should be "X/i". So
if you lower the interrupt rate you end up hurting the throughput
unless you increase the buffer size. However at a certain point the
buffer size starts becoming an issue. For example with UDP flows I
often see massive packet drops if you tune the interrupt rate too low
and then put the system under heavy stress.
- Alex
^ permalink raw reply
* Re: [GIT] Networking
From: pr-tracker-bot @ 2018-11-11 23:15 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20181111.142649.1250091930241970662.davem@davemloft.net>
The pull request you sent on Sun, 11 Nov 2018 14:26:49 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7a3765ed66d187071bbf56a8212f5d2bc2d2e2cc
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [PATCH net-next 0/3] tcp: tso defer improvements
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
This series makes tcp_tso_should_defer() a bit smarter :
1) MSG_EOR gives a hint to TCP to not defer some skbs
2) Second patch takes into account that head tstamp
can be in the future.
3) Third patch uses existing high resolution state variables
to have a more precise heuristic.
Eric Dumazet (3):
tcp: do not try to defer skbs with eor mark (MSG_EOR)
tcp: refine tcp_tso_should_defer() after EDT adoption
tcp: get rid of tcp_tso_should_defer() dependency on HZ/jiffies
net/ipv4/tcp_output.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply
* [PATCH net-next 1/3] tcp: do not try to defer skbs with eor mark (MSG_EOR)
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
Applications using MSG_EOR are giving a strong hint to TCP stack :
Subsequent sendmsg() can not append more bytes to skbs having
the EOR mark.
Do not try to TSO defer suchs skbs, there is really no hope.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 9c34b97d365d719ff76250bc9fe7fa20495a3ed2..35feadf480300cd061411d65257f06ee658daa3c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1944,6 +1944,10 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
if ((skb != tcp_write_queue_tail(sk)) && (limit >= skb->len))
goto send_now;
+ /* If this packet won't get more data, do not wait. */
+ if (TCP_SKB_CB(skb)->eor)
+ goto send_now;
+
win_divisor = READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_tso_win_divisor);
if (win_divisor) {
u32 chunk = min(tp->snd_wnd, tp->snd_cwnd * tp->mss_cache);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* [PATCH net-next 2/3] tcp: refine tcp_tso_should_defer() after EDT adoption
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
tcp_tso_should_defer() last step tries to check if the probable
next ACK packet is coming in less than half rtt.
Problem is that the head->tstamp might be in the future,
so we need to use signed arithmetics to avoid overflows.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 35feadf480300cd061411d65257f06ee658daa3c..78a56cef7e397c65ad18897d550f3800e8fe8f41 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1907,10 +1907,11 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
bool *is_cwnd_limited, u32 max_segs)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
- u32 age, send_win, cong_win, limit, in_flight;
+ u32 send_win, cong_win, limit, in_flight;
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *head;
int win_divisor;
+ s64 delta;
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
goto send_now;
@@ -1972,9 +1973,9 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
head = tcp_rtx_queue_head(sk);
if (!head)
goto send_now;
- age = tcp_stamp_us_delta(tp->tcp_mstamp, tcp_skb_timestamp_us(head));
+ delta = tp->tcp_clock_cache - head->tstamp;
/* If next ACK is likely to come too late (half srtt), do not defer */
- if (age < (tp->srtt_us >> 4))
+ if ((s64)(delta - (u64)NSEC_PER_USEC * (tp->srtt_us >> 4)) < 0)
goto send_now;
/* Ok, it looks like it is advisable to defer. */
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* [PATCH net-next 3/3] tcp: get rid of tcp_tso_should_defer() dependency on HZ/jiffies
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
tcp_tso_should_defer() first heuristic is to not defer
if last send is "old enough".
Its current implementation uses jiffies and its low granularity.
TSO autodefer performance should not rely on kernel HZ :/
After EDT conversion, we have state variables in nanoseconds that
can allow us to properly implement the heuristic.
This patch increases TSO chunk sizes on medium rate flows,
especially when receivers do not use GRO or similar aggregation.
It also reduces bursts for HZ=100 or HZ=250 kernels, making TCP
behavior more uniform.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 78a56cef7e397c65ad18897d550f3800e8fe8f41..75dcf4daca724a6819e9ecc9d0f3e6dc6df72e9b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1920,9 +1920,12 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
goto send_now;
/* Avoid bursty behavior by allowing defer
- * only if the last write was recent.
+ * only if the last write was recent (1 ms).
+ * Note that tp->tcp_wstamp_ns can be in the future if we have
+ * packets waiting in a qdisc or device for EDT delivery.
*/
- if ((s32)(tcp_jiffies32 - tp->lsndtime) > 0)
+ delta = tp->tcp_clock_cache - tp->tcp_wstamp_ns - NSEC_PER_MSEC;
+ if (delta > 0)
goto send_now;
in_flight = tcp_packets_in_flight(tp);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* Re: [PATCH net-next v3 6/6] net/ncsi: Configure multi-package, multi-channel modes with failover
From: Samuel Mendoza-Jonas @ 2018-11-12 0:38 UTC (permalink / raw)
To: Justin.Lee1, netdev; +Cc: davem, linux-kernel, openbmc
In-Reply-To: <b2c6aea94f1648648dd349d23ce61bf6@AUSX13MPS302.AMER.DELL.COM>
On Fri, 2018-11-09 at 21:58 +0000, Justin.Lee1@Dell.com wrote:
> Hi Samuel,
>
> After running more testing, I notice that the extra patch causing failover function
> to fail. Also, occasionally, I will see two channels having TX enabled if I
> send netlink command back-to-back.
>
> cat /sys/kernel/debug/ncsi_protocol/ncsi_device_
> IFIDX IFNAME NAME PID CID RX TX MP MC WP WC PC CS PS LS RU CR NQ HA
> =====================================================================
> 2 eth2 ncsi0 000 000 1 1 1 1 1 1 1 2 1 1 1 1 0 1
> 2 eth2 ncsi1 000 001 1 1 1 1 1 1 0 2 1 1 1 1 0 1
> 2 eth2 ncsi2 001 000 0 0 1 1 0 0 0 1 0 1 1 1 0 1
> 2 eth2 ncsi3 001 001 0 0 1 1 0 0 0 1 0 1 1 1 0 1
> =====================================================================
> MP: Multi-mode Package WP: Whitelist Package
> MC: Multi-mode Channel WC: Whitelist Channel
> PC: Primary Channel CS: Channel State IA/A/IV 1/2/3
> PS: Poll Status LS: Link Status
> RU: Running CR: Carrier OK
> NQ: Queue Stopped HA: Hardware Arbitration
>
> Thanks,
> Justin
>
>
> > From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
> > From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
> > Date: Fri, 9 Nov 2018 13:11:03 +1100
> > Subject: [PATCH] net/ncsi: Reset state fixes, single-channel LSC
> >
> > ---
> > net/ncsi/ncsi-aen.c | 8 +++++---
> > net/ncsi/ncsi-manage.c | 19 +++++++++++++++----
> > 2 files changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
> > index 39c2e9eea2ba..034cb1dc5566 100644
> > --- a/net/ncsi/ncsi-aen.c
> > +++ b/net/ncsi/ncsi-aen.c
> > @@ -93,14 +93,16 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
> > if ((had_link == has_link) || chained)
> > return 0;
> >
> > - if (!ndp->multi_package && !nc->package->multi_channel) {
> > - if (had_link)
> > - ndp->flags |= NCSI_DEV_RESHUFFLE;
> > + if (!ndp->multi_package && !nc->package->multi_channel && had_link) {
> > + ndp->flags |= NCSI_DEV_RESHUFFLE;
> > ncsi_stop_channel_monitor(nc);
> > spin_lock_irqsave(&ndp->lock, flags);
> > list_add_tail_rcu(&nc->link, &ndp->channel_queue);
> > spin_unlock_irqrestore(&ndp->lock, flags);
> > return ncsi_process_next_channel(ndp);
> > + } else {
> > + /* Configured channel came up */
> > + return 0;
>
> It is always going to else statement if multi_package and/or mutlit_channel is enabled.
>
> npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_aen_handler_lsc() - pkg 0 ch 0 state down
> npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_aen_handler_lsc() - had_link 1, has_link 0, chained 0
>
> These codes have no chance to run.
> if (had_link) {
> ncm = &nc->modes[NCSI_MODE_TX_ENABLE];
> if (ncsi_channel_is_last(ndp, nc)) {
> /* No channels left, reconfigure */
> return ncsi_reset_dev(&ndp->ndev);
> } else if (ncm->enable) {
> /* Need to failover Tx channel */
> ncsi_update_tx_channel(ndp, nc->package, nc, NULL);
> }
>
> > }
> >
Oops, wrote that patch a little fast it seems. This may also affect the
double-Tx above since ncsi_update_tx_channel() won't be reached.
I've attached a fixed up version below.
For the failover issue you're seeing in your previous email the issue is
likely in the ncsi_dev_state_suspend_gls state. This should send a GLS
command to all available channels, but it only does it for the current
package. Since not all packages are necessarily enabled in single-channel
mode I'll need to have a think about the neatest way to handle that, but
it's a separate issue from this patch.
Cheers,
Sam
>From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Date: Fri, 9 Nov 2018 13:11:03 +1100
Subject: [PATCH] net/ncsi: Reset state fixes, single-channel LSC
---
net/ncsi/ncsi-aen.c | 16 ++++++++++------
net/ncsi/ncsi-manage.c | 19 +++++++++++++++----
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
index 39c2e9eea2ba..76559d0eeea8 100644
--- a/net/ncsi/ncsi-aen.c
+++ b/net/ncsi/ncsi-aen.c
@@ -94,13 +94,17 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
return 0;
if (!ndp->multi_package && !nc->package->multi_channel) {
- if (had_link)
+ if (had_link) {
ndp->flags |= NCSI_DEV_RESHUFFLE;
- ncsi_stop_channel_monitor(nc);
- spin_lock_irqsave(&ndp->lock, flags);
- list_add_tail_rcu(&nc->link, &ndp->channel_queue);
- spin_unlock_irqrestore(&ndp->lock, flags);
- return ncsi_process_next_channel(ndp);
+ ncsi_stop_channel_monitor(nc);
+ spin_lock_irqsave(&ndp->lock, flags);
+ list_add_tail_rcu(&nc->link, &ndp->channel_queue);
+ spin_unlock_irqrestore(&ndp->lock, flags);
+ return ncsi_process_next_channel(ndp);
+ } else {
+ /* Configured channel came up */
+ return 0;
+ }
}
if (had_link) {
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index fa3c2144f5ba..92e59f07f9a7 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -1063,17 +1063,17 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp)
case ncsi_dev_state_config_done:
netdev_dbg(ndp->ndev.dev, "NCSI: channel %u config done\n",
nc->id);
+ spin_lock_irqsave(&nc->lock, flags);
+ nc->state = NCSI_CHANNEL_ACTIVE;
+
if (ndp->flags & NCSI_DEV_RESET) {
/* A reset event happened during config, start it now */
- spin_lock_irqsave(&nc->lock, flags);
nc->reconfigure_needed = false;
spin_unlock_irqrestore(&nc->lock, flags);
- nd->state = ncsi_dev_state_functional;
ncsi_reset_dev(nd);
break;
}
- spin_lock_irqsave(&nc->lock, flags);
if (nc->reconfigure_needed) {
/* This channel's configuration has been updated
* part-way during the config state - start the
@@ -1092,7 +1092,6 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp)
break;
}
- nc->state = NCSI_CHANNEL_ACTIVE;
if (nc->modes[NCSI_MODE_LINK].data[2] & 0x1) {
hot_nc = nc;
} else {
@@ -1803,6 +1802,18 @@ int ncsi_reset_dev(struct ncsi_dev *nd)
spin_unlock_irqrestore(&ndp->lock, flags);
return 0;
}
+ } else {
+ switch (nd->state) {
+ case ncsi_dev_state_suspend_done:
+ case ncsi_dev_state_config_done:
+ case ncsi_dev_state_functional:
+ /* Ok */
+ break;
+ default:
+ /* Current reset operation happening */
+ spin_unlock_irqrestore(&ndp->lock, flags);
+ return 0;
+ }
}
if (!list_empty(&ndp->channel_queue)) {
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 1/2] mm/page_alloc: free order-0 pages through PCP in page_frag_free()
From: Paweł Staszewski @ 2018-11-12 0:39 UTC (permalink / raw)
To: Alexander Duyck
Cc: aaron.lu, linux-mm, LKML, Netdev, Andrew Morton,
Jesper Dangaard Brouer, Eric Dumazet, Tariq Toukan,
ilias.apalodimas, yoel, Mel Gorman, Saeed Mahameed, Michal Hocko,
Vlastimil Babka, dave.hansen
In-Reply-To: <CAKgT0UdhcXF-ohPHPbg8onRjFabEMnbpXGmLm-27skCNzGKOgw@mail.gmail.com>
W dniu 12.11.2018 o 00:05, Alexander Duyck pisze:
> On Sat, Nov 10, 2018 at 3:54 PM Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>>
>>
>> W dniu 05.11.2018 o 16:44, Alexander Duyck pisze:
>>> On Mon, Nov 5, 2018 at 12:58 AM Aaron Lu <aaron.lu@intel.com> wrote:
>>>> page_frag_free() calls __free_pages_ok() to free the page back to
>>>> Buddy. This is OK for high order page, but for order-0 pages, it
>>>> misses the optimization opportunity of using Per-Cpu-Pages and can
>>>> cause zone lock contention when called frequently.
>>>>
>>>> Paweł Staszewski recently shared his result of 'how Linux kernel
>>>> handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer
>>>> found the lock contention comes from page allocator:
>>>>
>>>> mlx5e_poll_tx_cq
>>>> |
>>>> --16.34%--napi_consume_skb
>>>> |
>>>> |--12.65%--__free_pages_ok
>>>> | |
>>>> | --11.86%--free_one_page
>>>> | |
>>>> | |--10.10%--queued_spin_lock_slowpath
>>>> | |
>>>> | --0.65%--_raw_spin_lock
>>>> |
>>>> |--1.55%--page_frag_free
>>>> |
>>>> --1.44%--skb_release_data
>>>>
>>>> Jesper explained how it happened: mlx5 driver RX-page recycle
>>>> mechanism is not effective in this workload and pages have to go
>>>> through the page allocator. The lock contention happens during
>>>> mlx5 DMA TX completion cycle. And the page allocator cannot keep
>>>> up at these speeds.[2]
>>>>
>>>> I thought that __free_pages_ok() are mostly freeing high order
>>>> pages and thought this is an lock contention for high order pages
>>>> but Jesper explained in detail that __free_pages_ok() here are
>>>> actually freeing order-0 pages because mlx5 is using order-0 pages
>>>> to satisfy its page pool allocation request.[3]
>>>>
>>>> The free path as pointed out by Jesper is:
>>>> skb_free_head()
>>>> -> skb_free_frag()
>>>> -> skb_free_frag()
>>>> -> page_frag_free()
>>>> And the pages being freed on this path are order-0 pages.
>>>>
>>>> Fix this by doing similar things as in __page_frag_cache_drain() -
>>>> send the being freed page to PCP if it's an order-0 page, or
>>>> directly to Buddy if it is a high order page.
>>>>
>>>> With this change, Paweł hasn't noticed lock contention yet in
>>>> his workload and Jesper has noticed a 7% performance improvement
>>>> using a micro benchmark and lock contention is gone.
>>>>
>>>> [1]: https://www.spinics.net/lists/netdev/msg531362.html
>>>> [2]: https://www.spinics.net/lists/netdev/msg531421.html
>>>> [3]: https://www.spinics.net/lists/netdev/msg531556.html
>>>> Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
>>>> Analysed-by: Jesper Dangaard Brouer <brouer@redhat.com>
>>>> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
>>>> ---
>>>> mm/page_alloc.c | 10 ++++++++--
>>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>> index ae31839874b8..91a9a6af41a2 100644
>>>> --- a/mm/page_alloc.c
>>>> +++ b/mm/page_alloc.c
>>>> @@ -4555,8 +4555,14 @@ void page_frag_free(void *addr)
>>>> {
>>>> struct page *page = virt_to_head_page(addr);
>>>>
>>>> - if (unlikely(put_page_testzero(page)))
>>>> - __free_pages_ok(page, compound_order(page));
>>>> + if (unlikely(put_page_testzero(page))) {
>>>> + unsigned int order = compound_order(page);
>>>> +
>>>> + if (order == 0)
>>>> + free_unref_page(page);
>>>> + else
>>>> + __free_pages_ok(page, order);
>>>> + }
>>>> }
>>>> EXPORT_SYMBOL(page_frag_free);
>>>>
>>> One thing I would suggest for Pawel to try would be to reduce the Tx
>>> qdisc size on his transmitting interfaces, Reduce the Tx ring size,
>>> and possibly increase the Tx interrupt rate. Ideally we shouldn't have
>>> too many packets in-flight and I suspect that is the issue that Pawel
>>> is seeing that is leading to the page pool allocator freeing up the
>>> memory. I know we like to try to batch things but the issue is
>>> processing too many Tx buffers in one batch leads to us eating up too
>>> much memory and causing evictions from the cache. Ideally the Rx and
>>> Tx rings and queues should be sized as small as possible while still
>>> allowing us to process up to our NAPI budget. Usually I run things
>>> with a 128 Rx / 128 Tx setup and then reduce the Tx queue length so we
>>> don't have more buffers stored there than we can place in the Tx ring.
>>> Then we can avoid the extra thrash of having to pull/push memory into
>>> and out of the freelists. Essentially the issue here ends up being
>>> another form of buffer bloat.
>> Thanks Aleksandar - yes it can be - but in my scenario setting RX buffer
>> <4096 producing more interface rx drops - and no_rx_buffer on network
>> controller that is receiving more packets
>> So i need to stick with 3000-4000 on RX - and yes i was trying to lower
>> the TX buff on connectx4 - but that changed nothing before Aaron patch
>>
>> After Aaron patch - decreasing TX buffer influencing total bandwidth
>> that can be handled by the router/server
>> Dono why before this patch there was no difference there no matter what
>> i set there there was always page_alloc/slowpath on top in perf
>>
>>
>> Currently testing RX4096/TX256 - this helps with bandwidth like +10%
>> more bandwidth with less interrupts...
> The problem is if you are going for less interrupts you are setting
> yourself up for buffer bloat. Basically you are going to use much more
> cache and much more memory then you actually need and if things are
> properly configured NAPI should take care of the interrupts anyway
> since under maximum load you shouldn't stop polling normally.
Im trying to balance here - there is problem cause server is forwarding
all kingd of protocols packets/different size etc
The problem is im trying to go in high interrupt rate - but
Setting coalescence to adaptative for rx killing cpu's at 22Gbit/s RX
and 22Gbit with rly high interrupt rate
So adding a little more latency i can turn off adaptative rx and setup
rx-usecs from range 16-64 - and this gives me more or less interrupts -
but the problem is - always same bandwidth as maximum
>
> One issue I have seen is people delay interrupts for as long as
> possible which isn't really a good thing since most network
> controllers will use NAPI which will disable the interrupts and leave
> them disabled whenever the system is under heavy stress so you should
> be able to get the maximum performance by configuring an adapter with
> small ring sizes and for high interrupt rates.
Sure this is bad to setup rx-usec for high values - cause at some point
this will add high latency for packet traversing both sides - and start
to hurt buffers
But my problem is a little different now i have no problems with RX side
- cause i can setup anything like:
coalescence from 16 to 64
rx ring from 3000 to max 8192
And it does not change my max bw - only produces less or more interrupts.
So I start to change params for TX side - and for now i know that the
best for me is
coalescence adaptative on
TX buffer 128
This helps with max BW that for now is close to 70Gbit/s RX and 70Gbit
TX but after this change i have increasing DROPS on TX side for vlan
interfaces.
And only 50% cpu (max was 50% for 70Gbit/s)
> It is easiest to think of it this way. Your total packet rate is equal
> to your interrupt rate times the number of buffers you will store in
> the ring. So if you have some fixed rate "X" for packets and an
> interrupt rate of "i" then your optimal ring size should be "X/i". So
> if you lower the interrupt rate you end up hurting the throughput
> unless you increase the buffer size. However at a certain point the
> buffer size starts becoming an issue. For example with UDP flows I
> often see massive packet drops if you tune the interrupt rate too low
> and then put the system under heavy stress.
Yes - in normal life traffic - most of ddos'es are like this many pps
with small frames.
> - Alex
>
^ 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