* Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Wang, Dongsheng @ 2018-11-08 7:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: andrew@lunn.ch, timur@kernel.org, Zheng, Joey,
f.fainelli@gmail.com, linux-acpi@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <2150057.QtixCRFV9x@aspire.rjw.lan>
On 2018/11/8 15:44, Rafael J. Wysocki wrote:
> On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
>> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
>> The current implementation depend on mdio bus scan.
>> With _DSD device properties we can finally do this:
>>
>> Device (MDIO) {
>> Name (_DSD, Package () {
>> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
>> Package () { Package () { "ethernet-phy@0", PHY0 }, }
>> })
>> Name (PHY0, Package() {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () { "reg", 0x0 }, }
>> })
>> }
>>
>> Device (MACO) {
>> Name (_DSD, Package () {
>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
>> })
>> }
>>
>> Documentations:
>> The DT "phy-handle" binding that we reuse for ACPI is documented in
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Documentation/acpi/dsd/data-node-references.txt
>> Documentation/acpi/dsd/graph.txt
>>
>> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
>> ---
>> drivers/acpi/Kconfig | 6 ++
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
>> drivers/net/phy/mdio_bus.c | 3 +
>> include/linux/acpi_mdio.h | 82 ++++++++++++++++++
>> 5 files changed, 259 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 9705fc986da9..0fefa3410ce9 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
>> config ACPI_MCFG
>> bool
>>
>> +config ACPI_MDIO
>> + def_tristate PHYLIB
>> + depends on PHYLIB
>> + help
>> + ACPI MDIO bus (Ethernet PHY) accessors
>> +
>> config ACPI_CPPC_LIB
>> bool
>> depends on ACPI_PROCESSOR
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 6d59aa109a91..ec7461a064fc 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -41,6 +41,7 @@ acpi-y += ec.o
>> acpi-$(CONFIG_ACPI_DOCK) += dock.o
>> acpi-y += pci_root.o pci_link.o pci_irq.o
>> obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
>> +acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
>> acpi-y += acpi_lpss.o acpi_apd.o
>> acpi-y += acpi_platform.o
>> acpi-y += acpi_pnp.o
>> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
>> new file mode 100644
>> index 000000000000..293bf9a63197
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_mdio.c
>> @@ -0,0 +1,167 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +// Lots of code in this file is copy from drivers/of/of_mdio.c
> Would it be possible to re-factor that code and share it instead?
I thought about it, we can actually do it with fwnode.
But I don't have a lot of concentrate to do this. I'm going to focus on
a few other things...:(
Maybe in the second half of 2019 I can re-factor them if there is no one
re-factor them.
Cheers,
Dongsheng
> Thanks,
> Rafael
>
>
^ permalink raw reply
* RE:(2) (2) (2) [Kernel][NET] Bug report on packet defragmenting
From: 배석진 @ 2018-11-08 7:58 UTC (permalink / raw)
To: Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <b03af88f-8f18-bdac-ae64-c3c0688008d3@gmail.com>
>--------- Original Message ---------
>Sender : Eric Dumazet <eric.dumazet@gmail.com>
>Date : 2018-11-08 15:13 (GMT+9)
>Title : Re: (2) (2) [Kernel][NET] Bug report on packet defragmenting
>
>On 11/07/2018 08:26 PM, Eric Dumazet wrote:
>>
>>
>> On 11/07/2018 08:10 PM, 배석진 wrote:
>>>> --------- Original Message ---------
>>>> Sender : Eric Dumazet <eric.dumazet@gmail.com>
>>>> Date : 2018-11-08 12:57 (GMT+9)
>>>> Title : Re: (2) [Kernel][NET] Bug report on packet defragmenting
>>>>
>>>> On 11/07/2018 07:24 PM, Eric Dumazet wrote:
>>>>
>>>>> Sure, it is better if RPS is smarter, but if there is a bug in IPv6 defrag unit
>>>>> we must investigate and root-cause it.
>>>>
>>>> BTW, IPv4 defrag seems to have the same issue.
>>>
>>>
>>> yes, it could be.
>>> key point isn't limitted to ipv6.
>>>
>>> maybe because of faster air-network and modem,
>>> it looks like occure more often and we got recognized that.
>>>
>>> anyway,
>>> we'll apply our patch to resolve this problem.
>>
>> Yeah, and I will fix the defrag units.
>>
>> We can not rely on other layers doing proper no-reorder logic for us.
>>
>> Problem here is that multiple cpus attempt concurrent rhashtable_insert_fast()
>> and do not properly recover in case -EEXIST is returned.
>>
>> This is silly, of course :/
>
>Patch would be https://patchwork.ozlabs.org/patch/994658/
Dear Dumazet,
with your patch, kernel got the panic when packet recieved.
I double checked after disable your patch, then no problem.
<6>[ 119.702054] I[3: kworker/u18:1: 1705] LNK-RX(1464): 6b 80 00 00 05 90 2c 3e 20 01 44 30 00 05 04 01 ...
<6>[ 119.702120] I[3: kworker/u18:1: 1705] __skb_flow_dissect: ports: 77500000
<6>[ 119.702153] I[3: kworker/u18:1: 1705] get_rps_cpu: cpu:2, hash:2055028308
<6>[ 119.702203] I[3: kworker/u18:1: 1705] LNK-RX(1212): 6b 80 00 00 04 94 2c 3e 20 01 44 30 00 05 04 01 ...
<6>[ 119.702231] I[3: kworker/u18:1: 1705] __skb_flow_dissect: ports: 3c7e2c6b
<6>[ 119.702258] I[3: kworker/u18:1: 1705] get_rps_cpu: cpu:1, hash:671343869
<6>[ 119.702365] I[1: Binder:11369_2:11382] ipv6_rcv +++
<6>[ 119.702375] I[2: swapper/2: 0] ipv6_rcv +++
<6>[ 119.702406] I[2: swapper/2: 0] ipv6_defrag +++
<6>[ 119.702425] I[1: Binder:11369_2:11382] ipv6_defrag +++
<6>[ 119.702494] I[2: swapper/2: 0] ipv6_defrag: EINPROGRESS
<6>[ 119.702522] I[2: swapper/2: 0] ipv6_rcv ---
<6>[ 119.702628] I[1: Binder:11369_2:11382] ipv6_defrag ---
<6>[ 119.702892] I[1: Binder:11369_2:11382] ipv6_defrag +++
<6>[ 119.702922] I[1: Binder:11369_2:11382] ipv6_defrag ---
<6>[ 119.702966] I[1: Binder:11369_2:11382] ipv6_rcv ---
<0>[ 119.703792] [1: Binder:11369_2:11382] BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:518
<3>[ 119.703826] [1: Binder:11369_2:11382] in_atomic(): 0, irqs_disabled(): 0, pid: 11382, name: Binder:11369_2
<3>[ 119.703854] [1: Binder:11369_2:11382] Preemption disabled at:
<4>[ 119.703888] [1: Binder:11369_2:11382] [<ffffff80080b13d4>] __do_softirq+0x68/0x3c4
<4>[ 119.703934] [1: Binder:11369_2:11382] CPU: 1 PID: 11382 Comm: Binder:11369_2 Tainted: G S W 4.14.75-20181108-163447-eng #0
<4>[ 119.703960] [1: Binder:11369_2:11382] Hardware name: Samsung BEYOND2LTE KOR SINGLE 19 board based on EXYNOS9820 (DT)
<4>[ 119.703987] [1: Binder:11369_2:11382] Call trace:
<4>[ 119.704015] [1: Binder:11369_2:11382] [<ffffff80080bd87c>] dump_backtrace+0x0/0x280
<4>[ 119.704045] [1: Binder:11369_2:11382] [<ffffff80080bddd4>] show_stack+0x18/0x24
<4>[ 119.704074] [1: Binder:11369_2:11382] [<ffffff80090bb3f8>] dump_stack+0xb8/0xf8
<4>[ 119.704104] [1: Binder:11369_2:11382] [<ffffff800811f180>] ___might_sleep+0x16c/0x178
<4>[ 119.704132] [1: Binder:11369_2:11382] [<ffffff800811efdc>] __might_sleep+0x4c/0x84
<4>[ 119.704164] [1: Binder:11369_2:11382] [<ffffff80090dcf60>] do_page_fault+0x2e8/0x4b8
<4>[ 119.704193] [1: Binder:11369_2:11382] [<ffffff80090dcbf4>] do_translation_fault+0x7c/0x100
<4>[ 119.704219] [1: Binder:11369_2:11382] [<ffffff80080b0d70>] do_mem_abort+0x4c/0x12c
<4>[ 119.704243] [1: Binder:11369_2:11382] Exception stack(0xffffff8038bf3ec0 to 0xffffff8038bf4000)
<4>[ 119.704266] [1: Binder:11369_2:11382] 3ec0: 00000077b8262600 00000077b1bd0800 00000000708fcae0 0000000000000018
...
<4>[ 119.704459] [1: Binder:11369_2:11382] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
<4>[ 119.704480] [1: Binder:11369_2:11382] [<ffffff80080b33d0>] el0_da+0x20/0x24
<4>[ 119.704509] [1: Binder:11369_2:11382] ------------[ cut here ]------------
<0>[ 119.704541] [1: Binder:11369_2:11382] kernel BUG at kernel/sched/core.c:6152!
<2>[ 119.704563] [1: Binder:11369_2:11382] sec_debug_set_extra_info_fault = BUG / 0xffffff800811f180
<0>[ 119.704603] [1: Binder:11369_2:11382] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
^ permalink raw reply
* Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Rafael J. Wysocki @ 2018-11-08 8:01 UTC (permalink / raw)
To: Wang, Dongsheng
Cc: andrew@lunn.ch, timur@kernel.org, Zheng, Joey,
f.fainelli@gmail.com, linux-acpi@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <ad8eaa316b15403fa7f0b8f79d744331@HXTBJIDCEMVIW02.hxtcorp.net>
On Thursday, November 8, 2018 8:55:47 AM CET Wang, Dongsheng wrote:
> On 2018/11/8 15:44, Rafael J. Wysocki wrote:
> > On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
> >> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
> >> The current implementation depend on mdio bus scan.
> >> With _DSD device properties we can finally do this:
> >>
> >> Device (MDIO) {
> >> Name (_DSD, Package () {
> >> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> >> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> >> })
> >> Name (PHY0, Package() {
> >> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >> Package () { Package () { "reg", 0x0 }, }
> >> })
> >> }
> >>
> >> Device (MACO) {
> >> Name (_DSD, Package () {
> >> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >> Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
> >> })
> >> }
> >>
> >> Documentations:
> >> The DT "phy-handle" binding that we reuse for ACPI is documented in
> >> Documentation/devicetree/bindings/phy/phy-bindings.txt
> >>
> >> Documentation/acpi/dsd/data-node-references.txt
> >> Documentation/acpi/dsd/graph.txt
> >>
> >> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
> >> ---
> >> drivers/acpi/Kconfig | 6 ++
> >> drivers/acpi/Makefile | 1 +
> >> drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
> >> drivers/net/phy/mdio_bus.c | 3 +
> >> include/linux/acpi_mdio.h | 82 ++++++++++++++++++
> >> 5 files changed, 259 insertions(+)
> >>
> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> >> index 9705fc986da9..0fefa3410ce9 100644
> >> --- a/drivers/acpi/Kconfig
> >> +++ b/drivers/acpi/Kconfig
> >> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
> >> config ACPI_MCFG
> >> bool
> >>
> >> +config ACPI_MDIO
> >> + def_tristate PHYLIB
> >> + depends on PHYLIB
> >> + help
> >> + ACPI MDIO bus (Ethernet PHY) accessors
> >> +
> >> config ACPI_CPPC_LIB
> >> bool
> >> depends on ACPI_PROCESSOR
> >> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> >> index 6d59aa109a91..ec7461a064fc 100644
> >> --- a/drivers/acpi/Makefile
> >> +++ b/drivers/acpi/Makefile
> >> @@ -41,6 +41,7 @@ acpi-y += ec.o
> >> acpi-$(CONFIG_ACPI_DOCK) += dock.o
> >> acpi-y += pci_root.o pci_link.o pci_irq.o
> >> obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
> >> +acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
> >> acpi-y += acpi_lpss.o acpi_apd.o
> >> acpi-y += acpi_platform.o
> >> acpi-y += acpi_pnp.o
> >> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
> >> new file mode 100644
> >> index 000000000000..293bf9a63197
> >> --- /dev/null
> >> +++ b/drivers/acpi/acpi_mdio.c
> >> @@ -0,0 +1,167 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +// Lots of code in this file is copy from drivers/of/of_mdio.c
> > Would it be possible to re-factor that code and share it instead?
>
> I thought about it, we can actually do it with fwnode.
>
> But I don't have a lot of concentrate to do this. I'm going to focus on
> a few other things...:(
>
> Maybe in the second half of 2019 I can re-factor them if there is no one
> re-factor them.
Well, I'd rather avoid code duplication upfront if possible.
Thanks,
Rafael
^ permalink raw reply
* [PATCHv2] net: stmmac: Fix RX packet size > 8191
From: thor.thayer @ 2018-11-08 17:39 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, davem
Cc: netdev, linux-kernel, Thor Thayer
From: Thor Thayer <thor.thayer@linux.intel.com>
Ping problems with packets > 8191 as shown:
PING 192.168.1.99 (192.168.1.99) 8150(8178) bytes of data.
8158 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=0.669 ms
wrong data byte 8144 should be 0xd0 but was 0x0
16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
%< ---------------snip--------------------------------------
8112 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
8144 0 0 0 0 d0 d1
^^^^^^^
Notice the 4 bytes of 0 before the expected byte of d0.
Databook notes that the RX buffer must be a multiple of 4/8/16
bytes [1].
Update the DMA Buffer size define to 8188 instead of 8192. Remove
the -1 from the RX buffer size allocations and use the new
DMA Buffer size directly.
[1] Synopsys DesignWare Cores Ethernet MAC Universal v3.70a
[section 8.4.2 - Table 8-24]
Tested on SoCFPGA Stratix10 with ping sweep from 100 to 8300 byte packets.
Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)")
Suggested-by: Jose Abreu <jose.abreu@synopsys.com>
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
v2 Change BUF_SIZE_8KiB directly instead of separate define in RFT.
---
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 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index b1b305f8f414..272b9ca66314 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -365,7 +365,8 @@ struct dma_features {
/* GMAC TX FIFO is 8K, Rx FIFO is 16K */
#define BUF_SIZE_16KiB 16384
-#define BUF_SIZE_8KiB 8192
+/* RX Buffer size must be < 8191 and multiple of 4/8/16 bytes */
+#define BUF_SIZE_8KiB 8188
#define BUF_SIZE_4KiB 4096
#define BUF_SIZE_2KiB 2048
diff --git a/drivers/net/ethernet/stmicro/stmmac/descs_com.h b/drivers/net/ethernet/stmicro/stmmac/descs_com.h
index ca9d7e48034c..40d6356a7e73 100644
--- a/drivers/net/ethernet/stmicro/stmmac/descs_com.h
+++ b/drivers/net/ethernet/stmicro/stmmac/descs_com.h
@@ -31,7 +31,7 @@
/* Enhanced descriptors */
static inline void ehn_desc_rx_set_on_ring(struct dma_desc *p, int end)
{
- p->des1 |= cpu_to_le32(((BUF_SIZE_8KiB - 1)
+ p->des1 |= cpu_to_le32((BUF_SIZE_8KiB
<< ERDES1_BUFFER2_SIZE_SHIFT)
& ERDES1_BUFFER2_SIZE_MASK);
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 77914c89d749..5ef91a790f9d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -262,7 +262,7 @@ static void enh_desc_init_rx_desc(struct dma_desc *p, int disable_rx_ic,
int mode, int end)
{
p->des0 |= cpu_to_le32(RDES0_OWN);
- p->des1 |= cpu_to_le32((BUF_SIZE_8KiB - 1) & ERDES1_BUFFER1_SIZE_MASK);
+ p->des1 |= cpu_to_le32(BUF_SIZE_8KiB & ERDES1_BUFFER1_SIZE_MASK);
if (mode == STMMAC_CHAIN_MODE)
ehn_desc_rx_set_on_chain(p);
diff --git a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
index abc3f85270cd..d8c5bc412219 100644
--- a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
@@ -140,7 +140,7 @@ static void clean_desc3(void *priv_ptr, struct dma_desc *p)
static int set_16kib_bfsize(int mtu)
{
int ret = 0;
- if (unlikely(mtu >= BUF_SIZE_8KiB))
+ if (unlikely(mtu > BUF_SIZE_8KiB))
ret = BUF_SIZE_16KiB;
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCHv2] net: stmmac: Fix RX packet size > 8191
From: thor.thayer @ 2018-11-08 17:42 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, davem
Cc: netdev, linux-kernel, Thor Thayer
From: Thor Thayer <thor.thayer@linux.intel.com>
Ping problems with packets > 8191 as shown:
PING 192.168.1.99 (192.168.1.99) 8150(8178) bytes of data.
8158 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=0.669 ms
wrong data byte 8144 should be 0xd0 but was 0x0
16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
%< ---------------snip--------------------------------------
8112 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
8144 0 0 0 0 d0 d1
^^^^^^^
Notice the 4 bytes of 0 before the expected byte of d0.
Databook notes that the RX buffer must be a multiple of 4/8/16
bytes [1].
Update the DMA Buffer size define to 8188 instead of 8192. Remove
the -1 from the RX buffer size allocations and use the new
DMA Buffer size directly.
[1] Synopsys DesignWare Cores Ethernet MAC Universal v3.70a
[section 8.4.2 - Table 8-24]
Tested on SoCFPGA Stratix10 with ping sweep from 100 to 8300 byte packets.
Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)")
Suggested-by: Jose Abreu <jose.abreu@synopsys.com>
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
v2 Change BUF_SIZE_8KiB directly instead of separate define in RFT.
---
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 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index b1b305f8f414..272b9ca66314 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -365,7 +365,8 @@ struct dma_features {
/* GMAC TX FIFO is 8K, Rx FIFO is 16K */
#define BUF_SIZE_16KiB 16384
-#define BUF_SIZE_8KiB 8192
+/* RX Buffer size must be < 8191 and multiple of 4/8/16 bytes */
+#define BUF_SIZE_8KiB 8188
#define BUF_SIZE_4KiB 4096
#define BUF_SIZE_2KiB 2048
diff --git a/drivers/net/ethernet/stmicro/stmmac/descs_com.h b/drivers/net/ethernet/stmicro/stmmac/descs_com.h
index ca9d7e48034c..40d6356a7e73 100644
--- a/drivers/net/ethernet/stmicro/stmmac/descs_com.h
+++ b/drivers/net/ethernet/stmicro/stmmac/descs_com.h
@@ -31,7 +31,7 @@
/* Enhanced descriptors */
static inline void ehn_desc_rx_set_on_ring(struct dma_desc *p, int end)
{
- p->des1 |= cpu_to_le32(((BUF_SIZE_8KiB - 1)
+ p->des1 |= cpu_to_le32((BUF_SIZE_8KiB
<< ERDES1_BUFFER2_SIZE_SHIFT)
& ERDES1_BUFFER2_SIZE_MASK);
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 77914c89d749..5ef91a790f9d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -262,7 +262,7 @@ static void enh_desc_init_rx_desc(struct dma_desc *p, int disable_rx_ic,
int mode, int end)
{
p->des0 |= cpu_to_le32(RDES0_OWN);
- p->des1 |= cpu_to_le32((BUF_SIZE_8KiB - 1) & ERDES1_BUFFER1_SIZE_MASK);
+ p->des1 |= cpu_to_le32(BUF_SIZE_8KiB & ERDES1_BUFFER1_SIZE_MASK);
if (mode == STMMAC_CHAIN_MODE)
ehn_desc_rx_set_on_chain(p);
diff --git a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
index abc3f85270cd..d8c5bc412219 100644
--- a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
@@ -140,7 +140,7 @@ static void clean_desc3(void *priv_ptr, struct dma_desc *p)
static int set_16kib_bfsize(int mtu)
{
int ret = 0;
- if (unlikely(mtu >= BUF_SIZE_8KiB))
+ if (unlikely(mtu > BUF_SIZE_8KiB))
ret = BUF_SIZE_16KiB;
return ret;
}
--
2.7.4
^ permalink raw reply related
* a propose of snmp counter document
From: peng yu @ 2018-11-08 8:08 UTC (permalink / raw)
To: netdev
I'm planing to write a document which explains the meaning of the
kernel snmp counters, and combine the explanations with some tests,
because I found lots of the 'TcpExt' and 'IpExt' counters are not
explained in any document. Here is a draft:
https://github.com/yupeng0921/iproute2_learning/blob/master/nstat.md
It is still on going. I think it might be useful. Besides put it on my
git repo, could someone have any suggestion about any place I
could contribute this document to?
Best regards
^ permalink raw reply
* Re: [PATCH net] ipv6/mcast: update mc_qrv when join new group
From: David Miller @ 2018-11-08 8:12 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev
In-Reply-To: <20181108074410.GO24677@leo.usersys.redhat.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Thu, 8 Nov 2018 15:44:10 +0800
> On Fri, Oct 26, 2018 at 10:30:54AM +0800, Hangbin Liu wrote:
>> Currently we only set mc_qrv to sysctl_mld_qrv when interface up. If we
>> change sysctl_mld_qrv after interface up, it will has no effect.
>>
>> Fix it by assigning latest sysctl_mld_qrv to idev mc_qrv when join new group.
>>
>> Reported-by: Ying Xu <yinxu@redhat.com>
>> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>
> Hi David,
>
> Any comments for this patch?
I did give you feedback and you never responded:
https://patchwork.ozlabs.org/patch/989422/
So I tossed your patch.
^ permalink raw reply
* [PATCH] net: phy: leds: Don't make our own link speed names
From: Kyle Roeschley @ 2018-11-08 17:51 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli
Cc: David S . Miller, netdev, linux-kernel, Kyle Roeschley
The phy core provides a handy phy_speed_to_str() helper, so use that
instead of doing our own formatting of the different known link speeds.
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
drivers/net/phy/phy_led_triggers.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
index 491efc1bf5c4..2827eb413c9c 100644
--- a/drivers/net/phy/phy_led_triggers.c
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -77,20 +77,9 @@ static int phy_led_trigger_register(struct phy_device *phy,
struct phy_led_trigger *plt,
unsigned int speed)
{
- char name_suffix[PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE];
-
plt->speed = speed;
-
- if (speed < SPEED_1000)
- snprintf(name_suffix, sizeof(name_suffix), "%dMbps", speed);
- else if (speed == SPEED_2500)
- snprintf(name_suffix, sizeof(name_suffix), "2.5Gbps");
- else
- snprintf(name_suffix, sizeof(name_suffix), "%dGbps",
- DIV_ROUND_CLOSEST(speed, 1000));
-
phy_led_trigger_format_name(phy, plt->name, sizeof(plt->name),
- name_suffix);
+ phy_speed_to_str(speed));
plt->trigger.name = plt->name;
return led_trigger_register(&plt->trigger);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 2/5] VSOCK: support fill data to mergeable rx buffer in host
From: Jason Wang @ 2018-11-08 8:20 UTC (permalink / raw)
To: jiangyiwen, stefanha, stefanha
Cc: netdev, kvm, virtualization, Michael S. Tsirkin
In-Reply-To: <5BE397CA.5060000@huawei.com>
On 2018/11/8 上午9:56, jiangyiwen wrote:
> On 2018/11/7 21:32, Jason Wang wrote:
>> On 2018/11/7 下午3:11, jiangyiwen wrote:
>>> On 2018/11/7 14:18, Jason Wang wrote:
>>>> On 2018/11/6 下午2:30, jiangyiwen wrote:
>>>>>> Seems duplicated with the one used by vhost-net.
>>>>>>
>>>>>> In packed virtqueue implementation, I plan to move this to vhost.c.
>>>>>>
>>>>> Yes, this code is full copied from vhost-net, if it can be packed into
>>>>> vhost.c, it would be great.
>>>>>
>>>> If you try to reuse vhost-net, you don't even need to care about this:)
>>>>
>>>> Thanks
>>>>
>>>>
>>>> .
>>>>
>>> Hi Jason,
>>>
>>> Thank your advice, I will consider your idea. But I don't know
>>> what's stefan's suggestion? It seems that he doesn't care much
>>> about this community.:(
>> I think not. He is probably busy these days.
>>
>>
>>> I still hope this community can have some vitality.
>>>
>> Let's wait for few more days for the possible comments from Stefan or Michael. But I do prefer to unify the virtio networking datapath which will be easier to be extended and maintained.
>>
>> Thanks
>>
>>
>> .
>>
> Hi Jason,
>
> Actually vsock use virtio-net as transport path should be a better idea,
> I will try to consider the new idea.
>
> Thanks,
> Yiwen.
>
Good to know this and thanks!
^ permalink raw reply
* Re: [PATCH] net: phy: leds: Don't make our own link speed names
From: Florian Fainelli @ 2018-11-08 17:59 UTC (permalink / raw)
To: Kyle Roeschley, Andrew Lunn; +Cc: David S . Miller, netdev, linux-kernel
In-Reply-To: <20181108175106.25684-1-kyle.roeschley@ni.com>
On 11/8/18 9:51 AM, Kyle Roeschley wrote:
> The phy core provides a handy phy_speed_to_str() helper, so use that
> instead of doing our own formatting of the different known link speeds.
In case the speed is not supported, phy_speed_to_str() would return
"Unsupported (update phy-core.c)" which is bigger (by 21 characters)
than name_suffix.
If you bumped name_suffix/PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE to 11
characters, that would be just large enough to accommodate for the
"Unsupported" part of the string and that might be an acceptable
solution in between.
>
> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
> ---
> drivers/net/phy/phy_led_triggers.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
> index 491efc1bf5c4..2827eb413c9c 100644
> --- a/drivers/net/phy/phy_led_triggers.c
> +++ b/drivers/net/phy/phy_led_triggers.c
> @@ -77,20 +77,9 @@ static int phy_led_trigger_register(struct phy_device *phy,
> struct phy_led_trigger *plt,
> unsigned int speed)
> {
> - char name_suffix[PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE];
> -
> plt->speed = speed;
> -
> - if (speed < SPEED_1000)
> - snprintf(name_suffix, sizeof(name_suffix), "%dMbps", speed);
> - else if (speed == SPEED_2500)
> - snprintf(name_suffix, sizeof(name_suffix), "2.5Gbps");
> - else
> - snprintf(name_suffix, sizeof(name_suffix), "%dGbps",
> - DIV_ROUND_CLOSEST(speed, 1000));
> -
> phy_led_trigger_format_name(phy, plt->name, sizeof(plt->name),
> - name_suffix);
> + phy_speed_to_str(speed));
> plt->trigger.name = plt->name;
>
> return led_trigger_register(&plt->trigger);
>
--
Florian
^ permalink raw reply
* Re: SACK compression patch causing performance drop
From: Jean-Louis Dupond @ 2018-11-08 8:23 UTC (permalink / raw)
To: netdev, edumazet
In-Reply-To: <89214271-4496-c438-c4e8-b39f0ae72af7@dupond.be>
Hi,
Was somebody able to check this?
Really think this should be fixed :)
Thanks
Jean-Louis
On 3/11/18 16:59, Jean-Louis Dupond wrote:
> Hi All,
>
> On recent kernels we noticed a way lower throughput to our SAN system
> than before.
> While on pre 4.18 kernels we had 400-700MB/sec read speed, on 4.18+ we
> only had 70-120MB/sec.
>
> The SAN is connected via iSCSI over a 10G network (ixgbe/X520 NICS if
> it matters).
>
> After some debugging, I tried to bisect between 4.17 and 4.18 to see
> what commit caused the slowdown.
> It showed that the addition of the SACK compression
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d9f4262b7ea41ca9981cc790e37cca6e37c789e)
> was the cause.
>
> And indeed, if I set net.ipv4.tcp_comp_sack_nr to 0 on 4.19 for
> example, the throughput is (almost) back to normal again.
> So it seems like this change causes quite some performance issues.
>
> Any ideas?
>
> Thanks
> Jean-Louis
>
^ permalink raw reply
* Re: [PATCH 2/5] phy: core: add PHY_MODE_ETHERNET
From: Grygorii Strashko @ 2018-11-08 18:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Alexandre Belloni, Quentin Schulz, Tony Lindgren, netdev,
Antoine Tenart, Sekhar Nori, linux-kernel, Kishon Vijay Abraham I,
Manu Gautam, Chen-Yu Tsai, Chunfeng Yun, linux-mediatek,
Vivek Gautam, Maxime Ripard, linux-amlogic, Carlo Caione,
David S. Miller, linux-arm-kernel, Matthias Brugger
In-Reply-To: <20181108004200.GW30658@n2100.armlinux.org.uk>
hi Russell,
On 11/7/18 6:42 PM, Russell King - ARM Linux wrote:
> On Wed, Nov 07, 2018 at 06:36:14PM -0600, Grygorii Strashko wrote:
>> Add new PHY's mode to be used by Ethernet PHY interface drivers or
>> multipurpose PHYs like serdes. It will be reused in further changes.
>>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>> include/linux/phy/phy.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index b17e770..02c9ef0 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -42,6 +42,7 @@ enum phy_mode {
>> PHY_MODE_UFS_HS_A,
>> PHY_MODE_UFS_HS_B,
>> PHY_MODE_PCIE,
>> + PHY_MODE_ETHERNET,
>
> Are you sure about this - we already have a bunch of "ethernet" modes
> that are more specific, like PHY_MODE_SGMII, PHY_MODE_2500SGMII and
> PHY_MODE_10GKR which require PHYs to be configured differently. Having
> a very generic "ethernet" mode brings up questions about when it should
> be used vs the more specific modes.
yes. the idea of this series is to split PHY mode on - PHY mode (generic)
and PHY submode (subsystem specific), so multi-functional PHY like serdes will do
(for example):
phy_set_mode_ext(port->comphy, PHY_MODE_ETHERNET, PHY_INTERFACE_MODE_SGMII);
where PHY_INTERFACE_MODE_SGMII is defined by phy_interface_t enum.
instead of
phy_set_mode(port->comphy, PHY_MODE_SGMII);
In patches 3-5 I've converted users of existing PHY "ethernet" modes to use
this approach and, finally, in patch 5 removed
PHY_MODE_SGMII/2500SGMII/QSGMII/10GKR
>
> (I've already mentioned that the SGMII modes are mis-named, since
> they also apply to 1000base-X and 2500base-X - the only difference
> is how one 16-bit word in the data stream is used which has no effect
> on the PHY.)
>
--
regards,
-grygorii
^ permalink raw reply
* Re: [RFC perf,bpf 1/5] perf, bpf: Introduce PERF_RECORD_BPF_EVENT
From: David Ahern @ 2018-11-08 18:26 UTC (permalink / raw)
To: Song Liu, Peter Zijlstra
Cc: Netdev, lkml, Kernel Team, ast@kernel.org, daniel@iogearbox.net,
acme@kernel.org
In-Reply-To: <C858C862-E523-4CE8-AB39-CC9B27BE2538@fb.com>
On 11/8/18 11:04 AM, Song Liu wrote:
> On the other hand, processing BPF load/unload events synchronously should
> not introduce too much overhead for meaningful use cases. If many BPF progs
> are being loaded/unloaded within short period of time, it is not the steady
> state that profiling works care about.
but, profiling is not the only use case, and perf-record is common with
those other use cases.
I think that answers why your RFC set does not fork a thread for the bpf
events. You are focused on profiling and for already loaded programs or
for a small number of programs loaded by a specific workload started by
perf.
^ permalink raw reply
* [PATCH net-next] cxgb4: Add new T6 PCI device ids 0x608a
From: Ganesh Goudar @ 2018-11-08 8:51 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, dt, Ganesh Goudar
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
index 60df66f..bf7325f 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
@@ -217,6 +217,7 @@ CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
CH_PCI_ID_TABLE_FENTRY(0x6087), /* Custom T6225-CR */
CH_PCI_ID_TABLE_FENTRY(0x6088), /* Custom T62100-CR */
CH_PCI_ID_TABLE_FENTRY(0x6089), /* Custom T62100-KR */
+ CH_PCI_ID_TABLE_FENTRY(0x608a), /* Custom T62100-CR */
CH_PCI_DEVICE_ID_TABLE_DEFINE_END;
#endif /* __T4_PCI_ID_TBL_H__ */
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] staging: net: ipv4: tcp_vegas: fixed checks and warnings
From: David Miller @ 2018-11-08 18:34 UTC (permalink / raw)
To: suraj1998; +Cc: kuznet, yoshfuji, netdev, linux-kernel, edumazet
In-Reply-To: <1541665792-5888-1-git-send-email-suraj1998@gmail.com>
From: Suraj Singh <suraj1998@gmail.com>
Date: Thu, 8 Nov 2018 13:59:52 +0530
> Fixed checks and warnings in TCP Vegas
>
> Signed-off-by: Suraj Singh <suraj1998@gmail.com>
Once again, please explain why you are putting "staging: " into the subject
line of your TCP congestion control patches.
If you do not answer this question and fix your Subject lines, I will
really have no choice but to ignore your submissions as you are
ignoring our feedback.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 05/10] ipv6: factor out protocol delivery helper
From: Sergei Shtylyov @ 2018-11-08 9:01 UTC (permalink / raw)
To: Paolo Abeni, netdev
Cc: David S. Miller, Willem de Bruijn, Steffen Klassert,
Subash Abhinov Kasiviswanathan
In-Reply-To: <12bde3e41997a124df10c1af678ace0af50e5d9e.1541588248.git.pabeni@redhat.com>
On 11/7/2018 2:38 PM, Paolo Abeni wrote:
> So that we can re-use it at the UDP level in the next patch
>
> rfc v3 -> v1:
> - add the helper declaration into the ipv6 header
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> include/net/ipv6.h | 2 ++
> net/ipv6/ip6_input.c | 28 ++++++++++++++++------------
> 2 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index 829650540780..daf80863d3a5 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
[...]
> @@ -319,28 +319,26 @@ void ipv6_list_rcv(struct list_head *head, struct packet_type *pt,
> /*
> * Deliver the packet to the host
> */
> -
> -
> -static int ip6_input_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
> +void ip6_protocol_deliver_rcu(struct net *net, struct sk_buff *skb, int nexthdr,
> + bool have_final)
> {
> const struct inet6_protocol *ipprot;
> struct inet6_dev *idev;
> unsigned int nhoff;
> - int nexthdr;
> bool raw;
> - bool have_final = false;
>
> /*
> * Parse extension headers
> */
>
> - rcu_read_lock();
> resubmit:
> idev = ip6_dst_idev(skb_dst(skb));
> - if (!pskb_pull(skb, skb_transport_offset(skb)))
> - goto discard;
> nhoff = IP6CB(skb)->nhoff;
> - nexthdr = skb_network_header(skb)[nhoff];
> + if (!have_final) {
Haven't you removed this variable above?
> + if (!pskb_pull(skb, skb_transport_offset(skb)))
> + goto discard;
> + nexthdr = skb_network_header(skb)[nhoff];
And this?
> + }
>
> resubmit_final:
> raw = raw6_local_deliver(skb, nexthdr);
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH bpf-next 0/2] bpf: offer maximum packet offset info
From: Jiong Wang @ 2018-11-08 9:08 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, oss-drivers, Jiong Wang
The maximum packet offset accessed by one BPF program is useful
information.
Because sometimes there could be packet split and it is possible for some
reasons (for example performance) we want to reject the BPF program if the
maximum packet size would trigger such split. Normally, MTU value is
treated as the maximum packet size, but one BPF program does not always
access the whole packet, it could only access the head portion of the data.
We could let verifier calculate the maximum packet offset ever used and
record it inside prog auxiliar information structure as a new field
"max_pkt_offset".
Jiong Wang (2):
bpf: let verifier to calculate and record max_pkt_offset
nfp: bpf: relax prog rejection through max_pkt_offset
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 9 +++++----
include/linux/bpf.h | 1 +
kernel/bpf/verifier.c | 12 ++++++++++++
3 files changed, 18 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH bpf-next 1/2] bpf: let verifier to calculate and record max_pkt_offset
From: Jiong Wang @ 2018-11-08 9:08 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, oss-drivers, Jiong Wang
In-Reply-To: <1541668123-9571-1-git-send-email-jiong.wang@netronome.com>
In check_packet_access, update max_pkt_offset after the offset has passed
__check_packet_access.
It should be safe to use u32 for max_pkt_offset as explained in code
comment.
Also, when there is tail call, the max_pkt_offset of the called program is
unknown, so conservatively set max_pkt_offset to MAX_PACKET_OFF for such
case.
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
---
include/linux/bpf.h | 1 +
kernel/bpf/verifier.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 33014ae..b6a296e 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -293,6 +293,7 @@ struct bpf_prog_aux {
atomic_t refcnt;
u32 used_map_cnt;
u32 max_ctx_offset;
+ u32 max_pkt_offset;
u32 stack_depth;
u32 id;
u32 func_cnt;
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 98fa0be..6a248d8 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1452,6 +1452,17 @@ static int check_packet_access(struct bpf_verifier_env *env, u32 regno, int off,
verbose(env, "R%d offset is outside of the packet\n", regno);
return err;
}
+
+ /* __check_packet_access has made sure "off + size - 1" is within u16.
+ * reg->umax_value can't be bigger than MAX_PACKET_OFF which is 0xffff,
+ * otherwise find_good_pkt_pointers would have refused to set range info
+ * that __check_packet_access would have rejected this pkt access.
+ * Therefore, "off + reg->umax_value + size - 1" won't overflow u32.
+ */
+ env->prog->aux->max_pkt_offset =
+ max_t(u32, env->prog->aux->max_pkt_offset,
+ off + reg->umax_value + size - 1);
+
return err;
}
@@ -6128,6 +6139,7 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
*/
prog->cb_access = 1;
env->prog->aux->stack_depth = MAX_BPF_STACK;
+ env->prog->aux->max_pkt_offset = MAX_PACKET_OFF;
/* mark bpf_tail_call as different opcode to avoid
* conditional branch in the interpeter for every normal
--
2.7.4
^ permalink raw reply related
* [PATCH bpf-next 2/2] nfp: bpf: relax prog rejection through max_pkt_offset
From: Jiong Wang @ 2018-11-08 9:08 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, oss-drivers, Jiong Wang
In-Reply-To: <1541668123-9571-1-git-send-email-jiong.wang@netronome.com>
NFP is refusing to offload programs whenever the MTU is set to a value
larger than the max packet bytes that fits in NFP Cluster Target Memory
(CTM). However, a eBPF program doesn't always need to access the whole
packet data.
Verifier has always calculated maximum direct packet access (DPA) offset,
and kept it in max_pkt_offset inside prog auxiliar information. This patch
relax prog rejection based on max_pkt_offset.
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
---
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/bpf/offload.c b/drivers/net/ethernet/netronome/nfp/bpf/offload.c
index ba8ceed..07bdc1f 100644
--- a/drivers/net/ethernet/netronome/nfp/bpf/offload.c
+++ b/drivers/net/ethernet/netronome/nfp/bpf/offload.c
@@ -489,14 +489,15 @@ nfp_net_bpf_load(struct nfp_net *nn, struct bpf_prog *prog,
struct netlink_ext_ack *extack)
{
struct nfp_prog *nfp_prog = prog->aux->offload->dev_priv;
- unsigned int max_mtu, max_stack, max_prog_len;
+ unsigned int fw_mtu, pkt_off, max_stack, max_prog_len;
dma_addr_t dma_addr;
void *img;
int err;
- max_mtu = nn_readb(nn, NFP_NET_CFG_BPF_INL_MTU) * 64 - 32;
- if (max_mtu < nn->dp.netdev->mtu) {
- NL_SET_ERR_MSG_MOD(extack, "BPF offload not supported with MTU larger than HW packet split boundary");
+ fw_mtu = nn_readb(nn, NFP_NET_CFG_BPF_INL_MTU) * 64 - 32;
+ pkt_off = min(prog->aux->max_pkt_offset, nn->dp.netdev->mtu);
+ if (fw_mtu < pkt_off) {
+ NL_SET_ERR_MSG_MOD(extack, "BPF offload not supported with potential packet access beyond HW packet split boundary");
return -EOPNOTSUPP;
}
--
2.7.4
^ permalink raw reply related
* [PATCH iproute2-next] devlink: Add missing region option to devlink man page
From: Alex Vesker @ 2018-11-08 9:14 UTC (permalink / raw)
To: netdev, jiri; +Cc: Alex Vesker
The region field was not added to the devlink man page.
Fixes: 8b4fbf0bed8e6 ("devlink: Add support for devlink-region access")
Signed-off-by: Alex Vesker <valex@mellanox.com>
---
man/man8/devlink.8 | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/man/man8/devlink.8 b/man/man8/devlink.8
index 360031f..8d527e7 100644
--- a/man/man8/devlink.8
+++ b/man/man8/devlink.8
@@ -7,7 +7,7 @@ devlink \- Devlink tool
.in +8
.ti -8
.B devlink
-.RI "[ " OPTIONS " ] { " dev | port | monitor | sb | resource " } { " COMMAND " | "
+.RI "[ " OPTIONS " ] { " dev | port | monitor | sb | resource | region " } { " COMMAND " | "
.BR help " }"
.sp
@@ -74,6 +74,10 @@ Turn on verbose output.
.B resource
- devlink device resource configuration.
+.TP
+.B region
+- devlink address region access
+
.SS
.I COMMAND
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC perf,bpf 1/5] perf, bpf: Introduce PERF_RECORD_BPF_EVENT
From: Song Liu @ 2018-11-08 18:49 UTC (permalink / raw)
To: David Ahern
Cc: Peter Zijlstra, Netdev, lkml, Kernel Team, ast@kernel.org,
daniel@iogearbox.net, acme@kernel.org
In-Reply-To: <d5043aae-69b0-fd49-e82a-5a13834a3f32@gmail.com>
Hi David,
> On Nov 8, 2018, at 10:26 AM, David Ahern <dsahern@gmail.com> wrote:
>
> On 11/8/18 11:04 AM, Song Liu wrote:
>> On the other hand, processing BPF load/unload events synchronously should
>> not introduce too much overhead for meaningful use cases. If many BPF progs
>> are being loaded/unloaded within short period of time, it is not the steady
>> state that profiling works care about.
>
> but, profiling is not the only use case, and perf-record is common with
> those other use cases.
>
> I think that answers why your RFC set does not fork a thread for the bpf
> events. You are focused on profiling and for already loaded programs or
> for a small number of programs loaded by a specific workload started by
> perf.
We sure can fork a thread for the BPF event. But I guess that's not Peter's
main concern here...
Could you please point me to more information about the use cases you worry
about? I am more than happy to optimize the logic for those use cases.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH net-next 0/4] Remove VLAN_TAG_PRESENT from drivers
From: Leon Romanovsky @ 2018-11-08 18:50 UTC (permalink / raw)
To: Michał Mirosław
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Faisal Latif,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Claudiu Manoil, Shiraz Saleem
In-Reply-To: <cover.1541698641.git.mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1100 bytes --]
On Thu, Nov 08, 2018 at 06:44:46PM +0100, Michał Mirosław wrote:
> This series removes VLAN_TAG_PRESENT use from network drivers in
> preparation to removing its special meaning.
Can you please give an extra explanation why it is removed?
Such series come out-of-blue, for people who are not following
netdev mailing list closely (drivers/infiniband/*).
Thanks
>
> Michał Mirosław (4):
> i40iw: remove use of VLAN_TAG_PRESENT
> cnic: remove use of VLAN_TAG_PRESENT
> gianfar: remove use of VLAN_TAG_PRESENT
> OVS: remove use of VLAN_TAG_PRESENT
>
> drivers/infiniband/hw/i40iw/i40iw_cm.c | 8 +++----
> drivers/net/ethernet/broadcom/cnic.c | 2 +-
> .../net/ethernet/freescale/gianfar_ethtool.c | 8 +++----
> net/openvswitch/actions.c | 13 +++++++----
> net/openvswitch/flow.c | 4 ++--
> net/openvswitch/flow.h | 2 +-
> net/openvswitch/flow_netlink.c | 22 +++++++++----------
> 7 files changed, 31 insertions(+), 28 deletions(-)
>
> --
> 2.19.1
>
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH] ath10k: remove set but not used variable 'num_tdls_vifs'
From: YueHaibing @ 2018-11-08 9:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: YueHaibing, ath10k, linux-wireless, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_state':
drivers/net/wireless/ath/ath10k/mac.c:6238:7: warning:
variable 'num_tdls_vifs' set but not used [-Wunused-but-set-variable]
'num_tdls_vifs' not used any more after
9a993cc1ea95 ("ath10k: fix the logic of limiting tdls peer counts")
Also, remove the single called function ath10k_mac_tdls_vifs_count
and ath10k_mac_tdls_vifs_count_iter.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index a1c2801..6006f7a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5754,30 +5754,6 @@ static int ath10k_mac_tdls_vif_stations_count(struct ieee80211_hw *hw,
return data.num_tdls_stations;
}
-static void ath10k_mac_tdls_vifs_count_iter(void *data, u8 *mac,
- struct ieee80211_vif *vif)
-{
- struct ath10k_vif *arvif = (void *)vif->drv_priv;
- int *num_tdls_vifs = data;
-
- if (vif->type != NL80211_IFTYPE_STATION)
- return;
-
- if (ath10k_mac_tdls_vif_stations_count(arvif->ar->hw, vif) > 0)
- (*num_tdls_vifs)++;
-}
-
-static int ath10k_mac_tdls_vifs_count(struct ieee80211_hw *hw)
-{
- int num_tdls_vifs = 0;
-
- ieee80211_iterate_active_interfaces_atomic(hw,
- IEEE80211_IFACE_ITER_NORMAL,
- ath10k_mac_tdls_vifs_count_iter,
- &num_tdls_vifs);
- return num_tdls_vifs;
-}
-
static int ath10k_hw_scan(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_scan_request *hw_req)
@@ -6285,7 +6261,6 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
*/
enum wmi_peer_type peer_type = WMI_PEER_TYPE_DEFAULT;
u32 num_tdls_stations;
- u32 num_tdls_vifs;
ath10k_dbg(ar, ATH10K_DBG_MAC,
"mac vdev %d peer create %pM (new sta) sta %d / %d peer %d / %d\n",
@@ -6301,7 +6276,6 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
}
num_tdls_stations = ath10k_mac_tdls_vif_stations_count(hw, vif);
- num_tdls_vifs = ath10k_mac_tdls_vifs_count(hw);
if (sta->tdls) {
if (num_tdls_stations >= ar->max_num_tdls_vdevs) {
^ permalink raw reply related
* Re: [PATCH iproute2] bridge: fdb: remove redundant dev string in show output
From: Phil Sutter @ 2018-11-08 9:35 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: stephen, netdev, nikolay, dsahern
In-Reply-To: <1541632449-9993-1-git-send-email-roopa@cumulusnetworks.com>
Hi Roopa,
On Wed, Nov 07, 2018 at 03:14:09PM -0800, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> After commit 4abb8c723a64 ("bridge: fdb: Fix for missing
> keywords in non-JSON output"), I am seeing a double print for dev
> in bridge fdb show. eg:
> "44:38:39:00:6a:82 dev dev bridge vlan 1 master bridge permanent"
>
> this patch removes the redundant print.
>
> Fixes: 4abb8c723a64 ("bridge: fdb: Fix for missing keywords in non-JSON output")
Oh, stupid mistake. :(
Thanks for the fix!
> CC: Phil Sutter <phil@nwl.cc>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Acked-by: Phil Sutter <phil@nwl.cc>
^ permalink raw reply
* Re: [PATCH] net: phy: leds: Don't make our own link speed names
From: Kyle Roeschley @ 2018-11-08 19:32 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, David S . Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <fa2751d5-a15c-6414-9b80-15f54fd9f135@gmail.com>
On Thu, Nov 08, 2018 at 09:59:53AM -0800, Florian Fainelli wrote:
> On 11/8/18 9:51 AM, Kyle Roeschley wrote:
> > The phy core provides a handy phy_speed_to_str() helper, so use that
> > instead of doing our own formatting of the different known link speeds.
>
> In case the speed is not supported, phy_speed_to_str() would return
> "Unsupported (update phy-core.c)" which is bigger (by 21 characters)
> than name_suffix.
>
> If you bumped name_suffix/PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE to 11
> characters, that would be just large enough to accommodate for the
> "Unsupported" part of the string and that might be an acceptable
> solution in between.
>
Thanks for catching that, I'll send a v2.
--
Kyle Roeschley
Software Engineer
National Instruments
^ 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