* Re: [PATCH net-next 0/9] Use __vlan_hwaccel_*() helpers
From: mirq-linux @ 2018-11-11 16:16 UTC (permalink / raw)
To: Tariq Toukan
Cc: ajit.khaparde@broadcom.com, somnath.kotur@broadcom.com,
linux-rdma@vger.kernel.org, bridge@lists.linux-foundation.org,
coreteam@netfilter.org, kadlec@blackhole.kfki.hu,
kuznet@ms2.inr.ac.ru, pablo@netfilter.org, jiri@resnulli.us,
swise@chelsio.com, nikolay@cumulusnetworks.com,
roopa@cumulusnetworks.com, jhs@mojatatu.com,
sathya.perla@broadcom.com, xiyou.wangcong@gmail.com,
mlindner@marvell.com,
"sriharsha.basavapatna@broadcom.com"
In-Reply-To: <20181111161243.GA12849@qmqm.qmqm.pl>
On Sun, Nov 11, 2018 at 05:12:43PM +0100, mirq-linux@rere.qmqm.pl wrote:
> On Sun, Nov 11, 2018 at 03:26:29PM +0000, Tariq Toukan wrote:
> > On 09/11/2018 6:45 AM, David Miller wrote:
> > > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > Date: Fri, 09 Nov 2018 00:17:58 +0100
> > >> This series removes from networking core and driver code an assumption
> > >> about how VLAN tag presence is stored in an skb. This will allow to free
> > >> up overloading of VLAN.CFI bit to incidate tag's presence.
> > >
> > > This looks good, series applied.
> > >
> > > Thanks.
> > Hi Michal,
> >
> > We started seeing the compilation errors below, they look related to
> > this series.
>
> Do you have the previous series applied that introduced __vlan_hwaccel_clear_tag()?
> It was applied to net-next before I sent this series.
>
> I did a allmodconfig build of net-next and saw no failures (apart from
> OVS that is fixed already).
The prerequisite commit in net-next is:
7025abb2e447b ("Merge branch 'vlan-prepare-for-removal-of-VLAN_TAG_PRESENT'")
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [RFC PATCH 00/10] net: hns3: Adds support of debugfs to HNS3 driver
From: Andrew Lunn @ 2018-11-11 16:18 UTC (permalink / raw)
To: Salil Mehta
Cc: davem@davemloft.net, yuvalm@mellanox.com, leon@kernel.org,
Zhuangyuzeng (Yisen), lipeng (Y), mehta.salil@opnsrc.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org, Linuxarm
In-Reply-To: <F4CC6FACFEB3C54C9141D49AD221F7F93BF9FC72@FRAEML521-MBS.china.huawei.com>
> Agreed. But what about if we want to expose anything related to
> firmware to user-space using the debugfs, assuming we are presenting
> information in structured way and not as a black-box to some user-space
> application. Is it something which might be discouraged?
Hi Salil
Please take a look at devlink. Mellonex have been adding commands to
it for dumping firmware states.
Andrew
^ permalink raw reply
* RE: [RFC PATCH 07/10] net: hns3: Add checksum info query function
From: Salil Mehta @ 2018-11-11 16:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem@davemloft.net, yuvalm@mellanox.com, leon@kernel.org,
Zhuangyuzeng (Yisen), lipeng (Y), mehta.salil@opnsrc.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org, Linuxarm, Liuzhongzhu
In-Reply-To: <20181109225114.GF5259@lunn.ch>
> From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-
> owner@vger.kernel.org] On Behalf Of Andrew Lunn
> Sent: Friday, November 9, 2018 10:51 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: davem@davemloft.net; yuvalm@mellanox.com; leon@kernel.org;
> Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; lipeng (Y)
> <lipeng321@huawei.com>; mehta.salil@opnsrc.net; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-rdma@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; Liuzhongzhu <liuzhongzhu@huawei.com>
> Subject: Re: [RFC PATCH 07/10] net: hns3: Add checksum info query
> function
>
> On Fri, Nov 09, 2018 at 10:07:40PM +0000, Salil Mehta wrote:
> > From: liuzhongzhu <liuzhongzhu@huawei.com>
> >
> > This patch prints checksum config information
> > related to various layers of headers.
> >
> > debugfs command:
> > echo dump checksum > cmd
>
> How does the information here differ from ethtool -k
Sure, this should be enough. Will drop this patch.
Thanks
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/3] bpf: Allow narrow loads with offset > 0
From: Alexei Starovoitov @ 2018-11-11 6:39 UTC (permalink / raw)
To: Andrey Ignatov; +Cc: netdev, ast, daniel, yhs, kernel-team
In-Reply-To: <cover.1541916635.git.rdna@fb.com>
On Sat, Nov 10, 2018 at 10:15:12PM -0800, Andrey Ignatov wrote:
> This patch set adds support for narrow loads with offset > 0 to BPF
> verifier.
>
> Patch 1 provides more details and is the main patch in the set.
> Patches 2 and 3 add new test cases to test_verifier and test_sock_addr
> selftests.
>
> v1->v2:
> - fix -Wdeclaration-after-statement warning.
Applied, Thanks
^ permalink raw reply
* Re: net: ipv4: tcp_vegas
From: David Miller @ 2018-11-11 17:25 UTC (permalink / raw)
To: suraj1998; +Cc: netdev, linux-kernel
In-Reply-To: <1541956134-14029-1-git-send-email-suraj1998@gmail.com>
From: Suraj Singh <suraj1998@gmail.com>
Date: Sun, 11 Nov 2018 22:38:54 +0530
> I don't think you've been getting my emails because I've been sending them
> in response to the message-id of my patch.
I got your email, I'm just too busy to reply.
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] net: phy: replace PHY_HAS_INTERRUPT with a check for config_intr and ack_interrupt
From: David Miller @ 2018-11-11 17:38 UTC (permalink / raw)
To: hkallweit1
Cc: andrew, f.fainelli, netdev, bcm-kernel-feedback-list,
richardcochran, carlo, khilman, linux-kernel, linux-arm-kernel,
linux-amlogic
In-Reply-To: <203c4d9e-f39a-7a08-46c3-4ee6e61f181e@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 9 Nov 2018 18:15:31 +0100
> Flag PHY_HAS_INTERRUPT is used only here for this small check. I think
> using interrupts isn't possible if a driver defines neither
> config_intr nor ack_interrupts callback. So we can replace checking
> flag PHY_HAS_INTERRUPT with checking for these callbacks.
> This allows to remove this flag from all driver configs.
>
> v2:
> - add helper for check in patch 1
> - remove PHY_HAS_INTERRUPT from all drivers, not only Realtek
> - remove flag PHY_HAS_INTERRUPT completely
>
> v3:
> - rebase patch 2
Series applied, but please sort out that one driver which is preventing
us requiring both config_intr && ack_interrupt.
Thanks.
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Jesper Dangaard Brouer @ 2018-11-11 8:03 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Saeed Mahameed, netdev@vger.kernel.org, brouer
In-Reply-To: <428dfb15-0123-ce6d-c403-73e83caf145d@itcare.pl>
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)
> >
> > [...]
> >>>>> 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.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* (unknown),
From: Oliver Carter @ 2018-11-11 8:05 UTC (permalink / raw)
To: netdev
Netdev https://goo.gl/pW8d8y Oliver Carter
^ permalink raw reply
* Re: KASAN: use-after-free Read in update_blocked_averages
From: Dmitry Vyukov @ 2018-11-11 18:24 UTC (permalink / raw)
To: syzbot; +Cc: LKML, syzkaller-bugs, netdev
In-Reply-To: <000000000000fd464c057a679adb@google.com>
On Sun, Nov 11, 2018 at 10:18 AM, syzbot
<syzbot+0dbf864d3b52555e8265@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 12ceaf8864c2 infiniband: nes: Fix more direct skb list acc..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15a82783400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=dcbea7daf3ea3e3e
> dashboard link: https://syzkaller.appspot.com/bug?extid=0dbf864d3b52555e8265
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=137ae6d5400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15dbd77b400000
Looking at the reproducer this looks network related, +netdev
r0 = socket$inet6(0xa, 0x2, 0x0)
connect$inet6(r0, &(0x7f0000000100)={0xa, 0x0, 0x0, @dev, 0x6}, 0x1c)
connect$inet6(r0, &(0x7f0000000580)={0xa, 0x4e22, 0x0, @ipv4={[], [],
@local}}, 0x1c)
sendmmsg(r0, &(0x7f00000092c0), 0x4ff, 0x0)
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+0dbf864d3b52555e8265@syzkaller.appspotmail.com
>
> IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
> IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
> 8021q: adding VLAN 0 to HW filter on device team0
> ==================================================================
> BUG: KASAN: use-after-free in skip_blocked_update kernel/sched/fair.c:3324
> [inline]
> BUG: KASAN: use-after-free in update_blocked_averages+0x1533/0x1e00
> kernel/sched/fair.c:7400
> kasan: CONFIG_KASAN_INLINE enabled
> Read of size 8 at addr ffff8801bf0d6ea0 by task syz-executor841/6015
>
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> CPU: 1 PID: 6015 Comm: syz-executor841 Not tainted 4.20.0-rc1+ #289
> general protection fault: 0000 [#1] PREEMPT SMP KASAN
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> CPU: 0 PID: 6272 Comm: syz-executor841 Not tainted 4.20.0-rc1+ #289
> Call Trace:
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x244/0x39d lib/dump_stack.c:113
> RIP: 0010:vmalloc_fault+0x426/0x770 arch/x86/mm/fault.c:405
> Code: e0 e8 fe 25 47 00 48 b8 00 00 00 00 00 88 ff ff 48 ba 00 00 00 00 00
> fc ff df 48 01 c3 4d 21 e5 4c 01 eb 48 89 d9 48 c1 e9 03 <80> 3c 11 00 0f 85
> b2 02 00 00 48 8b 1b 31 ff 49 89 dc 49 83 e4 9f
> RSP: 0018:ffff8801d9d624c8 EFLAGS: 00010002
> RAX: ffff880000000000 RBX: 000f100180000040 RCX: 0001e20030000008
> print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
> RDX: dffffc0000000000 RSI: ffffffff813864c2 RDI: 0000000000000007
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
> RBP: ffff8801d9d624f8 R08: ffff8801bbb56700 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 000fffffc0000000
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> R13: 000f880180000000 R14: ffffc90001159838 R15: 1ffffffff12a3f98
> skip_blocked_update kernel/sched/fair.c:3324 [inline]
> update_blocked_averages+0x1533/0x1e00 kernel/sched/fair.c:7400
> FS: 0000000001f7d880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffc90001159838 CR3: 00000001ba705000 CR4: 00000000001406f0
> Call Trace:
> Modules linked in:
> ---[ end trace f6450057874cc9c7 ]---
> RIP: 0010:vmalloc_fault+0x426/0x770 arch/x86/mm/fault.c:405
> Code: e0 e8 fe 25 47 00 48 b8 00 00 00 00 00 88 ff ff 48 ba 00 00 00 00 00
> fc ff df 48 01 c3 4d 21 e5 4c 01 eb 48 89 d9 48 c1 e9 03 <80> 3c 11 00 0f 85
> b2 02 00 00 48 8b 1b 31 ff 49 89 dc 49 83 e4 9f
> RSP: 0018:ffff8801d9d624c8 EFLAGS: 00010002
> RAX: ffff880000000000 RBX: 000f100180000040 RCX: 0001e20030000008
> RDX: dffffc0000000000 RSI: ffffffff813864c2 RDI: 0000000000000007
> RBP: ffff8801d9d624f8 R08: ffff8801bbb56700 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 000fffffc0000000
> R13: 000f880180000000 R14: ffffc90001159838 R15: 1ffffffff12a3f98
> FS: 0000000001f7d880(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffc90001159838 CR3: 00000001ba705000 CR4: 00000000001406f0
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000fd464c057a679adb%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH net-next v2] tcp: minor optimization in tcp ack fast path processing
From: David Miller @ 2018-11-11 18:26 UTC (permalink / raw)
To: laoar.shao; +Cc: edumazet, netdev, linux-kernel, joe
In-Reply-To: <1541938210-11797-1-git-send-email-laoar.shao@gmail.com>
From: Yafang Shao <laoar.shao@gmail.com>
Date: Sun, 11 Nov 2018 20:10:10 +0800
> Bitwise operation is a little faster.
> So I replace after() with using the flag FLAG_SND_UNA_ADVANCED as it is
> already set before.
>
> In addtion, there's another similar improvement in tcp_cwnd_reduction().
>
> Cc: Joe Perches <joe@perches.com>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: Work around mv886e6161 SERDES missing MII_PHYSID2
From: Sergei Shtylyov @ 2018-11-11 8:44 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev
In-Reply-To: <1541893839-4828-1-git-send-email-andrew@lunn.ch>
Hello!
On 11.11.2018 2:50, Andrew Lunn wrote:
> We already have a workaround for a couple of switches whose internal
> PHYs only have the Marvel OUI, but no model number. We detect such
> PHYs and give them the 6390 ID as the model number. However the
> mv88e6161 has two SERDES interfaces in the same address range as its
> internal PHYs. These suffer from the same problem, the Marvell OUI,
> but no model number. As a result, these SERDES interfaces were getting
> the same PHY ID as the mv88e6390, even though they are not PHYs, and
> the Marvell PHY driver was trying to drive them.
>
> Add a special case to stop this happen.
Dtop this from happening, maybe?
>
> Reported-by: Chris Healy <Chris.Healy@zii.aero>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index fc0f508879d4..4906a4f39d62 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2524,11 +2524,22 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
> mutex_unlock(&chip->reg_lock);
>
> if (reg == MII_PHYSID2) {
> - /* Some internal PHYS don't have a model number. Use
> - * the mv88e6390 family model number instead.
> - */
> - if (!(val & 0x3f0))
> - val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
> + /* Some internal PHYS don't have a model number. */
PHYs (else you're inconsistent with the next comment).
> + if (chip->info->family != MV88E6XXX_FAMILY_6165)
> + /* Then there is the 6165 family. It gets is
> + * PHYs correct. But it can also have two
> + * SERDES interfaces in the PHY address
> + * space. And these don't have a model
> + * number. But they are not PHYs, so we don't
> + * want to give them something a PHY driver
> + * will recognise.
> + *
> + * Use the mv88e6390 family model number
> + * instead, for anything which really could be
> + * a PHY,
> + */
> + if (!(val & 0x3f0))
> + val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
> }
>
> return err ? err : val;
MBR, Sergei
^ permalink raw reply
* 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
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