* Re: [PATCH] net: phy: marvell: avoid configuring fiber page for SGMII-to-Copper
From: David Miller @ 2017-12-13 21:13 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, jon, netdev
In-Reply-To: <E1eP3Ep-0000ZC-UN@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Wed, 13 Dec 2017 09:22:03 +0000
> When in SGMII-to-Copper mode, the fiber page is used for the MAC facing
> link, and does not require configuration of the fiber auto-negotiation
> settings. Avoid trying.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net] dwc-xlgmac: Add co-maintainer
From: David Miller @ 2017-12-13 21:13 UTC (permalink / raw)
To: Jie.Deng1; +Cc: netdev, Jose.Abreu
In-Reply-To: <7629e8d0cb525682e3392696bc1b642351e47f98.1493987088.git.jiedeng@synopsys.com>
From: Jie Deng <Jie.Deng1@synopsys.com>
Date: Wed, 13 Dec 2017 12:04:12 +0800
> Jose Abreu will join to maintain dwc-xlgmac.
> He will help with new feature development for
> this driver. Thanks Jose and welcome on board!
>
> Signed-off-by: Jie Deng <jiedeng@synopsys.com>
Applied.
^ permalink raw reply
* Re: Huge memory leak with 4.15.0-rc2+
From: John Fastabend @ 2017-12-13 21:05 UTC (permalink / raw)
To: Paweł Staszewski, Linux Kernel Network Developers
In-Reply-To: <1b1f58e6-3af1-8b14-142d-06deeb458e3b@itcare.pl>
On 12/12/2017 09:57 AM, Paweł Staszewski wrote:
>
>
> W dniu 2017-12-11 o 23:27, Paweł Staszewski pisze:
>>
>>
>> W dniu 2017-12-11 o 23:15, John Fastabend pisze:
>>> On 12/11/2017 01:48 PM, Paweł Staszewski wrote:
>>>>
>>>> W dniu 2017-12-11 o 22:23, Paweł Staszewski pisze:
>>>>> Hi
>>>>>
>>>>>
>>>>> I just upgraded some testing host to 4.15.0-rc2+ kernel
>>>>>
>>>>> And after some time of traffic processing - when traffic on all ports
>>>>> reach about 3Mpps - memleak started.
>>>>>
>>>
>>> [...]
>>>
>>>>> Some observations - when i disable tso on all cards there is more
>>>>> memleak.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> When traffic starts to drop - there is less and less memleak
>>>> below link to memory usage graph:
>>>> https://ibb.co/hU97kG
>>>>
>>>> And there is rising slab_unrecl - Amount of unreclaimable memory used
>>>> for slab kernel allocations
>>>>
>>>>
>>>> Forgot to add that im using hfsc and qdiscs like pfifo on classes.
>>>>
>>>>
>>> Maybe some error case I missed in the qdisc patches I'm looking into
>>> it.
>>>
>>> Thanks,
>>> John
>>>
>>>
>> This is how it looks like when corelated on graph - traffic vs mem
>> https://ibb.co/njpkqG
>>
>> Typical hfsc class + qdisc:
>> ### Client interface vlan1616
>> tc qdisc del dev vlan1616 root
>> tc qdisc add dev vlan1616 handle 1: root hfsc default 100
>> tc class add dev vlan1616 parent 1: classid 1:100 hfsc ls m2 200Mbit ul m2 200Mbit
>> tc qdisc add dev vlan1616 parent 1:100 handle 100: pfifo limit 128
>> ### End TM for client interface
>> tc qdisc del dev vlan1616 ingress
>> tc qdisc add dev vlan1616 handle ffff: ingress
>> tc filter add dev vlan1616 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 200Mbit burst 200M mtu 32k drop flowid 1:1
>>
>> And this is same for about 450 vlan interfaces
>>
>>
>> Good thing is that compared to 4.14.3 i have about 5% less cpu load on 4.15.0-rc2+
>>
>> When hfsc will be lockless or tbf - then it will be really huge difference in cpu load on x86 when using traffic shaping - so really good job John.
>>
>>
>>
>>
>
> Yestarday changed kernel from
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>
> to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v4.15-rc3
>
>
> And there is no memleak.
> So yes probabbly lockless qdisc patches
>
It seems I was able to produce a similar memleak with qdisc patches
reverted and running TCP traffic overnight. I guess we can do a bisect
and track it down. Will try to get a "good" run tonight.
Thanks,
John
^ permalink raw reply
* Re: [PATCH net] tcp: refresh tcp_mstamp from timers callbacks
From: David Miller @ 2017-12-13 21:04 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, soheil, ncardwell, maloney
In-Reply-To: <1513131772.25033.60.camel@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Dec 2017 18:22:52 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Only the retransmit timer currently refreshes tcp_mstamp
>
> We should do the same for delayed acks and keepalives.
>
> Even if RFC 7323 does not request it, this is consistent to what linux
> did in the past, when TS values were based on jiffies.
>
> Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] tcp: fix potential underestimation on rcv_rtt
From: David Miller @ 2017-12-13 21:03 UTC (permalink / raw)
To: weiwan; +Cc: netdev, edumazet
In-Reply-To: <20171213002858.74188-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Tue, 12 Dec 2017 16:28:58 -0800
> From: Wei Wang <weiwan@google.com>
>
> When ms timestamp is used, current logic uses 1us in
> tcp_rcv_rtt_update() when the real rcv_rtt is within 1 - 999us.
> This could cause rcv_rtt underestimation.
> Fix it by always using a min value of 1ms if ms timestamp is used.
>
> Fixes: 645f4c6f2ebd ("tcp: switch rcv_rtt_est and rcvq_space to high
> resolution timestamps")
>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Please, in the future, do not wrap long Fixes: tag lines. Also, do
not add an empty line between Fixes: and other tags like Signed-off-by.
That are all tags and belong together as a seamless block of text.
Thank you.
^ permalink raw reply
* Re: net: phy: consolidate PHY reset in phy_init_hw()
From: Daniel Walker @ 2017-12-13 21:03 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20171213203512.GC932@lunn.ch>
On 12/13/2017 12:35 PM, Andrew Lunn wrote:
> On Wed, Dec 13, 2017 at 10:46:02AM -0800, Daniel Walker wrote:
>> Hi,
>>
>> https://sjc-apl-grt32.cisco.com:8081/gitweb?p=xe-linux/kernel.git;a=commit;h=87aa9f9c61ad56d505641681812e92ad976f8608
> Hi Daniel
>
> This is a 4 year old patch, so i'm kind of surprised nobody noticed
> this before. How did you conclude this patch is the problem?
>
> Thanks
> Andrew
I just did some debugging to find the -ETIMEDOUT error message which I
tracked back to the waiting routine inside this patch. I did do a high
level bisect jumping between major versions, and the issue seemed to go
away around the time when this patch was added. v3.10 didn't have it,
and one of the version of the kernel immediately after had it, either
v3.11 or v3.12 ..
This phy may not be used often, that might be part of it.
Daniel
^ permalink raw reply
* Re: [PATCH net-next 0/6] hv_netvsc: minor changes
From: David Miller @ 2017-12-13 20:57 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20171213004840.17507-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 12 Dec 2017 16:48:34 -0800
> This includes minor cleanup of code in send and receive path and
> also a new statistic to check for allocation failures. This also
> eliminates some of the extra RCU when not needed.
>
> There is a theoritical bug where buffered data could be blocked
> for longer than necessary if the ring buffer got full. This
> has not been seen in the wild, found by inspection.
>
> The reference count between net device and internal RNDIS
> is not needed.
Series applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] PHYLINK preparatory patches for DSA
From: David Miller @ 2017-12-13 20:55 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, rmk+kernel, andrew, vivien.didelot
In-Reply-To: <20171213000029.8649-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 12 Dec 2017 16:00:24 -0800
> In preparation for having DSA migrate to PHYLINK, I had to come up with a
> number of preparatory patches:
>
> - we need to be able to pass phy_flags from an external component calling
> phylink_of_phy_connect()
> - DSA tries to connect through OF first, then fallsback using its own internal
> MDIO bus, in that case we would both show an error, but also not know what
> the correct phy_interface_t would be, instead use the PHY device/driver provided
> one
> - Finally bcm_sf2 makes use of all possible PHYs out there: internal, external,
> fixed, and MoCA, the latter requires a bit of help to signal link notifications
> through a MMIO interrupt, as well a report a correct PORT type
>
> Changes in v2:
>
> - rebased against latest net-next/master
> - added kernel doc documentation
> - dropped error message in phylink_of_phy_connect() as suggested by Russell
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATH net-next] tcp: pause Fast Open globally after third consecutive timeout
From: David Miller @ 2017-12-13 20:51 UTC (permalink / raw)
To: ycheng; +Cc: netdev, edumazet, ncardwell, weiwan, cpaasch, ddamjanovic,
mcmanus
In-Reply-To: <20171212211040.222118-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Tue, 12 Dec 2017 13:10:40 -0800
> Prior to this patch, active Fast Open is paused on a specific
> destination IP address if the previous connections to the
> IP address have experienced recurring timeouts . But recent
> experiments by Microsoft (https://goo.gl/cykmn7) and Mozilla
> browsers indicate the isssue is often caused by broken middle-boxes
> sitting close to the client. Therefore it is much better user
> experience if Fast Open is disabled out-right globally to avoid
> experiencing further timeouts on connections toward other
> destinations.
>
> This patch changes the destination-IP disablement to global
> disablement if a connection experiencing recurring timeouts
> or aborts due to timeout. Repeated incidents would still
> exponentially increase the pause time, starting from an hour.
> This is extremely conservative but an unfortunate compromise to
> minimize bad experience due to broken middle-boxes.
>
> Reported-by: Dragana Damjanovic <ddamjanovic@mozilla.com>
> Reported-by: Patrick McManus <mcmanus@ducksong.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Reviewed-by: Wei Wang <weiwan@google.com>
> Reviewed-by: Neal Cardwell <ncardwell@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Very unfortunate, but I can't suggest anything better at this time.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: ethernet: ti: cpdma: correct error handling for chan create
From: David Miller @ 2017-12-13 20:51 UTC (permalink / raw)
To: ivan.khoronzhuk; +Cc: grygorii.strashko, netdev, linux-omap, linux-kernel
In-Reply-To: <1513112795-20045-1-git-send-email-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 12 Dec 2017 23:06:35 +0200
> It's not correct to return NULL when that is actually an error and
> function returns errors in any other wrong case. In the same time,
> the cpsw driver and davinci emac doesn't check error case while
> creating channel and it can miss actual error. Also remove WARNs
> replacing them on dev_err msgs.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add support for ethtool i2c dump
From: David Miller @ 2017-12-13 20:49 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, arjun, leedom
In-Reply-To: <1513107245-13703-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 13 Dec 2017 01:04:05 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> Adds support for ethtool get_module_info() and get_module_eeprom()
> callbacks that will dump necessary information for a SFP.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] skge: remove redundunt free_irq under spinlock
From: David Miller @ 2017-12-13 20:47 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20171212183029.28684-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 12 Dec 2017 10:30:29 -0800
> The code to handle multi-port SKGE boards was freeing IRQ
> twice. The first one was under lock and might sleep.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> Given that multi-port SKGE devices are very old and unlikely
> to still be in use. This patch does not need to go to stable.
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next v4 4/5] bnx2x: Use NETIF_F_GRO_HW.
From: Michael Chan @ 2017-12-13 20:45 UTC (permalink / raw)
To: Chopra, Manish
Cc: davem@davemloft.net, netdev@vger.kernel.org,
andrew.gospodarek@broadcom.com, Elior, Ariel,
Dept-Eng Everest Linux L2
In-Reply-To: <BN3PR0701MB1412837727C4AB036434737289350@BN3PR0701MB1412.namprd07.prod.outlook.com>
On Wed, Dec 13, 2017 at 1:08 AM, Chopra, Manish
<Manish.Chopra@cavium.com> wrote:
>
> Hi Michael, There seems a behavioral change here. This driver support two HW aggregation modes [LRO and GRO]
> With the changes, Interfaces come with HW GRO enabled and LRO disabled by default as opposed to earlier where interfaces used to come with LRO enabled.
Right. Before, you had both NETIF_F_GRO and NETIF_F_LRO set and the
code looked at NETIF_F_LRO first and turned on LRO.
Now, we set NETIF_F_GRO and NETIF_F_GRO_HW by default. NETIF_F_LRO is
turned off since NETIF_F_GRO_HW is on.
If you want, I can change it back to the old default.
>
> Also, there seems some problem when turning on LRO even after GRO disable.
> When I tried to disable GRO and then tried to enable LRO it didn't go well. Not sure why ?
I just put an old BCM57810 card into my machine and it works for me.
As long as I turn off GRO or GRO_HW, I can turn on LRO.
[root@localhost bnx2x]# ethtool -K p1p1 lro on
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
Could not change any device features
[root@localhost bnx2x]# ethtool -K p1p1 gro off
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
Actual changes:
generic-receive-offload: off
large-receive-offload: on
rx-gro-hw: off [requested on]
[root@localhost bnx2x]# ethtool -K p1p1 lro on
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
^ permalink raw reply
* Re: net: phy: consolidate PHY reset in phy_init_hw()
From: Andrew Lunn @ 2017-12-13 20:35 UTC (permalink / raw)
To: Daniel Walker; +Cc: Florian Fainelli, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <e03a30bf-9af0-2375-0b50-6fd2766c2249@cisco.com>
On Wed, Dec 13, 2017 at 10:46:02AM -0800, Daniel Walker wrote:
>
> Hi,
>
> https://sjc-apl-grt32.cisco.com:8081/gitweb?p=xe-linux/kernel.git;a=commit;h=87aa9f9c61ad56d505641681812e92ad976f8608
Hi Daniel
This is a 4 year old patch, so i'm kind of surprised nobody noticed
this before. How did you conclude this patch is the problem?
Thanks
Andrew
^ permalink raw reply
* [PATCH] Fix handling of verdicts after NF_QUEUE
From: Debabrata Banerjee @ 2017-12-13 20:33 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Greg Kroah-Hartman, David S . Miller, netfilter-devel, coreteam,
netdev, stable, dbanerje
A verdict of NF_STOLEN after NF_QUEUE will cause an incorrect return value
and a potential kernel panic via double free of skb's
This was broken by commit 7034b566a4e7 ("netfilter: fix nf_queue handling")
and subsequently fixed in v4.10 by commit c63cbc460419 ("netfilter:
use switch() to handle verdict cases from nf_hook_slow()"). However that
commit cannot be cleanly cherry-picked to v4.9
Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
---
This fix is only needed for v4.9 stable since v4.10+ does not have the
issue
---
net/netfilter/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 004af030ef1a..d869ea50623e 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -364,6 +364,11 @@ int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state)
ret = nf_queue(skb, state, &entry, verdict);
if (ret == 1 && entry)
goto next_hook;
+ } else {
+ /* Implicit handling for NF_STOLEN, as well as any other
+ * non conventional verdicts.
+ */
+ ret = 0;
}
return ret;
}
--
2.15.1
^ permalink raw reply related
* [PATCH iproute2] ip: add vxcan to help text
From: Oliver Hartkopp @ 2017-12-13 20:21 UTC (permalink / raw)
To: linux-can, netdev, Stephen Hemminger; +Cc: Oliver Hartkopp
Add missing tag 'vxcan' inside the help text which was missing in commit
efe459c76d35f ('ip: link add vxcan support').
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
ip/ipaddress.c | 2 +-
ip/iplink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 8057011e..f150d919 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -74,7 +74,7 @@ static void usage(void)
fprintf(stderr, "CONFFLAG := [ home | nodad | mngtmpaddr | noprefixroute | autojoin ]\n");
fprintf(stderr, "LIFETIME := [ valid_lft LFT ] [ preferred_lft LFT ]\n");
fprintf(stderr, "LFT := forever | SECONDS\n");
- fprintf(stderr, "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |\n");
+ fprintf(stderr, "TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |\n");
fprintf(stderr, " bridge | bond | ipoib | ip6tnl | ipip | sit | vxlan | lowpan |\n");
fprintf(stderr, " gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan | vti |\n");
fprintf(stderr, " nlmon | can | bond_slave | ipvlan | geneve | bridge_slave |\n");
diff --git a/ip/iplink.c b/ip/iplink.c
index 0a8eb56f..e83f1477 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -109,7 +109,7 @@ void iplink_usage(void)
"\n"
" ip link help [ TYPE ]\n"
"\n"
- "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |\n"
+ "TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |\n"
" bridge | bond | team | ipoib | ip6tnl | ipip | sit | vxlan |\n"
" gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan |\n"
" vti | nlmon | team_slave | bond_slave | ipvlan | geneve |\n"
--
2.15.1
^ permalink raw reply related
* Re: [PATCH iproute2] Show 'external' link mode in output
From: Stephen Hemminger @ 2017-12-13 20:15 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: netdev, phild
In-Reply-To: <20171212202319.GA7066@ipom.com>
On Tue, 12 Dec 2017 12:23:19 -0800
Phil Dibowitz <phil@ipom.com> wrote:
> Recently `external` support was added to the tunnel drivers, but there is no way
> to introspect this from userspace. This adds support for that.
>
> Now `ip -details link` shows it:
>
> ```
> 7: tunl60@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group
> default qlen 1
> link/tunnel6 :: brd :: promiscuity 0
> ip6tnl external any remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000) addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
> ```
>
> Signed-off-by: Phil Dibowitz <phil@ipom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: avoid skb_warn_bad_offload on IS_ERR
From: David Miller @ 2017-12-13 20:14 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, edumazet, willemb
In-Reply-To: <20171212163904.209480-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Tue, 12 Dec 2017 11:39:04 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> skb_warn_bad_offload warns when packets enter the GSO stack that
> require skb_checksum_help or vice versa. Do not warn on arbitrary
> bad packets. Packet sockets can craft many. Syzkaller was able to
> demonstrate another one with eth_type games.
>
> In particular, suppress the warning when segmentation returns an
> error, which is for reasons other than checksum offload.
>
> See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
> called on skb requiring segmentation") for context on this warning.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks Willem.
^ permalink raw reply
* Re: [PATCH net-next] net: sk_pacing_shift_update() helper
From: David Miller @ 2017-12-13 20:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: nbd, netdev, johannes.berg, toke, kir
In-Reply-To: <1513089259.25033.51.camel@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Dec 2017 06:34:19 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In commit 3a9b76fd0db9 ("tcp: allow drivers to tweak TSQ logic")
> I gave a code sample to set sk->sk_pacing_shift that was not complete.
>
> Better add a helper that can be used by drivers without worries,
> and maybe amended in the future.
>
> A wifi driver might use it from its ndo_start_xmit()
>
> Following call would setup TCP to allow up to ~8ms of queued data per
> flow.
>
> sk_pacing_shift_update(skb->sk, 7);
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/3] net: phy: add support to detect 100BASE-T1 capability
From: Andrew Lunn @ 2017-12-13 20:11 UTC (permalink / raw)
To: Lucas Stach; +Cc: Florian Fainelli, netdev, kernel, patchwork-lst
In-Reply-To: <20171213173751.12722-1-l.stach@pengutronix.de>
On Wed, Dec 13, 2017 at 06:37:49PM +0100, Lucas Stach wrote:
> 100BASE-T1 is the automotive ethernet standard 802.3bw-2015. Currently
> we don't detect any valid modes for PHYs, which only support this
> standard. Add support to detect the common 100Mbit full-duplex mode.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/net/phy/phy_device.c | 2 ++
> include/uapi/linux/mii.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 67f25ac29025..8ef48b38d97b 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1607,6 +1607,8 @@ int genphy_config_init(struct phy_device *phydev)
> if (val < 0)
> return val;
>
> + if (val & ESTATUS_100T1_FULL)
> + features |= SUPPORTED_100baseT_Full;
Hi Lucas
Why did you decide to do this, and not add a SUPPORTED_100baseT1?
Could a device support both 100-BASE-T and 100-BASE-T1? If at some
point we need to differentiate between them, it is going to be
hard. Especially since this is part of the kernel ABI.
Andrew
^ permalink raw reply
* Re: [PATCH net] sock: free skb in skb_complete_tx_timestamp on error
From: Eric Dumazet @ 2017-12-13 20:10 UTC (permalink / raw)
To: Willem de Bruijn, netdev; +Cc: richardcochran, davem, Willem de Bruijn
In-Reply-To: <20171213194106.128322-1-willemdebruijn.kernel@gmail.com>
On Wed, 2017-12-13 at 14:41 -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> skb_complete_tx_timestamp must ingest the skb it is passed. Call
> kfree_skb if the skb cannot be enqueued.
>
> Fixes: b245be1f4db1 ("net-timestamp: no-payload only sysctl")
> Fixes: 9ac25fc06375 ("net: fix socket refcounting in skb_complete_tx_timestamp()")
> Reported-by: Richard Cochran <richardcochran@gmail.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH net-next] net: bridge: use rhashtable for fdbs
From: David Miller @ 2017-12-13 20:10 UTC (permalink / raw)
To: nikolay; +Cc: netdev, bridge, roopa, stephen, srn
In-Reply-To: <1513087370-4791-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Tue, 12 Dec 2017 16:02:50 +0200
> Before this patch the bridge used a fixed 256 element hash table which
> was fine for small use cases (in my tests it starts to degrade
> above 1000 entries), but it wasn't enough for medium or large
> scale deployments. Modern setups have thousands of participants in a
> single bridge, even only enabling vlans and adding a few thousand vlan
> entries will cause a few thousand fdbs to be automatically inserted per
> participating port. So we need to scale the fdb table considerably to
> cope with modern workloads, and this patch converts it to use a
> rhashtable for its operations thus improving the bridge scalability.
> Tests show the following results (10 runs each), at up to 1000 entries
> rhashtable is ~3% slower, at 2000 rhashtable is 30% faster, at 3000 it
> is 2 times faster and at 30000 it is 50 times faster.
> Obviously this happens because of the properties of the two constructs
> and is expected, rhashtable keeps pretty much a constant time even with
> 10000000 entries (tested), while the fixed hash table struggles
> considerably even above 10000.
> As a side effect this also reduces the net_bridge struct size from 3248
> bytes to 1344 bytes. Also note that the key struct is 8 bytes.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> After this I'll post patches for the per-port fdb limit option. Later we
> can get rid of hash_lock altogether though that requires much more
> careful changes.
Nice work Nikolay, applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next v2] ip6_vti: adjust vti mtu according to mtu of output device
From: David Miller @ 2017-12-13 20:09 UTC (permalink / raw)
To: alexey.kodanev; +Cc: netdev, steffen.klassert, pvorel, shannon.nelson
In-Reply-To: <1513086812-24896-1-git-send-email-alexey.kodanev@oracle.com>
From: Alexey Kodanev <alexey.kodanev@oracle.com>
Date: Tue, 12 Dec 2017 16:53:32 +0300
> + if (tdev) {
> + dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len,
> + IPV6_MIN_MTU);
> + }
Please don't use curly braces for a single-statement basic block.
Thank you.
^ permalink raw reply
* Re: [RFC PATCH] reuseport: compute the ehash only if needed
From: David Miller @ 2017-12-13 20:08 UTC (permalink / raw)
To: pabeni; +Cc: netdev, kraig, edumazet
In-Reply-To: <af8a2d2c27b6f91ca7a7c65ac375ce2ba7aa4764.1513084090.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Tue, 12 Dec 2017 14:09:28 +0100
> When a reuseport socket group is using a BPF filter to distribute
> the packets among the sockets, we don't need to compute any hash
> value, but the current reuseport_select_sock() requires the
> caller to compute such hash in advance.
>
> This patch reworks reuseport_select_sock() to compute the hash value
> only if needed - missing or failing BPF filter. Since different
> hash functions have different argument types - ipv4 addresses vs ipv6
> ones - to avoid over-complicate the interface, reuseport_select_sock()
> is now a macro.
>
> Additionally, the sk_reuseport test is move inside reuseport_select_sock,
> to avoid some code duplication.
>
> Overall this gives small but measurable performance improvement
> under UDP flood while using SO_REUSEPORT + BPF.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
I don't doubt that this improves the case where the hash is elided, but
I suspect it makes things slower othewise.
You're doing two function calls for an operation that used to require
just one in the bottom of the call chain.
You're also putting something onto the stack that the compiler can't
possibly optimize into purely using cpu registers to hold.
^ permalink raw reply
* Re: [PATCH][next] net: phy: meson-gxl: make function meson_gxl_read_status static
From: David Miller @ 2017-12-13 20:05 UTC (permalink / raw)
To: colin.king
Cc: andrew, f.fainelli, carlo, khilman, netdev, linux-arm-kernel,
linux-amlogic, kernel-janitors, linux-kernel
In-Reply-To: <20171212130311.17185-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 12 Dec 2017 13:03:11 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> The function meson_gxl_read_status is local to the source and does
> not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol 'meson_gxl_read_status' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ 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