* RE: [RFC PATCH 04/10] net: hns3: Add "promisc mode" config info query function
From: Salil Mehta @ 2018-11-11 16:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem@davemloft.net, yuvalm@mellanox.com, leon@kernel.org,
Zhuangyuzeng (Yisen), lipeng (Y), mehta.salil@opnsrc.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org, Linuxarm, Liuzhongzhu
In-Reply-To: <20181109224903.GE5259@lunn.ch>
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, November 9, 2018 10:49 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: davem@davemloft.net; yuvalm@mellanox.com; leon@kernel.org;
> Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; lipeng (Y)
> <lipeng321@huawei.com>; mehta.salil@opnsrc.net; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-rdma@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; Liuzhongzhu <liuzhongzhu@huawei.com>
> Subject: Re: [RFC PATCH 04/10] net: hns3: Add "promisc mode" config info
> query function
>
> On Fri, Nov 09, 2018 at 10:07:37PM +0000, Salil Mehta wrote:
> > From: liuzhongzhu <liuzhongzhu@huawei.com>
> >
> > This patch prints promiscuous mode status.
>
> netstat -i
>
> Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-
> OVR Flg
> lo 65536 871698 0 0 0 871698 0 0
> 0 LRU
> tun0 1500 1052639 0 0 0 1013998 0 0
> 0 MOPRU
>
> The flag P means promisc.
sure, got the point. Anything which is available in the tools should be
avoided in the debugfs?
Many thanks
^ permalink raw reply
* Re: [PATCH net-next] net: phy: marvell: remove set but not used variable 'pause'
From: David Miller @ 2018-11-12 2:20 UTC (permalink / raw)
To: yuehaibing; +Cc: andrew, f.fainelli, netdev, linux-kernel, kernel-janitors
In-Reply-To: <1541987250-18687-1-git-send-email-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 12 Nov 2018 01:47:30 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/phy/marvell.c: In function 'm88e1510_config_init':
> drivers/net/phy/marvell.c:850:7: warning:
> variable 'pause' set but not used [-Wunused-but-set-variable]
>
> It not used any more after commit 3c1bcc8614db ("net: ethernet: Convert phydev
> advertize and supported from u32 to link mode")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: marvell: remove set but not used variable 'pause'
From: Andrew Lunn @ 2018-11-12 2:17 UTC (permalink / raw)
To: YueHaibing
Cc: Florian Fainelli, David S. Miller, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <1541987250-18687-1-git-send-email-yuehaibing@huawei.com>
On Mon, Nov 12, 2018 at 01:47:30AM +0000, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/phy/marvell.c: In function 'm88e1510_config_init':
> drivers/net/phy/marvell.c:850:7: warning:
> variable 'pause' set but not used [-Wunused-but-set-variable]
>
> It not used any more after commit 3c1bcc8614db ("net: ethernet: Convert phydev
> advertize and supported from u32 to link mode")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: WARN_ON() in netconsole with PREEMPT_RT
From: Steven Rostedt @ 2018-11-12 2:01 UTC (permalink / raw)
To: Oleksandr Natalenko
Cc: David S. Miller, Sebastian Andrzej Siewior, Thomas Gleixner,
Eric Dumazet, Dave Jones, netdev, linux-rt-users, linux-kernel
In-Reply-To: <a23ae3a8501d5c996d7a9dd2f27dd5fa@natalenko.name>
On Sun, 11 Nov 2018 21:16:00 +0100
Oleksandr Natalenko <oleksandr@natalenko.name> wrote:
> > This is a v4.19.1-rt3-based kernel.
> >
> > The WARN_ON() is:
> >
> > 362 void netpoll_send_udp(struct netpoll *np, const char *msg, int len)
> > 363 {
> > …
> > 372 WARN_ON_ONCE(!irqs_disabled());
> > …
> >
> > If that matters, I have "threadirqs" passed to the kernel.
> >
> > Netconsole seems to work even after this warning. Is this OK/expected?
> >
> > Thanks.
>
> Oh, I see that write_msg() calls netpoll_send_udp() under
> spin_lock_irqsave(), but in PREEMPT_RT this, AFAIK, does not disable
> interrupts.
>
> So, the real question here is whether the interrupts should be indeed
> disabled. And if so, -rt should replace spin_lock_irqsave() call there
> with what? local_irq_save()? and get rid of the warning?
>
Why do we care if interrupts are disabled with PREEMPT_RT here?
printk() itself has a lot of issues with PREEMPT_RT that we are working
on dealing with. Right now netconsole is actually at the end of that
todo list.
-- Steve
^ permalink raw reply
* [PATCH net-next] net: phy: marvell: remove set but not used variable 'pause'
From: YueHaibing @ 2018-11-12 1:47 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David S. Miller
Cc: YueHaibing, netdev, linux-kernel, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/phy/marvell.c: In function 'm88e1510_config_init':
drivers/net/phy/marvell.c:850:7: warning:
variable 'pause' set but not used [-Wunused-but-set-variable]
It not used any more after commit 3c1bcc8614db ("net: ethernet: Convert phydev
advertize and supported from u32 to link mode")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/phy/marvell.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 36a0db8..6a98819 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -847,7 +847,6 @@ static int m88e1510_config_init(struct phy_device *phydev)
/* SGMII-to-Copper mode initialization */
if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
- u32 pause;
/* Select page 18 */
err = marvell_set_page(phydev, 18);
@@ -878,7 +877,6 @@ static int m88e1510_config_init(struct phy_device *phydev)
* This means we can never be truely sure what was advertised,
* so disable Pause support.
*/
- pause = SUPPORTED_Pause | SUPPORTED_Asym_Pause;
linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
phydev->supported);
linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT,
^ permalink raw reply related
* [PATCH net-next] tcp: tsq: no longer use limit_output_bytes for paced flows
From: Eric Dumazet @ 2018-11-11 15:34 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet
FQ pacing guarantees that paced packets queued by one flow do not
add head-of-line blocking for other flows.
After TCP GSO conversion, increasing limit_output_bytes to 1 MB is safe,
since this maps to 16 skbs at most in qdisc or device queues.
(or slightly more if some drivers lower {gso_max_segs|size})
We still can queue at most 1 ms worth of traffic (this can be scaled
by wifi drivers if they need to)
Tested:
# ethtool -c eth0 | egrep "tx-usecs:|tx-frames:" # 40 Gbit mlx4 NIC
tx-usecs: 16
tx-frames: 16
# tc qdisc replace dev eth0 root fq
# for f in {1..10};do netperf -P0 -H lpaa24,6 -o THROUGHPUT;done
Before patch:
27711
26118
27107
27377
27712
27388
27340
27117
27278
27509
After patch:
37434
36949
36658
36998
37711
37291
37605
36659
36544
37349
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
Documentation/networking/ip-sysctl.txt | 2 +-
net/ipv4/tcp_ipv4.c | 4 ++--
net/ipv4/tcp_output.c | 5 +++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index aa9e6a3316791d9dea5a2115530c9da801c01fc2..af2a69439b93be51400909b7cecbed776fb8dce1 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -759,7 +759,7 @@ tcp_limit_output_bytes - INTEGER
flows, for typical pfifo_fast qdiscs. tcp_limit_output_bytes
limits the number of bytes on qdisc or device to reduce artificial
RTT/cwnd and reduce bufferbloat.
- Default: 262144
+ Default: 1048576 (16 * 65536)
tcp_challenge_ack_limit - INTEGER
Limits number of Challenge ACK sent per second, as recommended
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5424a4077c272170ba961858d933d8ba56c6b8a7..0952d4b772e7aa3cfb936596aa586dbd2dd6efde 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2574,8 +2574,8 @@ static int __net_init tcp_sk_init(struct net *net)
* which are too large can cause TCP streams to be bursty.
*/
net->ipv4.sysctl_tcp_tso_win_divisor = 3;
- /* Default TSQ limit of four TSO segments */
- net->ipv4.sysctl_tcp_limit_output_bytes = 262144;
+ /* Default TSQ limit of 16 TSO segments */
+ net->ipv4.sysctl_tcp_limit_output_bytes = 16 * 65536;
/* rfc5961 challenge ack rate limiting */
net->ipv4.sysctl_tcp_challenge_ack_limit = 1000;
net->ipv4.sysctl_tcp_min_tso_segs = 2;
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 75dcf4daca724a6819e9ecc9d0f3e6dc6df72e9b..d40d4cc533197f4199b6c0eba4c0e9aea5448474 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2220,8 +2220,9 @@ static bool tcp_small_queue_check(struct sock *sk, const struct sk_buff *skb,
limit = max_t(unsigned long,
2 * skb->truesize,
sk->sk_pacing_rate >> sk->sk_pacing_shift);
- limit = min_t(unsigned long, limit,
- sock_net(sk)->ipv4.sysctl_tcp_limit_output_bytes);
+ if (sk->sk_pacing_status == SK_PACING_NONE)
+ limit = min_t(unsigned long, limit,
+ sock_net(sk)->ipv4.sysctl_tcp_limit_output_bytes);
limit <<= factor;
if (refcount_read(&sk->sk_wmem_alloc) > limit) {
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* Re: [PATCH net-next 0/9] Use __vlan_hwaccel_*() helpers
From: Tariq Toukan @ 2018-11-11 15:26 UTC (permalink / raw)
To: David Miller, mirq-linux@rere.qmqm.pl
Cc: netdev@vger.kernel.org, ajit.khaparde@broadcom.com,
kuznet@ms2.inr.ac.ru, bridge@lists.linux-foundation.org,
xiyou.wangcong@gmail.com, coreteam@netfilter.org, fw@strlen.de,
yoshfuji@linux-ipv6.org, jhs@mojatatu.com, jiri@resnulli.us,
kadlec@blackhole.kfki.hu, linux-rdma@vger.kernel.org,
mlindner@marvell.com, netfilter-devel@vger.kernel.org,
nikolay@cumulusnetworks.com
In-Reply-To: <20181108.204523.1353698272847299871.davem@davemloft.net>
On 09/11/2018 6:45 AM, David Miller wrote:
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Date: Fri, 09 Nov 2018 00:17:58 +0100
>
>> This series removes from networking core and driver code an assumption
>> about how VLAN tag presence is stored in an skb. This will allow to free
>> up overloading of VLAN.CFI bit to incidate tag's presence.
>
> This looks good, series applied.
>
> Thanks.
>
Hi Michal,
We started seeing the compilation errors below, they look related to
this series.
Thanks,
Tariq
02:15:09 net/8021q/vlan_core.c: In function 'vlan_do_receive':
02:15:09 net/8021q/vlan_core.c:60:2: error: implicit declaration of
function '__vlan_hwaccel_clear_tag'; did you mean
'__vlan_hwaccel_get_tag'? [-Werror=implicit-function-declaration]
02:15:09 __vlan_hwaccel_clear_tag(skb);
02:15:09 ^~~~~~~~~~~~~~~~~~~~~~~~
02:15:09 __vlan_hwaccel_get_tag
02:15:09 cc1: some warnings being treated as errors
02:15:09 make[4]: *** [scripts/Makefile.build:293:
net/8021q/vlan_core.o] Error 1
02:15:09 make[4]: *** Waiting for unfinished jobs....
02:15:11 make[3]: *** [scripts/Makefile.build:518: net/8021q] Error 2
02:15:11 make[3]: *** Waiting for unfinished jobs....
02:15:14 make[2]: *** [Makefile:1060: net] Error 2
02:15:14 make[2]: *** Waiting for unfinished jobs....
02:15:36 drivers/net/ethernet/mellanox/mlx4/en_rx.c: In function
'mlx4_en_process_rx_cq':
02:15:36 drivers/net/ethernet/mellanox/mlx4/en_rx.c:878:4: error:
implicit declaration of function '__vlan_hwaccel_clear_tag'; did you
mean '__vlan_hwaccel_get_tag'? [-Werror=implicit-function-declaration]
02:15:36 __vlan_hwaccel_clear_tag(skb);
02:15:36 ^~~~~~~~~~~~~~~~~~~~~~~~
02:15:36 __vlan_hwaccel_get_tag
02:15:36 cc1: some warnings being treated as errors
02:15:37 make[7]: *** [scripts/Makefile.build:293:
drivers/net/ethernet/mellanox/mlx4/en_rx.o] Error 1
02:15:37 make[7]: *** Waiting for unfinished jobs....
02:15:37 make[6]: *** [scripts/Makefile.build:518:
drivers/net/ethernet/mellanox/mlx4] Error 2
02:15:37 make[6]: *** Waiting for unfinished jobs....
02:15:39 drivers/net/ethernet/mellanox/mlx5/core/en_stats.c: In function
'mlx5e_grp_sw_update_stats':
02:15:39 drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1:
warning: the frame size of 1200 bytes is larger than 1024 bytes
[-Wframe-larger-than=]
02:15:39 }
02:15:39 ^
02:15:49 make[5]: *** [scripts/Makefile.build:518:
drivers/net/ethernet/mellanox] Error 2
02:15:49 make[4]: *** [scripts/Makefile.build:518: drivers/net/ethernet]
Error 2
02:15:49 make[3]: *** [scripts/Makefile.build:518: drivers/net] Error 2
02:15:49 make[2]: *** [Makefile:1060: drivers] Error 2
02:15:49 make[1]: *** [scripts/package/Makefile:63: binrpm-pkg] Error 2
02:15:49 make: *** [Makefile:1399: binrpm-pkg] Error 2
^ permalink raw reply
* [PATCH net 4/4] qed: Fix reading wrong value in loop condition
From: Denis Bolotin @ 2018-11-11 15:05 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
In-Reply-To: <20181111150500.4345-1-denis.bolotin@cavium.com>
The value of "sb_index" is written by the hardware. Reading its value and
writing it to "index" must finish before checking the loop condition.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_int.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_int.c b/drivers/net/ethernet/qlogic/qed/qed_int.c
index 0f0aba7..aa7504a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_int.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_int.c
@@ -992,6 +992,8 @@ static int qed_int_attentions(struct qed_hwfn *p_hwfn)
*/
do {
index = p_sb_attn->sb_index;
+ /* finish reading index before the loop condition */
+ rmb();
attn_bits = le32_to_cpu(p_sb_attn->atten_bits);
attn_acks = le32_to_cpu(p_sb_attn->atten_ack);
} while (index != p_sb_attn->sb_index);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/4] qed: Fix overriding offload_tc by protocols without APP TLV
From: Denis Bolotin @ 2018-11-11 15:04 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
In-Reply-To: <20181111150500.4345-1-denis.bolotin@cavium.com>
The TC received from APP TLV is stored in offload_tc, and should not be
set by protocols which did not receive an APP TLV. Fixed the condition
when overriding the offload_tc.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 8e8fa82..69966df 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -191,7 +191,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
static void
qed_dcbx_set_params(struct qed_dcbx_results *p_data,
struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- bool enable, u8 prio, u8 tc,
+ bool app_tlv, bool enable, u8 prio, u8 tc,
enum dcbx_protocol_type type,
enum qed_pci_personality personality)
{
@@ -210,7 +210,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
p_data->arr[type].dont_add_vlan0 = true;
/* QM reconf data */
- if (p_hwfn->hw_info.personality == personality)
+ if (app_tlv && p_hwfn->hw_info.personality == personality)
qed_hw_info_set_offload_tc(&p_hwfn->hw_info, tc);
/* Configure dcbx vlan priority in doorbell block for roce EDPM */
@@ -225,7 +225,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
static void
qed_dcbx_update_app_info(struct qed_dcbx_results *p_data,
struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
- bool enable, u8 prio, u8 tc,
+ bool app_tlv, bool enable, u8 prio, u8 tc,
enum dcbx_protocol_type type)
{
enum qed_pci_personality personality;
@@ -240,7 +240,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
personality = qed_dcbx_app_update[i].personality;
- qed_dcbx_set_params(p_data, p_hwfn, p_ptt, enable,
+ qed_dcbx_set_params(p_data, p_hwfn, p_ptt, app_tlv, enable,
prio, tc, type, personality);
}
}
@@ -319,8 +319,8 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
enable = true;
}
- qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, enable,
- priority, tc, type);
+ qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, true,
+ enable, priority, tc, type);
}
}
@@ -341,7 +341,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
continue;
enable = (type == DCBX_PROTOCOL_ETH) ? false : !!dcbx_version;
- qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, enable,
+ qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, false, enable,
priority, tc, type);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 3/4] qed: Fix rdma_info structure allocation
From: Denis Bolotin @ 2018-11-11 15:04 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
In-Reply-To: <20181111150500.4345-1-denis.bolotin@cavium.com>
From: Michal Kalderon <michal.kalderon@cavium.com>
Certain flows need to access the rdma-info structure, for example dcbx
update flows. In some cases there can be a race between the allocation or
deallocation of the structure which was done in roce start / roce stop and
an asynchrounous dcbx event that tries to access the structure.
For this reason, we move the allocation of the rdma_info structure to be
similar to the iscsi/fcoe info structures which are allocated during device
setup.
We add a new field of "active" to the struct to define whether roce has
already been started or not, and this is checked instead of whether the
pointer to the info structure.
Fixes: 51ff17251c9c ("qed: Add support for RoCE hw init")
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 ++++++---
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 50 +++++++++++++++++-------------
drivers/net/ethernet/qlogic/qed/qed_rdma.h | 5 +++
3 files changed, 45 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 7ceb2b9..cff1410 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -185,6 +185,10 @@ void qed_resc_free(struct qed_dev *cdev)
qed_iscsi_free(p_hwfn);
qed_ooo_free(p_hwfn);
}
+
+ if (QED_IS_RDMA_PERSONALITY(p_hwfn))
+ qed_rdma_info_free(p_hwfn);
+
qed_iov_free(p_hwfn);
qed_l2_free(p_hwfn);
qed_dmae_info_free(p_hwfn);
@@ -1081,6 +1085,12 @@ int qed_resc_alloc(struct qed_dev *cdev)
goto alloc_err;
}
+ if (QED_IS_RDMA_PERSONALITY(p_hwfn)) {
+ rc = qed_rdma_info_alloc(p_hwfn);
+ if (rc)
+ goto alloc_err;
+ }
+
/* DMA info initialization */
rc = qed_dmae_info_alloc(p_hwfn);
if (rc)
@@ -2102,11 +2112,8 @@ int qed_hw_start_fastpath(struct qed_hwfn *p_hwfn)
if (!p_ptt)
return -EAGAIN;
- /* If roce info is allocated it means roce is initialized and should
- * be enabled in searcher.
- */
if (p_hwfn->p_rdma_info &&
- p_hwfn->b_rdma_enabled_in_prs)
+ p_hwfn->p_rdma_info->active && p_hwfn->b_rdma_enabled_in_prs)
qed_wr(p_hwfn, p_ptt, p_hwfn->rdma_prs_search_reg, 0x1);
/* Re-open incoming traffic */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.c b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
index 6211343..7873d6df 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.c
@@ -140,22 +140,34 @@ static u32 qed_rdma_get_sb_id(void *p_hwfn, u32 rel_sb_id)
return FEAT_NUM((struct qed_hwfn *)p_hwfn, QED_PF_L2_QUE) + rel_sb_id;
}
-static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt,
- struct qed_rdma_start_in_params *params)
+int qed_rdma_info_alloc(struct qed_hwfn *p_hwfn)
{
struct qed_rdma_info *p_rdma_info;
- u32 num_cons, num_tasks;
- int rc = -ENOMEM;
- DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "Allocating RDMA\n");
-
- /* Allocate a struct with current pf rdma info */
p_rdma_info = kzalloc(sizeof(*p_rdma_info), GFP_KERNEL);
if (!p_rdma_info)
- return rc;
+ return -ENOMEM;
+
+ spin_lock_init(&p_rdma_info->lock);
p_hwfn->p_rdma_info = p_rdma_info;
+ return 0;
+}
+
+void qed_rdma_info_free(struct qed_hwfn *p_hwfn)
+{
+ kfree(p_hwfn->p_rdma_info);
+ p_hwfn->p_rdma_info = NULL;
+}
+
+static int qed_rdma_alloc(struct qed_hwfn *p_hwfn)
+{
+ struct qed_rdma_info *p_rdma_info = p_hwfn->p_rdma_info;
+ u32 num_cons, num_tasks;
+ int rc = -ENOMEM;
+
+ DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "Allocating RDMA\n");
+
if (QED_IS_IWARP_PERSONALITY(p_hwfn))
p_rdma_info->proto = PROTOCOLID_IWARP;
else
@@ -183,7 +195,7 @@ static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
/* Allocate a struct with device params and fill it */
p_rdma_info->dev = kzalloc(sizeof(*p_rdma_info->dev), GFP_KERNEL);
if (!p_rdma_info->dev)
- goto free_rdma_info;
+ return rc;
/* Allocate a struct with port params and fill it */
p_rdma_info->port = kzalloc(sizeof(*p_rdma_info->port), GFP_KERNEL);
@@ -298,8 +310,6 @@ static int qed_rdma_alloc(struct qed_hwfn *p_hwfn,
kfree(p_rdma_info->port);
free_rdma_dev:
kfree(p_rdma_info->dev);
-free_rdma_info:
- kfree(p_rdma_info);
return rc;
}
@@ -370,8 +380,6 @@ static void qed_rdma_resc_free(struct qed_hwfn *p_hwfn)
kfree(p_rdma_info->port);
kfree(p_rdma_info->dev);
-
- kfree(p_rdma_info);
}
static void qed_rdma_free_tid(void *rdma_cxt, u32 itid)
@@ -679,8 +687,6 @@ static int qed_rdma_setup(struct qed_hwfn *p_hwfn,
DP_VERBOSE(p_hwfn, QED_MSG_RDMA, "RDMA setup\n");
- spin_lock_init(&p_hwfn->p_rdma_info->lock);
-
qed_rdma_init_devinfo(p_hwfn, params);
qed_rdma_init_port(p_hwfn);
qed_rdma_init_events(p_hwfn, params);
@@ -727,7 +733,7 @@ static int qed_rdma_stop(void *rdma_cxt)
/* Disable RoCE search */
qed_wr(p_hwfn, p_ptt, p_hwfn->rdma_prs_search_reg, 0);
p_hwfn->b_rdma_enabled_in_prs = false;
-
+ p_hwfn->p_rdma_info->active = 0;
qed_wr(p_hwfn, p_ptt, PRS_REG_ROCE_DEST_QP_MAX_PF, 0);
ll2_ethertype_en = qed_rd(p_hwfn, p_ptt, PRS_REG_LIGHT_L2_ETHERTYPE_EN);
@@ -1236,7 +1242,8 @@ static int qed_rdma_destroy_qp(void *rdma_cxt, struct qed_rdma_qp *qp)
u8 max_stats_queues;
int rc;
- if (!rdma_cxt || !in_params || !out_params || !p_hwfn->p_rdma_info) {
+ if (!rdma_cxt || !in_params || !out_params ||
+ !p_hwfn->p_rdma_info->active) {
DP_ERR(p_hwfn->cdev,
"qed roce create qp failed due to NULL entry (rdma_cxt=%p, in=%p, out=%p, roce_info=?\n",
rdma_cxt, in_params, out_params);
@@ -1802,8 +1809,8 @@ bool qed_rdma_allocated_qps(struct qed_hwfn *p_hwfn)
{
bool result;
- /* if rdma info has not been allocated, naturally there are no qps */
- if (!p_hwfn->p_rdma_info)
+ /* if rdma wasn't activated yet, naturally there are no qps */
+ if (!p_hwfn->p_rdma_info->active)
return false;
spin_lock_bh(&p_hwfn->p_rdma_info->lock);
@@ -1849,7 +1856,7 @@ static int qed_rdma_start(void *rdma_cxt,
if (!p_ptt)
goto err;
- rc = qed_rdma_alloc(p_hwfn, p_ptt, params);
+ rc = qed_rdma_alloc(p_hwfn);
if (rc)
goto err1;
@@ -1858,6 +1865,7 @@ static int qed_rdma_start(void *rdma_cxt,
goto err2;
qed_ptt_release(p_hwfn, p_ptt);
+ p_hwfn->p_rdma_info->active = 1;
return rc;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_rdma.h b/drivers/net/ethernet/qlogic/qed/qed_rdma.h
index 6f722ee..50d609c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_rdma.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_rdma.h
@@ -102,6 +102,7 @@ struct qed_rdma_info {
u16 max_queue_zones;
enum protocol_type proto;
struct qed_iwarp_info iwarp;
+ u8 active:1;
};
struct qed_rdma_qp {
@@ -176,10 +177,14 @@ struct qed_rdma_qp {
#if IS_ENABLED(CONFIG_QED_RDMA)
void qed_rdma_dpm_bar(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt);
void qed_rdma_dpm_conf(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt);
+int qed_rdma_info_alloc(struct qed_hwfn *p_hwfn);
+void qed_rdma_info_free(struct qed_hwfn *p_hwfn);
#else
static inline void qed_rdma_dpm_conf(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt) {}
static inline void qed_rdma_dpm_bar(struct qed_hwfn *p_hwfn,
struct qed_ptt *p_ptt) {}
+static inline int qed_rdma_info_alloc(struct qed_hwfn *p_hwfn) {return -EINVAL}
+static inline void qed_rdma_info_free(struct qed_hwfn *p_hwfn) {}
#endif
int
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 1/4] qed: Fix PTT leak in qed_drain()
From: Denis Bolotin @ 2018-11-11 15:04 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
In-Reply-To: <20181111150500.4345-1-denis.bolotin@cavium.com>
Release PTT before entering error flow.
Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 35fd0db..fff7f04 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1782,9 +1782,9 @@ static int qed_drain(struct qed_dev *cdev)
return -EBUSY;
}
rc = qed_mcp_drain(hwfn, ptt);
+ qed_ptt_release(hwfn, ptt);
if (rc)
return rc;
- qed_ptt_release(hwfn, ptt);
}
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/4] qed: Miscellaneous bug fixes
From: Denis Bolotin @ 2018-11-11 15:04 UTC (permalink / raw)
To: davem, netdev; +Cc: michal.kalderon, ariel.elior, Denis Bolotin
Hi Dave,
This patch series fixes several unrelated bugs across the driver.
Please consider applying to net.
Thanks,
Denis
Denis Bolotin (3):
qed: Fix PTT leak in qed_drain()
qed: Fix overriding offload_tc by protocols without APP TLV
qed: Fix reading wrong value in loop condition
Michal Kalderon (1):
qed: Fix rdma_info structure allocation
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 14 ++++-----
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 ++++++---
drivers/net/ethernet/qlogic/qed/qed_int.c | 2 ++
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 50 +++++++++++++++++-------------
drivers/net/ethernet/qlogic/qed/qed_rdma.h | 5 +++
6 files changed, 55 insertions(+), 33 deletions(-)
--
1.8.3.1
^ permalink raw reply
* linux-next: manual merge of the bpf-next tree with the bpf tree
From: Stephen Rothwell @ 2018-11-12 0:54 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andrey Ignatov, Nitin Hande
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
net/core/filter.c
between commit:
b13b8787c95c ("bpf: Fix IPv6 dport byte order in bpf_sk_lookup_udp")
from the bpf tree and commit:
c8123ead13a5 ("bpf: Extend the sk_lookup() helper to XDP hookpoint.")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/core/filter.c
index 9a1327eb25fa,53d50fb75ea1..000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -4852,19 -4867,19 +4867,18 @@@ static struct sock *sk_lookup(struct ne
} else {
struct in6_addr *src6 = (struct in6_addr *)&tuple->ipv6.saddr;
struct in6_addr *dst6 = (struct in6_addr *)&tuple->ipv6.daddr;
- int sdif = inet6_sdif(skb);
- u16 hnum = ntohs(tuple->ipv6.dport);
if (proto == IPPROTO_TCP)
- sk = __inet6_lookup(net, &tcp_hashinfo, skb, 0,
+ sk = __inet6_lookup(net, &tcp_hashinfo, NULL, 0,
src6, tuple->ipv6.sport,
- dst6, hnum,
+ dst6, ntohs(tuple->ipv6.dport),
dif, sdif, &refcounted);
else if (likely(ipv6_bpf_stub))
sk = ipv6_bpf_stub->udp6_lib_lookup(net,
src6, tuple->ipv6.sport,
- dst6, hnum,
+ dst6, tuple->ipv6.dport,
dif, sdif,
- &udp_table, skb);
+ &udp_table, NULL);
#endif
}
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] mm/page_alloc: free order-0 pages through PCP in page_frag_free()
From: Paweł Staszewski @ 2018-11-12 0:39 UTC (permalink / raw)
To: Alexander Duyck
Cc: aaron.lu, linux-mm, LKML, Netdev, Andrew Morton,
Jesper Dangaard Brouer, Eric Dumazet, Tariq Toukan,
ilias.apalodimas, yoel, Mel Gorman, Saeed Mahameed, Michal Hocko,
Vlastimil Babka, dave.hansen
In-Reply-To: <CAKgT0UdhcXF-ohPHPbg8onRjFabEMnbpXGmLm-27skCNzGKOgw@mail.gmail.com>
W dniu 12.11.2018 o 00:05, Alexander Duyck pisze:
> On Sat, Nov 10, 2018 at 3:54 PM Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>>
>>
>> W dniu 05.11.2018 o 16:44, Alexander Duyck pisze:
>>> On Mon, Nov 5, 2018 at 12:58 AM Aaron Lu <aaron.lu@intel.com> wrote:
>>>> page_frag_free() calls __free_pages_ok() to free the page back to
>>>> Buddy. This is OK for high order page, but for order-0 pages, it
>>>> misses the optimization opportunity of using Per-Cpu-Pages and can
>>>> cause zone lock contention when called frequently.
>>>>
>>>> Paweł Staszewski recently shared his result of 'how Linux kernel
>>>> handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer
>>>> found the lock contention comes from page allocator:
>>>>
>>>> mlx5e_poll_tx_cq
>>>> |
>>>> --16.34%--napi_consume_skb
>>>> |
>>>> |--12.65%--__free_pages_ok
>>>> | |
>>>> | --11.86%--free_one_page
>>>> | |
>>>> | |--10.10%--queued_spin_lock_slowpath
>>>> | |
>>>> | --0.65%--_raw_spin_lock
>>>> |
>>>> |--1.55%--page_frag_free
>>>> |
>>>> --1.44%--skb_release_data
>>>>
>>>> Jesper explained how it happened: mlx5 driver RX-page recycle
>>>> mechanism is not effective in this workload and pages have to go
>>>> through the page allocator. The lock contention happens during
>>>> mlx5 DMA TX completion cycle. And the page allocator cannot keep
>>>> up at these speeds.[2]
>>>>
>>>> I thought that __free_pages_ok() are mostly freeing high order
>>>> pages and thought this is an lock contention for high order pages
>>>> but Jesper explained in detail that __free_pages_ok() here are
>>>> actually freeing order-0 pages because mlx5 is using order-0 pages
>>>> to satisfy its page pool allocation request.[3]
>>>>
>>>> The free path as pointed out by Jesper is:
>>>> skb_free_head()
>>>> -> skb_free_frag()
>>>> -> skb_free_frag()
>>>> -> page_frag_free()
>>>> And the pages being freed on this path are order-0 pages.
>>>>
>>>> Fix this by doing similar things as in __page_frag_cache_drain() -
>>>> send the being freed page to PCP if it's an order-0 page, or
>>>> directly to Buddy if it is a high order page.
>>>>
>>>> With this change, Paweł hasn't noticed lock contention yet in
>>>> his workload and Jesper has noticed a 7% performance improvement
>>>> using a micro benchmark and lock contention is gone.
>>>>
>>>> [1]: https://www.spinics.net/lists/netdev/msg531362.html
>>>> [2]: https://www.spinics.net/lists/netdev/msg531421.html
>>>> [3]: https://www.spinics.net/lists/netdev/msg531556.html
>>>> Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
>>>> Analysed-by: Jesper Dangaard Brouer <brouer@redhat.com>
>>>> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
>>>> ---
>>>> mm/page_alloc.c | 10 ++++++++--
>>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>> index ae31839874b8..91a9a6af41a2 100644
>>>> --- a/mm/page_alloc.c
>>>> +++ b/mm/page_alloc.c
>>>> @@ -4555,8 +4555,14 @@ void page_frag_free(void *addr)
>>>> {
>>>> struct page *page = virt_to_head_page(addr);
>>>>
>>>> - if (unlikely(put_page_testzero(page)))
>>>> - __free_pages_ok(page, compound_order(page));
>>>> + if (unlikely(put_page_testzero(page))) {
>>>> + unsigned int order = compound_order(page);
>>>> +
>>>> + if (order == 0)
>>>> + free_unref_page(page);
>>>> + else
>>>> + __free_pages_ok(page, order);
>>>> + }
>>>> }
>>>> EXPORT_SYMBOL(page_frag_free);
>>>>
>>> One thing I would suggest for Pawel to try would be to reduce the Tx
>>> qdisc size on his transmitting interfaces, Reduce the Tx ring size,
>>> and possibly increase the Tx interrupt rate. Ideally we shouldn't have
>>> too many packets in-flight and I suspect that is the issue that Pawel
>>> is seeing that is leading to the page pool allocator freeing up the
>>> memory. I know we like to try to batch things but the issue is
>>> processing too many Tx buffers in one batch leads to us eating up too
>>> much memory and causing evictions from the cache. Ideally the Rx and
>>> Tx rings and queues should be sized as small as possible while still
>>> allowing us to process up to our NAPI budget. Usually I run things
>>> with a 128 Rx / 128 Tx setup and then reduce the Tx queue length so we
>>> don't have more buffers stored there than we can place in the Tx ring.
>>> Then we can avoid the extra thrash of having to pull/push memory into
>>> and out of the freelists. Essentially the issue here ends up being
>>> another form of buffer bloat.
>> Thanks Aleksandar - yes it can be - but in my scenario setting RX buffer
>> <4096 producing more interface rx drops - and no_rx_buffer on network
>> controller that is receiving more packets
>> So i need to stick with 3000-4000 on RX - and yes i was trying to lower
>> the TX buff on connectx4 - but that changed nothing before Aaron patch
>>
>> After Aaron patch - decreasing TX buffer influencing total bandwidth
>> that can be handled by the router/server
>> Dono why before this patch there was no difference there no matter what
>> i set there there was always page_alloc/slowpath on top in perf
>>
>>
>> Currently testing RX4096/TX256 - this helps with bandwidth like +10%
>> more bandwidth with less interrupts...
> The problem is if you are going for less interrupts you are setting
> yourself up for buffer bloat. Basically you are going to use much more
> cache and much more memory then you actually need and if things are
> properly configured NAPI should take care of the interrupts anyway
> since under maximum load you shouldn't stop polling normally.
Im trying to balance here - there is problem cause server is forwarding
all kingd of protocols packets/different size etc
The problem is im trying to go in high interrupt rate - but
Setting coalescence to adaptative for rx killing cpu's at 22Gbit/s RX
and 22Gbit with rly high interrupt rate
So adding a little more latency i can turn off adaptative rx and setup
rx-usecs from range 16-64 - and this gives me more or less interrupts -
but the problem is - always same bandwidth as maximum
>
> One issue I have seen is people delay interrupts for as long as
> possible which isn't really a good thing since most network
> controllers will use NAPI which will disable the interrupts and leave
> them disabled whenever the system is under heavy stress so you should
> be able to get the maximum performance by configuring an adapter with
> small ring sizes and for high interrupt rates.
Sure this is bad to setup rx-usec for high values - cause at some point
this will add high latency for packet traversing both sides - and start
to hurt buffers
But my problem is a little different now i have no problems with RX side
- cause i can setup anything like:
coalescence from 16 to 64
rx ring from 3000 to max 8192
And it does not change my max bw - only produces less or more interrupts.
So I start to change params for TX side - and for now i know that the
best for me is
coalescence adaptative on
TX buffer 128
This helps with max BW that for now is close to 70Gbit/s RX and 70Gbit
TX but after this change i have increasing DROPS on TX side for vlan
interfaces.
And only 50% cpu (max was 50% for 70Gbit/s)
> It is easiest to think of it this way. Your total packet rate is equal
> to your interrupt rate times the number of buffers you will store in
> the ring. So if you have some fixed rate "X" for packets and an
> interrupt rate of "i" then your optimal ring size should be "X/i". So
> if you lower the interrupt rate you end up hurting the throughput
> unless you increase the buffer size. However at a certain point the
> buffer size starts becoming an issue. For example with UDP flows I
> often see massive packet drops if you tune the interrupt rate too low
> and then put the system under heavy stress.
Yes - in normal life traffic - most of ddos'es are like this many pps
with small frames.
> - Alex
>
^ permalink raw reply
* Re: [PATCH net-next v3 6/6] net/ncsi: Configure multi-package, multi-channel modes with failover
From: Samuel Mendoza-Jonas @ 2018-11-12 0:38 UTC (permalink / raw)
To: Justin.Lee1, netdev; +Cc: davem, linux-kernel, openbmc
In-Reply-To: <b2c6aea94f1648648dd349d23ce61bf6@AUSX13MPS302.AMER.DELL.COM>
On Fri, 2018-11-09 at 21:58 +0000, Justin.Lee1@Dell.com wrote:
> Hi Samuel,
>
> After running more testing, I notice that the extra patch causing failover function
> to fail. Also, occasionally, I will see two channels having TX enabled if I
> send netlink command back-to-back.
>
> cat /sys/kernel/debug/ncsi_protocol/ncsi_device_
> IFIDX IFNAME NAME PID CID RX TX MP MC WP WC PC CS PS LS RU CR NQ HA
> =====================================================================
> 2 eth2 ncsi0 000 000 1 1 1 1 1 1 1 2 1 1 1 1 0 1
> 2 eth2 ncsi1 000 001 1 1 1 1 1 1 0 2 1 1 1 1 0 1
> 2 eth2 ncsi2 001 000 0 0 1 1 0 0 0 1 0 1 1 1 0 1
> 2 eth2 ncsi3 001 001 0 0 1 1 0 0 0 1 0 1 1 1 0 1
> =====================================================================
> MP: Multi-mode Package WP: Whitelist Package
> MC: Multi-mode Channel WC: Whitelist Channel
> PC: Primary Channel CS: Channel State IA/A/IV 1/2/3
> PS: Poll Status LS: Link Status
> RU: Running CR: Carrier OK
> NQ: Queue Stopped HA: Hardware Arbitration
>
> Thanks,
> Justin
>
>
> > From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
> > From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
> > Date: Fri, 9 Nov 2018 13:11:03 +1100
> > Subject: [PATCH] net/ncsi: Reset state fixes, single-channel LSC
> >
> > ---
> > net/ncsi/ncsi-aen.c | 8 +++++---
> > net/ncsi/ncsi-manage.c | 19 +++++++++++++++----
> > 2 files changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
> > index 39c2e9eea2ba..034cb1dc5566 100644
> > --- a/net/ncsi/ncsi-aen.c
> > +++ b/net/ncsi/ncsi-aen.c
> > @@ -93,14 +93,16 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
> > if ((had_link == has_link) || chained)
> > return 0;
> >
> > - if (!ndp->multi_package && !nc->package->multi_channel) {
> > - if (had_link)
> > - ndp->flags |= NCSI_DEV_RESHUFFLE;
> > + if (!ndp->multi_package && !nc->package->multi_channel && had_link) {
> > + ndp->flags |= NCSI_DEV_RESHUFFLE;
> > ncsi_stop_channel_monitor(nc);
> > spin_lock_irqsave(&ndp->lock, flags);
> > list_add_tail_rcu(&nc->link, &ndp->channel_queue);
> > spin_unlock_irqrestore(&ndp->lock, flags);
> > return ncsi_process_next_channel(ndp);
> > + } else {
> > + /* Configured channel came up */
> > + return 0;
>
> It is always going to else statement if multi_package and/or mutlit_channel is enabled.
>
> npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_aen_handler_lsc() - pkg 0 ch 0 state down
> npcm7xx-emc f0825000.eth eth2: NCSI: ncsi_aen_handler_lsc() - had_link 1, has_link 0, chained 0
>
> These codes have no chance to run.
> if (had_link) {
> ncm = &nc->modes[NCSI_MODE_TX_ENABLE];
> if (ncsi_channel_is_last(ndp, nc)) {
> /* No channels left, reconfigure */
> return ncsi_reset_dev(&ndp->ndev);
> } else if (ncm->enable) {
> /* Need to failover Tx channel */
> ncsi_update_tx_channel(ndp, nc->package, nc, NULL);
> }
>
> > }
> >
Oops, wrote that patch a little fast it seems. This may also affect the
double-Tx above since ncsi_update_tx_channel() won't be reached.
I've attached a fixed up version below.
For the failover issue you're seeing in your previous email the issue is
likely in the ncsi_dev_state_suspend_gls state. This should send a GLS
command to all available channels, but it only does it for the current
package. Since not all packages are necessarily enabled in single-channel
mode I'll need to have a think about the neatest way to handle that, but
it's a separate issue from this patch.
Cheers,
Sam
>From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Date: Fri, 9 Nov 2018 13:11:03 +1100
Subject: [PATCH] net/ncsi: Reset state fixes, single-channel LSC
---
net/ncsi/ncsi-aen.c | 16 ++++++++++------
net/ncsi/ncsi-manage.c | 19 +++++++++++++++----
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/net/ncsi/ncsi-aen.c b/net/ncsi/ncsi-aen.c
index 39c2e9eea2ba..76559d0eeea8 100644
--- a/net/ncsi/ncsi-aen.c
+++ b/net/ncsi/ncsi-aen.c
@@ -94,13 +94,17 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
return 0;
if (!ndp->multi_package && !nc->package->multi_channel) {
- if (had_link)
+ if (had_link) {
ndp->flags |= NCSI_DEV_RESHUFFLE;
- ncsi_stop_channel_monitor(nc);
- spin_lock_irqsave(&ndp->lock, flags);
- list_add_tail_rcu(&nc->link, &ndp->channel_queue);
- spin_unlock_irqrestore(&ndp->lock, flags);
- return ncsi_process_next_channel(ndp);
+ ncsi_stop_channel_monitor(nc);
+ spin_lock_irqsave(&ndp->lock, flags);
+ list_add_tail_rcu(&nc->link, &ndp->channel_queue);
+ spin_unlock_irqrestore(&ndp->lock, flags);
+ return ncsi_process_next_channel(ndp);
+ } else {
+ /* Configured channel came up */
+ return 0;
+ }
}
if (had_link) {
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index fa3c2144f5ba..92e59f07f9a7 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -1063,17 +1063,17 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp)
case ncsi_dev_state_config_done:
netdev_dbg(ndp->ndev.dev, "NCSI: channel %u config done\n",
nc->id);
+ spin_lock_irqsave(&nc->lock, flags);
+ nc->state = NCSI_CHANNEL_ACTIVE;
+
if (ndp->flags & NCSI_DEV_RESET) {
/* A reset event happened during config, start it now */
- spin_lock_irqsave(&nc->lock, flags);
nc->reconfigure_needed = false;
spin_unlock_irqrestore(&nc->lock, flags);
- nd->state = ncsi_dev_state_functional;
ncsi_reset_dev(nd);
break;
}
- spin_lock_irqsave(&nc->lock, flags);
if (nc->reconfigure_needed) {
/* This channel's configuration has been updated
* part-way during the config state - start the
@@ -1092,7 +1092,6 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp)
break;
}
- nc->state = NCSI_CHANNEL_ACTIVE;
if (nc->modes[NCSI_MODE_LINK].data[2] & 0x1) {
hot_nc = nc;
} else {
@@ -1803,6 +1802,18 @@ int ncsi_reset_dev(struct ncsi_dev *nd)
spin_unlock_irqrestore(&ndp->lock, flags);
return 0;
}
+ } else {
+ switch (nd->state) {
+ case ncsi_dev_state_suspend_done:
+ case ncsi_dev_state_config_done:
+ case ncsi_dev_state_functional:
+ /* Ok */
+ break;
+ default:
+ /* Current reset operation happening */
+ spin_unlock_irqrestore(&ndp->lock, flags);
+ return 0;
+ }
}
if (!list_empty(&ndp->channel_queue)) {
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 3/3] tcp: get rid of tcp_tso_should_defer() dependency on HZ/jiffies
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
tcp_tso_should_defer() first heuristic is to not defer
if last send is "old enough".
Its current implementation uses jiffies and its low granularity.
TSO autodefer performance should not rely on kernel HZ :/
After EDT conversion, we have state variables in nanoseconds that
can allow us to properly implement the heuristic.
This patch increases TSO chunk sizes on medium rate flows,
especially when receivers do not use GRO or similar aggregation.
It also reduces bursts for HZ=100 or HZ=250 kernels, making TCP
behavior more uniform.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 78a56cef7e397c65ad18897d550f3800e8fe8f41..75dcf4daca724a6819e9ecc9d0f3e6dc6df72e9b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1920,9 +1920,12 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
goto send_now;
/* Avoid bursty behavior by allowing defer
- * only if the last write was recent.
+ * only if the last write was recent (1 ms).
+ * Note that tp->tcp_wstamp_ns can be in the future if we have
+ * packets waiting in a qdisc or device for EDT delivery.
*/
- if ((s32)(tcp_jiffies32 - tp->lsndtime) > 0)
+ delta = tp->tcp_clock_cache - tp->tcp_wstamp_ns - NSEC_PER_MSEC;
+ if (delta > 0)
goto send_now;
in_flight = tcp_packets_in_flight(tp);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* [PATCH net-next 2/3] tcp: refine tcp_tso_should_defer() after EDT adoption
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
tcp_tso_should_defer() last step tries to check if the probable
next ACK packet is coming in less than half rtt.
Problem is that the head->tstamp might be in the future,
so we need to use signed arithmetics to avoid overflows.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 35feadf480300cd061411d65257f06ee658daa3c..78a56cef7e397c65ad18897d550f3800e8fe8f41 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1907,10 +1907,11 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
bool *is_cwnd_limited, u32 max_segs)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
- u32 age, send_win, cong_win, limit, in_flight;
+ u32 send_win, cong_win, limit, in_flight;
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *head;
int win_divisor;
+ s64 delta;
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
goto send_now;
@@ -1972,9 +1973,9 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
head = tcp_rtx_queue_head(sk);
if (!head)
goto send_now;
- age = tcp_stamp_us_delta(tp->tcp_mstamp, tcp_skb_timestamp_us(head));
+ delta = tp->tcp_clock_cache - head->tstamp;
/* If next ACK is likely to come too late (half srtt), do not defer */
- if (age < (tp->srtt_us >> 4))
+ if ((s64)(delta - (u64)NSEC_PER_USEC * (tp->srtt_us >> 4)) < 0)
goto send_now;
/* Ok, it looks like it is advisable to defer. */
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* [PATCH net-next 1/3] tcp: do not try to defer skbs with eor mark (MSG_EOR)
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <20181111144131.156754-1-edumazet@google.com>
Applications using MSG_EOR are giving a strong hint to TCP stack :
Subsequent sendmsg() can not append more bytes to skbs having
the EOR mark.
Do not try to TSO defer suchs skbs, there is really no hope.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_output.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 9c34b97d365d719ff76250bc9fe7fa20495a3ed2..35feadf480300cd061411d65257f06ee658daa3c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1944,6 +1944,10 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
if ((skb != tcp_write_queue_tail(sk)) && (limit >= skb->len))
goto send_now;
+ /* If this packet won't get more data, do not wait. */
+ if (TCP_SKB_CB(skb)->eor)
+ goto send_now;
+
win_divisor = READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_tso_win_divisor);
if (win_divisor) {
u32 chunk = min(tp->snd_wnd, tp->snd_cwnd * tp->mss_cache);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* [PATCH net-next 0/3] tcp: tso defer improvements
From: Eric Dumazet @ 2018-11-11 14:41 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Soheil Hassas Yeganeh, Eric Dumazet
This series makes tcp_tso_should_defer() a bit smarter :
1) MSG_EOR gives a hint to TCP to not defer some skbs
2) Second patch takes into account that head tstamp
can be in the future.
3) Third patch uses existing high resolution state variables
to have a more precise heuristic.
Eric Dumazet (3):
tcp: do not try to defer skbs with eor mark (MSG_EOR)
tcp: refine tcp_tso_should_defer() after EDT adoption
tcp: get rid of tcp_tso_should_defer() dependency on HZ/jiffies
net/ipv4/tcp_output.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply
* Re: [GIT] Networking
From: pr-tracker-bot @ 2018-11-11 23:15 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20181111.142649.1250091930241970662.davem@davemloft.net>
The pull request you sent on Sun, 11 Nov 2018 14:26:49 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7a3765ed66d187071bbf56a8212f5d2bc2d2e2cc
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH 1/2] mm/page_alloc: free order-0 pages through PCP in page_frag_free()
From: Alexander Duyck @ 2018-11-11 23:05 UTC (permalink / raw)
To: Paweł Staszewski
Cc: aaron.lu, linux-mm, LKML, Netdev, Andrew Morton,
Jesper Dangaard Brouer, Eric Dumazet, Tariq Toukan,
ilias.apalodimas, yoel, Mel Gorman, Saeed Mahameed, Michal Hocko,
Vlastimil Babka, dave.hansen
In-Reply-To: <b8b1fbb7-9139-9455-69b8-8c1bed4f7c74@itcare.pl>
On Sat, Nov 10, 2018 at 3:54 PM Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>
>
>
> W dniu 05.11.2018 o 16:44, Alexander Duyck pisze:
> > On Mon, Nov 5, 2018 at 12:58 AM Aaron Lu <aaron.lu@intel.com> wrote:
> >> page_frag_free() calls __free_pages_ok() to free the page back to
> >> Buddy. This is OK for high order page, but for order-0 pages, it
> >> misses the optimization opportunity of using Per-Cpu-Pages and can
> >> cause zone lock contention when called frequently.
> >>
> >> Paweł Staszewski recently shared his result of 'how Linux kernel
> >> handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer
> >> found the lock contention comes from page allocator:
> >>
> >> mlx5e_poll_tx_cq
> >> |
> >> --16.34%--napi_consume_skb
> >> |
> >> |--12.65%--__free_pages_ok
> >> | |
> >> | --11.86%--free_one_page
> >> | |
> >> | |--10.10%--queued_spin_lock_slowpath
> >> | |
> >> | --0.65%--_raw_spin_lock
> >> |
> >> |--1.55%--page_frag_free
> >> |
> >> --1.44%--skb_release_data
> >>
> >> Jesper explained how it happened: mlx5 driver RX-page recycle
> >> mechanism is not effective in this workload and pages have to go
> >> through the page allocator. The lock contention happens during
> >> mlx5 DMA TX completion cycle. And the page allocator cannot keep
> >> up at these speeds.[2]
> >>
> >> I thought that __free_pages_ok() are mostly freeing high order
> >> pages and thought this is an lock contention for high order pages
> >> but Jesper explained in detail that __free_pages_ok() here are
> >> actually freeing order-0 pages because mlx5 is using order-0 pages
> >> to satisfy its page pool allocation request.[3]
> >>
> >> The free path as pointed out by Jesper is:
> >> skb_free_head()
> >> -> skb_free_frag()
> >> -> skb_free_frag()
> >> -> page_frag_free()
> >> And the pages being freed on this path are order-0 pages.
> >>
> >> Fix this by doing similar things as in __page_frag_cache_drain() -
> >> send the being freed page to PCP if it's an order-0 page, or
> >> directly to Buddy if it is a high order page.
> >>
> >> With this change, Paweł hasn't noticed lock contention yet in
> >> his workload and Jesper has noticed a 7% performance improvement
> >> using a micro benchmark and lock contention is gone.
> >>
> >> [1]: https://www.spinics.net/lists/netdev/msg531362.html
> >> [2]: https://www.spinics.net/lists/netdev/msg531421.html
> >> [3]: https://www.spinics.net/lists/netdev/msg531556.html
> >> Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
> >> Analysed-by: Jesper Dangaard Brouer <brouer@redhat.com>
> >> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> >> ---
> >> mm/page_alloc.c | 10 ++++++++--
> >> 1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >> index ae31839874b8..91a9a6af41a2 100644
> >> --- a/mm/page_alloc.c
> >> +++ b/mm/page_alloc.c
> >> @@ -4555,8 +4555,14 @@ void page_frag_free(void *addr)
> >> {
> >> struct page *page = virt_to_head_page(addr);
> >>
> >> - if (unlikely(put_page_testzero(page)))
> >> - __free_pages_ok(page, compound_order(page));
> >> + if (unlikely(put_page_testzero(page))) {
> >> + unsigned int order = compound_order(page);
> >> +
> >> + if (order == 0)
> >> + free_unref_page(page);
> >> + else
> >> + __free_pages_ok(page, order);
> >> + }
> >> }
> >> EXPORT_SYMBOL(page_frag_free);
> >>
> > One thing I would suggest for Pawel to try would be to reduce the Tx
> > qdisc size on his transmitting interfaces, Reduce the Tx ring size,
> > and possibly increase the Tx interrupt rate. Ideally we shouldn't have
> > too many packets in-flight and I suspect that is the issue that Pawel
> > is seeing that is leading to the page pool allocator freeing up the
> > memory. I know we like to try to batch things but the issue is
> > processing too many Tx buffers in one batch leads to us eating up too
> > much memory and causing evictions from the cache. Ideally the Rx and
> > Tx rings and queues should be sized as small as possible while still
> > allowing us to process up to our NAPI budget. Usually I run things
> > with a 128 Rx / 128 Tx setup and then reduce the Tx queue length so we
> > don't have more buffers stored there than we can place in the Tx ring.
> > Then we can avoid the extra thrash of having to pull/push memory into
> > and out of the freelists. Essentially the issue here ends up being
> > another form of buffer bloat.
> Thanks Aleksandar - yes it can be - but in my scenario setting RX buffer
> <4096 producing more interface rx drops - and no_rx_buffer on network
> controller that is receiving more packets
> So i need to stick with 3000-4000 on RX - and yes i was trying to lower
> the TX buff on connectx4 - but that changed nothing before Aaron patch
>
> After Aaron patch - decreasing TX buffer influencing total bandwidth
> that can be handled by the router/server
> Dono why before this patch there was no difference there no matter what
> i set there there was always page_alloc/slowpath on top in perf
>
>
> Currently testing RX4096/TX256 - this helps with bandwidth like +10%
> more bandwidth with less interrupts...
The problem is if you are going for less interrupts you are setting
yourself up for buffer bloat. Basically you are going to use much more
cache and much more memory then you actually need and if things are
properly configured NAPI should take care of the interrupts anyway
since under maximum load you shouldn't stop polling normally.
One issue I have seen is people delay interrupts for as long as
possible which isn't really a good thing since most network
controllers will use NAPI which will disable the interrupts and leave
them disabled whenever the system is under heavy stress so you should
be able to get the maximum performance by configuring an adapter with
small ring sizes and for high interrupt rates.
It is easiest to think of it this way. Your total packet rate is equal
to your interrupt rate times the number of buffers you will store in
the ring. So if you have some fixed rate "X" for packets and an
interrupt rate of "i" then your optimal ring size should be "X/i". So
if you lower the interrupt rate you end up hurting the throughput
unless you increase the buffer size. However at a certain point the
buffer size starts becoming an issue. For example with UDP flows I
often see massive packet drops if you tune the interrupt rate too low
and then put the system under heavy stress.
- Alex
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-11-11 22:26 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
One last pull request before heading to Vancouver for LPC, here we have:
1) Don't forget to free VSI contexts during ice driver unload, from
Victor Raj.
2) Don't forget napi delete calls during device remove in ice driver,
from Dave Ertman.
3) Don't request VLAN tag insertion of ibmvnic device when SKB doesn't
have VLAN tags at all.
4) IPV4 frag handling code has to accomodate the situation where two
threads try to insert the same fragment into the hash table at the
same time. From Eric Dumazet.
5) Relatedly, don't flow separate on protocol ports for fragmented
frames, also from Eric Dumazet.
6) Memory leaks in qed driver, from Denis Bolotin.
7) Correct valid MTU range in smsc95xx driver, from Stefan Wahren.
8) Validate cls_flower nested policies properly, from Jakub Kicinski.
9) Clearing of stats counters in mc88e6xxx driver doesn't retain
important bits in the G1_STATS_OP register causing the chip to
hang. Fix from Andrew Lunn.
Please pull, thanks a lot!
The following changes since commit 8053e5b93eca9b011f7b79bb019bf1eeaaf96c4b:
Merge tag 'trace-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2018-11-06 08:12:10 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 7236ead1b14923f3ba35cd29cce13246be83f451:
act_mirred: clear skb->tstamp on redirect (2018-11-11 10:21:31 -0800)
----------------------------------------------------------------
Akeem G Abodunrin (1):
ice: Fix dead device link issue with flow control
Alexandre Belloni (1):
net: mvneta: correct typo
Andrew Lunn (1):
net: dsa: mv88e6xxx: Fix clearing of stats counters
Anirudh Venkataramanan (4):
ice: Set carrier state and start/stop queues in rebuild
ice: Check for reset in progress during remove
ice: Remove duplicate addition of VLANs in replay path
ice: Fix typo in error message
Brett Creeley (2):
ice: Fix tx_timeout in PF driver
ice: Fix the bytecount sent to netdev_tx_sent_queue
Chinh T Cao (1):
ice: Change req_speeds to be u16
Dave Ertman (1):
ice: Fix napi delete calls for remove
David S. Miller (4):
Merge branch '100GbE' of git://git.kernel.org/.../jkirsher/net-queue
Merge branch 'FDDI-defza-Fix-a-bunch-of-small-issues'
Merge branch 'qed-Slowpath-Queue-bug-fixes'
Merge branch 'aquantia-fixes'
Denis Bolotin (3):
qed: Fix memory/entry leak in qed_init_sp_request()
qed: Fix blocking/unlimited SPQ entries leak
qed: Fix SPQ entries not returned to pool in error flows
Dmitry Bogdanov (3):
net: aquantia: fix potential IOMMU fault after driver unbind
net: aquantia: invalid checksumm offload implementation
net: aquantia: allow rx checksum offload configuration
Eric Dumazet (2):
inet: frags: better deal with smp races
act_mirred: clear skb->tstamp on redirect
Huazhong Tan (1):
net: hns3: bugfix for not checking return value
Igor Russkikh (2):
net: aquantia: synchronized flow control between mac/phy
net: aquantia: fixed enable unicast on 32 macvlan
Jacob Keller (2):
i40e: restore NETIF_F_GSO_IPXIP[46] to netdev features
i40e: enable NETIF_F_NTUPLE and NETIF_F_HW_TC at driver load
Jakub Kicinski (1):
net: sched: cls_flower: validate nested enc_opts_policy to avoid warning
Jon Maloy (1):
tipc: fix link re-establish failure
Maciej W. Rozycki (4):
FDDI: defza: Fix SPDX annotation
FDDI: defza: Add missing comment closing
FDDI: defza: Move SMT Tx data buffer declaration next to its skb
FDDI: defza: Make the driver version string constant
Md Fahad Iqbal Polash (1):
ice: Fix flags for port VLAN
Michał Mirosław (2):
ibmvnic: fix accelerated VLAN handling
qlcnic: remove assumption that vlan_tci != 0
Miroslav Lichvar (1):
igb: shorten maximum PHC timecounter update interval
Sagiv Ozeri (1):
qed: Fix potential memory corruption
Stefan Wahren (1):
net: smsc95xx: Fix MTU range
Subash Abhinov Kasiviswanathan (1):
net: qualcomm: rmnet: Fix incorrect assignment of real_dev
Tao Ren (1):
net: phy: Allow BCM54616S PHY to setup internal TX/RX clock delay
Thor Thayer (1):
net: stmmac: Fix RX packet size > 8191
Victor Raj (1):
ice: Free VSI contexts during for unload
배석진 (1):
flow_dissector: do not dissect l4 ports for fragments
drivers/net/dsa/mv88e6xxx/global1.c | 2 ++
drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c | 8 ++++----
drivers/net/ethernet/aquantia/atlantic/aq_hw.h | 6 ++++++
drivers/net/ethernet/aquantia/atlantic/aq_main.c | 10 ++++++++--
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 18 +++++++++++++++---
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 2 +-
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 35 +++++++++++++++++++++++------------
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 61 ++++++++++++++++++++++++++++++++++++++-----------------------
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c | 8 ++++++++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h | 3 +++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h | 18 ++++++++++++++++++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c | 21 +++++++++++++++++++++
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++-
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +++++---
drivers/net/ethernet/intel/ice/ice.h | 4 +++-
drivers/net/ethernet/intel/ice/ice_common.c | 3 +++
drivers/net/ethernet/intel/ice/ice_ethtool.c | 7 ++++++-
drivers/net/ethernet/intel/ice/ice_hw_autogen.h | 2 ++
drivers/net/ethernet/intel/ice/ice_lib.c | 3 ++-
drivers/net/ethernet/intel/ice/ice_main.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------
drivers/net/ethernet/intel/ice/ice_switch.c | 12 ++++++++++++
drivers/net/ethernet/intel/ice/ice_switch.h | 2 ++
drivers/net/ethernet/intel/ice/ice_txrx.c | 11 ++++++-----
drivers/net/ethernet/intel/ice/ice_txrx.h | 17 +++++++++++++++--
drivers/net/ethernet/intel/ice/ice_type.h | 2 +-
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 4 +---
drivers/net/ethernet/intel/igb/igb_ptp.c | 12 +++++++-----
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
drivers/net/ethernet/qlogic/qed/qed_fcoe.c | 11 ++++++++---
drivers/net/ethernet/qlogic/qed/qed_iscsi.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_l2.c | 12 ++++++++----
drivers/net/ethernet/qlogic/qed/qed_rdma.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_roce.c | 1 +
drivers/net/ethernet/qlogic/qed/qed_sp.h | 14 ++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 22 ++++++++++++++++++++--
drivers/net/ethernet/qlogic/qed/qed_spq.c | 69 +++++++++++++++++++++++++++++++++++----------------------------------
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 1 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 8 +++++---
drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c | 6 +++---
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/descs_com.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 2 +-
drivers/net/fddi/defza.c | 7 ++++---
drivers/net/fddi/defza.h | 3 ++-
drivers/net/phy/broadcom.c | 18 ++++++++++++++++--
drivers/net/usb/smsc95xx.c | 2 ++
net/core/flow_dissector.c | 4 ++--
net/ipv4/inet_fragment.c | 29 +++++++++++++++--------------
net/sched/act_mirred.c | 3 ++-
net/sched/cls_flower.c | 14 +++++++++++++-
net/sched/sch_netem.c | 9 ---------
net/tipc/link.c | 11 +++++++----
54 files changed, 430 insertions(+), 199 deletions(-)
^ permalink raw reply
* Re: [PATCH iproute2] testsuite: ss: Fix spacing in expected output for ssfilter.t
From: Phil Sutter @ 2018-11-11 12:12 UTC (permalink / raw)
To: Stefano Brivio; +Cc: Stephen Hemminger, Yoann P., netdev
In-Reply-To: <20181111125039.639dd608@redhat.com>
Hi Stefano,
On Sun, Nov 11, 2018 at 12:50:39PM +0100, Stefano Brivio wrote:
> On Sat, 10 Nov 2018 22:48:44 +0100
> Phil Sutter <phil@nwl.cc> wrote:
>
> > On Sat, Nov 10, 2018 at 10:21:59AM +0100, Stefano Brivio wrote:
> >
> > > @@ -12,37 +12,37 @@ export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
> > > ts_log "[Testing ssfilter]"
> > >
> > > ts_ss "$0" "Match dport = 22" -Htna dport = 22
> > > -test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> > > +test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> >
> > How about using a regular expression ('test_on' calls grep with '-E')?
> > E.g. this instead of the above:
> >
> > | test_on "ESTAB *0 *0 *10.0.0.1:36266 *10.0.0.1:22"
>
> I also thought about something similar (perhaps uglier: piping the
> output through tr -s ' ' in ts_ss()).
>
> But then I thought we might like to use this test to also check that we
> don't accidentally modify spacing, so I'd rather leave it as it is,
> with this patch on top.
Fair enough, no objections from my side.
Thanks, Phil
^ permalink raw reply
* Re: [PATCH iproute2] testsuite: ss: Fix spacing in expected output for ssfilter.t
From: Stefano Brivio @ 2018-11-11 11:50 UTC (permalink / raw)
To: Phil Sutter; +Cc: Stephen Hemminger, Yoann P., netdev
In-Reply-To: <20181110214844.GL6440@orbyte.nwl.cc>
Hi Phil,
On Sat, 10 Nov 2018 22:48:44 +0100
Phil Sutter <phil@nwl.cc> wrote:
> On Sat, Nov 10, 2018 at 10:21:59AM +0100, Stefano Brivio wrote:
>
> > @@ -12,37 +12,37 @@ export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
> > ts_log "[Testing ssfilter]"
> >
> > ts_ss "$0" "Match dport = 22" -Htna dport = 22
> > -test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
> > +test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
>
> How about using a regular expression ('test_on' calls grep with '-E')?
> E.g. this instead of the above:
>
> | test_on "ESTAB *0 *0 *10.0.0.1:36266 *10.0.0.1:22"
I also thought about something similar (perhaps uglier: piping the
output through tr -s ' ' in ts_ss()).
But then I thought we might like to use this test to also check that we
don't accidentally modify spacing, so I'd rather leave it as it is,
with this patch on top.
--
Stefano
^ permalink raw reply
* [PATCH net-next v2] PCI: add USR vendor id and use it in r8169 and w6692 driver
From: Heiner Kallweit @ 2018-11-11 10:50 UTC (permalink / raw)
To: Bjorn Helgaas, David Miller, Karsten Keil
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <9af6abf5-ba01-155f-17d1-ca4b71b74fa6@gmail.com>
The PCI vendor id of U.S. Robotics isn't defined in pci_ids.h so far,
only ISDN driver w6692 has a private definition. Move the definition
to pci_ids.h and use it also in the r8169 driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- The original patch caused a build failure in w6692 driver because
it broke the private PCI device id definition.
I hope it's ok to submit this through the netdev tree.
---
drivers/isdn/hardware/mISDN/w6692.c | 5 -----
drivers/net/ethernet/realtek/r8169.c | 2 +-
include/linux/pci_ids.h | 4 ++++
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/w6692.c b/drivers/isdn/hardware/mISDN/w6692.c
index 5acf6ab67..f6b4f4f11 100644
--- a/drivers/isdn/hardware/mISDN/w6692.c
+++ b/drivers/isdn/hardware/mISDN/w6692.c
@@ -52,11 +52,6 @@ static const struct w6692map w6692_map[] =
{W6692_USR, "USR W6692"}
};
-#ifndef PCI_VENDOR_ID_USR
-#define PCI_VENDOR_ID_USR 0x16ec
-#define PCI_DEVICE_ID_USR_6692 0x3409
-#endif
-
struct w6692_ch {
struct bchannel bch;
u32 addr;
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 1fd01688d..366a690eb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -224,7 +224,7 @@ static const struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4302), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_AT, 0xc107), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_USR, 0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS, 0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
{ 0x0001, 0x8168,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 69f0abe1b..1fac231fe 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2359,6 +2359,10 @@
#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_VENDOR_ID_USR 0x16ec
+#define PCI_DEVICE_ID_USR_997902 0x0116
+#define PCI_DEVICE_ID_USR_6692 0x3409
+
#define PCI_VENDOR_ID_VITESSE 0x1725
#define PCI_DEVICE_ID_VITESSE_VSC7174 0x7174
--
2.19.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox