* Re: [RFT net-next v2 0/3] dwmac-meson8b: RGMII clock fixes for Meson8b
From: Emiliano Ingrassia @ 2017-12-28 17:51 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: netdev, linus.luessing, khilman, linux-amlogic, jbrunet,
Neil Armstrong, peppe.cavallaro, alexandre.torgue
In-Reply-To: <CAFBinCBMN4Kkai82ZaehytM11JR+TCcz2jUSLU5gbWz9w8PE6A@mail.gmail.com>
Hi Martin,
thank you for the quick response!
On Thu, Dec 28, 2017 at 05:58:34PM +0100, Martin Blumenstingl wrote:
> Hi Emiliano,
>
> thank you for testing this!
>
> On Thu, Dec 28, 2017 at 5:16 PM, Emiliano Ingrassia
> <ingrassia@epigenesys.com> wrote:
> > Hi Martin, Hi Dave,
> >
> > On Sun, Dec 24, 2017 at 12:40:57AM +0100, Martin Blumenstingl wrote:
> >> Hi Dave,
> >>
> >> please do not apply this series until it got a Tested-by from Emiliano.
> >>
> >>
> >> Hi Emiliano,
> >>
> >> you reported [0] that you couldn't get dwmac-meson8b to work on your
> >> Odroid-C1. With your findings (register dumps, clk_summary output, etc.)
> >> I think I was able to find a fix: it consists of two patches (which you
> >> find in this series)
> >>
> >> Unfortunately I don't have any Meson8b boards with RGMII PHY so I could
> >> only partially test this (I could only check if the clocks were
> >> calculated correctly when using a dummy 500002394Hz input clock instead
> >> of MPLL2).
> >>
> >> Could you please give this series a try and let me know about the
> >> results?
> >> You obviously still need your two "ARM: dts: meson8b" patches which
> >> - add the amlogic,meson8b-dwmac" compatible to meson8b.dtsi
> >> - enable Ethernet on the Odroid-C1
> >>
> >> I have tested this myself on a Khadas VIM (GXL SoC, internal RMII PHY)
> >> and a Khadas VIM2 (GXM SoC, external RGMII PHY). Both are still working
> >> fine (so let's hope that this also fixes your Meson8b issue :)).
> >>
> >>
> >> changes since v1 at [1]:
> >> - changed the subject of the cover-letter to indicate that this is all
> >> about the RGMII clock
> >> - added PATCH #1 which ensures that we don't unnecessarily change the
> >> parent clocks in RMII mode (and also makes the code easier to
> >> understand)
> >> - changed subject of PATCH #2 (formerly PATCH #1) to state that this
> >> is about the RGMII clock
> >> - added Jerome's Reviewed-by to PATCH #2 (formerly PATCH #1)
> >> - replaced PATCH #3 (formerly PATCH #2) with one that sets
> >> CLK_SET_RATE_PARENT on the mux and thus re-configures the MPLL2 clock
> >> on Meson8b correctly
> >>
> >
> > Really thank you for your help and effort. I tried your patch but
> > unfortunately it didn't solve the problem.
> this is probably my fault: I forgot to mention that it requires a fix
> for the 32-bit SoCs in the clock driver ("clk: meson: mpll: use 64-bit
> maths in params_from_rate", see [0]) to work properly
>
Ok, with that patch applied I got:
xtal 1 1 24000000 0 0
sys_pll 0 0 1200000000 0 0
cpu_clk 0 0 1200000000 0 0
vid_pll 0 0 732000000 0 0
fixed_pll 2 2 2550000000 0 0
mpll2 1 1 124999851 0 0
c9410000.ethernet#m250_sel 1 1 124999851 0 0
c9410000.ethernet#m250_div 1 1 124999851 0 0
c9410000.ethernet#m25_div 1 1 24999971 0 0
which is equal to your result. However, the ethernet is still not working.
The prg0 register is set to 0x70A1.
A problem that I see with this solution is that MPLL2 is set to ~125 MHz.
The S805 SoC manual reports that bits 9-7 should contain a value x such
that: MPLL2 = 250 MHz * x (with x >= 1).
In our case, bits 9-7 are set to 1 which is incorrect.
I think that MPLL2 should be 250 MHz at least.
> >
> > Here is the new clk_summary:
> >
> > xtal 1 1 24000000 0 0
> > sys_pll 0 0 1200000000 0 0
> > cpu_clk 0 0 1200000000 0 0
> > vid_pll 0 0 732000000 0 0
> > fixed_pll 2 2 2550000000 0 0
> > mpll2 1 1 106250000 0 0
> > c9410000.ethernet#m250_sel 1 1 106250000 0 0
> > c9410000.ethernet#m250_div 1 1 106250000 0 0
> > c9410000.ethernet#m25_div 1 1 21250000 0 0
> >
> > which leads to a value of 0x70a1 in the prg0 ethernet register.
> > As you can see, something is changed but the RGMII clock is not at 25 MHz.
> > In particular, the bit 10 of prg0, which enables the "generation of 25 MHz
> > clock for PHY" (see S805 manual), is 0.
> assuming that the description in the datasheet is correct
> after Kevin and Mike got updated information from Amlogic about the
> PRG_ETHERNET0 register documenation (see [1]) we thought that bit 10
> means "0 = divide by 5, 1 = divide by 10" (see [2]). I didn't question
> this so far, but I'll test this on a newer SoC later (by forcing
> m250_div to 125MHz, then m25_div will have register value 0 = divide
> by 5)
>
> if the description from the documentation is correct then we need to
> replace m25_div with a fixed-factor clock (mult = 1, div = 5) and make
> it a m25_en gate clock instead
> the resulting clock path would look like this: mpll2 > m250_sel >
> m250_div > fixed_factor > m25_en
>
> > Please, if you have other suggestions let me know.
> could you please re-test this with the patch from [0] applied? no
> other changes should be needed!
>
> > Best regards,
> >
> > Emiliano
> >
> >>
> >> [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005596.html
> >> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005848.html
> >>
> >>
> >> Martin Blumenstingl (3):
> >> net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode
> >> net: stmmac: dwmac-meson8b: fix setting the RGMII clock on Meson8b
> >> net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
> >>
> >> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 55 +++++++++++-----------
> >> 1 file changed, 27 insertions(+), 28 deletions(-)
> >>
> >> --
> >> 2.15.1
> >>
>
> Regards
> Martin
>
Thank you,
Emiliano
>
> [0] https://patchwork.kernel.org/patch/10131677/
> [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg119290.html
> [2] https://www.mail-archive.com/netdev@vger.kernel.org/msg119293.html
^ permalink raw reply
* [PATCH net] skbuff: in skb_copy_ubufs unclone before releasing zerocopy
From: Willem de Bruijn @ 2017-12-28 17:38 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
skb_copy_ubufs must unclone before it is safe to modify its
skb_shared_info with skb_zcopy_clear.
Commit b90ddd568792 ("skbuff: skb_copy_ubufs must release uarg even
without user frags") ensures that all skbs release their zerocopy
state, even those without frags.
But I forgot an edge case where such an skb arrives that is cloned.
The stack does not build such packets. Vhost/tun skbs have their
frags orphaned before cloning. TCP skbs only attach zerocopy state
when a frag is added.
But if TCP packets can be trimmed or linearized, this might occur.
Tracing the code I found no instance so far (e.g., skb_linearize
ends up calling skb_zcopy_clear if !skb->data_len).
Still, it is non-obvious that no path exists. And it is fragile to
rely on this.
Fixes: b90ddd568792 ("skbuff: skb_copy_ubufs must release uarg even without user frags")
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
I should have spotted this when preparing the above patch, of course.
Apologies for the added work.
Since I did not spot a path that triggers the issue, this can also
go to net-next, instead. It applies to both cleanly.
---
net/core/skbuff.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index a3cb0be4c6f3..08f574081315 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1177,12 +1177,12 @@ int skb_copy_ubufs(struct sk_buff *skb, gfp_t gfp_mask)
int i, new_frags;
u32 d_off;
- if (!num_frags)
- goto release;
-
if (skb_shared(skb) || skb_unclone(skb, gfp_mask))
return -EINVAL;
+ if (!num_frags)
+ goto release;
+
new_frags = (__skb_pagelen(skb) + PAGE_SIZE - 1) >> PAGE_SHIFT;
for (i = 0; i < new_frags; i++) {
page = alloc_page(gfp_mask);
--
2.15.1.620.gb9897f4670-goog
^ permalink raw reply related
* Re: [PATCH net-next 0/4] mlx4 misc for 4.16
From: David Miller @ 2017-12-28 17:28 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe
In-Reply-To: <1514471171-3894-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Thu, 28 Dec 2017 16:26:07 +0200
> This patchset contains misc cleanups and improvements
> to the mlx4 Core and Eth drivers.
>
> In patches 1 and 2 I reduce and reorder the branches in the RX csum flow.
> In patch 3 I align the FMR unmapping flow with the device spec, to allow
> a remapping afterwards.
> Patch 4 by Moni changes the default QoS settings so that a pause
> frame stops all traffic regardless of its prio.
>
> Series generated against net-next commit:
> 836df24a7062 net: hns3: hns3_get_channels() can be static
Series applied, thanks Tariq.
I can't say that that ipv6 ifdef you added in patch #1 is the nicest.
It's one thing to ifdef control entire blocks of code, or individual
values.
It's another thing to partially include pieces of code structure
such as closing parenthesis, arithmetic operators, and curly braces.
Two of those were included in the ifdef section.
For example, if we have:
if (x & (IPV4_THING | IPV6_THING)) {
I don't want to see:
if (x & (IPV4_THING |
#ifdef IPV6_TEST
IPV6_THING)) {
#else
0)) {
#endif
Those closing parenthesis and the openning curly brace are there
regardless of the CPP test, and duplicating them in both arms of
the CPP test only makes the code more confusing to read.
I can say I would prefer:
if (x & (IPV4_THING |
#ifdef IPV6_TEST
IPV6_THING
#else
0
#endif
)) {
which is better. However, best would be:
#ifdef IPV6_TEST
#define THING_MASK IPV4_THING | IPV6_THING
#else
#define THING_MASK IPV4_THING
#endif
if (x & THING_MASK) {
is the best.
^ permalink raw reply
* Re: [patch net-next] net: sched: don't set extack message in case the qdisc will be created
From: David Miller @ 2017-12-28 17:18 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, xiyou.wangcong, mlxsw, aring
In-Reply-To: <20171228155210.1177-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 28 Dec 2017 16:52:10 +0100
> From: Jiri Pirko <jiri@mellanox.com>
>
> If the qdisc is not found here, it is going to be created. Therefore,
> this is not an error path. Remove the extack message set and don't
> confuse user with error message in case the qdisc was created
> successfully.
>
> Fixes: 09215598119e ("net: sched: sch_api: handle generic qdisc errors")
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] net: Fix possible race in peernet2id_alloc()
From: David Miller @ 2017-12-28 17:17 UTC (permalink / raw)
To: ktkhai; +Cc: ebiederm, netdev, eric.dumazet
In-Reply-To: <14a75452-5550-c046-8fbf-df214815306a@virtuozzo.com>
From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Thu, 28 Dec 2017 15:55:15 +0300
> Could you please clarify the status or what I should do with the patchset
> (because it's not clear for me)?
Please resend.
^ permalink raw reply
* Re: [PATCH net v1 1/1] tipc: fix hanging poll() for stream sockets
From: David Miller @ 2017-12-28 17:16 UTC (permalink / raw)
To: parthasarathy.bhuvaragan; +Cc: netdev, tipc-discussion, jon.maloy
In-Reply-To: <20171228110306.29607-1-parthasarathy.bhuvaragan@gmail.com>
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@gmail.com>
Date: Thu, 28 Dec 2017 12:03:06 +0100
> In commit 42b531de17d2f6 ("tipc: Fix missing connection request
> handling"), we replaced unconditional wakeup() with condtional
> wakeup for clients with flags POLLIN | POLLRDNORM | POLLRDBAND.
>
> This breaks the applications which do a connect followed by poll
> with POLLOUT flag. These applications are not woken when the
> connection is ESTABLISHED and hence sleep forever.
>
> In this commit, we fix it by including the POLLOUT event for
> sockets in TIPC_CONNECTING state.
>
> Fixes: 42b531de17d2f6 ("tipc: Fix missing connection request handling")
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next v9 0/2] add UniPhier AVE ethernet support
From: David Miller @ 2017-12-28 17:11 UTC (permalink / raw)
To: hayashi.kunihiko
Cc: netdev, andrew, f.fainelli, robh+dt, mark.rutland,
linux-arm-kernel, linux-kernel, devicetree, yamada.masahiro,
masami.hiramatsu, jaswinder.singh
In-Reply-To: <1514444292-20643-1-git-send-email-hayashi.kunihiko@socionext.com>
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date: Thu, 28 Dec 2017 15:58:10 +0900
> This series adds support for Socionext AVE ethernet controller implemented
> on UniPhier SoCs. This driver supports RGMII/RMII modes.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4/cxgb4vf: support for XLAUI Port Type
From: David Miller @ 2017-12-28 17:09 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, leedom
In-Reply-To: <1514443035-15716-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 28 Dec 2017 12:07:15 +0530
> Add support for new Backplane XLAUI port type.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Fw: [Bug 198297] New: Unable to add ethX to bridge if ethX.<VLAN_ID> is already present in this bridge
From: Stephen Hemminger @ 2017-12-28 17:08 UTC (permalink / raw)
To: netdev
I don't think this is ever going to work as expected.
Begin forwarded message:
Date: Thu, 28 Dec 2017 08:38:37 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 198297] New: Unable to add ethX to bridge if ethX.<VLAN_ID> is already present in this bridge
https://bugzilla.kernel.org/show_bug.cgi?id=198297
Bug ID: 198297
Summary: Unable to add ethX to bridge if ethX.<VLAN_ID> is
already present in this bridge
Product: Networking
Version: 2.5
Kernel Version: 4.14.2
Hardware: ARM
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: alexander_cheremshinsky@yahoo.com
Regression: No
Kernel fails adding ethX to bridge if ethX.<VLAN_ID> is already present in this
bridge.
Steps to reproduce:
# vconfig add eth2 10
# brctl addbr br
# brctl addif br eth2.10
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2.10
# brctl addif br eth2
can't add eth2 to bridge br: File exists
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2.10
But it is ok if ethX is added before ethX.<VLAN_ID>
Steps to reproduce:
# brctl delif br eth2.10
# brctl addif br eth2
# brctl addif br eth2.10
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2
eth2.10
So the result is depending on order of interface addition, that does not looks
logical as for me. This works good at least in kernel 3.10.70.
From my investigation it fails in function __netdev_upper_dev_link
(net/core/dev.c) on lines:
if (netdev_has_upper_dev(dev, upper_dev))
return -EEXIST;
I checked source code of kernel 4.14.8 but it looks the same and I think it
also has this issue.
I'm not so good with linux kernel to fix this by myself so it would be very
nice to get a patch with fix for this issue or explanation why such behavior is
correct.
Thanks in advance,
Alex.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next v6 0/6] net: tcp: sctp: dccp: Replace jprobe usage with trace events
From: David Miller @ 2017-12-28 17:06 UTC (permalink / raw)
To: mhiramat
Cc: mingo, ian.mcdonald, vyasevich, stephen, rostedt, peterz, tglx,
linux-kernel, hpa, gerrit, nhorman, dccp, netdev, linux-sctp, sfr
In-Reply-To: <151444140014.11331.17287122201510506083.stgit@devbox>
From: Masami Hiramatsu <mhiramat@kernel.org>
Date: Thu, 28 Dec 2017 15:10:00 +0900
> Changes from v5:
> [1/6]: Avoid preprocessor directives in tracepoint macro args
Patch #1 is not the only patch which has this problem, at a minimum
patch #5 has it too.
Please audit the entire series for an issue when it is brought to your
attention.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: display VNI correctly
From: David Miller @ 2017-12-28 17:00 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, santosh
In-Reply-To: <1514440792-30713-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 28 Dec 2017 11:29:52 +0530
> Fix incorrect VNI display in mps_tcam
>
> Signed-off-by: Santosh Rastapur <santosh@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [RFT net-next v2 0/3] dwmac-meson8b: RGMII clock fixes for Meson8b
From: Martin Blumenstingl @ 2017-12-28 16:58 UTC (permalink / raw)
To: Emiliano Ingrassia
Cc: netdev, linus.luessing, khilman, linux-amlogic, jbrunet,
Neil Armstrong, peppe.cavallaro, alexandre.torgue
In-Reply-To: <20171228161658.GA22727@ingrassia.epigenesys.com>
Hi Emiliano,
thank you for testing this!
On Thu, Dec 28, 2017 at 5:16 PM, Emiliano Ingrassia
<ingrassia@epigenesys.com> wrote:
> Hi Martin, Hi Dave,
>
> On Sun, Dec 24, 2017 at 12:40:57AM +0100, Martin Blumenstingl wrote:
>> Hi Dave,
>>
>> please do not apply this series until it got a Tested-by from Emiliano.
>>
>>
>> Hi Emiliano,
>>
>> you reported [0] that you couldn't get dwmac-meson8b to work on your
>> Odroid-C1. With your findings (register dumps, clk_summary output, etc.)
>> I think I was able to find a fix: it consists of two patches (which you
>> find in this series)
>>
>> Unfortunately I don't have any Meson8b boards with RGMII PHY so I could
>> only partially test this (I could only check if the clocks were
>> calculated correctly when using a dummy 500002394Hz input clock instead
>> of MPLL2).
>>
>> Could you please give this series a try and let me know about the
>> results?
>> You obviously still need your two "ARM: dts: meson8b" patches which
>> - add the amlogic,meson8b-dwmac" compatible to meson8b.dtsi
>> - enable Ethernet on the Odroid-C1
>>
>> I have tested this myself on a Khadas VIM (GXL SoC, internal RMII PHY)
>> and a Khadas VIM2 (GXM SoC, external RGMII PHY). Both are still working
>> fine (so let's hope that this also fixes your Meson8b issue :)).
>>
>>
>> changes since v1 at [1]:
>> - changed the subject of the cover-letter to indicate that this is all
>> about the RGMII clock
>> - added PATCH #1 which ensures that we don't unnecessarily change the
>> parent clocks in RMII mode (and also makes the code easier to
>> understand)
>> - changed subject of PATCH #2 (formerly PATCH #1) to state that this
>> is about the RGMII clock
>> - added Jerome's Reviewed-by to PATCH #2 (formerly PATCH #1)
>> - replaced PATCH #3 (formerly PATCH #2) with one that sets
>> CLK_SET_RATE_PARENT on the mux and thus re-configures the MPLL2 clock
>> on Meson8b correctly
>>
>
> Really thank you for your help and effort. I tried your patch but
> unfortunately it didn't solve the problem.
this is probably my fault: I forgot to mention that it requires a fix
for the 32-bit SoCs in the clock driver ("clk: meson: mpll: use 64-bit
maths in params_from_rate", see [0]) to work properly
>
> Here is the new clk_summary:
>
> xtal 1 1 24000000 0 0
> sys_pll 0 0 1200000000 0 0
> cpu_clk 0 0 1200000000 0 0
> vid_pll 0 0 732000000 0 0
> fixed_pll 2 2 2550000000 0 0
> mpll2 1 1 106250000 0 0
> c9410000.ethernet#m250_sel 1 1 106250000 0 0
> c9410000.ethernet#m250_div 1 1 106250000 0 0
> c9410000.ethernet#m25_div 1 1 21250000 0 0
>
> which leads to a value of 0x70a1 in the prg0 ethernet register.
> As you can see, something is changed but the RGMII clock is not at 25 MHz.
> In particular, the bit 10 of prg0, which enables the "generation of 25 MHz
> clock for PHY" (see S805 manual), is 0.
assuming that the description in the datasheet is correct
after Kevin and Mike got updated information from Amlogic about the
PRG_ETHERNET0 register documenation (see [1]) we thought that bit 10
means "0 = divide by 5, 1 = divide by 10" (see [2]). I didn't question
this so far, but I'll test this on a newer SoC later (by forcing
m250_div to 125MHz, then m25_div will have register value 0 = divide
by 5)
if the description from the documentation is correct then we need to
replace m25_div with a fixed-factor clock (mult = 1, div = 5) and make
it a m25_en gate clock instead
the resulting clock path would look like this: mpll2 > m250_sel >
m250_div > fixed_factor > m25_en
> Please, if you have other suggestions let me know.
could you please re-test this with the patch from [0] applied? no
other changes should be needed!
> Best regards,
>
> Emiliano
>
>>
>> [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005596.html
>> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005848.html
>>
>>
>> Martin Blumenstingl (3):
>> net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode
>> net: stmmac: dwmac-meson8b: fix setting the RGMII clock on Meson8b
>> net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
>>
>> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 55 +++++++++++-----------
>> 1 file changed, 27 insertions(+), 28 deletions(-)
>>
>> --
>> 2.15.1
>>
Regards
Martin
[0] https://patchwork.kernel.org/patch/10131677/
[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg119290.html
[2] https://www.mail-archive.com/netdev@vger.kernel.org/msg119293.html
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: Jiri Pirko @ 2017-12-28 16:43 UTC (permalink / raw)
To: David Ahern
Cc: Yuval Mintz, netdev@vger.kernel.org, davem@davemloft.net,
Arkadi Sharshevsky, mlxsw, andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
michael.chan@broadcom.com, ganeshgr@chelsio.com, Saeed Mahameed,
Matan Barak, Leon Romanovsky, Ido Schimmel,
jakub.kicinski@netronome.com, ast@kernel.org,
daniel@iogearbox.net, "
In-Reply-To: <4bd0a9d4-350d-274c-6370-e3a98a1e4f93@cumulusnetworks.com>
Thu, Dec 28, 2017 at 05:33:58PM CET, dsa@cumulusnetworks.com wrote:
>On 12/28/17 10:23 AM, Jiri Pirko wrote:
>>> So there are 4 tables exported to userspace:
>>>
>>> 1. mlxsw_erif table which is not in any of the kvd regions (no resource
>>> path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
>>> in Router Interfaces? So the switch supports up to 1000 router interfaces.
>>>
>>> 2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the
>> Size tells you the actual size. It cannot give you max size. The reason
>> is simple. The resources are shared among multiple tables. That is
>> exactly what this resource patch makes visible.
>>
>>
>
>In the erif table, the 1000 is the max not current usage. I do not have
I believe that is a bug in erif dpipe implementation
(mlxsw_sp_dpipe_table_erif_size_get) We'll fix that. Thanks!
>1000 interfaces:
>
>$ ip -br li sh | wc -l
>597
>
>
>$ devlink dpipe table dump pci/0000:03:00.0 name mlxsw_erif
>...
> index 503
> match_value:
> type field_exact header mlxsw_meta field erif_port mapping ifindex
>mapping_value 601 value 503
> action_value:
> type field_modify header mlxsw_meta field l3_forward value 1
>
>
>The host4 table it is current size with no maximum.
>
>The meaning of table size needs to be consistent across tables.
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: David Ahern @ 2017-12-28 16:33 UTC (permalink / raw)
To: Jiri Pirko
Cc: Yuval Mintz, netdev@vger.kernel.org, davem@davemloft.net,
Arkadi Sharshevsky, mlxsw, andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
michael.chan@broadcom.com, ganeshgr@chelsio.com, Saeed Mahameed,
Matan Barak, Leon Romanovsky, Ido Schimmel,
jakub.kicinski@netronome.com, ast@kernel.org,
daniel@iogearbox.net, "
In-Reply-To: <20171228162314.GA1983@nanopsycho>
On 12/28/17 10:23 AM, Jiri Pirko wrote:
>> So there are 4 tables exported to userspace:
>>
>> 1. mlxsw_erif table which is not in any of the kvd regions (no resource
>> path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
>> in Router Interfaces? So the switch supports up to 1000 router interfaces.
>>
>> 2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the
> Size tells you the actual size. It cannot give you max size. The reason
> is simple. The resources are shared among multiple tables. That is
> exactly what this resource patch makes visible.
>
>
In the erif table, the 1000 is the max not current usage. I do not have
1000 interfaces:
$ ip -br li sh | wc -l
597
$ devlink dpipe table dump pci/0000:03:00.0 name mlxsw_erif
...
index 503
match_value:
type field_exact header mlxsw_meta field erif_port mapping ifindex
mapping_value 601 value 503
action_value:
type field_modify header mlxsw_meta field l3_forward value 1
The host4 table it is current size with no maximum.
The meaning of table size needs to be consistent across tables.
^ permalink raw reply
* Re: WARNING in strp_data_ready
From: Dmitry Vyukov @ 2017-12-28 16:33 UTC (permalink / raw)
To: Tom Herbert
Cc: Ozgur, John Fastabend, syzbot, David S. Miller, Eric Biggers,
LKML, Linux Kernel Network Developers,
syzkaller-bugs@googlegroups.com, Tom Herbert, Cong Wang
In-Reply-To: <CALx6S36HESpYXAtz+EdiFr5UGD2hs2BtXA8i65GVPbTiuamfRA@mail.gmail.com>
On Thu, Dec 28, 2017 at 5:14 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Thu, Dec 28, 2017 at 12:59 AM, Ozgur <ozgur@goosey.org> wrote:
>>
>>
>> 28.12.2017, 04:19, "Tom Herbert" <tom@herbertland.com>:
>>> On Wed, Dec 27, 2017 at 12:20 PM, Ozgur <ozgur@goosey.org> wrote:
>>>> 27.12.2017, 23:14, "Dmitry Vyukov" <dvyukov@google.com>:
>>>>> On Wed, Dec 27, 2017 at 9:08 PM, Ozgur <ozgur@goosey.org> wrote:
>>>>>> 27.12.2017, 22:21, "Dmitry Vyukov" <dvyukov@google.com>:
>>>>>>> On Wed, Dec 27, 2017 at 8:09 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>>> Did you try the patch I posted?
>>>>>>>
>>>>>>> Hi Tom,
>>>>>>
>>>>>> Hello Dmitry,
>>>>>>
>>>>>>> No. And I didn't know I need to. Why?
>>>>>>> If you think the patch needs additional testing, you can ask syzbot to
>>>>>>> test it. See https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot
>>>>>>> Otherwise proceed with committing it. Or what are we waiting for?
>>>>>>>
>>>>>>> Thanks
>>>>>>
>>>>>> I think we need to fixed patch for crash, in fact check to patch code and test solve the bug.
>>>>>> How do test it because there is no patch in the following bug?
>>>>>
>>>>> Hi Ozgur,
>>>>>
>>>>> I am not sure I completely understand what you mean. But the
>>>>> reproducer for this bug (which one can use for testing) is here:
>>>>> https://groups.google.com/forum/#!topic/syzkaller-bugs/Kxs05ziCpgY
>>>>> Tom also mentions there is some patch for this, but I don't know where
>>>>> it is, it doesn't seem to be referenced from this thread.
>>>>
>>>> Hello Dmitry,
>>>>
>>>> Ah, I'm sorry I don't seen Tom mail and I don't have a patch not tested :)
>>>> I think Tom send patch to only you and are you tested?
>>>>
>>>> kcmsock.c will change and strp_data_ready I think locked.
>>>>
>>>> Tom, please send a patch for me? I can test and inform you.
>>>
>>> Hi Ozgur,
>>>
>>> I reposted the patches as RFC "kcm: Fix lockdep issue". Please test if you can!
>>>
>>> Thanks,
>>> Tom
>>
>> Hello Tom,
>>
>> Which are you use the repos? I pulled but I don't seen this patches.
>>
> They are not in any public repo yet. I posted the patches to netdev
> list so they can be reviewed and tested by third parties. Posting
> patches to the list a normal path to get patches into the kernel
> (http://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/).
>
> These patches were applied to net-next but are simple enough that they
> should apply to other branches. I will repost and target to net per
> Dave's directive once they are verified to fix the issue.
FWIW they are already verified to fix the issue, see few emails up, also here:
https://groups.google.com/d/msg/syzkaller-bugs/Kxs05ziCpgY/fPdZcO_GAwAJ
and don't forget this:
https://groups.google.com/d/msg/syzkaller-bugs/Kxs05ziCpgY/uGjsrA3HAwAJ
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: Jiri Pirko @ 2017-12-28 16:23 UTC (permalink / raw)
To: David Ahern
Cc: Yuval Mintz, netdev@vger.kernel.org, davem@davemloft.net,
Arkadi Sharshevsky, mlxsw, andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
michael.chan@broadcom.com, ganeshgr@chelsio.com, Saeed Mahameed,
Matan Barak, Leon Romanovsky, Ido Schimmel,
jakub.kicinski@netronome.com, ast@kernel.org,
daniel@iogearbox.net, "
In-Reply-To: <22cc777b-e39e-29c0-22fe-aa7a99ef80df@cumulusnetworks.com>
Thu, Dec 28, 2017 at 05:09:09PM CET, dsa@cumulusnetworks.com wrote:
>On 12/28/17 2:25 AM, Yuval Mintz wrote:
>>>>> Again, I have no objections to kvd, linear, hash, etc terms as they do
>>>>> relate to Mellanox products. But kvd/linear, for example, does correlate
>>>>> to industry standard concepts in some way. My request is that the
>>>>> resource listing guide the user in some way, stating what these
>>>>> resources mean.
>>>>
>>>> So the showed relation to dpipe table would be enougn or you would still
>>>> like to see some description? I don't like the description concept here
>>>> as the relations to dpipe table should tell user exactly what he needs
>>>> to know.
>>>
>>> I believe it is useful to have a 1-line, short description that gives
>>> the user some memory jogger as to what the resource is used for. It does
>>> not have to be an exhaustive list, but the user should not have to do
>>> mental jumping jacks running a bunch of commands to understand the
>>> resources for vendor specific asics.
>>
>> Perhaps we can simply have devlink utility output the dpipe
>> table[s] associated with the resource when showing the resource?
>> It would contain live information as well as prevent the need for
>> 'mental jumping jacks'.
>>
>
>My primary contention for this static partitioning is that the proposal
>is not giving the user the information they need to make decisions.
>
>As I mentioned earlier, the resource show command gives this:
>$ devlink resource show pci/0000:03:00.0
>pci/0000:03:00.0:
> name kvd size 245760 size_valid true
> resources:
> name linear size 98304 occ 0
> name hash_double size 60416
> name hash_single size 87040
>
>the paths /kvd/linear, /kvd/hash_single and /kvd/hash_double are
>essentially random names (nothing related to industry standard names)
Of course. There is no industry standard for internal ASIC
implementations. This is the same as for dpipe. There is no industry
standard for ASIC pipeline. dpipe visualizes it. This resource patch
visualizes the internal ASIC resources and their mapping to the
individual dpipe tables.
>and the listed sizes are random numbers (no units)[1]. There is nothing
>there to tell a user what they can adjust or why they would want to make
>an adjustment.
>
>
>Looking at 'dpipe table show':
>
>$ devlink dpipe table show pci/0000:03:00.0
>pci/0000:03:00.0:
> name mlxsw_erif size 1000 counters_enabled false
> match:
> type field_exact header mlxsw_meta field erif_port mapping ifindex
> action:
> type field_modify header mlxsw_meta field l3_forward
> type field_modify header mlxsw_meta field l3_drop
>
> resource_path /kvd/hash_single name mlxsw_host4 size 62
>counters_enabled false
> match:
> type field_exact header mlxsw_meta field erif_port mapping ifindex
> type field_exact header ipv4 field destination ip
> action:
> type field_modify header ethernet field destination mac
>
> resource_path /kvd/hash_double name mlxsw_host6 size 0
>counters_enabled false
> match:
> type field_exact header mlxsw_meta field erif_port mapping ifindex
> type field_exact header ipv6 field destination ip
> action:
> type field_modify header ethernet field destination mac
>
> resource_path /kvd/linear name mlxsw_adj size 0 counters_enabled false
> match:
> type field_exact header mlxsw_meta field adj_index
> type field_exact header mlxsw_meta field adj_size
> type field_exact header mlxsw_meta field adj_hash_index
> action:
> type field_modify header ethernet field destination mac
> type field_modify header mlxsw_meta field erif_port mapping ifindex
>
>
>So there are 4 tables exported to userspace:
>
>1. mlxsw_erif table which is not in any of the kvd regions (no resource
>path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
>in Router Interfaces? So the switch supports up to 1000 router interfaces.
>
>2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the
Size tells you the actual size. It cannot give you max size. The reason
is simple. The resources are shared among multiple tables. That is
exactly what this resource patch makes visible.
>fields mlxsw_host4 means IPv4 host entries (neighbor entries). Why is
>the size set at 62? Seems really low.
>
>3. mlxsw_host6 in /kvd/hash_double with a size of 0. Based on the fields
>mlxsw_host6 means IPv6 host entries (neighbor entries). The size of 0 is
>concerning. I guess the switch is not configured to do IPv6?
>
>4. mlxsw_adj in /kvd/linear with a size of 0. Based on the fields I am
>going to guess it is an fdb entry????
^ permalink raw reply
* Re: [RFT net-next v2 0/3] dwmac-meson8b: RGMII clock fixes for Meson8b
From: Emiliano Ingrassia @ 2017-12-28 16:16 UTC (permalink / raw)
To: Martin Blumenstingl, netdev
Cc: linus.luessing, khilman, linux-amlogic, jbrunet, narmstrong,
peppe.cavallaro, alexandre.torgue
In-Reply-To: <20171223234100.11814-1-martin.blumenstingl@googlemail.com>
Hi Martin, Hi Dave,
On Sun, Dec 24, 2017 at 12:40:57AM +0100, Martin Blumenstingl wrote:
> Hi Dave,
>
> please do not apply this series until it got a Tested-by from Emiliano.
>
>
> Hi Emiliano,
>
> you reported [0] that you couldn't get dwmac-meson8b to work on your
> Odroid-C1. With your findings (register dumps, clk_summary output, etc.)
> I think I was able to find a fix: it consists of two patches (which you
> find in this series)
>
> Unfortunately I don't have any Meson8b boards with RGMII PHY so I could
> only partially test this (I could only check if the clocks were
> calculated correctly when using a dummy 500002394Hz input clock instead
> of MPLL2).
>
> Could you please give this series a try and let me know about the
> results?
> You obviously still need your two "ARM: dts: meson8b" patches which
> - add the amlogic,meson8b-dwmac" compatible to meson8b.dtsi
> - enable Ethernet on the Odroid-C1
>
> I have tested this myself on a Khadas VIM (GXL SoC, internal RMII PHY)
> and a Khadas VIM2 (GXM SoC, external RGMII PHY). Both are still working
> fine (so let's hope that this also fixes your Meson8b issue :)).
>
>
> changes since v1 at [1]:
> - changed the subject of the cover-letter to indicate that this is all
> about the RGMII clock
> - added PATCH #1 which ensures that we don't unnecessarily change the
> parent clocks in RMII mode (and also makes the code easier to
> understand)
> - changed subject of PATCH #2 (formerly PATCH #1) to state that this
> is about the RGMII clock
> - added Jerome's Reviewed-by to PATCH #2 (formerly PATCH #1)
> - replaced PATCH #3 (formerly PATCH #2) with one that sets
> CLK_SET_RATE_PARENT on the mux and thus re-configures the MPLL2 clock
> on Meson8b correctly
>
Really thank you for your help and effort. I tried your patch but
unfortunately it didn't solve the problem.
Here is the new clk_summary:
xtal 1 1 24000000 0 0
sys_pll 0 0 1200000000 0 0
cpu_clk 0 0 1200000000 0 0
vid_pll 0 0 732000000 0 0
fixed_pll 2 2 2550000000 0 0
mpll2 1 1 106250000 0 0
c9410000.ethernet#m250_sel 1 1 106250000 0 0
c9410000.ethernet#m250_div 1 1 106250000 0 0
c9410000.ethernet#m25_div 1 1 21250000 0 0
which leads to a value of 0x70a1 in the prg0 ethernet register.
As you can see, something is changed but the RGMII clock is not at 25 MHz.
In particular, the bit 10 of prg0, which enables the "generation of 25 MHz
clock for PHY" (see S805 manual), is 0.
Please, if you have other suggestions let me know.
Best regards,
Emiliano
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005596.html
> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005848.html
>
>
> Martin Blumenstingl (3):
> net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode
> net: stmmac: dwmac-meson8b: fix setting the RGMII clock on Meson8b
> net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
>
> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 55 +++++++++++-----------
> 1 file changed, 27 insertions(+), 28 deletions(-)
>
> --
> 2.15.1
>
^ permalink raw reply
* Re: WARNING in strp_data_ready
From: Tom Herbert @ 2017-12-28 16:14 UTC (permalink / raw)
To: Ozgur
Cc: Dmitry Vyukov, John Fastabend, syzbot, David S. Miller,
Eric Biggers, LKML, Linux Kernel Network Developers,
syzkaller-bugs@googlegroups.com, Tom Herbert, Cong Wang
In-Reply-To: <297161514451589@web50o.yandex.ru>
On Thu, Dec 28, 2017 at 12:59 AM, Ozgur <ozgur@goosey.org> wrote:
>
>
> 28.12.2017, 04:19, "Tom Herbert" <tom@herbertland.com>:
>> On Wed, Dec 27, 2017 at 12:20 PM, Ozgur <ozgur@goosey.org> wrote:
>>> 27.12.2017, 23:14, "Dmitry Vyukov" <dvyukov@google.com>:
>>>> On Wed, Dec 27, 2017 at 9:08 PM, Ozgur <ozgur@goosey.org> wrote:
>>>>> 27.12.2017, 22:21, "Dmitry Vyukov" <dvyukov@google.com>:
>>>>>> On Wed, Dec 27, 2017 at 8:09 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>> Did you try the patch I posted?
>>>>>>
>>>>>> Hi Tom,
>>>>>
>>>>> Hello Dmitry,
>>>>>
>>>>>> No. And I didn't know I need to. Why?
>>>>>> If you think the patch needs additional testing, you can ask syzbot to
>>>>>> test it. See https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot
>>>>>> Otherwise proceed with committing it. Or what are we waiting for?
>>>>>>
>>>>>> Thanks
>>>>>
>>>>> I think we need to fixed patch for crash, in fact check to patch code and test solve the bug.
>>>>> How do test it because there is no patch in the following bug?
>>>>
>>>> Hi Ozgur,
>>>>
>>>> I am not sure I completely understand what you mean. But the
>>>> reproducer for this bug (which one can use for testing) is here:
>>>> https://groups.google.com/forum/#!topic/syzkaller-bugs/Kxs05ziCpgY
>>>> Tom also mentions there is some patch for this, but I don't know where
>>>> it is, it doesn't seem to be referenced from this thread.
>>>
>>> Hello Dmitry,
>>>
>>> Ah, I'm sorry I don't seen Tom mail and I don't have a patch not tested :)
>>> I think Tom send patch to only you and are you tested?
>>>
>>> kcmsock.c will change and strp_data_ready I think locked.
>>>
>>> Tom, please send a patch for me? I can test and inform you.
>>
>> Hi Ozgur,
>>
>> I reposted the patches as RFC "kcm: Fix lockdep issue". Please test if you can!
>>
>> Thanks,
>> Tom
>
> Hello Tom,
>
> Which are you use the repos? I pulled but I don't seen this patches.
>
They are not in any public repo yet. I posted the patches to netdev
list so they can be reviewed and tested by third parties. Posting
patches to the list a normal path to get patches into the kernel
(http://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/).
These patches were applied to net-next but are simple enough that they
should apply to other branches. I will repost and target to net per
Dave's directive once they are verified to fix the issue.
Tom
^ permalink raw reply
* Re: [patch net-next v2 00/10] Add support for resource abstraction
From: David Ahern @ 2017-12-28 16:09 UTC (permalink / raw)
To: Yuval Mintz, Jiri Pirko
Cc: netdev@vger.kernel.org, davem@davemloft.net, Arkadi Sharshevsky,
mlxsw, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com,
f.fainelli@gmail.com, michael.chan@broadcom.com,
ganeshgr@chelsio.com, Saeed Mahameed, Matan Barak,
Leon Romanovsky, Ido Schimmel, jakub.kicinski@netronome.com,
ast@kernel.org, daniel@iogearbox.net, simon.horman@netronome.com
In-Reply-To: <VI1PR05MB35206F8E7CB725188F9F509EBF040@VI1PR05MB3520.eurprd05.prod.outlook.com>
On 12/28/17 2:25 AM, Yuval Mintz wrote:
>>>> Again, I have no objections to kvd, linear, hash, etc terms as they do
>>>> relate to Mellanox products. But kvd/linear, for example, does correlate
>>>> to industry standard concepts in some way. My request is that the
>>>> resource listing guide the user in some way, stating what these
>>>> resources mean.
>>>
>>> So the showed relation to dpipe table would be enougn or you would still
>>> like to see some description? I don't like the description concept here
>>> as the relations to dpipe table should tell user exactly what he needs
>>> to know.
>>
>> I believe it is useful to have a 1-line, short description that gives
>> the user some memory jogger as to what the resource is used for. It does
>> not have to be an exhaustive list, but the user should not have to do
>> mental jumping jacks running a bunch of commands to understand the
>> resources for vendor specific asics.
>
> Perhaps we can simply have devlink utility output the dpipe
> table[s] associated with the resource when showing the resource?
> It would contain live information as well as prevent the need for
> 'mental jumping jacks'.
>
My primary contention for this static partitioning is that the proposal
is not giving the user the information they need to make decisions.
As I mentioned earlier, the resource show command gives this:
$ devlink resource show pci/0000:03:00.0
pci/0000:03:00.0:
name kvd size 245760 size_valid true
resources:
name linear size 98304 occ 0
name hash_double size 60416
name hash_single size 87040
the paths /kvd/linear, /kvd/hash_single and /kvd/hash_double are
essentially random names (nothing related to industry standard names)
and the listed sizes are random numbers (no units)[1]. There is nothing
there to tell a user what they can adjust or why they would want to make
an adjustment.
Looking at 'dpipe table show':
$ devlink dpipe table show pci/0000:03:00.0
pci/0000:03:00.0:
name mlxsw_erif size 1000 counters_enabled false
match:
type field_exact header mlxsw_meta field erif_port mapping ifindex
action:
type field_modify header mlxsw_meta field l3_forward
type field_modify header mlxsw_meta field l3_drop
resource_path /kvd/hash_single name mlxsw_host4 size 62
counters_enabled false
match:
type field_exact header mlxsw_meta field erif_port mapping ifindex
type field_exact header ipv4 field destination ip
action:
type field_modify header ethernet field destination mac
resource_path /kvd/hash_double name mlxsw_host6 size 0
counters_enabled false
match:
type field_exact header mlxsw_meta field erif_port mapping ifindex
type field_exact header ipv6 field destination ip
action:
type field_modify header ethernet field destination mac
resource_path /kvd/linear name mlxsw_adj size 0 counters_enabled false
match:
type field_exact header mlxsw_meta field adj_index
type field_exact header mlxsw_meta field adj_size
type field_exact header mlxsw_meta field adj_hash_index
action:
type field_modify header ethernet field destination mac
type field_modify header mlxsw_meta field erif_port mapping ifindex
So there are 4 tables exported to userspace:
1. mlxsw_erif table which is not in any of the kvd regions (no resource
path is given) and it has a size of 1000. Does mlxsw_erif mean a rif as
in Router Interfaces? So the switch supports up to 1000 router interfaces.
2. mlxsw_host4 in /kvd/hash_single with a size of 62. Based on the
fields mlxsw_host4 means IPv4 host entries (neighbor entries). Why is
the size set at 62? Seems really low.
3. mlxsw_host6 in /kvd/hash_double with a size of 0. Based on the fields
mlxsw_host6 means IPv6 host entries (neighbor entries). The size of 0 is
concerning. I guess the switch is not configured to do IPv6?
4. mlxsw_adj in /kvd/linear with a size of 0. Based on the fields I am
going to guess it is an fdb entry????
So if I combine the output of "resource show" and "dpipe table show", I
can conclude:
1. /kvd/linear is only used for fdb entries. So if I want an L3 only use
case I can set /kvd/linear 0. Is that correct? I believe the answer is
no, but based on the information given it seems that way.
2. /kvd/hash_double has a size of 60416, but it is only used for
mlxsw_host6 table which has a size of 0. Now, I am confused.
3. /kvd/hash_single has a size of 87040, but it is only used for
mlxsw_host4 table which has a size of 62. Again confused.
What is a user to make of this output? How is it useful for making
decisions on whether to increase or decrease some resource?
----
[1] In a response, Jiri mentioned units are added by this patch set but
all I see in the patches is this:
@@ -245,4 +256,8 @@ enum devlink_dpipe_header_id {
DEVLINK_DPIPE_HEADER_IPV6,
};
+enum devlink_resource_unit {
+ DEVLINK_RESOURCE_UNIT_DOUBLE_WORD,
+};
+
#endif /* _UAPI_LINUX_DEVLINK_H_ */
DEVLINK_RESOURCE_UNIT_DOUBLE_WORD means what???
^ permalink raw reply
* SPECIAL OFFER !!!
From: Abdul Halima @ 2017-12-28 16:08 UTC (permalink / raw)
Do you need a Loan if the answer is yes kindly contact us for more
information: lenderroyal0@gmail.com
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor
From: Jason Baron @ 2017-12-28 15:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, virtualization, qemu-devel, mst, jasowang
In-Reply-To: <20171227.164334.2079471466039224265.davem@davemloft.net>
On 12/27/2017 04:43 PM, David Miller wrote:
> From: Jason Baron <jbaron@akamai.com>
> Date: Fri, 22 Dec 2017 16:54:01 -0500
>
>> The ability to set speed and duplex for virtio_net in useful in various
>> scenarios as described here:
>>
>> 16032be virtio_net: add ethtool support for set and get of settings
>>
>> However, it would be nice to be able to set this from the hypervisor,
>> such that virtio_net doesn't require custom guest ethtool commands.
>>
>> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
>> the hypervisor to export a linkspeed and duplex setting. The user can
>> subsequently overwrite it later if desired via: 'ethtool -s'.
>>
>> Signed-off-by: Jason Baron <jbaron@akamai.com>
>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> Cc: Jason Wang <jasowang@redhat.com>
>
> Looks mostly fine to me but need some virtio_net reviewers on this one.
>
>> @@ -57,6 +57,8 @@
>> * Steering */
>> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>>
>> +#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Host set linkspeed and duplex */
>> +
>
> Why use a value so far away from the largest existing one?
>
> Just curious.
>
So that came from a discussion with Michael about which bit to use for
this, and he suggested using 63:
"
Transports started from bit 24 and are growing up.
So I would say devices should start from bit 63 and grow down.
"
https://patchwork.ozlabs.org/patch/848814/#1826669
I will add a comment to explain it.
Thanks,
-Jason
^ permalink raw reply
* [patch net-next] net: sched: don't set extack message in case the qdisc will be created
From: Jiri Pirko @ 2017-12-28 15:52 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, mlxsw, aring
From: Jiri Pirko <jiri@mellanox.com>
If the qdisc is not found here, it is going to be created. Therefore,
this is not an error path. Remove the extack message set and don't
confuse user with error message in case the qdisc was created
successfully.
Fixes: 09215598119e ("net: sched: sch_api: handle generic qdisc errors")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/sch_api.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 3a3a1da..81ecf5b 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1402,10 +1402,8 @@ static int tc_modify_qdisc(struct sk_buff *skb, struct nlmsghdr *n,
return -EINVAL;
}
q = qdisc_lookup(dev, tcm->tcm_handle);
- if (!q) {
- NL_SET_ERR_MSG(extack, "No qdisc found for specified handle");
+ if (!q)
goto create_n_graft;
- }
if (n->nlmsg_flags & NLM_F_EXCL) {
NL_SET_ERR_MSG(extack, "Exclusivity flag on, cannot override");
return -EEXIST;
--
2.9.5
^ permalink raw reply related
* Re: [PATCH iproute2] gre/tunnel: Print erspan_index using print_uint()
From: Serhey Popovych @ 2017-12-28 15:48 UTC (permalink / raw)
To: William Tu; +Cc: Linux Kernel Network Developers
In-Reply-To: <CALDO+SYhqzg=rewp0qRBOLdz8r7QdN_aORHpz1o02PMiTcWiUQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1450 bytes --]
> Hi Serhey,
Hi William,
Yes, iproute2-next/net-next branch contains fix already: we probably do
not need proposed change. Sorry for noise.
I'm currently focused on bug fixing in stable which affects my work for
iproute2-next. All my future work will be based on iproute2-next as it
contains refactoring, optimization and cleanups, not fixes.
Sorry again and thanks for feedback.
>
> On Thu, Dec 28, 2017 at 3:12 AM, Serhey Popovych
> <serhe.popovych@gmail.com> wrote:
>> One is missing in JSON output because fprintf()
>> is used instead of print_uint().
>>
>> Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
>> ---
>> ip/link_gre.c | 3 ++-
>> ip/link_gre6.c | 4 +++-
>> 2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/ip/link_gre.c b/ip/link_gre.c
>> index 896bb19..1e331c8 100644
>> --- a/ip/link_gre.c
>> +++ b/ip/link_gre.c
>> @@ -476,7 +476,8 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
>> if (tb[IFLA_GRE_ERSPAN_INDEX]) {
>> __u32 erspan_idx = rta_getattr_u32(tb[IFLA_GRE_ERSPAN_INDEX]);
>>
>> - fprintf(f, "erspan_index %u ", erspan_idx);
>> + print_uint(PRINT_ANY,
>> + "erspan_index", "erspan_index %u ", erspan_idx);
>> }
>>
>
> Did you pull the latest code from net-next branch?
> I think I already fix it.
> William
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2] gre/tunnel: Print erspan_index using print_uint()
From: William Tu @ 2017-12-28 15:13 UTC (permalink / raw)
To: Serhey Popovych; +Cc: Linux Kernel Network Developers
In-Reply-To: <1514459579-20379-1-git-send-email-serhe.popovych@gmail.com>
Hi Serhey,
On Thu, Dec 28, 2017 at 3:12 AM, Serhey Popovych
<serhe.popovych@gmail.com> wrote:
> One is missing in JSON output because fprintf()
> is used instead of print_uint().
>
> Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
> ---
> ip/link_gre.c | 3 ++-
> ip/link_gre6.c | 4 +++-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/ip/link_gre.c b/ip/link_gre.c
> index 896bb19..1e331c8 100644
> --- a/ip/link_gre.c
> +++ b/ip/link_gre.c
> @@ -476,7 +476,8 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
> if (tb[IFLA_GRE_ERSPAN_INDEX]) {
> __u32 erspan_idx = rta_getattr_u32(tb[IFLA_GRE_ERSPAN_INDEX]);
>
> - fprintf(f, "erspan_index %u ", erspan_idx);
> + print_uint(PRINT_ANY,
> + "erspan_index", "erspan_index %u ", erspan_idx);
> }
>
Did you pull the latest code from net-next branch?
I think I already fix it.
William
^ permalink raw reply
* Re: [PATCH net-next 2/2] l2tp: add peer_offset parameter
From: Guillaume Nault @ 2017-12-28 14:53 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: davem, netdev, jchapman, liuhangbin
In-Reply-To: <d51dc65a40c5e335984e95a1e6db0eea00d9fd13.1513951129.git.lorenzo.bianconi@redhat.com>
On Fri, Dec 22, 2017 at 03:10:18PM +0100, Lorenzo Bianconi wrote:
> Introduce peer_offset parameter in order to add the capability
> to specify two different values for payload offset on tx/rx side.
> If just offset is provided by userspace use it for rx side as well
> in order to maintain compatibility with older l2tp versions
>
Sorry for being late on this, I originally missed this patchset and
only noticed it yesterday.
Lorenzo, can you give some context around this new feature?
Quite frankly I can't see the point of it. I've never heard of offsets
in L2TPv3, and for L2TPv2, the offset value is already encoded in the
header.
After a quick review of L2TPv3 and pseudowires RFCs, I still don't see
how adding some padding between the L2TPv3 header and the payload could
constitute a valid frame. Of course, the base feature is already there,
but after a quick test, it looks like the padding bits aren't
initialised and leak memory.
So, unless I missed something, setting offsets in L2TPv3 is
non-compliant, the current implementation is buggy and most likely
unused. I'd really prefer getting the implementation fixed, or even
removed entirely. Extending it to allow asymmetrical offset values
looks wrong to me, unless you have a use case in mind.
Regards,
Guillaume
PS: I also noticed that iproute2 has a "peer_offset" option, but it's a
noop.
^ 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