* Re: [pull request][for-next 00/12] Mellanox, mlx5 IPoIB Muli Pkey support 2017-10-11
From: Leon Romanovsky @ 2017-10-15 6:30 UTC (permalink / raw)
To: Doug Ledford; +Cc: Saeed Mahameed, David S. Miller, netdev, linux-rdma
In-Reply-To: <af28440c-bb1c-c47b-92dd-60bfbeaa839d@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Sat, Oct 14, 2017 at 05:19:34PM -0400, Doug Ledford wrote:
> On 10/14/2017 2:48 PM, Saeed Mahameed wrote:
> > Hi Dave and Doug,
> >
> > This series includes updates for mlx5 IPoIB offloading driver from Alex
> > and Feras to add the support for Muli Pkey in the mlx5i ipoib offloading netdev,
> > to be merged into net-next and rdma-next trees.
>
> As far as the two IPoIB patches are concerned, they're fine.
>
> > Doug, I am sorry I couldn't base this on rc2 since the series needs and conflicts
> > with a fix that was submitted to rc3, so to keep things simple I based it on rc4,
> > I hope this is ok with you..
>
> No worries, it just means I have to submit it under another branch. But
> I'm already holding one patch series in a stand alone branch, so no big
> deal. And, actually, the IPoIB changes are so small they can simply go
> through Dave's tree if you don't have any dependent code in the IPoIB
> driver to submit after this but still in this devel cycle.
I have IPoIB NAPI implementation waiting for this shared code.
Thanks
>
> > Please pull and let me know if there's any problem.
>
> Once I hear that Dave is OK with the net changes, I'm ready to pull (if
> I need to).
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG Key ID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver
From: Yuval Mintz @ 2017-10-15 5:14 UTC (permalink / raw)
To: Yunsheng Lin, davem@davemloft.net
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5c268e80-3b04-28bd-26fb-d77f2edd69a8@huawei.com>
> Hi, Yuval
>
> On 2017/10/13 4:21, Yuval Mintz wrote:
> >> This patchset adds a new hardware offload type in mqprio before adding
> >> mqprio hardware offload support in hns3 driver.
> >
> > I think one of the biggest issues in tying this to DCB configuration is the
> > non-immediate [and possibly non persistent] configuration.
> >
> > Scenario #1:
> > User is configuring mqprio offloaded with 3 TCs while device is in willing
> mode.
> > Would you expect the driver to immediately respond with a success or
> instead
> > delay the return until the DCBx negotiation is complete and the operational
> > num of TCs is actually 3?
>
> Well, when user requsts the mqprio offloaded by a hardware shared by DCB,
> I expect
> the user is not using the dcb tool.
> If user is still using dcb tool, then result is undefined.
>
> The scenario you mention maybe can be enforced by setting willing to zero
> when user
> is requesting the mqprio offload, and restore the willing bit when unloaded
> the mqprio
> offload.
Sounds a bit harsh but would probably work.
> But I think the real issue is that dcb and mqprio shares the tc system in the
> stack,
> the problem may be better to be fixed in the stack rather than in the driver,
> as you
> suggested in the DCB patchset. What do you think?
What did you have in mind?
>
> >
> > Scenario #2:
> > Assume user explicitly offloaded mqprio with 3 TCs, but now DCB
> configuration
> > has changed on the peer side and 4 TCs is the new negotiated operational
> value.
> > Your current driver logic would change the number of TCs underneath the
> user
> > configuration [and it would actually probably work due to mqprio being a
> crappy
> > qdisc]. But was that the user actual intention?
> > [I think the likely answer in this scenario is 'yes' since the alternative is no
> better.
> > But I still thought it was worth mentioning]
>
> You are right, the problem also have something to do with mqprio and dcb
> sharing
> the tc in the stack.
>
> Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
> queue has a default pfifo mqprio attached, after DCB changes the tc num to
> 4,
> using tc qdisc shows some queue does not have a default pfifo mqprio
> attached.
Really? Then what did it show?
[I assume it has some pfifo attached, and it's an mqprio dump kind of an issue]
>
> Maybe we can add a callback to notify mqprio the configuration has changed.
>
Which would do what?
You already have the notifications available for monitoring using dcbnl logic if the
configuration change [for user]; So user can re-configure whatever it wants.
But other than dropping all the qdisc configurations and going back to the default
qdiscs, what default action would mqprio be able to do when configuration changes
that actually makes sense?
> Thanks
> Yunsheng Lin
>
> >
> > Cheers,
> > Yuval
> >
> >>
> >> Yunsheng Lin (2):
> >> mqprio: Add a new hardware offload type in mqprio
> >> net: hns3: Add mqprio hardware offload support in hns3 driver
> >>
> >> drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
> >> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++++++++++
> >> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46
> ++++++++++++++-
> >> -------
> >> include/uapi/linux/pkt_sched.h | 1 +
> >> 4 files changed, 55 insertions(+), 16 deletions(-)
> >>
> >> --
> >> 1.9.1
> >
> >
> >
^ permalink raw reply
* Re: [net-next 3/3] tcp: keep tcp_collapse controllable even after processing starts
From: Koichiro Den @ 2017-10-15 2:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995970.31614.59.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:46 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > Combining actual collapsing with reasoning for deciding the starting
> > point, we can apply its logic in a consistent manner such that we can
> > avoid costly yet not much useful collapsing. When collapsing to be
> > triggered, it's not rare that most of the skbs in the receive or ooo
> > queue are large ones without much metadata overhead. This also
> > simplifies code and makes it easier to apply logic in a fair manner.
> >
> > Subtle subsidiary changes included:
> > - When the end_seq of the skb we are trying to collapse was larger than
> > the 'end' argument provided, we would end up copying to the 'end'
> > even though we couldn't collapse the original one. Current users of
> > tcp_collapse does not require such reserves so redefines it as the
> > point over which skbs whose seq passes guranteed not to be collapsed.
> > - Naturally tcp_collapse_ofo_queue shapes up and we no longer need
> > 'tail' argument.
>
>
> I am not inclined to review such a large change, without you providing
> actual numbers.
>
> We have a problem in TCP right now, that receiver announces a too big
> window, and that is the main reason we trigger collapsing.
>
> I would rather fix the root cause.
>
>
Ok I got it, thank you.
^ permalink raw reply
* Re: [net-next 2/3] tcp: do not tcp_collapse once SYN or FIN found
From: Koichiro Den @ 2017-10-15 2:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995823.31614.57.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:43 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > Since 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
> > applied, we no longer need to continue to search for the starting
> > point once we encounter FIN packet. Same reasoning for SYN packet
> > since commit 9d691539eea2d ("tcp: do not enqueue skb with SYN flag"),
> > that would help us with error message when actual receiving.
>
> Very confusing changelog or patch.
>
> What exact problem do you want to solve ?
>
>
That I thought as unnecessary search for the starting point. I am going to re-
read all to correct my misunderstanding.
Thank you.
^ permalink raw reply
* Re: [net-next 1/3] tcp: avoid useless copying and collapsing of just one skb
From: Koichiro Den @ 2017-10-15 2:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995761.31614.56.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:42 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > On the starting point chosen, it could be possible that just one skb
> > remains in between the range provided, leading to copying and re-insertion
> > of rb node, which is useless with respect to the rcv buf measurement.
> > This is rather probable in ooo queue case, in which non-contiguous bloated
> > packets have been queued up.
> >
> > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > ---
> > net/ipv4/tcp_input.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > index d0682ce2a5d6..1d785b5bf62d 100644
> > --- a/net/ipv4/tcp_input.c
> > +++ b/net/ipv4/tcp_input.c
> > @@ -4807,7 +4807,8 @@ tcp_collapse(struct sock *sk, struct sk_buff_head
> > *list, struct rb_root *root,
> > start = TCP_SKB_CB(skb)->end_seq;
> > }
> > if (end_of_skbs ||
> > - (TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
> > + (TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) ||
> > + (TCP_SKB_CB(skb)->seq == start && TCP_SKB_CB(skb)->end_seq ==
> > end))
> > return;
> >
> > __skb_queue_head_init(&tmp);
>
>
> What do you mean by useless ?
>
> Surely if this skb contains 17 segments (some USB drivers allocate 8KB
> per frame), we want to collapse them to save memory.
>
> So I do not agree with this patch.
>
>
I missed that, and sorry about bothering with all, I totally misunderstood it.
Thank you for all of them.
^ permalink raw reply
* [PATCH] rtlwifi: Fix typo in if ... else if ... else construct
From: Larry Finger @ 2017-10-15 1:58 UTC (permalink / raw)
To: gregkh
Cc: netdev, devel, Larry Finger, Ping-Ke Shih, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting, kbuild-all, Julia Lawall
The kbuild test robot reports two conditions with no effect (if == else).
These are the result of copy and paste typographical errors.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Cc: kbuild-all@01.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
---
drivers/staging/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index b88b0e8edd3d..1a0331cf63ee 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c
@@ -920,7 +920,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw *hw,
else if ((tx_mcs_map & 0x000c) >> 2 ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
- rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
+ rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
@@ -932,7 +932,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw *hw,
else if ((tx_mcs_map & 0x0003) ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
- rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
+ rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
--
2.12.3
^ permalink raw reply related
* Re: [PATCH net 0/6] bnxt_en: bug fixes.
From: David Miller @ 2017-10-15 1:52 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1507943374-13308-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 13 Oct 2017 21:09:28 -0400
> Various bug fixes for the VF/PF link change logic, VF resource checking,
> potential firmware response corruption on NVRAM and DCB parameters,
> and reading the wrong register for PCIe link speed on the VF.
Series applied, thanks.
^ permalink raw reply
* Re: [net-next 0/9][pull request] 40GbE Intel Wired LAN Driver Updates 2017-10-13
From: David Miller @ 2017-10-15 1:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20171013215249.61286-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 13 Oct 2017 14:52:40 -0700
> This series contains updates to mqprio and i40e.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] tc-testing: Test suite updates
From: David Miller @ 2017-10-15 1:48 UTC (permalink / raw)
To: lucasb; +Cc: netdev, xiyou.wangcong, jiri, jhs, aring, mrv
In-Reply-To: <1507931485-1814-1-git-send-email-lucasb@mojatatu.com>
From: Lucas Bates <lucasb@mojatatu.com>
Date: Fri, 13 Oct 2017 17:51:21 -0400
> This patch series is a roundup of changes to the tc-testing
> suite:
>
> - Add test cases for police and mirred modules and some coverage
> in already-submitted test categories
> - Break the test case files down into more user-friendly sizes
> - Bug fix to the tdc.py script's handling of the -l argument
>
> v2: fix the lack of final newlines in two new files (thanks David)
Series applied, thanks for fixing that up.
^ permalink raw reply
* Re: [net-next PATCH 0/2] Minor macvlan source mode cleanups
From: David Miller @ 2017-10-15 1:46 UTC (permalink / raw)
To: alexander.duyck; +Cc: netdev
In-Reply-To: <20171013203726.16950.32584.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 13 Oct 2017 13:40:18 -0700
> So this patch series is just a few minor cleanups for macvlan source mode.
> The first patch addresses double receives when a packet is being routed to
> the macvlan destination address, and the other addresses the pkt_type being
> updated in cases where it most likely should not be.
Series applied, thanks.
^ permalink raw reply
* Re: [Patch net-next v3] tcp: add a tracepoint for tcp retransmission
From: David Miller @ 2017-10-15 1:45 UTC (permalink / raw)
To: xiyou.wangcong
Cc: netdev, edumazet, alexei.starovoitov, hannes, brendan.d.gregg,
ncardwell
In-Reply-To: <20171013200316.28561-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 13 Oct 2017 13:03:16 -0700
> We need a real-time notification for tcp retransmission
> for monitoring.
>
> Of course we could use ftrace to dynamically instrument this
> kernel function too, however we can't retrieve the connection
> information at the same time, for example perf-tools [1] reads
> /proc/net/tcp for socket details, which is slow when we have
> a lots of connections.
>
> Therefore, this patch adds a tracepoint for __tcp_retransmit_skb()
> and exposes src/dst IP addresses and ports of the connection.
> This also makes it easier to integrate into perf.
>
> Note, I expose both IPv4 and IPv6 addresses at the same time:
> for a IPv4 socket, v4 mapped address is used as IPv6 addresses,
> for a IPv6 socket, LOOPBACK4_IPV6 is already filled by kernel.
> Also, add sk and skb pointers as they are useful for BPF.
>
> 1. https://github.com/brendangregg/perf-tools/blob/master/net/tcpretrans
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix a compile warning in act_ife
From: David Miller @ 2017-10-15 1:44 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, mrv
In-Reply-To: <20171013195813.25321-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 13 Oct 2017 12:58:13 -0700
> Apparently ife_meta_id2name() is only called when
> CONFIG_MODULES is defined.
>
> This fixes:
>
> net/sched/act_ife.c:251:20: warning: ‘ife_meta_id2name’ defined but not used [-Wunused-function]
> static const char *ife_meta_id2name(u32 metaid)
> ^~~~~~~~~~~~~~~~
>
> Fixes: d3f24ba895f0 ("net sched actions: fix module auto-loading")
> Cc: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next,0/3] Add init of send table and var renames
From: David Miller @ 2017-10-15 1:43 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: netdev, kys, sthemmin, olaf, vkuznets, linux-kernel
In-Reply-To: <20171013192805.18183-1-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@exchange.microsoft.com>
Date: Fri, 13 Oct 2017 12:28:02 -0700
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> Add initialization of send indirection table. Otherwise it may contain
> old info of previous device with different number of channels.
>
> Also, did some variable renaming for easier reading.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net] l2tp: check ps->sock before running pppol2tp_session_ioctl()
From: David Miller @ 2017-10-15 1:39 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman, tparkin
In-Reply-To: <520e39809f7ca7d8b38282e3a6bf0bbf93219541.1507915312.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Fri, 13 Oct 2017 19:22:35 +0200
> When pppol2tp_session_ioctl() is called by pppol2tp_tunnel_ioctl(),
> the session may be unconnected. That is, it was created by
> pppol2tp_session_create() and hasn't been connected with
> pppol2tp_connect(). In this case, ps->sock is NULL, so we need to check
> for this case in order to avoid dereferencing a NULL pointer.
>
> Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH][net-next] cxgb4: fix missing break in switch and indent return statements
From: David Miller @ 2017-10-15 1:38 UTC (permalink / raw)
To: colin.king; +Cc: ganeshgr, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20171013162900.16911-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 13 Oct 2017 17:29:00 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The break statement for the Macronix case is missing and will
> fall through to the Winbond case and re-assign the size setting.
> Fix this by adding the missing break statement. Also correctly
> indent the return statements.
>
> Detected by CoverityScan, CID#1458020 ("Missing break in switch")
>
> Fixes: 96ac18f14a5a ("cxgb4: Add support for new flash parts")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: pull-request: mac80211-next 2017-10-13
From: David Miller @ 2017-10-15 1:37 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20171013155332.4310-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 13 Oct 2017 17:53:31 +0200
> Sorry for the quick succession - there were a few issues with
> the last pull request that only got noticed now, so I'm fixing
> those here.
>
> Please pull and let me know if there's any problem.
No worries, pulled, thanks Johannes.
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] cxgb4: add support to get hardware debug logs via ethtool
From: David Miller @ 2017-10-15 1:35 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, ganeshgr, nirranjan, indranil
In-Reply-To: <cover.1507899723.git.rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Fri, 13 Oct 2017 18:48:12 +0530
> This series of patches add support to collect hardware debug logs
> via ethtool --get-dump facility.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] nfp: Explicitly include linux/bug.h
From: David Miller @ 2017-10-15 1:31 UTC (permalink / raw)
To: broonie; +Cc: jakub.kicinski, simon.horman, oss-drivers, netdev
In-Reply-To: <20171013025035.4450-1-broonie@kernel.org>
From: Mark Brown <broonie@kernel.org>
Date: Fri, 13 Oct 2017 03:50:35 +0100
> Today's -next build encountered an error due to a missing definition of
> WARN_ON(), caused by some header reorganization removing an implicit
> inclusion of linux/bug.h. Fix this with an explicit inclusion.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
Applied, thanks Mark.
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] net: dsa: remove .set_addr
From: David Miller @ 2017-10-15 1:30 UTC (permalink / raw)
To: vivien.didelot
Cc: netdev, linux-kernel, kernel, f.fainelli, andrew, David.Laight
In-Reply-To: <20171013181809.14627-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Fri, 13 Oct 2017 14:18:04 -0400
> An Ethernet switch may support having a MAC address, which can be used
> as the switch's source address in transmitted full-duplex Pause frames.
>
> If a DSA switch supports the related .set_addr operation, the DSA core
> sets the master's MAC address on the switch.
>
> This won't make sense anymore in a multi-CPU ports system, because there
> won't be a unique master device assigned to a switch tree.
>
> Moreover this operation is confusing because it makes the user think
> that it could be used to program the switch with the MAC address of the
> CPU/management port such that MAC address learning can be disabled on
> said port, but in fact, that's not how it is currently used.
>
> To fix this, assign a random MAC address at setup time in the mv88e6060
> and mv88e6xxx drivers before removing .set_addr completely from DSA.
>
> Changes in v3:
> - include fix for mv88e6060 switch MAC address setter.
>
> Changes in v2:
> - remove .set_addr implementation from drivers and use a random MAC.
Series applied,thanks Vivien.
^ permalink raw reply
* Re: [PATCH] atm: fore200e: mark expected switch fall-throughs
From: David Miller @ 2017-10-15 1:25 UTC (permalink / raw)
To: garsilva; +Cc: 3chas3, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20171012211132.GA6589@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Thu, 12 Oct 2017 16:11:32 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH] fix typo in skbuff.c
From: David Miller @ 2017-10-15 1:24 UTC (permalink / raw)
To: march511; +Cc: netdev, linux-kernel
In-Reply-To: <20171014165136.2041-1-march511@gmail.com>
From: Wenhua Shi <march511@gmail.com>
Date: Sat, 14 Oct 2017 18:51:36 +0200
> ---
> net/core/skbuff.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Alexander Duyck @ 2017-10-15 0:58 UTC (permalink / raw)
To: Paweł Staszewski
Cc: Anders K. Pedersen | Cohaesio, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, alexander.h.duyck@intel.com
In-Reply-To: <c49a750f-c47c-9de0-ebf0-148db5e3d3c5@itcare.pl>
Hi Pawel,
To clarify is that Dave Miller's tree or Linus's that you are talking
about? If it is Dave's tree how long ago was it you pulled it since I
think the fix was just pushed by Jeff Kirsher a few days ago.
The issue should be fixed in the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972
Thanks.
- Alex
On Sat, Oct 14, 2017 at 3:03 PM, Paweł Staszewski <pstaszewski@itcare.pl> wrote:
> Forgot to add - this graphs are tested with Kernel 4.14-rc4-next
>
>
> W dniu 2017-10-15 o 00:00, Paweł Staszewski pisze:
>
> Same problem here
>
> Also only difference is change 82599 intel to x710 and have memleak
>
> mem with ixgbe driver over time - same config saame kernel
>
>
>
> changed NIC's to x710 i40e driver (this is the only change)
>
> And mem over time:
>
>
>
> There is no process that is eating memory - looks like there is some problem
> with i40e driver - but it not a surprise :) this driver is really buggy -
> with many things - most tickets on e1000e sourceforge that i openned have no
> reply for year or more - or if somebody reply after year they are closing
> ticket after 1 day with info about no activity :)
>
>
>
> W dniu 2017-10-05 o 07:19, Anders K. Pedersen | Cohaesio pisze:
>
> On ons, 2017-10-04 at 08:32 -0700, Alexander Duyck wrote:
>
> On Wed, Oct 4, 2017 at 5:56 AM, Anders K. Pedersen | Cohaesio
> <akp@cohaesio.com> wrote:
>
> Hello,
>
> After updating one of our Linux based routers to kernel 4.13 it
> began
> leaking memory quite fast (about 1 GB every half hour). To narrow
> we
> tried various kernel versions and found that 4.11.12 is okay, while
> 4.12 also leaks, so we did a bisection between 4.11 and 4.12.
>
> The first bisection ended at
> "[6964e53f55837b0c49ed60d36656d2e0ee4fc27b] i40e: fix handling of
> HW
> ATR eviction", which fixes some flag handling that was broken by
> 47994c119a36 "i40e: remove hw_disabled_flags in favor of using
> separate
> flag bits", so I did a second bisection, where I added 6964e53f5583
> "i40e: fix handling of HW ATR eviction" to the steps that had
> 47994c119a36 "i40e: remove hw_disabled_flags in favor of using
> separate
> flag bits" in them.
>
> The second bisection ended at
> "[0e626ff7ccbfc43c6cc4aeea611c40b899682382] i40e: Fix support for
> flow
> director programming status", where I don't see any obvious
> problems,
> so I'm hoping for some assistance.
>
> The router is a PowerEdge R730 server (Haswell based) with three
> Intel
> NICs (all using the i40e driver):
>
> X710 quad port 10 GbE SFP+: eth0 eth1 eth2 eth3
> X710 quad port 10 GbE SFP+: eth4 eth5 eth6 eth7
> XL710 dual port 40 GbE QSFP+: eth8 eth9
>
> The NICs are aggregated with LACP with the team driver:
>
> team0: eth9 (40 GbE selected primary), and eth3, eth7 (10 GbE non-
> selected backups)
> team1: eth0, eth1, eth4, eth5 (all 10 GbE selected)
>
> team0 is used for internal networks and has one untagged and four
> tagged VLAN interfaces, while team1 has an external uplink
> connection
> without any VLANs.
>
> The router runs an eBGP session on team1 to one of our uplinks, and
> iBGP via team0 to our other border routers. It also runs OSPF on
> the
> internal VLANs on team0. One thing I've noticed is that when OSPF
> is
> not announcing a default gateway to the internal networks, so there
> is
> almost no traffic coming in on team0 and out on team1, but still
> plenty
> of traffic coming in on team1 and out via team0, there's no memory
> leak
> (or at least it is so small that we haven't detected it). But as
> soon
> as we configure OSPF to announce a default gateway to the internal
> VLANs, so we get traffic from team0 to team1 the leaking begins.
> Stopping the OSPF default gateway announcement again also stops the
> leaking, but does not release already leaked memory.
>
> So this leads to me suspect that the leaking is related to RX on
> team0
> (where XL710 eth9 is normally the only active interface) or TX on
> team1
> (X710 eth0, eth1, eth4, eth5). The first bad commit is related to
> RX
> cleaning, which suggests RX on team0. Since we're only seeing the
> leak
> for our outbound traffic, I suspect either a difference between the
> X710 vs. XL710 NICs, or that the inbound traffic is for relatively
> few
> destination addresses (only our own systems) while the outbound
> traffic
> is for many different addresses on the internet. But I'm just
> guessing
> here.
>
> I've tried kmemleak, but it only found a few kB of suspected memory
> leaks (several of which disappeared again after a while).
>
> Below I've included more details - git bisect logs, ethtool -i,
> dmesg,
> Kernel .config, and various memory related /proc files. Any help or
> suggestions would be much appreciated, and please let me know if
> more
> information is needed or there's something I should try.
>
> Regards,
> Anders K. Pedersen
>
> Hi Anders,
>
> I think I see the problem and should have a patch submitted shortly
> to
> address it. From what I can tell it looks like the issue is that we
> weren't properly recycling the pages associated with descriptors that
> contained an Rx programming status. For now the workaround would be
> to
> try disabling ATR via the "ethtool --set-priv-flags" command. I
> should
> have a patch out in the next hour or so that you can try testing to
> verify if it addresses the issue.
>
> Thanks.
>
> - Alex
>
> Thanks Alex,
>
> I will test the patch in our next service window on Tuesday morning.
>
> Regards,
> Anders
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET
From: Michael S. Tsirkin @ 2017-10-15 0:45 UTC (permalink / raw)
To: Willem de Bruijn
Cc: netdev, davem, jasowang, virtualization, Willem de Bruijn
In-Reply-To: <20171013155140.124530-1-willemdebruijn.kernel@gmail.com>
On Fri, Oct 13, 2017 at 11:51:40AM -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> Implement the reset communication request defined in the VIRTIO 1.0
> specification and introduces in Linux in commit c00bbcf862896 ("virtio:
> add VIRTIO_CONFIG_S_NEEDS_RESET device status bit").
>
> Use the virtnet_reset function introduced in commit 2de2f7f40ef9
> ("virtio_net: XDP support for adjust_head"). That was removed in
> commit 4941d472bf95 ("virtio-net: do not reset during XDP set"),
> because no longer used. Bring it back, minus the xdp specific code.
>
> Before tearing down any state, virtnet_freeze_down quiesces the
> device with netif_tx_disable. virtnet_reset also ensures that no
> other config operations can run concurrently.
>
> On successful reset, the host can observe that the flag has been
> cleared. There is no need for the explicit control flag introduced
> in the previous RFC of this patch.
>
> Changes
> RFC -> v1
> - drop VIRTIO_NET_CTRL_RESET_ACK message
> - drop VIRTIO_F_CAN_RESET flag to notify guest support
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
> drivers/net/virtio_net.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index fc059f193e7d..8e768b54844f 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1903,13 +1903,14 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
> .set_link_ksettings = virtnet_set_link_ksettings,
> };
>
> -static void virtnet_freeze_down(struct virtio_device *vdev)
> +static void virtnet_freeze_down(struct virtio_device *vdev, bool in_config)
> {
> struct virtnet_info *vi = vdev->priv;
> int i;
>
> - /* Make sure no work handler is accessing the device */
> - flush_work(&vi->config_work);
> + /* Make sure no other work handler is accessing the device */
> + if (!in_config)
> + flush_work(&vi->config_work);
>
> netif_device_detach(vi->dev);
> netif_tx_disable(vi->dev);
> @@ -1924,6 +1925,7 @@ static void virtnet_freeze_down(struct virtio_device *vdev)
> }
>
> static int init_vqs(struct virtnet_info *vi);
> +static void remove_vq_common(struct virtnet_info *vi);
>
> static int virtnet_restore_up(struct virtio_device *vdev)
> {
> @@ -1952,6 +1954,40 @@ static int virtnet_restore_up(struct virtio_device *vdev)
> return err;
> }
>
> +static int virtnet_reset(struct virtnet_info *vi)
> +{
> + struct virtio_device *dev = vi->vdev;
> + int ret;
> +
> + virtio_config_disable(dev);
> + dev->failed = dev->config->get_status(dev) & VIRTIO_CONFIG_S_FAILED;
> + virtnet_freeze_down(dev, true);
> + remove_vq_common(vi);
> +
> + virtio_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
> + virtio_add_status(dev, VIRTIO_CONFIG_S_DRIVER);
> +
> + ret = virtio_finalize_features(dev);
> + if (ret)
> + goto err;
> +
> + ret = virtnet_restore_up(dev);
> + if (ret)
> + goto err;
> +
> + ret = virtnet_set_queues(vi, vi->curr_queue_pairs);
> + if (ret)
> + goto err;
> +
> + virtio_add_status(dev, VIRTIO_CONFIG_S_DRIVER_OK);
> + virtio_config_enable(dev);
> + return 0;
> +
> +err:
> + virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
> + return ret;
> +}
> +
> static int virtnet_set_guest_offloads(struct virtnet_info *vi, u64 offloads)
> {
> struct scatterlist sg;
I have a question here though. How do things like MAC address
get restored?
What about the rx mode?
vlans?
Also, it seems that LINK_ANNOUNCE requests will get ignored
even if they got set before the reset, leading to downtime.
> @@ -2136,6 +2172,10 @@ static void virtnet_config_changed_work(struct work_struct *work)
> virtnet_ack_link_announce(vi);
> }
>
> + if (vi->vdev->config->get_status(vi->vdev) &
> + VIRTIO_CONFIG_S_NEEDS_RESET)
> + virtnet_reset(vi);
> +
> /* Ignore unknown (future) status bits */
> v &= VIRTIO_NET_S_LINK_UP;
>
> @@ -2756,7 +2796,7 @@ static __maybe_unused int virtnet_freeze(struct virtio_device *vdev)
> struct virtnet_info *vi = vdev->priv;
>
> virtnet_cpu_notif_remove(vi);
> - virtnet_freeze_down(vdev);
> + virtnet_freeze_down(vdev, false);
> remove_vq_common(vi);
>
> return 0;
> --
> 2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply
* Re: [patch net-next 06/34] net: core: use dev->ingress_queue instead of tp->q
From: Daniel Borkmann @ 2017-10-14 23:18 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, jeffrey.t.kirsher, saeedm,
matanb, leonro, idosch, jakub.kicinski, ast, simon.horman,
pieter.jansenvanvuuren, john.hurley, edumazet, dsahern,
alexander.h.duyck, john.fastabend, willemb
In-Reply-To: <20171013063019.GC1952@nanopsycho.orion>
On 10/13/2017 08:30 AM, Jiri Pirko wrote:
> Thu, Oct 12, 2017 at 11:45:43PM CEST, daniel@iogearbox.net wrote:
>> On 10/12/2017 07:17 PM, Jiri Pirko wrote:
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> In sch_handle_egress and sch_handle_ingress, don't use tp->q and use
>>> dev->ingress_queue which stores the same pointer instead.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>> ---
>>> net/core/dev.c | 21 +++++++++++++++------
>>> 1 file changed, 15 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index fcddccb..cb9e5e5 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -3273,14 +3273,18 @@ EXPORT_SYMBOL(dev_loopback_xmit);
>>> static struct sk_buff *
>>> sch_handle_egress(struct sk_buff *skb, int *ret, struct net_device *dev)
>>> {
>>> + struct netdev_queue *netdev_queue =
>>> + rcu_dereference_bh(dev->ingress_queue);
>>> struct tcf_proto *cl = rcu_dereference_bh(dev->egress_cl_list);
>>> struct tcf_result cl_res;
>>> + struct Qdisc *q;
>>>
>>> - if (!cl)
>>> + if (!cl || !netdev_queue)
>>> return skb;
>>> + q = netdev_queue->qdisc;
>>
>> NAK, no additional overhead in the software fast-path of
>> sch_handle_{ingress,egress}() like this. There are users out there
>> that use tc in software only, so performance is critical here.
>
> Okay, how else do you suggest I can avoid the need to use tp->q?
> I was thinking about storing q directly to net_device, which would safe
> one dereference, resulting in the same amount as current cl->q.
Sorry for late reply, mostly off for few days. netdev struct has different
cachelines which are hot on rx and tx (see also the location of the two
lists, ingress_cl_list and egress_cl_list), if you add only one qdisc
pointer there, then you'd at least penalize one of the two w/ potential
cache miss. Can we leave it in cl?
^ permalink raw reply
* Re: [PATCH] Add -target to clang switch while cross compiling.
From: Daniel Borkmann @ 2017-10-14 23:10 UTC (permalink / raw)
To: Abhijit Ayarekar, ast; +Cc: netdev, linux-kernel
In-Reply-To: <1507922646-19260-1-git-send-email-abhijit.ayarekar@caviumnetworks.com>
On 10/13/2017 09:24 PM, Abhijit Ayarekar wrote:
> Update to llvm excludes assembly instructions.
> llvm git revision is below
>
> commit 65fad7c26569 ("bpf: add inline-asm support")
>
> This change will be part of llvm release 6.0
>
> __ASM_SYSREG_H define is not required for native compile.
> -target switch includes appropriate target specific files
> while cross compiling
>
> Tested on x86 and arm64.
>
> Signed-off-by: Abhijit Ayarekar <abhijit.ayarekar@caviumnetworks.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ 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