* Re: [PATCH net] sctp: define SCTP_SS_DEFAULT for Stream schedulers
From: David Miller @ 2018-11-04 2:41 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <4986625e9c58cccdfbb6c809a82c77a83b57a541.1541224891.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 3 Nov 2018 14:01:31 +0800
> According to rfc8260#section-4.3.2, SCTP_SS_DEFAULT is required to
> defined as SCTP_SS_FCFS or SCTP_SS_RR.
>
> SCTP_SS_FCFS is used for SCTP_SS_DEFAULT's value in this patch.
>
> Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations")
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Also applied and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net] mlxsw: spectrum: Fix IP2ME CPU policer configuration
From: David Miller @ 2018-11-04 2:32 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, shalomt, mlxsw
In-Reply-To: <20181102194840.31107-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Fri, 2 Nov 2018 19:49:15 +0000
> From: Shalom Toledo <shalomt@mellanox.com>
>
> The CPU policer used to police packets being trapped via a local route
> (IP2ME) was incorrectly configured to police based on bytes per second
> instead of packets per second.
>
> Change the policer to police based on packets per second and avoid
> packet loss under certain circumstances.
>
> Fixes: 9148e7cf73ce ("mlxsw: spectrum: Add policers for trap groups")
> Signed-off-by: Shalom Toledo <shalomt@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Update
From: Dr Kannan @ 2018-11-03 16:26 UTC (permalink / raw)
To: Recipients
Hello dear
Greetings to you,I am Dr.Kannan, a personal account manager to Late Engr. Richard Hernandez, who died with his family in the missing Malaysian Air crash
of 2014. His account with us is in intestate with no claim his fixed deposit of U$D 7 Million.
I have been mandated by the Bank Management as his personal account officer, to present his relative or next of kin.
I have searched through notary register of his country here all to no avail, so I wish to present you to the Bank as his only relative and next of kin.
kindly contact me for more details, terms and condition shall be clarified upon your response. There is no risk whatsoever to this transaction as I have all papers and documents to pose of you the inheritance to this.
I wait for your prompt response.
My regards,
Dr. Kannan.
^ permalink raw reply
* Re: [PATCH v3 1/2] kretprobe: produce sane stack traces
From: Aleksa Sarai @ 2018-11-04 11:59 UTC (permalink / raw)
To: Steven Rostedt
Cc: Naveen N. Rao, Anil S Keshavamurthy, David S. Miller,
Masami Hiramatsu, Jonathan Corbet, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Brendan Gregg, Christian Brauner, Aleksa Sarai, netdev, linux-doc,
linux-kernel
In-Reply-To: <20181103070253.ajrqzs5xu2vf5stu@yavin>
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
On 2018-11-03, Aleksa Sarai <cyphar@cyphar.com> wrote:
> This is actually a general bug in ftrace as well, because (for
> instance) while the unwinder calls into ftrace_graph_ret_addr() while
> walking up the stack this isn't used to correct regs->ip in
> perf_callchain_kernel(). I think this is the cause of the bug in
> ftrace-graph (if you switch to the "frame" unwinder you might be able
> to see it more clearly) -- but when trying to fix it I'm having
> trouble figuring out what retp should be (stack_addr(regs) doesn't
> give the right result for some reason).
@Steven, @Masami: Can you verify whether this is an actual bug? The
snippet is like (arch/x86/events/core.c):
void
perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs)
{
/* ... */
if (perf_callchain_store(entry, regs->ip))
return;
/* rest of unwind code */
}
And it seems to me that there's an ftrace_graph_ret_addr missing here
(though I was having trouble figuring out what the right retp would be
in this context -- both stack_addr(regs) and ®s->sp appear to be
wrong when I was trying to get this to work with kretprobes -- while my
patch worked with all other kretprobe_trampoline cases in the unwinder).
The same issue is present in __save_stack_trace
(arch/x86/kernel/stacktrace.c). This is likely the only reason that --
as Steven said -- stacktraces wouldn't work with ftrace-graph (and thus
with the refactor both of you are discussing).
Thanks.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Andre Tomt @ 2018-11-04 5:43 UTC (permalink / raw)
To: Eric Dumazet, Eric Dumazet
Cc: Stephen Hemminger, netdev, rossi.f, Dimitris Michailidis
In-Reply-To: <973f5f0e-fc25-7a99-70b5-3b53f7c69fca@tomt.net>
On 31.10.2018 05:08, Andre Tomt wrote:
> On 30.10.2018 12:04, Andre Tomt wrote:
>> On 30.10.2018 11:58, Andre Tomt wrote:
>>> On 27.10.2018 23:41, Andre Tomt wrote:
>>>> On 26.10.2018 13:45, Andre Tomt wrote:
>>>>> On 25.10.2018 19:38, Eric Dumazet wrote:
>>>>>>
>>>>>>
>>>>>> On 10/24/2018 12:41 PM, Andre Tomt wrote:
>>>>>>>
>>>>>>> It eventually showed up again with mlx4, on 4.18.16 + fix and
>>>>>>> also on 4.19. I still do not have a useful packet capture.
>>>>>>>
>>>>>>> It is running a torrent client serving up various linux
>>>>>>> distributions.
>>>>>>>
>>>>>>
>>>>>> Have you also applied this fix ?
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=db4f1be3ca9b0ef7330763d07bf4ace83ad6f913
>>>>>>
>>>>>>
>>>>>
>>>>> No. I've applied it now to 4.19 and will report back if anything
>>>>> shows up.
>>>>
>>>> Just hit it on the simpler server; no VRF, no tunnels, no
>>>> nat/conntrack. Only a basic stateless nftables ruleset and a vlan
>>>> netdev (unlikely to be the one triggering this I guess; it has only
>>>> v4 traffic).
>>>
>>> I'm currently testing 4.19 with the recomended commit added, plus
>>> these to sort out some GRO issues (on a hunch, unsure if related):
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=a8305bff685252e80b7c60f4f5e7dd2e63e38218
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=992cba7e276d438ac8b0a8c17b147b37c8c286f7
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=ece23711dd956cd5053c9cb03e9fe0668f9c8894
>>>
>>>
>>> and I *think* it is behaving better now? it's not conclusive as it
>>> could take a while to trip in this environment but some of the test
>>> servers have not shown anything bad in almost 24h.
>>
>> Sorry, s/some of the/none of the
>
> I think it is fairly safe to say 4.19 + mlx4 + these 4 commits is OK. At
> least for my workload. Servers are now 51-61 hours in, no splats. I also
> added ntp pool traffic to one of them to make things a little more
> exciting.
>
> Not sure what is needed for 4.18, I dont have the mental bandwidth to
> test that right now. Also no idea about the similar looking mlx5 splats
> reported elsewhere.
As expected conntrack/nat + vlan + forwarding still splats.
sch_cake, IFB and VRF was removed from this setup.
Here is a conntrack splat without IFB/VRF/Cake inteference:
> [34458.506346] wanib: hw csum failure
> [34458.506371] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.0-1 #1
> [34458.506374] Hardware name: Supermicro Super Server/X10SDV-4C-TLN2F, BIOS 2.0 06/13/2018
> [34458.506377] Call Trace:
> [34458.506381] <IRQ>
> [34458.506388] dump_stack+0x5c/0x80
> [34458.506392] __skb_checksum_complete+0xac/0xc0
> [34458.506402] icmp_error+0x1c8/0x1f0 [nf_conntrack]
> [34458.506406] ? skb_copy_bits+0x13d/0x220
> [34458.506411] nf_conntrack_in+0xd8/0x390 [nf_conntrack]
> [34458.506416] ? ___pskb_trim+0x192/0x330
> [34458.506421] nf_hook_slow+0x43/0xc0
> [34458.506426] ip_rcv+0x90/0xb0
> [34458.506430] ? ip_rcv_finish_core.isra.0+0x310/0x310
> [34458.506435] __netif_receive_skb_one_core+0x42/0x50
> [34458.506438] netif_receive_skb_internal+0x24/0xb0
> [34458.506441] napi_gro_frags+0x177/0x210
> [34458.506446] mlx4_en_process_rx_cq+0x8df/0xb50 [mlx4_en]
> [34458.506459] ? mlx4_eq_int+0x38f/0xcb0 [mlx4_core]
> [34458.506463] mlx4_en_poll_rx_cq+0x55/0xf0 [mlx4_en]
> [34458.506466] net_rx_action+0xe1/0x2c0
> [34458.506469] __do_softirq+0xe7/0x2d3
> [34458.506475] irq_exit+0x96/0xd0
> [34458.506478] do_IRQ+0x85/0xd0
> [34458.506483] common_interrupt+0xf/0xf
> [34458.506486] </IRQ>
> [34458.506491] RIP: 0010:cpuidle_enter_state+0xb9/0x320
> [34458.506495] Code: e8 3c 16 bc ff 80 7c 24 0b 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 5e fb c0 ff fb 66 0f 1f 44 00 00 <48> b8 ff ff ff ff f3 01 00 00 48 2b 1c 24 ba ff ff ff 7f 48 39 c3
> [34458.506497] RSP: 0018:ffff978d41943ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdb
> [34458.506500] RAX: ffff8d8f6fa60fc0 RBX: 00001f56ff07af28 RCX: 000000000000001f
> [34458.506501] RDX: 00001f56ff07af28 RSI: 000000003a2e90d6 RDI: 0000000000000000
> [34458.506503] RBP: ffff8d8f6fa698c0 R08: 0000000000000002 R09: 0000000000020840
> [34458.506504] R10: 0004ea58f2899595 R11: ffff8d8f6fa601e8 R12: 0000000000000001
> [34458.506505] R13: ffffffff8a0ac638 R14: 0000000000000001 R15: 0000000000000000
> [34458.506509] ? cpuidle_enter_state+0x94/0x320
> [34458.506512] do_idle+0x1e4/0x220
> [34458.506515] cpu_startup_entry+0x5f/0x70
> [34458.506519] start_secondary+0x185/0x1a0
> [34458.506521] secondary_startup_64+0xa4/0xb0
Stateless filtered non-forwarding host still looks like it has been
fixed (the udp6_gro_* splats are still all gone). Also seems fine when
moving the traffic over a vlan device. These fixes went into 4.19.1-rc1
(checksum_complete + unlink gro packets on overflow fixes)
^ permalink raw reply
* may I ignore "net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes ..."?
From: Toralf Förster @ 2018-11-04 16:14 UTC (permalink / raw)
To: netdev; +Cc: Linux Kernel
compiling recent kernel (4.18.x, 4.19.1) at my server I do still get :
net/core/rtnetlink.c: In function ‘rtnl_newlink’:
net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes is larger than 1024 bytes [-Wframe-larger-than=]
with "gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4) " and do wonder whether it is safe to ignore it?
--
Toralf
PGP C4EACDDE 0076E94E
^ permalink raw reply
* Re: may I ignore "net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes ..."?
From: Joe Perches @ 2018-11-04 17:15 UTC (permalink / raw)
To: Toralf Förster, netdev, Kees Cook; +Cc: Linux Kernel
In-Reply-To: <0cfb892c-b358-4bd6-f7c9-071a0039bc71@gmx.de>
On Sun, 2018-11-04 at 17:14 +0100, Toralf Förster wrote:
> compiling recent kernel (4.18.x, 4.19.1) at my server I do still get :
>
>
> net/core/rtnetlink.c: In function ‘rtnl_newlink’:
> net/core/rtnetlink.c:3156:1: warning: the frame size of 1280 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
>
> with "gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4) " and do wonder whether it is safe to ignore it?
>
This was introduce by a desire to eliminate variable length array
declarations by
commit ccf8dbcd062a930e64741c939ca784d15316aa0c
Author: Kees Cook <
keescook@chromium.org>
Date: Wed May 30 15:20:52 2018 -0700
rtnetlink: Remove VLA usage
It does make the stack use here unfortunately obviously large, but
it could have been this large, just unreported.
Perhaps no obvious solution here as an alloc instead of stack use
may be costly.
^ permalink raw reply
* Re: [RFC] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Shawn Guo @ 2018-11-04 8:45 UTC (permalink / raw)
To: Pankaj Bansal
Cc: Andrew Lunn, Florian Fainelli, Leo Li, netdev@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <HE1PR0402MB3323371C130088B2A26F1627F1F60@HE1PR0402MB3323.eurprd04.prod.outlook.com>
On Wed, Oct 24, 2018 at 01:18:32PM +0000, Pankaj Bansal wrote:
> Hi All,
>
> As per the device tree ePappr https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
> section 2.2.1
>
> Each node in the device tree is named according to the following convention:
> node-name@unit-address
>
> The node-name shall start with a lower or uppercase character and should describe the general class of device.
> The unit-address component of the name is specific to the bus type on which the node sits. It consists of one or more ASCII characters from the set of characters in Table 2-1. The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree.
>
> I am having a hard time following this convention when defining mdio-mux nodes for LX2160AQDS.
> The mdio-mux in LX2160AQDS is controlled by same register in fpga. Only some bits are different for the two buses' mux.
> How to differentiate between the node names for two buses' muxes?
>
> For now I have made their names as mdio-mux@54_f8 and mdio-mux@54_07.
> The first number is register address and second number indicates the bit mask that is used to select the bits from that register for a bus.
No. DTC will report warnings against that, because unit-address has to
match 'reg' property. I would suggest mdio-mux-1@54, mdio-mux-2@54 etc.
Shawn
>
> Any better alternatives?
>
> Regards,
> Pankaj Bansal
>
> -----Original Message-----
> From: Pankaj Bansal
> Sent: Wednesday, October 24, 2018 6:35 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Subject: [RFC] arm64: dts: lx2160aqds: Add mdio mux nodes
>
> The two external MDIO buses used to communicate with phy devices that
> are external to SOC are muxed in LX2160AQDS board.
>
> These buses can be routed to any one of the eight IO slots on LX2160AQDS
> board depending on value in fpga register 0x54.
>
> Additionally the external MDIO1 is used to communicate to the onboard
> RGMII phy devices.
>
> The mdio1 is controlled by bits 4-7 of fpga register and mdio2 is controlled by
> bits 0-3 of fpga register.
>
> Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> ---
>
> Notes:
> This patch depends on below patches:
> [1] https://lore.kernel.org/patchwork/project/lkml/list/?series=369563
> [2] https://patchwork.kernel.org/patch/10645287/
>
> This patch is used by below patches:
> [1]https://patchwork.ozlabs.org/project/netdev/list/?series=69426&state=%2A&archive=both
>
> .../boot/dts/freescale/fsl-lx2160a-qds.dts | 115 +++++++++++++++++
> .../boot/dts/freescale/fsl-lx2160a.dtsi | 22 ++++
> 2 files changed, 137 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> index 99a22abbe725..4b282bf6c36a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> @@ -46,6 +46,121 @@
> &i2c0 {
> status = "okay";
>
> + fpga@66 {
> + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> + reg = <0x66>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mdio-mux@54_f8 {
> + mdio-parent-bus = <&emdio1>;
> + reg = <0x54>; /* BRDCFG4 */
> + mux-mask = <0xf8>; /* EMI1_MDIO */
> + #address-cells=<1>;
> + #size-cells = <0>;
> +
> + mdio@0 {
> + reg = <0x00>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@40 {
> + reg = <0x40>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@c0 {
> + reg = <0xc0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@c8 {
> + reg = <0xc8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@d0 {
> + reg = <0xd0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@d8 {
> + reg = <0xd8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@e0 {
> + reg = <0xe0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@e8 {
> + reg = <0xe8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@f0 {
> + reg = <0xf0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@f8 {
> + reg = <0xf8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + mdio-mux@54_07 {
> + mdio-parent-bus = <&emdio2>;
> + reg = <0x54>; /* BRDCFG4 */
> + mux-mask = <0x07>; /* EMI2_MDIO */
> + #address-cells=<1>;
> + #size-cells = <0>;
> +
> + mdio@0 {
> + reg = <0x00>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@1 {
> + reg = <0x01>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@2 {
> + reg = <0x02>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@3 {
> + reg = <0x03>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@4 {
> + reg = <0x04>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@5 {
> + reg = <0x05>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@6 {
> + reg = <0x06>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + mdio@7 {
> + reg = <0x07>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> + };
> +
> i2c-mux@77 {
> compatible = "nxp,pca9547";
> reg = <0x77>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index 56f846c55812..e16b1643595b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -761,5 +761,27 @@
> <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
> dma-coherent;
> };
> +
> + /* TODO: WRIOP (CCSR?) */
> + emdio1: mdio@0x8B96000 { /* WRIOP0: 0x8B8_0000, E-MDIO1: 0x1_6000 */
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0x0 0x8B96000 0x0 0x1000>;
> + device_type = "mdio"; /* TODO: is this necessary? */
> + little-endian; /* force the driver in LE mode */
> +
> + /* Not necessary on the QDS, but needed on the RDB*/
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + emdio2: mdio@0x8B97000 { /* WRIOP0: 0x8B8_0000, E-MDIO2: 0x1_7000 */
> + compatible = "fsl,fman-memac-mdio";
> + reg = <0x0 0x8B97000 0x0 0x1000>;
> + device_type = "mdio"; /* TODO: is this necessary? */
> + little-endian; /* force the driver in LE mode */
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
> };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] bonding:avoid repeated display of same link status change
From: Michal Kubecek @ 2018-11-04 19:41 UTC (permalink / raw)
To: David Miller
Cc: mk.singh, netdev, eric.dumazet, j.vosburgh, vfalico, andy,
linux-kernel
In-Reply-To: <20181102.233138.738200505012734856.davem@davemloft.net>
On Fri, Nov 02, 2018 at 11:31:38PM -0700, David Miller wrote:
> From: mk.singh@oracle.com
> Date: Wed, 31 Oct 2018 16:27:28 +0530
>
> > - if (slave->delay) {
> > + if (slave->delay &&
> > + !atomic64_read(&bond->rtnl_needed)) {
> ...
> > + !atomic64_read(&bond->rtnl_needed)) {
> ...
> > + atomic64_set(&bond->rtnl_needed, 1);
> ...
> > + atomic64_set(&bond->rtnl_needed, 0);
> ...
> > @@ -229,6 +229,7 @@ struct bonding {
> > struct dentry *debug_dir;
> > #endif /* CONFIG_DEBUG_FS */
> > struct rtnl_link_stats64 bond_stats;
> > + atomic64_t rtnl_needed;
>
> There is nothing "atomic" about a value that is only set and read.
>
> And using a full 64-bit value for something taking on only '0' and
> '1' is unnecessary as well.
Part of the misunderstanding is caused by the fact that this is actually
a v4 but not marked as such:
v1: https://patchwork.ozlabs.org/patch/955789/
v2: https://patchwork.ozlabs.org/patch/970421/
v3: https://patchwork.ozlabs.org/patch/988241/
When commenting v3, I didn't know about the v2 discussion where Eric
Dumazet NACKed the patch because of potential conflict issues:
https://patchwork.ozlabs.org/patch/970421/#1992397
https://patchwork.ozlabs.org/patch/988241/#2017317
On the other hand, there is no need for atomic64_t. Simple atomic_t
(with explaining comment) would suffice. On architectures allowing
atomic read/write for 32-bit integers, there would be no performance
penalty. On architectures not allowing it, atomic_read() and
atomic_set() are implemented to be safe.
Michal Kubecek
^ permalink raw reply
* [PATCH net v2] bonding/802.3ad: fix link_failure_count tracking
From: Jarod Wilson @ 2018-11-04 19:59 UTC (permalink / raw)
To: linux-kernel
Cc: Jarod Wilson, Mahesh Bandewar, David S . Miller, netdev, stable
In-Reply-To: <20181101212240.26768-1-jarod@redhat.com>
Commit 4d2c0cda07448ea6980f00102dc3964eb25e241c set slave->link to
BOND_LINK_DOWN for 802.3ad bonds whenever invalid speed/duplex values
were read, to fix a problem with slaves getting into weird states, but
in the process, broke tracking of link failures, as going straight to
BOND_LINK_DOWN when a link is indeed down (cable pulled, switch rebooted)
means we broke out of bond_miimon_inspect()'s BOND_LINK_DOWN case because
!link_state was already true, we never incremented commit, and never got
a chance to call bond_miimon_commit(), where slave->link_failure_count
would be incremented. I believe the simple fix here is to mark the slave
as BOND_LINK_FAIL, and let bond_miimon_inspect() transition the link from
_FAIL to either _UP or _DOWN, and in the latter case, we now get proper
incrementing of link_failure_count again.
Fixes: 4d2c0cda0744 ("bonding: speed/duplex update at NETDEV_UP event")
CC: Mahesh Bandewar <maheshb@google.com>
CC: David S. Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
CC: stable@vger.kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
---
v2: fix Fixes line
drivers/net/bonding/bond_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ffa37adb7681..333387f1f1fe 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3112,13 +3112,13 @@ static int bond_slave_netdev_event(unsigned long event,
case NETDEV_CHANGE:
/* For 802.3ad mode only:
* Getting invalid Speed/Duplex values here will put slave
- * in weird state. So mark it as link-down for the time
+ * in weird state. So mark it as link-fail for the time
* being and let link-monitoring (miimon) set it right when
* correct speeds/duplex are available.
*/
if (bond_update_speed_duplex(slave) &&
BOND_MODE(bond) == BOND_MODE_8023AD)
- slave->link = BOND_LINK_DOWN;
+ slave->link = BOND_LINK_FAIL;
if (BOND_MODE(bond) == BOND_MODE_8023AD)
bond_3ad_adapter_speed_duplex_changed(slave);
--
2.16.1
^ permalink raw reply related
* Re: [PATCH iproute2-next v1 4/4] rdma: Document IB device renaming option
From: Leon Romanovsky @ 2018-11-04 11:12 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, RDMA mailing list, Stephen Hemminger, Steve Wise
In-Reply-To: <bb0836d9-6ebb-3383-3d61-8347d0d72561@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
On Fri, Nov 02, 2018 at 10:47:16AM -0600, David Ahern wrote:
> On 10/31/18 1:17 AM, Leon Romanovsky wrote:
> > diff --git a/man/man8/rdma-dev.8 b/man/man8/rdma-dev.8
> > index 461681b6..b2f9964a 100644
> > --- a/man/man8/rdma-dev.8
> > +++ b/man/man8/rdma-dev.8
> > @@ -22,6 +22,12 @@ rdmak-dev \- RDMA device configuration
> > .B rdma dev show
> > .RI "[ " DEV " ]"
> >
> > +.ti -8
> > +.B rdma dev set
> > +.RI "[ " DEV " ]"
> > +.BR name
> > +.BR NEWNAME
> > +
> > .ti -8
> > .B rdma dev help
> >
> > @@ -33,6 +39,8 @@ rdmak-dev \- RDMA device configuration
> > - specifies the RDMA device to show.
> > If this argument is omitted all devices are listed.
> >
> > +.SS rdma dev set - rename rdma device
> > +
>
> 'nroff -u0 -Tlp -man man/man8/rdma-dev.8' shows that you lost the
> spacing between that line and the Examples line.
>
> rdma dev set - rename rdma device
> EXAMPLES
> rdma dev
> Shows the state of all RDMA devices on the system.
Thanks, sending v2 now.
>
> ...
>
>
> > .SH "EXAMPLES"
> > .PP
> > rdma dev
> > @@ -45,6 +53,11 @@ rdma dev show mlx5_3
> > Shows the state of specified RDMA device.
> > .RE
> > .PP
> > +rdma dev set mlx5_3 name rdma_0
> > +.RS 4
> > +Renames the mlx5_3 device to be named rdma_0.
>
> That does not read well. I suggest dropping the 'be named' to make it
> "Renames the mlx5_3 device to rdma_0."
>
> > +.RE
> > +.PP
> >
> > .SH SEE ALSO
> > .BR rdma (8),
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH iproute2-next v2] rdma: Document IB device renaming option
From: Leon Romanovsky @ 2018-11-04 11:54 UTC (permalink / raw)
To: David Ahern; +Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
From: Leon Romanovsky <leonro@mellanox.com>
[leonro@server /]$ lspci |grep -i Ether
00:08.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:09.0 Ethernet controller: Mellanox Technologies MT27700 Family [ConnectX-4]
[leonro@server /]$ sudo rdma dev
1: mlx5_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455
sys_image_guid 5254:00c0:fe12:3455
[leonro@server /]$ sudo rdma dev set mlx5_0 name hfi1_0
[leonro@server /]$ sudo rdma dev
1: hfi1_0: node_type ca fw 3.8.9999 node_guid 5254:00c0:fe12:3455
sys_image_guid 5254:00c0:fe12:3455
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
Changelog v1->v2:
* Restored lost spacing above Example section
* Fixed old spelling mistake: rdmak-dev -> rdma-dev.
----
man/man8/rdma-dev.8 | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/man/man8/rdma-dev.8 b/man/man8/rdma-dev.8
index 461681b6..86921578 100644
--- a/man/man8/rdma-dev.8
+++ b/man/man8/rdma-dev.8
@@ -1,6 +1,6 @@
.TH RDMA\-DEV 8 "06 Jul 2017" "iproute2" "Linux"
.SH NAME
-rdmak-dev \- RDMA device configuration
+rdma-dev \- RDMA device configuration
.SH SYNOPSIS
.sp
.ad l
@@ -22,10 +22,18 @@ rdmak-dev \- RDMA device configuration
.B rdma dev show
.RI "[ " DEV " ]"
+.ti -8
+.B rdma dev set
+.RI "[ " DEV " ]"
+.BR name
+.BR NEWNAME
+
.ti -8
.B rdma dev help
.SH "DESCRIPTION"
+.SS rdma dev set - rename rdma device
+
.SS rdma dev show - display rdma device attributes
.PP
@@ -45,6 +53,11 @@ rdma dev show mlx5_3
Shows the state of specified RDMA device.
.RE
.PP
+rdma dev set mlx5_3 name rdma_0
+.RS 4
+Renames the mlx5_3 device to be named rdma_0.
+.RE
+.PP
.SH SEE ALSO
.BR rdma (8),
^ permalink raw reply related
* Re: [PATCH iproute2-next v2] rdma: Document IB device renaming option
From: David Ahern @ 2018-11-04 14:26 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Leon Romanovsky, netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <20181104115405.9455-1-leon@kernel.org>
On 11/4/18 4:54 AM, Leon Romanovsky wrote:
> @@ -45,6 +53,11 @@ rdma dev show mlx5_3
> Shows the state of specified RDMA device.
> .RE
> .PP
> +rdma dev set mlx5_3 name rdma_0
> +.RS 4
> +Renames the mlx5_3 device to be named rdma_0.
> +.RE
> +.PP
You missed my other comment: Fix the "Renames .... to be named ..."
^ permalink raw reply
* Re: [PATCH net v2] bonding/802.3ad: fix link_failure_count tracking
From: David Miller @ 2018-11-05 0:45 UTC (permalink / raw)
To: jarod; +Cc: linux-kernel, maheshb, netdev, stable
In-Reply-To: <20181104195946.33861-1-jarod@redhat.com>
From: Jarod Wilson <jarod@redhat.com>
Date: Sun, 4 Nov 2018 14:59:46 -0500
> Commit 4d2c0cda07448ea6980f00102dc3964eb25e241c set slave->link to
> BOND_LINK_DOWN for 802.3ad bonds whenever invalid speed/duplex values
> were read, to fix a problem with slaves getting into weird states, but
> in the process, broke tracking of link failures, as going straight to
> BOND_LINK_DOWN when a link is indeed down (cable pulled, switch rebooted)
> means we broke out of bond_miimon_inspect()'s BOND_LINK_DOWN case because
> !link_state was already true, we never incremented commit, and never got
> a chance to call bond_miimon_commit(), where slave->link_failure_count
> would be incremented. I believe the simple fix here is to mark the slave
> as BOND_LINK_FAIL, and let bond_miimon_inspect() transition the link from
> _FAIL to either _UP or _DOWN, and in the latter case, we now get proper
> incrementing of link_failure_count again.
>
> Fixes: 4d2c0cda0744 ("bonding: speed/duplex update at NETDEV_UP event")
> CC: Mahesh Bandewar <maheshb@google.com>
> CC: David S. Miller <davem@davemloft.net>
> CC: netdev@vger.kernel.org
> CC: stable@vger.kernel.org
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
> ---
> v2: fix Fixes line
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next v4 0/9] vrf: allow simultaneous service instances in default and other VRFs
From: David Ahern @ 2018-11-04 15:52 UTC (permalink / raw)
To: Mike Manning, netdev, David Miller
In-Reply-To: <20181102191020.14170-1-mmanning@vyatta.att-mail.com>
On 11/2/18 1:10 PM, Mike Manning wrote:
> Services currently have to be VRF-aware if they are using an unbound
> socket. One cannot have multiple service instances running in the
> default and other VRFs for services that are not VRF-aware and listen
> on an unbound socket. This is because there is no easy way of isolating
> packets received in the default VRF from those arriving in other VRFs.
>
> This series provides this isolation for stream sockets subject to the
> existing kernel parameter net.ipv4.tcp_l3mdev_accept not being set,
> given that this is documented as allowing a single service instance to
> work across all VRF domains. Similarly, net.ipv4.udp_l3mdev_accept is
> checked for datagram sockets, and net.ipv4.raw_l3mdev_accept is
> introduced for raw sockets. The functionality applies to UDP & TCP
> services as well as those using raw sockets, and is for IPv4 and IPv6.
>
> Example of running ssh instances in default and blue VRF:
>
> $ /usr/sbin/sshd -D
> $ ip vrf exec vrf-blue /usr/sbin/sshd
> $ ss -ta | egrep 'State|ssh'
> State Recv-Q Send-Q Local Address:Port Peer Address:Port
> LISTEN 0 128 0.0.0.0%vrf-blue:ssh 0.0.0.0:*
> LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
> ESTAB 0 0 192.168.122.220:ssh 192.168.122.1:50282
> LISTEN 0 128 [::]%vrf-blue:ssh [::]:*
> LISTEN 0 128 [::]:ssh [::]:*
> ESTAB 0 0 [3000::2]%vrf-blue:ssh [3000::9]:45896
> ESTAB 0 0 [2000::2]:ssh [2000::9]:46398
>
DaveM:
I will take a look at this set the early part of this week. I just need
a few days. Thanks,
^ permalink raw reply
* Re: [PATCH 0/1] vhost: parallel virtqueue handling
From: Jason Wang @ 2018-11-05 2:51 UTC (permalink / raw)
To: Vitaly Mayatskikh, Michael S . Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20181102160710.3741-1-v.mayatskih@gmail.com>
On 2018/11/3 上午12:07, Vitaly Mayatskikh wrote:
> Hi,
>
> I stumbled across poor performance of virtio-blk while working on a
> high-performance network storage protocol. Moving virtio-blk's host
> side to kernel did increase single queue IOPS, but multiqueue disk
> still was not scaling well. It turned out that vhost handles events
> from all virtio queues in one helper thread, and that's pretty much a
> big serialization point.
>
> The following patch enables events handling in per-queue thread and
> increases IO concurrency, see IOPS numbers:
Thanks a lot for the patches. Here's some thoughts:
- This is not the first attempt that tries to parallelize vhost workers.
So we need a comparing among them.
1) Multiple vhost workers from Anthony,
https://www.spinics.net/lists/netdev/msg189432.html
2) ELVIS from IBM, http://www.mulix.org/pubs/eli/elvis-h319.pdf
3) CMWQ from Bandan,
http://www.linux-kvm.org/images/5/52/02x08-Aspen-Bandan_Das-vhost-sharing_is_better.pdf
- vhost-net use a different multiqueue model. Each vhost device on host
is only dealing with a specific queue pair instead of a whole device.
This allow great flexibility and multiqueue could be implemented without
touching vhost codes.
- current vhost-net implementation depends heavily on the assumption of
single thread model especially its busy polling code. It would be broken
by this attempt. If we decide to go this way, this needs to be fixed.
And we do need performance result of networking.
- Having more threads is not necessarily a win, at least we need a
module parameter to other stuffs to control the number of threads I
believe.
Thanks
>
> # num-queues
> # bare metal
> # virtio-blk
> # vhost-blk
>
> 1 171k 148k 195k
> 2 328k 249k 349k
> 3 479k 179k 501k
> 4 622k 143k 620k
> 5 755k 136k 737k
> 6 887k 131k 830k
> 7 1004k 126k 926k
> 8 1099k 117k 1001k
> 9 1194k 115k 1055k
> 10 1278k 109k 1130k
> 11 1345k 110k 1119k
> 12 1411k 104k 1201k
> 13 1466k 106k 1260k
> 14 1517k 103k 1296k
> 15 1552k 102k 1322k
> 16 1480k 101k 1346k
>
> Vitaly Mayatskikh (1):
> vhost: add per-vq worker thread
>
> drivers/vhost/vhost.c | 123 +++++++++++++++++++++++++++++++-----------
> drivers/vhost/vhost.h | 11 +++-
> 2 files changed, 100 insertions(+), 34 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/1] vhost: add per-vq worker thread
From: Jason Wang @ 2018-11-05 2:53 UTC (permalink / raw)
To: Vitaly Mayatskikh, Michael S . Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20181102160710.3741-2-v.mayatskih@gmail.com>
On 2018/11/3 上午12:07, Vitaly Mayatskikh wrote:
> +
> +static int vhost_vq_poll_start(struct vhost_virtqueue *vq)
> +{
> + if (!vq->worker) {
> + vq->worker = kthread_create(vhost_vq_worker, vq, "vhost-%d/%i",
> + vq->dev->pid, vq->index);
> + if (IS_ERR(vq->worker)) {
> + int ret = PTR_ERR(vq->worker);
> +
> + pr_err("%s: can't create vq worker: %d\n", __func__,
> + ret);
> + vq->worker = NULL;
> + return ret;
> + }
> + }
> + vhost_work_init(&vq->work, vhost_vq_poll_start_work);
> + vhost_vq_work_queue(vq, &vq->work);
> + return 0;
> +}
> +
I wonder whether or not it's better to allow the device to specific the
worker here instead of forcing a per vq worker model. Then we can keep
the behavior of exist implementation and do optimization on top?
Thanks
^ permalink raw reply
* [PATCH] net: phy: realtek: fix RTL8201F sysfs name
From: Holger Hoffstätte @ 2018-11-04 18:02 UTC (permalink / raw)
To: Netdev, David S. Miller
Since 4.19 the following error in sysfs has appeared when using the
r8169 NIC driver:
$cd /sys/module/realtek/drivers
$ls -l
ls: cannot access 'mdio_bus:RTL8201F 10/100Mbps Ethernet': No such file or directory
[..garbled dir entries follow..]
Apparently the forward slash in "10/100Mbps Ethernet" is interpreted
as directory separator that leads nowhere, and was introduced in commit
513588dd44b ("net: phy: realtek: add RTL8201F phy-id and functions").
Fix this by removing the offending slash in the driver name.
Other drivers in net/phy seem to have the same problem, but I cannot
test/verify them.
Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
---
drivers/net/phy/realtek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 7fc8508b5231..271e8adc39f1 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -220,7 +220,7 @@ static struct phy_driver realtek_drvs[] = {
.flags = PHY_HAS_INTERRUPT,
}, {
.phy_id = 0x001cc816,
- .name = "RTL8201F 10/100Mbps Ethernet",
+ .name = "RTL8201F Fast Ethernet",
.phy_id_mask = 0x001fffff,
.features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 1/1] vhost: add per-vq worker thread
From: Vitaly Mayatskih @ 2018-11-05 3:28 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S . Tsirkin, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <fe79c7fd-1e9f-dab8-3c65-8151181c922c@redhat.com>
On Sun, Nov 4, 2018 at 9:53 PM Jason Wang <jasowang@redhat.com> wrote:
> I wonder whether or not it's better to allow the device to specific the
> worker here instead of forcing a per vq worker model. Then we can keep
> the behavior of exist implementation and do optimization on top?
I was thinking about that too, but for the sake of simplicity it
sounds valid that if the user wanted 8 parallel queues for the disk,
they better be parallel, i.e. worker per queue. The rest of disks that
don't need high-performance, can have 1 queue specified.
--
wbr, Vitaly
^ permalink raw reply
* Re: [PATCH net-next v4 0/9] vrf: allow simultaneous service instances in default and other VRFs
From: David Miller @ 2018-11-04 18:23 UTC (permalink / raw)
To: dsahern; +Cc: mmanning, netdev
In-Reply-To: <28e37d43-9581-d84b-ebae-fdea8ee02242@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Sun, 4 Nov 2018 08:52:26 -0700
> I will take a look at this set the early part of this week. I just need
> a few days. Thanks,
No rush, net-next is closed so it will need to be resubmitted when it opens
back up anyways.
^ permalink raw reply
* Re: [PATCH 0/1] vhost: parallel virtqueue handling
From: Vitaly Mayatskih @ 2018-11-05 3:40 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S . Tsirkin, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <baca6444-0ef8-2b3b-4ff9-84737f4ecd32@redhat.com>
On Sun, Nov 4, 2018 at 9:52 PM Jason Wang <jasowang@redhat.com> wrote:
> Thanks a lot for the patches. Here's some thoughts:
>
> - This is not the first attempt that tries to parallelize vhost workers.
> So we need a comparing among them.
>
> 1) Multiple vhost workers from Anthony,
> https://www.spinics.net/lists/netdev/msg189432.html
>
> 2) ELVIS from IBM, http://www.mulix.org/pubs/eli/elvis-h319.pdf
>
> 3) CMWQ from Bandan,
> http://www.linux-kvm.org/images/5/52/02x08-Aspen-Bandan_Das-vhost-sharing_is_better.pdf
>
> - vhost-net use a different multiqueue model. Each vhost device on host
> is only dealing with a specific queue pair instead of a whole device.
> This allow great flexibility and multiqueue could be implemented without
> touching vhost codes.
I'm no way a network expert, but I think this is because it follows a
combined queue model of the NIC. Having a TX/RX queues pair looks like
a natural choice for this case.
> - current vhost-net implementation depends heavily on the assumption of
> single thread model especially its busy polling code. It would be broken
> by this attempt. If we decide to go this way, this needs to be fixed.
> And we do need performance result of networking.
Thanks for noting that, I miss a lot of historical background. Will
check that up.
> - Having more threads is not necessarily a win, at least we need a
> module parameter to other stuffs to control the number of threads I
> believe.
I agree I didn't think fully about other cases, but for the disk it is
already under controll: QEMU's num-queues disk parameter.
There's a certain saturation point when adding more threads does not
yield lot more more performance. For my environment it's about 12
queues.
So, how does it sound: the default behaviour is 1 worker per vhost
device. If the user needs per-vq worker he does a new VHOST_SET_
ioctl?
--
wbr, Vitaly
^ permalink raw reply
* Re: [PATCH] net: phy: realtek: fix RTL8201F sysfs name
From: Andrew Lunn @ 2018-11-04 18:43 UTC (permalink / raw)
To: Holger Hoffstätte; +Cc: Netdev, David S. Miller
In-Reply-To: <ddd70b86-1b30-9b04-6482-0487fa241648@applied-asynchrony.com>
On Sun, Nov 04, 2018 at 07:02:42PM +0100, Holger Hoffstätte wrote:
> Since 4.19 the following error in sysfs has appeared when using the
> r8169 NIC driver:
>
> $cd /sys/module/realtek/drivers
> $ls -l
> ls: cannot access 'mdio_bus:RTL8201F 10/100Mbps Ethernet': No such file or directory
> [..garbled dir entries follow..]
>
> Apparently the forward slash in "10/100Mbps Ethernet" is interpreted
> as directory separator that leads nowhere, and was introduced in commit
> 513588dd44b ("net: phy: realtek: add RTL8201F phy-id and functions").
>
> Fix this by removing the offending slash in the driver name.
>
> Other drivers in net/phy seem to have the same problem, but I cannot
> test/verify them.
>
> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Fixes:513588dd44b ("net: phy: realtek: add RTL8201F phy-id and functions").
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
David, please apply to net.
Andrew
^ permalink raw reply
* Re: [PATCH] net: phy: realtek: fix RTL8201F sysfs name
From: Andrew Lunn @ 2018-11-04 18:47 UTC (permalink / raw)
To: Holger Hoffstätte; +Cc: Netdev, David S. Miller
In-Reply-To: <ddd70b86-1b30-9b04-6482-0487fa241648@applied-asynchrony.com>
On Sun, Nov 04, 2018 at 07:02:42PM +0100, Holger Hoffstätte wrote:
> Since 4.19 the following error in sysfs has appeared when using the
> r8169 NIC driver:
>
> $cd /sys/module/realtek/drivers
> $ls -l
> ls: cannot access 'mdio_bus:RTL8201F 10/100Mbps Ethernet': No such file or directory
> [..garbled dir entries follow..]
>
> Apparently the forward slash in "10/100Mbps Ethernet" is interpreted
> as directory separator that leads nowhere, and was introduced in commit
> 513588dd44b ("net: phy: realtek: add RTL8201F phy-id and functions").
>
> Fix this by removing the offending slash in the driver name.
>
> Other drivers in net/phy seem to have the same problem, but I cannot
> test/verify them.
Hi Holger
This last comment would generally be placed after the ---. It will
then not appear in the commit message.
Also, in future, please put the target tree, net or net-next as part
of the subject line:
[PATCH net] ....
Thanks
Andrew
^ permalink raw reply
* Re: [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets
From: Eric Dumazet @ 2018-11-04 18:58 UTC (permalink / raw)
To: Jana Iyengar, Ian Swett
Cc: Christoph Paasch, willemdebruijn.kernel, netdev, lhedstrom
In-Reply-To: <CACpbDccs6WmLCknpu2GLMMBnkHwS4apsr3Z3sAKt4Ch_2HPwgg@mail.gmail.com>
On 11/04/2018 02:45 AM, Jana Iyengar wrote:
> I think SO_TXTIME solves the most egregious problem I have with using sched_fq for QUIC. That's a great help, so thank you!
>
> That said, as Ian says, SO_TXTIME does not allow for the flow isolation properties of sched_fq, which would be a nice secondary benefit. I suspect that can also be done in a similar manner to SO_TXTIME -- by attaching an opaque label to each sendmsg which is used by sched_fq to determine the flow. Is that feasible?
The plan is to have flow isolation, without having to change applications to provide a flow identifier,
since we can not trust user applications anyway.
FQ will perform a proper flow dissection for packets sent over unconnected UDP sockets.
FQ has two parts [1], one being used by locally generated packets (local TCP stack),
one being used in forwarding workloads.
The patch which I will send shortly (when net-next reopens)
will only make sure FQ does not use skb->sk as a flow identifier
if the socket is not a connected one.
[1] See commit 06eb395fa9856b5a87cf7d80baee2a0ed3cdb9d7 for some details.
^ permalink raw reply
* Re: [PATCH iproute2-next v2] rdma: Document IB device renaming option
From: Leon Romanovsky @ 2018-11-04 19:00 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, RDMA mailing list, Stephen Hemminger
In-Reply-To: <07ffbccc-916c-25d3-654e-7e457be3c133@gmail.com>
On Sun, Nov 04, 2018 at 07:26:24AM -0700, David Ahern wrote:
> On 11/4/18 4:54 AM, Leon Romanovsky wrote:
> > @@ -45,6 +53,11 @@ rdma dev show mlx5_3
> > Shows the state of specified RDMA device.
> > .RE
> > .PP
> > +rdma dev set mlx5_3 name rdma_0
> > +.RS 4
> > +Renames the mlx5_3 device to be named rdma_0.
> > +.RE
> > +.PP
>
> You missed my other comment: Fix the "Renames .... to be named ..."
Sorry, my bad.
I'm resending it right now.
Thanks
^ 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