* Re: [PATCH net-next] sctp: reuse sent_count to avoid retransmitted chunks for RTT measurements
From: David Miller @ 2016-10-13 13:44 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel
In-Reply-To: <b68194a4735a1ea5a652c13540df5d68e3c4b305.1475897765.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 8 Oct 2016 11:36:05 +0800
> Now sctp uses chunk->resent to record if a chunk is retransmitted, for
> RTT measurements with retransmitted DATA chunks. chunk->sent_count was
> introduced to record how many times one chunk has been sent for prsctp
> RTX policy before. We actually can know if one chunk is retransmitted
> by checking chunk->sent_count is greater than 1.
>
> This patch is to remove resent from sctp_chunk and reuse sent_count
> to avoid retransmitted chunks for RTT measurements.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sctp: remove the old ttl expires policy
From: David Miller @ 2016-10-13 13:44 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel
In-Reply-To: <db5df5806c3c0b7c37ab9039a906664a33c74563.1475898016.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 8 Oct 2016 11:40:16 +0800
> The prsctp polices include ttl expires policy already, we should remove
> the old ttl expires codes, and just adjust the new polices' codes to be
> compatible with the old one for users.
>
> This patch is to remove all the old expires codes, and if prsctp polices
> are not set, it will still set msg's expires_at and check the expires in
> sctp_check_abandoned.
>
> Note that asoc->prsctp_enable is set by default, so users can't feel any
> difference even if they use the old expires api in userspace.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/3] net: smc91x: isolate u16 writes alignment workaround
From: David Miller @ 2016-10-13 13:50 UTC (permalink / raw)
To: robert.jarzmik-GANU6spQydw
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
nico-vtqb6HGKxmzR7s880joybQ, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
arnd-r2nGTMty4D4, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476045227-2970-1-git-send-email-robert.jarzmik-GANU6spQydw@public.gmane.org>
From: Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>
Date: Sun, 9 Oct 2016 22:33:45 +0200
> Writes to u16 has a special handling on 3 PXA platforms, where the
> hardware wiring forces these writes to be u32 aligned.
>
> This patch isolates this handling for PXA platforms as before, but
> enables this "workaround" to be set up dynamically, which will be the
> case in device-tree build types.
>
> This patch was tested on 2 PXA platforms : mainstone, which relies on
> the workaround, and lubbock, which doesn't.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>
Please resubmit this patch series:
1) Respun against net-next, these don't currently apply cleanly there.
2) With a proper "[PATCH 0/3] ..." posting explaining at a high level
what this patch series does, how it does it, and why it does it
that way.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] xen-netback: (re-)create a debugfs node for hash information
From: David Miller @ 2016-10-13 13:54 UTC (permalink / raw)
To: paul.durrant; +Cc: netdev, wei.liu2, xen-devel
In-Reply-To: <1476088253-10685-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Mon, 10 Oct 2016 09:30:53 +0100
> From: Paul Durrant <Paul.Durrant@citrix.com>
>
> It is useful to be able to see the hash configuration when running tests.
> This patch adds a debugfs node for that purpose.
>
> The original version of this patch (commit c0c64c152389) was reverted due
> to build failures caused by a conflict with commit 0364a8824c02
> ("xen-netback: switch to threaded irq for control ring"). This new version
> of the patch is nearly identical to the original, the only difference
> being that creation of the debugfs node is predicated on 'ctrl_irq' being
> non-zero rather then the now non-existent 'ctrl_task'.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Applied.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH net] net_sched: do not broadcast RTM_GETTFILTER result
From: David Miller @ 2016-10-13 13:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jhs
In-Reply-To: <1476069955.28155.292.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 09 Oct 2016 20:25:55 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> There are two ways to get tc filters from kernel to user space.
>
> 1) Full dump (tc_dump_tfilter())
> 2) RTM_GETTFILTER to get one precise filter, reducing overhead.
>
> The second operation is unfortunately broadcasting its result,
> polluting "tc monitor" users.
>
> This patch makes sure only the requester gets the result, using
> netlink_unicast() instead of rtnetlink_send()
>
> Jamal cooked an iproute2 patch to implement "tc filter get" operation,
> but other user space libraries already use RTM_GETTFILTER when a single
> filter is queried, instead of dumping all filters.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
Want me to queue this up for -stable too?
^ permalink raw reply
* Re: [PATCH] qed: fix old-style function definition
From: David Miller @ 2016-10-13 13:55 UTC (permalink / raw)
To: arnd
Cc: Yuval.Mintz, Ariel.Elior, everest-linux-l2, Ram.Amrani, netdev,
linux-kernel
In-Reply-To: <20161010115937.730249-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 10 Oct 2016 13:59:16 +0200
> The definition of qed_get_rdma_ops() is not a prototype unless
> we add 'void' here, as indicated by this W=1 warning:
>
> drivers/net/ethernet/qlogic/qed/qed_roce.c: In function ‘qed_get_rdma_ops’:
> drivers/net/ethernet/qlogic/qed/qed_roce.c:2950:28: error: old-style function definition [-Werror=old-style-definition]
>
> Fixes: abd49676c707 ("qed: Add RoCE ll2 & GSI support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Again, Qlogic folks, please properly review patches posted against your
driver.
Thanks.
^ permalink raw reply
* Re: [PATCH] tlan: avoid unused label with PCI=n
From: David Miller @ 2016-10-13 13:56 UTC (permalink / raw)
To: arnd; +Cc: chessman, mugunthanvnm, ivecera, a, fw, netdev, linux-kernel
In-Reply-To: <20161010124120.1522425-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 10 Oct 2016 14:41:10 +0200
> While build testing with randconfig on x86, I ran into this warning
> that appears to have been around forever
>
> drivers/net/ethernet/ti/tlan.c: In function ‘tlan_probe1’:
> drivers/net/ethernet/ti/tlan.c:614:1: error: label ‘err_out’ defined but not used [-Werror=unused-label]
>
> This can be trivially avoided by just moving the label into the
> existing #ifdef.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Chris Rorvick @ 2016-10-13 13:56 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linuxwifi-ral2JQCrhuEAvxtiuMwx3w,
emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w,
johannes-cdvu00un1VgdHxzADdlk8Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
oren.givon-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paul Bolle
In-Reply-To: <1476358075.1999.5.camel-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>
Hi Luca,
> On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> Could you please give this a spin? I have tested it with some handmade
> ACPI tables in QEMU and it seems to work fine now.
Tested-by: Chris Rorvick <chris-FAYdYWbMHyxBDgjK7y7TUQ@public.gmane.org>
I think the debug output looks as expected, see below for the first 20
lines or so. And, more importantly, everything seems to be working!
:-)
Thanks!
Chris
==========
iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
iwlwifi: module verification failed: signature and/or required key
missing - tainting kernel
Intel(R) Wireless WiFi driver for Linux
Copyright(c) 2003- 2015 Intel Corporation
iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-24.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-24.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-23.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-23.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-22.ucode'
iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-22.ucode
failed with error -2
iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load
firmware 'iwlwifi-8000C-21.ucode'
iwlwifi 0000:3a:00.0: U iwl_req_fw_callback Loaded firmware file
'iwlwifi-8000C-21.ucode' (2394060 bytes).
iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware unknown TLV: 48
iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware GSCAN is supported but
capabilities TLV is unavailable
iwlwifi 0000:3a:00.0: U splc_get_pwr_limit No element for the WiFi
domain returned by the SPLC method.
iwlwifi 0000:3a:00.0: U set_dflt_pwr_limit Default power limit set to 0
iwlwifi 0000:3a:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm
iwlwifi 0000:3a:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
^ permalink raw reply
* Re: [PATCH v2] qed: Fix to use list_for_each_entry_safe() when delete items
From: David Miller @ 2016-10-13 13:58 UTC (permalink / raw)
To: weiyj.lk; +Cc: Yuval.Mintz, Ariel.Elior, weiyongjun1, everest-linux-l2, netdev
In-Reply-To: <1476108508-14376-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Mon, 10 Oct 2016 14:08:28 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Since we will remove items off the list using list_del() we need
> to use a safe version of the list_for_each_entry() macro aptly named
> list_for_each_entry_safe().
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Acked-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
> ---
> v1 -> v2: use tmp_buffer instead of tmp
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] qed: Fix to use list_for_each_entry_safe() when delete items
From: David Miller @ 2016-10-13 13:47 UTC (permalink / raw)
To: weiyj.lk; +Cc: Yuval.Mintz, Ariel.Elior, weiyongjun1, everest-linux-l2, netdev
In-Reply-To: <1476019942-6837-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Sun, 9 Oct 2016 13:32:22 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Since we will remove items off the list using list_del() we need
> to use a safe version of the list_for_each_entry() macro aptly named
> list_for_each_entry_safe().
>
> Fixes: 0a7fb11c23c0 ("qed: Add Light L2 support")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Can the QED maintainers please review this simple fix?
In my opinion 4 days is sufficient time in which to expect a
reasonable review to occur, let me know if you disagree. :-)
^ permalink raw reply
* Re: [PATCH net 0/3] openvswitch: vlan fixes
From: David Miller @ 2016-10-13 14:03 UTC (permalink / raw)
To: jbenc; +Cc: netdev, pshelar, e
In-Reply-To: <cover.1476111550.git.jbenc@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Mon, 10 Oct 2016 17:02:41 +0200
> Fix three issues introduced by the 802.1AD patchset.
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-13 13:45 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andy Lutomirski, Johannes Berg, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <20161013134252.GA583@swordfish>
On (10/13/16 22:42), Sergey Senozhatsky wrote:
>
> On (10/13/16 08:02), Johannes Berg wrote:
> > On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
> >
> > > In a pinch, I have these patches sitting around:
> > >
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
> >
> > That truly sounds like something we'd rather avoid in the TX/RX paths
> > though, which should perform well.
>
> didn't fix.
>
> so I finally had some time to do a better bug-reporter job.
>
> I added a bunch of printk-s and several virt_addr_valid()-s
> to ieee80211_aes_ccm_encrypt().
>
> and right befoe the Oops I see the following report from
> virt_addr_valid()
>
>
> FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02 >> 39) == 130
that `(00004100002cba02 >> 39) == 130' part is
phys_addr_valid()
{
(addr >> boot_cpu_data.x86_phys_bits)
}
-ss
^ permalink raw reply
* Re: [PATCH net] qmi_wwan: add support for Quectel EC21 and EC25
From: David Miller @ 2016-10-13 14:06 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161010191249.23814-1-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Mon, 10 Oct 2016 21:12:49 +0200
> The Quectel EC21 and EC25 need the same "set DTR" request as devices
> based on the MDM9230 chipset, but has no USB3 support. Our best guess
> is that the "set DTR" functionality depends on chipset and/or
> baseband firmware generation. But USB3 is still an optional feature.
>
> Since we cannot enable this unconditionally for all older devices, and
> there doesn't appear to be anything we can use in the USB descriptors
> to identify these chips, we are forced to use a device specific quirk
> flag.
>
> Reported-and-tested-by: Sebastian Sjoholm <sebastian.sjoholm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v10 1/1] net: phy: Cleanup the Edge-Rate feature in Microsemi PHYs.
From: David Miller @ 2016-10-13 14:01 UTC (permalink / raw)
To: allan.nielsen; +Cc: netdev, andrew, f.fainelli, raju.lakkaraju
In-Reply-To: <1476108825-14613-2-git-send-email-allan.nielsen@microsemi.com>
From: "Allan W. Nielsen" <allan.nielsen@microsemi.com>
Date: Mon, 10 Oct 2016 16:13:45 +0200
> Edge-Rate cleanup include the following:
> - Updated device tree bindings documentation for edge-rate
> - The edge-rate is now specified as a "slowdown", meaning that it is now
> being specified as positive values instead of negative (both
> documentation and implementation wise).
> - Only explicitly documented values for "vsc8531,vddmac" and
> "vsc8531,edge-slowdown" are accepted by the device driver.
> - Deleted include/dt-bindings/net/mscc-phy-vsc8531.h as it was not needed.
> - Read/validate devicetree settings in probe instead of init
>
> Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
> Signed-off-by: Raju Lakkaraju <raju.lakkaraju@microsemi.com>
This doesn't apply cleanly to net-next, please respin.
Thanks.
^ permalink raw reply
* Re: [PATCH V2 net-next] net/mlx5: Add MLX5_ARRAY_SET64 to fix BUILD_BUG_ON
From: David Miller @ 2016-10-13 14:13 UTC (permalink / raw)
To: saeedm; +Cc: netdev, tom, leonro, David.Laight, kernel-team
In-Reply-To: <1476237430-11756-1-git-send-email-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 12 Oct 2016 04:57:10 +0300
> From: Tom Herbert <tom@herbertland.com>
>
> I am hitting this in mlx5:
>
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function
> reclaim_pages_cmd.clone.0:
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:346: error: call
> to __compiletime_assert_346 declared with attribute error:
> BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_out, pas[i]) % 64
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function give_pages:
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:291: error: call
> to __compiletime_assert_291 declared with attribute error:
> BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_in, pas[i]) % 64
>
> Problem is that this is doing a BUILD_BUG_ON on a non-constant
> expression because of trying to take offset of pas[i] in the
> structure.
>
> Fix is to create MLX5_ARRAY_SET64 that takes an additional argument
> that is the field index to separate between BUILD_BUG_ON on the array
> constant field and the indexed field to assign the value to.
> There are two callers of MLX5_SET64 that are trying to get a variable
> offset, change those to call MLX5_ARRAY_SET64 passing 'pas' and 'i'
> as the arguments to use in the offset check and the indexed value
> assignment.
>
> Fixes: a533ed5e179cd ("net/mlx5: Pages management commands via mlx5 ifc")
> Signed-off-by: Tom Herbert <tom@herbertland.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] drivers/ptp: Fix kernel memory disclosure
From: David Miller @ 2016-10-13 14:20 UTC (permalink / raw)
To: vlad; +Cc: netdev, richardcochran
In-Reply-To: <1476190967-38256-1-git-send-email-vlad@tsyrklevich.net>
From: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Date: Tue, 11 Oct 2016 15:02:47 +0200
> The reserved field precise_offset->rsv is not cleared before being
> copied to user space, leaking kernel stack memory. Clear the struct
> before it's copied.
>
> Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Applied and queued up for -stable, thanks Vlad.
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: fix guest Rx stall detection (after guest Rx refactor)
From: David Miller @ 2016-10-13 14:21 UTC (permalink / raw)
To: david.vrabel; +Cc: netdev, xen-devel, paul.durrant, wei.liu2
In-Reply-To: <1476200907-16085-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 11 Oct 2016 16:48:27 +0100
> If a VIF has been ready for rx_stall_timeout (60s by default) and an
> Rx ring is drained of all requests an Rx stall will be incorrectly
> detected. When this occurs and the guest Rx queue is empty, the Rx
> ring's event index will not be set and the frontend will not raise an
> event when new requests are placed on the ring, permanently stalling
> the VIF.
>
> This is a regression introduced by eb1723a29b9a7 (xen-netback:
> refactor guest rx).
>
> Fix this by reinstating the setting of queue->last_rx_time when
> placing a packet onto the guest Rx ring.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: David Miller @ 2016-10-13 14:24 UTC (permalink / raw)
To: pabeni-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1dbd83dfe7f435eecc5bc460e901b47758280f30.1476206016.git.pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Tue, 11 Oct 2016 19:15:44 +0200
> After the commit 9207f9d45b0a ("net: preserve IP control block
> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
> That destroy the IPoIB address information cached there,
> causing a severe performance regression, as better described here:
>
> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>
> This change moves the data cached by the IPoIB driver from the
> skb control lock into the IPoIB hard header, as done before
> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
> and use skb->cb to stash LL addresses").
> In order to avoid GRO issue, on packet reception, the IPoIB driver
> stash into the skb a dummy pseudo header, so that the received
> packets have actually a hard header matching the declared length.
> Also the connected mode maximum mtu is reduced by 16 bytes to
> cope with the increased hard header len.
>
> After this commit, IPoIB performances are back to pre-regression
> value.
>
> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
> Signed-off-by: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Not providing an accurate hard_header_len causes many problems.
In fact we recently fixed the mlxsw driver to stop doing this.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/6] fjes: Implement debug mode for fjes driver
From: David Miller @ 2016-10-13 14:19 UTC (permalink / raw)
To: izumi.taku; +Cc: netdev
In-Reply-To: <1476176120-18859-1-git-send-email-izumi.taku@jp.fujitsu.com>
From: Taku Izumi <izumi.taku@jp.fujitsu.com>
Date: Tue, 11 Oct 2016 17:55:20 +0900
> This patch implements debug mode for fjes driver.
> You can get firmware activity information by enabling
> debug mode. This is useful for debugging.
>
> To enable debug mode, write value of debugging mode to
> debug_mode file in debugfs:
>
> # echo 1 > /sys/kernel/debug/fjes/fjes.0/debug_mode
>
> To disable debug mode, write 0 to debug_mode file in debugfs:
>
> # echo 0 > /sys/kernel/debug/fjes/fjes.0/debug_mode
>
> Firmware activity information can be retrieved via
> /sys/kernel/debug/fjes/fjes.0/debug_data file.
>
> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
There is no reason to use debugfs for this, we have facilities such
as ETHTOOL_SET_DUMP et al. that you can use to implement this.
^ permalink raw reply
* Re: [PATCH net-next 00/11] net: Fix netdev adjacency tracking
From: David Ahern @ 2016-10-13 14:32 UTC (permalink / raw)
To: Jiri Pirko
Cc: jiri-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
j.vosburgh-Re5JQEeQqe8AvxtiuMwx3w, vfalico-Re5JQEeQqe8AvxtiuMwx3w,
andy-QlMahl40kYEqcZcGjlUOXw,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
intel-wired-lan-qjLDD68F18P21nG7glBr7A
In-Reply-To: <20161013073424.GB1816-6KJVSR23iU488b5SBfVpbw@public.gmane.org>
On 10/13/16 1:34 AM, Jiri Pirko wrote:
>
> Although I didn't like the "all-list" idea when Veaceslav pushed it
> because it looked to me like a big hammer, it turned out to be very handy
> and quick for traversing neighbours. Why it cannot be fixed?
>
> The walks with possibly hundreds of function calls instead of a single
> list traverse worries me.
>
I have been looking at this code for a week now. Every solution I came up with that solved the original problems introduced new ones -- usually with adjacency remove expecting an adjacency that did not exist. In the end I came to the conclusion it is not possible to maintain an all_adj_list when the upper tree can have multiple paths to the top device. If someone thinks otherwise I am happy to test a patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 14:30 UTC (permalink / raw)
To: Chris Rorvick
Cc: linux-wireless, linuxwifi, emmanuel.grumbach, johannes, kvalo,
oren.givon, netdev, linux-kernel, Paul Bolle
In-Reply-To: <CAEUsAPaqyxA1=3ktisBO3Vrw9ygi7PSrk32Rw+iyHVe_WB1oyg@mail.gmail.com>
On Thu, 2016-10-13 at 08:56 -0500, Chris Rorvick wrote:
> Hi Luca,
>
> > On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> > Could you please give this a spin? I have tested it with some handmade
> > ACPI tables in QEMU and it seems to work fine now.
>
>
> Tested-by: Chris Rorvick <chris@rorvick.com>
>
> I think the debug output looks as expected, see below for the first 20
> lines or so. And, more importantly, everything seems to be working!
> :-)
Yes, you got exactly what was expected. Thanks for testing!
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: Doug Ledford @ 2016-10-13 14:35 UTC (permalink / raw)
To: David Miller, pabeni-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161013.102432.1450901395774429343.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1817 bytes --]
On 10/13/2016 10:24 AM, David Miller wrote:
> From: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Tue, 11 Oct 2016 19:15:44 +0200
>
>> After the commit 9207f9d45b0a ("net: preserve IP control block
>> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
>> That destroy the IPoIB address information cached there,
>> causing a severe performance regression, as better described here:
>>
>> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>>
>> This change moves the data cached by the IPoIB driver from the
>> skb control lock into the IPoIB hard header, as done before
>> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
>> and use skb->cb to stash LL addresses").
>> In order to avoid GRO issue, on packet reception, the IPoIB driver
>> stash into the skb a dummy pseudo header, so that the received
>> packets have actually a hard header matching the declared length.
>> Also the connected mode maximum mtu is reduced by 16 bytes to
>> cope with the increased hard header len.
>>
>> After this commit, IPoIB performances are back to pre-regression
>> value.
>>
>> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
>> Signed-off-by: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Not providing an accurate hard_header_len causes many problems.
>
> In fact we recently fixed the mlxsw driver to stop doing this.
>
Sure, but there are too many users of the cb struct, and whatever
problems you are saying there are by lying about the hard header len are
dwarfed by the problems caused by the inability to store the ll address
anywhere between hard_header and send time.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* RE: Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest
From: David Laight @ 2016-10-13 14:02 UTC (permalink / raw)
To: 'Koehrer Mathias (ETAS/ESW5)', Julia Cartwright,
Williams, Mitch A, Kirsher, Jeffrey T
Cc: linux-rt-users@vger.kernel.org, Sebastian Andrzej Siewior,
netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, Greg
In-Reply-To: <b77ea8ab312149d2b20a717d3ab0a8dc@FE-MBX1012.de.bosch.com>
From: Koehrer Mathias
> Sent: 13 October 2016 11:57
..
> > The time between my trace points 700 and 701 is about 30us, the time between my
> > trace points 600 and 601 is even 37us!!
> > The code in between is
> > tsyncrxctl = rd32(E1000_TSYNCRXCTL); resp.
> > lvmmc = rd32(E1000_LVMMC);
> >
> > In both cases this is a single read from a register.
> > I have no idea why this single read could take that much time!
> > Is it possible that the igb hardware is in a state that delays the read access and this is
> > why the whole I/O system might be delayed?
> >
>
> To have a proper comparison, I did the same with kernel 3.18.27-rt27.
> Also here, I instrumented the igb driver to get traces for the rd32 calls.
> However, here everything is generally much faster!
> In the idle system the maximum I got for a read was about 6us, most times it was 1-2us.
1-2us is probably about right, PCIe is high throughput high latency.
You should see the latencies we get talking to fpga!
> On the 4.8 kernel this is always much slower (see above).
> My question is now: Is there any kernel config option that has been introduced in the meantime
> that may lead to this effect and which is not set in my 4.8 config?
Have a look at the generated code for rd32().
Someone might have added a load of synchronisation instructions to it.
On x86 I don't think it needs any.
It is also possible for other PCIe accesses to slow things down
(which might be why you see 6us).
I presume you are doing these comparisons on the same hardware?
Obscure bus topologies could slow things down.
David
^ permalink raw reply
* Re: [PATCH net] Revert "net: Add driver helper functions to determine checksum offloadability"
From: David Miller @ 2016-10-13 14:35 UTC (permalink / raw)
To: stephen; +Cc: tom, netdev
In-Reply-To: <20161011130409.7e6b54ff@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 11 Oct 2016 13:04:09 -0700
> This reverts commit 6ae23ad36253a8033c5714c52b691b84456487c5.
>
> The code has been in kernel since 4.4 but there are no in tree
> code that uses. Unused code is broken code, remove it.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Tom if you have any real plans to develop on this work at all in
the immediate future, please speak up now.
Otherwise I'm applying Stephen's patch.
Thanks.
^ permalink raw reply
* Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header,Re: [PATCH] IB/ipoib: move back the IB LL address into the hard header
From: David Miller @ 2016-10-13 14:43 UTC (permalink / raw)
To: dledford; +Cc: pabeni, linux-rdma, sean.hefty, hal.rosenstock, netdev
In-Reply-To: <20ace6ee-b9e4-073c-56e7-29b2c50ae2d5@redhat.com>
From: Doug Ledford <dledford@redhat.com>
Date: Thu, 13 Oct 2016 10:35:35 -0400
> On 10/13/2016 10:24 AM, David Miller wrote:
>> From: Paolo Abeni <pabeni@redhat.com>
>> Date: Tue, 11 Oct 2016 19:15:44 +0200
>>
>>> After the commit 9207f9d45b0a ("net: preserve IP control block
>>> during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
>>> That destroy the IPoIB address information cached there,
>>> causing a severe performance regression, as better described here:
>>>
>>> http://marc.info/?l=linux-kernel&m=146787279825501&w=2
>>>
>>> This change moves the data cached by the IPoIB driver from the
>>> skb control lock into the IPoIB hard header, as done before
>>> the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
>>> and use skb->cb to stash LL addresses").
>>> In order to avoid GRO issue, on packet reception, the IPoIB driver
>>> stash into the skb a dummy pseudo header, so that the received
>>> packets have actually a hard header matching the declared length.
>>> Also the connected mode maximum mtu is reduced by 16 bytes to
>>> cope with the increased hard header len.
>>>
>>> After this commit, IPoIB performances are back to pre-regression
>>> value.
>>>
>>> Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
>>> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>>
>> Not providing an accurate hard_header_len causes many problems.
>>
>> In fact we recently fixed the mlxsw driver to stop doing this.
>>
>
> Sure, but there are too many users of the cb struct, and whatever
> problems you are saying there are by lying about the hard header len are
> dwarfed by the problems caused by the inability to store the ll address
> anywhere between hard_header and send time.
IB wants to pass addressing information between layers, it needs to
find a safe way to do that. The currently propsoed patch does not
meet this criteria.
Pushing metadata before the head of the SKB data pointer is illegal,
as the layers in between might want to push protocol headers, mirror
the packet to another interface, etc.
So this "metadata in SKB data" approach is buggy too.
^ 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