* [PATCH net] mlx4: do not call napi_schedule() without care
From: Eric Dumazet @ 2017-01-13 16:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Erez Shitrit, Eugenia Emantayev, Tariq Toukan
From: Eric Dumazet <edumazet@google.com>
Disable BH around the call to napi_schedule() to avoid following warning
[ 52.095499] NOHZ: local_softirq_pending 08
[ 52.421291] NOHZ: local_softirq_pending 08
[ 52.608313] NOHZ: local_softirq_pending 08
Fixes: 8d59de8f7bb3 ("net/mlx4_en: Process all completions in RX rings after port goes up")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Erez Shitrit <erezsh@mellanox.com>
Cc: Eugenia Emantayev <eugenia@mellanox.com>
Cc: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 4910d9af19335d4b97d39760c163b41eecc26242..761f8b12399cab245abccc0f7d7f84fde742c14d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1748,8 +1748,11 @@ int mlx4_en_start_port(struct net_device *dev)
/* Process all completions if exist to prevent
* the queues freezing if they are full
*/
- for (i = 0; i < priv->rx_ring_num; i++)
+ for (i = 0; i < priv->rx_ring_num; i++) {
+ local_bh_disable();
napi_schedule(&priv->rx_cq[i]->napi);
+ local_bh_enable();
+ }
netif_tx_start_all_queues(dev);
netif_device_attach(dev);
^ permalink raw reply related
* Re: [PATCH v3 1/8] arm: put types.h in uapi
From: Russell King - ARM Linux @ 2017-01-13 17:06 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: linux-mips, alsa-devel, linux-ia64, linux-doc, airlied,
daniel.vetter, linux-fbdev, dri-devel, linux-mtd, sparclinux,
linux-arch, linux-s390, linux-am33-list, linux-c6x-dev,
linux-rdma, linux-hexagon, linux-sh, hch, coreteam, msalter,
fcoe-devel, xen-devel, linux-snps-arc, linux-media,
uclinux-h8-devel, linux-xtensa, arnd, linux-kbuild,
adi-buildroot-devel, linux-raid, linux-m68k, openri
In-Reply-To: <1484304406-10820-2-git-send-email-nicolas.dichtel@6wind.com>
On Fri, Jan 13, 2017 at 11:46:39AM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.
I'm taking this patch, but with the following commit log:
Due to the way kbuild works, this header was unintentionally exported
back in 2013 when it was created, despite it not being in a uapi/
directory. This is very non-intuitive behaviour by Kbuild.
However, we've had this include exported to userland for almost four
years, and searching google for "ARM types.h __UINTPTR_TYPE__" gives
no hint that anyone has complained about it. So, let's make it
officially exported in this state.
If anyone has any objections, they better shout sooner rather than
later.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> arch/arm/include/asm/types.h | 40 ---------------------------------------
> arch/arm/include/uapi/asm/types.h | 40 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 40 insertions(+), 40 deletions(-)
> delete mode 100644 arch/arm/include/asm/types.h
> create mode 100644 arch/arm/include/uapi/asm/types.h
>
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> deleted file mode 100644
> index a53cdb8f068c..000000000000
> --- a/arch/arm/include/asm/types.h
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -#ifndef _ASM_TYPES_H
> -#define _ASM_TYPES_H
> -
> -#include <asm-generic/int-ll64.h>
> -
> -/*
> - * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> - * unambiguous on ARM as you would expect. For the types below, there is a
> - * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
> - * and the kernel itself, which results in build errors if you try to build with
> - * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
> - * in order to use NEON intrinsics)
> - *
> - * As the typedefs for these types in 'stdint.h' are based on builtin defines
> - * supplied by GCC, we can tweak these to align with the kernel's idea of those
> - * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
> - * source file (provided that -ffreestanding is used).
> - *
> - * int32_t uint32_t uintptr_t
> - * bare metal GCC long unsigned long unsigned int
> - * glibc GCC int unsigned int unsigned int
> - * kernel int unsigned int unsigned long
> - */
> -
> -#ifdef __INT32_TYPE__
> -#undef __INT32_TYPE__
> -#define __INT32_TYPE__ int
> -#endif
> -
> -#ifdef __UINT32_TYPE__
> -#undef __UINT32_TYPE__
> -#define __UINT32_TYPE__ unsigned int
> -#endif
> -
> -#ifdef __UINTPTR_TYPE__
> -#undef __UINTPTR_TYPE__
> -#define __UINTPTR_TYPE__ unsigned long
> -#endif
> -
> -#endif /* _ASM_TYPES_H */
> diff --git a/arch/arm/include/uapi/asm/types.h b/arch/arm/include/uapi/asm/types.h
> new file mode 100644
> index 000000000000..9435a42f575e
> --- /dev/null
> +++ b/arch/arm/include/uapi/asm/types.h
> @@ -0,0 +1,40 @@
> +#ifndef _UAPI_ASM_TYPES_H
> +#define _UAPI_ASM_TYPES_H
> +
> +#include <asm-generic/int-ll64.h>
> +
> +/*
> + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> + * unambiguous on ARM as you would expect. For the types below, there is a
> + * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
> + * and the kernel itself, which results in build errors if you try to build with
> + * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
> + * in order to use NEON intrinsics)
> + *
> + * As the typedefs for these types in 'stdint.h' are based on builtin defines
> + * supplied by GCC, we can tweak these to align with the kernel's idea of those
> + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
> + * source file (provided that -ffreestanding is used).
> + *
> + * int32_t uint32_t uintptr_t
> + * bare metal GCC long unsigned long unsigned int
> + * glibc GCC int unsigned int unsigned int
> + * kernel int unsigned int unsigned long
> + */
> +
> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__ int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__ unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif
> +
> +#endif /* _UAPI_ASM_TYPES_H */
> --
> 2.8.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: resend: tcp: performance issue with fastopen connections (mss > window)
From: Alexey Kodanev @ 2017-01-13 17:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Vasily Isaenko, Neal Cardwell,
Yuchung Cheng, Eric Dumazet
In-Reply-To: <1484321734.13165.24.camel@edumazet-glaptop3.roam.corp.google.com>
Hi Eric,
On 13.01.2017 18:35, Eric Dumazet wrote:
> On Fri, 2017-01-13 at 18:01 +0300, Alexey Kodanev wrote:
>> Hi,
>>
>> Got the issue when running LTP/netstress test on localhost with mss
>> greater than the send window advertised by client (right after 3WHS).
>> Here is the testscenario that can reproduce this:
> Hi Alexey
>
> So this is a combination of Fastopen + small window + large MSS ?
Yeah, this happens only in the beginning, after first ack from client.
Later window gets
lager than mss and it doesn't happen.
>
> I would rather not force burning tons of coal or other fossil fuel,
> by making each tcp_sendmsg() done by billions of linux devices more
> expensive, only to accommodate for some LTP test doing something not
> sensible ;)
>
> Fact that you removed one condition in the BUG_ON() might hide another
> issue later in the path.
>
> I would suggest to clamp MSS to half the initial window, but I guess
> this is impractical since window in SYN/SYNACK are not scaled.
> Care to send a packetdrill test so that we have a clear picture of what
> is going on ?
Is it capable of making two connections in the single test, one after
another?
Thanks,
Alexey
^ permalink raw reply
* Re: [Patch net] atm: remove an unnecessary loop
From: David Miller @ 2017-01-13 17:10 UTC (permalink / raw)
To: romieu; +Cc: xiyou.wangcong, netdev, mhocko, 3chas3, andreyknvl
In-Reply-To: <20170113000700.GA1482@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Fri, 13 Jan 2017 01:07:00 +0100
> Were alloc_skb moved one level up in the call stack, there would be
> no need to use the new wait api in the subsequent page, thus easing
> pre 3.19 longterm kernel maintenance (at least those on korg page).
>
> But it tastes a tad bit too masochistic.
Lack of error handling of allocation failure is always a huge red
flag. We even long ago tried to do something like this for TCP FIN
handling.
It's dumb, it doesn't work.
Therefore I agree that the correct fix is to move the SKB allocation
up one level to vcc_sendmsg() and make it handle errors properly.
^ permalink raw reply
* [PATCH 1/3] powerpc: bpf: remove redundant check for non-null image
From: Naveen N. Rao @ 2017-01-13 17:10 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, netdev, ast, daniel, davem
From: Daniel Borkmann <daniel@iogearbox.net>
We have a check earlier to ensure we don't proceed if image is NULL. As
such, the redundant check can be removed.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
[Added similar changes for classic BPF JIT]
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/net/bpf_jit_comp.c | 17 +++++++++--------
arch/powerpc/net/bpf_jit_comp64.c | 16 ++++++++--------
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 7e706f3..f9941b3 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -662,16 +662,17 @@ void bpf_jit_compile(struct bpf_prog *fp)
*/
bpf_jit_dump(flen, proglen, pass, code_base);
- if (image) {
- bpf_flush_icache(code_base, code_base + (proglen/4));
+ bpf_flush_icache(code_base, code_base + (proglen/4));
+
#ifdef CONFIG_PPC64
- /* Function descriptor nastiness: Address + TOC */
- ((u64 *)image)[0] = (u64)code_base;
- ((u64 *)image)[1] = local_paca->kernel_toc;
+ /* Function descriptor nastiness: Address + TOC */
+ ((u64 *)image)[0] = (u64)code_base;
+ ((u64 *)image)[1] = local_paca->kernel_toc;
#endif
- fp->bpf_func = (void *)image;
- fp->jited = 1;
- }
+
+ fp->bpf_func = (void *)image;
+ fp->jited = 1;
+
out:
kfree(addrs);
return;
diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index 0fe98a5..89b6a86 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -1046,16 +1046,16 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
*/
bpf_jit_dump(flen, proglen, pass, code_base);
- if (image) {
- bpf_flush_icache(bpf_hdr, image + alloclen);
+ bpf_flush_icache(bpf_hdr, image + alloclen);
+
#ifdef PPC64_ELF_ABI_v1
- /* Function descriptor nastiness: Address + TOC */
- ((u64 *)image)[0] = (u64)code_base;
- ((u64 *)image)[1] = local_paca->kernel_toc;
+ /* Function descriptor nastiness: Address + TOC */
+ ((u64 *)image)[0] = (u64)code_base;
+ ((u64 *)image)[1] = local_paca->kernel_toc;
#endif
- fp->bpf_func = (void *)image;
- fp->jited = 1;
- }
+
+ fp->bpf_func = (void *)image;
+ fp->jited = 1;
out:
kfree(addrs);
--
2.10.2
^ permalink raw reply related
* [PATCH 2/3] powerpc: bpf: flush the entire JIT buffer
From: Naveen N. Rao @ 2017-01-13 17:10 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, netdev, ast, daniel, davem
In-Reply-To: <e73efe6facf6c06932b4a87707e5978172ee773e.1484326337.git.naveen.n.rao@linux.vnet.ibm.com>
With bpf_jit_binary_alloc(), we allocate at a page granularity and fill
the rest of the space with illegal instructions to mitigate BPF spraying
attacks, while having the actual JIT'ed BPF program at a random location
within the allocated space. Under this scenario, it would be better to
flush the entire allocated buffer rather than just the part containing
the actual program. We already flush the buffer from start to the end of
the BPF program. Extend this to include the illegal instructions after
the BPF program.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/net/bpf_jit_comp64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index 89b6a86..1e313db 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -1046,8 +1046,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
*/
bpf_jit_dump(flen, proglen, pass, code_base);
- bpf_flush_icache(bpf_hdr, image + alloclen);
-
#ifdef PPC64_ELF_ABI_v1
/* Function descriptor nastiness: Address + TOC */
((u64 *)image)[0] = (u64)code_base;
@@ -1057,6 +1055,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
fp->bpf_func = (void *)image;
fp->jited = 1;
+ bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE));
+
out:
kfree(addrs);
--
2.10.2
^ permalink raw reply related
* [PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations
From: Naveen N. Rao @ 2017-01-13 17:10 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, netdev, ast, daniel, davem
In-Reply-To: <e73efe6facf6c06932b4a87707e5978172ee773e.1484326337.git.naveen.n.rao@linux.vnet.ibm.com>
Generate instructions to perform the endian conversion using registers,
rather than generating two memory accesses.
The "way easier and faster" comment was obviously for the author, not
the processor.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/net/bpf_jit_comp64.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index 1e313db..0413a89 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -599,16 +599,22 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
break;
case 64:
/*
- * Way easier and faster(?) to store the value
- * into stack and then use ldbrx
+ * We'll split it up into two words, swap those
+ * independently and then merge them back.
*
- * ctx->seen will be reliable in pass2, but
- * the instructions generated will remain the
- * same across all passes
+ * First up, let's swap the most-significant word.
*/
- PPC_STD(dst_reg, 1, bpf_jit_stack_local(ctx));
- PPC_ADDI(b2p[TMP_REG_1], 1, bpf_jit_stack_local(ctx));
- PPC_LDBRX(dst_reg, 0, b2p[TMP_REG_1]);
+ PPC_RLDICL(b2p[TMP_REG_1], dst_reg, 32, 32);
+ PPC_RLWINM(b2p[TMP_REG_2], b2p[TMP_REG_1], 8, 0, 31);
+ PPC_RLWIMI(b2p[TMP_REG_2], b2p[TMP_REG_1], 24, 0, 7);
+ PPC_RLWIMI(b2p[TMP_REG_2], b2p[TMP_REG_1], 24, 16, 23);
+ /* Then, the second half */
+ PPC_RLWINM(b2p[TMP_REG_1], dst_reg, 8, 0, 31);
+ PPC_RLWIMI(b2p[TMP_REG_1], dst_reg, 24, 0, 7);
+ PPC_RLWIMI(b2p[TMP_REG_1], dst_reg, 24, 16, 23);
+ /* Merge back */
+ PPC_RLDICR(dst_reg, b2p[TMP_REG_1], 32, 31);
+ PPC_OR(dst_reg, dst_reg, b2p[TMP_REG_2]);
break;
}
break;
--
2.10.2
^ permalink raw reply related
* [PATCH net-next] netlink: do not enter direct reclaim from netlink_trim()
From: Eric Dumazet @ 2017-01-13 17:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
In commit d35c99ff77ecb ("netlink: do not enter direct reclaim from
netlink_dump()") we made sure to not trigger expensive memory reclaim.
Problem is that a bit later, netlink_trim() might be called and
trigger memory reclaim.
netlink_trim() should be best effort, and really as fast as possible.
Under memory pressure, it is fine to not trim this skb.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/netlink/af_netlink.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 161b628ab2b08bf4321dbe617022c4c50486534d..edcc1e19ad532641f51f6809b8c90d1e377081ff 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1210,7 +1210,9 @@ static struct sk_buff *netlink_trim(struct sk_buff *skb, gfp_t allocation)
skb = nskb;
}
- if (!pskb_expand_head(skb, 0, -delta, allocation))
+ if (!pskb_expand_head(skb, 0, -delta,
+ (allocation & ~__GFP_DIRECT_RECLAIM) |
+ __GFP_NOWARN | __GFP_NORETRY))
skb->truesize -= delta;
return skb;
^ permalink raw reply related
* Re: kill off pci_enable_msi_{exact,range}
From: Bjorn Helgaas @ 2017-01-13 17:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-pci, Mauro Carvalho Chehab, netdev, linux-media,
Tom Lendacky
In-Reply-To: <20170113080553.GA26280@lst.de>
On Fri, Jan 13, 2017 at 09:05:53AM +0100, Christoph Hellwig wrote:
> On Fri, Jan 13, 2017 at 08:55:03AM +0100, Christoph Hellwig wrote:
> > On Thu, Jan 12, 2017 at 03:29:00PM -0600, Bjorn Helgaas wrote:
> > > Applied all three (with Tom's ack on the amd-xgbe patch) to pci/msi for
> > > v4.11, thanks!
> >
> > Tom had just send me an event better version of the xgbe patch. Tom,
> > maybe you can resend that relative to the PCI tree [1], so that we don't
> > lose it for next merge window?
>
> Actually - Bjorn, your msi branch contains an empty commit from this
> thread:
>
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/msi&id=7a8191de43faa9869b421a1b06075d8126ce7c0b
Yep, I botched that. Thought I'd fixed it, but guess I got distracted.
> Maybe we should rebase it after all to avoid that? In that case please
> pick up the xgbe patch from Tom below:
I dropped the empty commit and replaced the xgbe patch with the one below.
Can you take a look at [1] and make sure it's what you expected?
[1] https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/msi
Thanks!
> ---
> From: Tom Lendacky <thomas.lendacky@amd.com>
> Subject: [PATCH] amd-xgbe: Update PCI support to use new IRQ functions
>
> Some of the PCI MSI/MSI-X functions have been deprecated and it is
> recommended to use the new pci_alloc_irq_vectors() function. Convert
> the code over to use the new function. Also, modify the way in which
> the IRQs are requested - try for multiple MSI-X/MSI first, then a
> single MSI/legacy interrupt.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 128 +++++++++---------------------
> drivers/net/ethernet/amd/xgbe/xgbe.h | 8 +-
> 2 files changed, 41 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> index e76b7f6..e436902 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> @@ -122,104 +122,40 @@
> #include "xgbe.h"
> #include "xgbe-common.h"
>
> -static int xgbe_config_msi(struct xgbe_prv_data *pdata)
> +static int xgbe_config_multi_msi(struct xgbe_prv_data *pdata)
> {
> - unsigned int msi_count;
> + unsigned int vector_count;
> unsigned int i, j;
> int ret;
>
> - msi_count = XGBE_MSIX_BASE_COUNT;
> - msi_count += max(pdata->rx_ring_count,
> - pdata->tx_ring_count);
> - msi_count = roundup_pow_of_two(msi_count);
> + vector_count = XGBE_MSI_BASE_COUNT;
> + vector_count += max(pdata->rx_ring_count,
> + pdata->tx_ring_count);
>
> - ret = pci_enable_msi_exact(pdata->pcidev, msi_count);
> + ret = pci_alloc_irq_vectors(pdata->pcidev, XGBE_MSI_MIN_COUNT,
> + vector_count, PCI_IRQ_MSI | PCI_IRQ_MSIX);
> if (ret < 0) {
> - dev_info(pdata->dev, "MSI request for %u interrupts failed\n",
> - msi_count);
> -
> - ret = pci_enable_msi(pdata->pcidev);
> - if (ret < 0) {
> - dev_info(pdata->dev, "MSI enablement failed\n");
> - return ret;
> - }
> -
> - msi_count = 1;
> - }
> -
> - pdata->irq_count = msi_count;
> -
> - pdata->dev_irq = pdata->pcidev->irq;
> -
> - if (msi_count > 1) {
> - pdata->ecc_irq = pdata->pcidev->irq + 1;
> - pdata->i2c_irq = pdata->pcidev->irq + 2;
> - pdata->an_irq = pdata->pcidev->irq + 3;
> -
> - for (i = XGBE_MSIX_BASE_COUNT, j = 0;
> - (i < msi_count) && (j < XGBE_MAX_DMA_CHANNELS);
> - i++, j++)
> - pdata->channel_irq[j] = pdata->pcidev->irq + i;
> - pdata->channel_irq_count = j;
> -
> - pdata->per_channel_irq = 1;
> - pdata->channel_irq_mode = XGBE_IRQ_MODE_LEVEL;
> - } else {
> - pdata->ecc_irq = pdata->pcidev->irq;
> - pdata->i2c_irq = pdata->pcidev->irq;
> - pdata->an_irq = pdata->pcidev->irq;
> - }
> -
> - if (netif_msg_probe(pdata))
> - dev_dbg(pdata->dev, "MSI interrupts enabled\n");
> -
> - return 0;
> -}
> -
> -static int xgbe_config_msix(struct xgbe_prv_data *pdata)
> -{
> - unsigned int msix_count;
> - unsigned int i, j;
> - int ret;
> -
> - msix_count = XGBE_MSIX_BASE_COUNT;
> - msix_count += max(pdata->rx_ring_count,
> - pdata->tx_ring_count);
> -
> - pdata->msix_entries = devm_kcalloc(pdata->dev, msix_count,
> - sizeof(struct msix_entry),
> - GFP_KERNEL);
> - if (!pdata->msix_entries)
> - return -ENOMEM;
> -
> - for (i = 0; i < msix_count; i++)
> - pdata->msix_entries[i].entry = i;
> -
> - ret = pci_enable_msix_range(pdata->pcidev, pdata->msix_entries,
> - XGBE_MSIX_MIN_COUNT, msix_count);
> - if (ret < 0) {
> - dev_info(pdata->dev, "MSI-X enablement failed\n");
> - devm_kfree(pdata->dev, pdata->msix_entries);
> - pdata->msix_entries = NULL;
> + dev_info(pdata->dev, "multi MSI/MSI-X enablement failed\n");
> return ret;
> }
>
> pdata->irq_count = ret;
>
> - pdata->dev_irq = pdata->msix_entries[0].vector;
> - pdata->ecc_irq = pdata->msix_entries[1].vector;
> - pdata->i2c_irq = pdata->msix_entries[2].vector;
> - pdata->an_irq = pdata->msix_entries[3].vector;
> + pdata->dev_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 1);
> + pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 2);
> + pdata->an_irq = pci_irq_vector(pdata->pcidev, 3);
>
> - for (i = XGBE_MSIX_BASE_COUNT, j = 0; i < ret; i++, j++)
> - pdata->channel_irq[j] = pdata->msix_entries[i].vector;
> + for (i = XGBE_MSI_BASE_COUNT, j = 0; i < ret; i++, j++)
> + pdata->channel_irq[j] = pci_irq_vector(pdata->pcidev, i);
> pdata->channel_irq_count = j;
>
> pdata->per_channel_irq = 1;
> pdata->channel_irq_mode = XGBE_IRQ_MODE_LEVEL;
>
> if (netif_msg_probe(pdata))
> - dev_dbg(pdata->dev, "MSI-X interrupts enabled\n");
> + dev_dbg(pdata->dev, "multi %s interrupts enabled\n",
> + pdata->pcidev->msix_enabled ? "MSI-X" : "MSI");
>
> return 0;
> }
> @@ -228,21 +164,28 @@ static int xgbe_config_irqs(struct xgbe_prv_data *pdata)
> {
> int ret;
>
> - ret = xgbe_config_msix(pdata);
> + ret = xgbe_config_multi_msi(pdata);
> if (!ret)
> goto out;
>
> - ret = xgbe_config_msi(pdata);
> - if (!ret)
> - goto out;
> + ret = pci_alloc_irq_vectors(pdata->pcidev, 1, 1,
> + PCI_IRQ_LEGACY | PCI_IRQ_MSI);
> + if (ret < 0) {
> + dev_info(pdata->dev, "single IRQ enablement failed\n");
> + return ret;
> + }
>
> pdata->irq_count = 1;
> - pdata->irq_shared = 1;
> + pdata->channel_irq_count = 1;
> +
> + pdata->dev_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->an_irq = pci_irq_vector(pdata->pcidev, 0);
>
> - pdata->dev_irq = pdata->pcidev->irq;
> - pdata->ecc_irq = pdata->pcidev->irq;
> - pdata->i2c_irq = pdata->pcidev->irq;
> - pdata->an_irq = pdata->pcidev->irq;
> + if (netif_msg_probe(pdata))
> + dev_dbg(pdata->dev, "single %s interrupt enabled\n",
> + pdata->pcidev->msi_enabled ? "MSI" : "legacy");
>
> out:
> if (netif_msg_probe(pdata)) {
> @@ -412,12 +355,15 @@ static int xgbe_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> /* Configure the netdev resource */
> ret = xgbe_config_netdev(pdata);
> if (ret)
> - goto err_pci_enable;
> + goto err_irq_vectors;
>
> netdev_notice(pdata->netdev, "net device enabled\n");
>
> return 0;
>
> +err_irq_vectors:
> + pci_free_irq_vectors(pdata->pcidev);
> +
> err_pci_enable:
> xgbe_free_pdata(pdata);
>
> @@ -433,6 +379,8 @@ static void xgbe_pci_remove(struct pci_dev *pdev)
>
> xgbe_deconfig_netdev(pdata);
>
> + pci_free_irq_vectors(pdata->pcidev);
> +
> xgbe_free_pdata(pdata);
> }
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe.h b/drivers/net/ethernet/amd/xgbe/xgbe.h
> index f52a9bd..99f1c87 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe.h
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe.h
> @@ -211,9 +211,9 @@
> #define XGBE_MAC_PROP_OFFSET 0x1d000
> #define XGBE_I2C_CTRL_OFFSET 0x1e000
>
> -/* PCI MSIx support */
> -#define XGBE_MSIX_BASE_COUNT 4
> -#define XGBE_MSIX_MIN_COUNT (XGBE_MSIX_BASE_COUNT + 1)
> +/* PCI MSI/MSIx support */
> +#define XGBE_MSI_BASE_COUNT 4
> +#define XGBE_MSI_MIN_COUNT (XGBE_MSI_BASE_COUNT + 1)
>
> /* PCI clock frequencies */
> #define XGBE_V2_DMA_CLOCK_FREQ 500000000 /* 500 MHz */
> @@ -980,14 +980,12 @@ struct xgbe_prv_data {
> unsigned int desc_ded_count;
> unsigned int desc_sec_count;
>
> - struct msix_entry *msix_entries;
> int dev_irq;
> int ecc_irq;
> int i2c_irq;
> int channel_irq[XGBE_MAX_DMA_CHANNELS];
>
> unsigned int per_channel_irq;
> - unsigned int irq_shared;
> unsigned int irq_count;
> unsigned int channel_irq_count;
> unsigned int channel_irq_mode;
>
^ permalink raw reply
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: David Miller @ 2017-01-13 17:14 UTC (permalink / raw)
To: saeedm-VPRAkNaXOzVWk0Htik3J/w
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, leon-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1484241755-17603-1-git-send-email-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Date: Thu, 12 Jan 2017 19:22:34 +0200
> This pull request includes one patch from Leon, this patch as described
> below will change the driver directory structure and layout for better,
> logical and modular driver files separation.
>
> This change is important to both rdma and net maintainers in order to
> have smoother management of driver patches for different mlx5 sub modules
> and smoother rdma-next vs. net-next features submissions.
>
> Please find more info below -in the tag commit message-,
> review and let us know if there's any problem.
>
> This change doesn't introduce any conflicts with the current mlx5
> fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
> worked flawlessly with no issues.
>
> This is the last pull request meant for both rdma-next and net-next.
> Once pulled, this will be the base shared code for both trees.
This is pretty crazy, it will make all bug fix backporting to -stable
a complete nightmare for myself, Doug, various distribution maintainers
and many other people who quietly have to maintain their own trees and
do backporting.
I really don't think you can justify this rearrangement based upon the
consequences and how much activity happens in this driver.
You should have thought long and hard about the layout a long time ago
rather than after the driver has been in the tree for many years.
Sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kill off pci_enable_msi_{exact,range}
From: Christoph Hellwig @ 2017-01-13 17:15 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Christoph Hellwig, linux-pci, Mauro Carvalho Chehab, netdev,
linux-media, Tom Lendacky
In-Reply-To: <20170113171321.GA22776@bhelgaas-glaptop.roam.corp.google.com>
On Fri, Jan 13, 2017 at 11:13:21AM -0600, Bjorn Helgaas wrote:
> I dropped the empty commit and replaced the xgbe patch with the one below.
> Can you take a look at [1] and make sure it's what you expected?
This looks great, thanks!
^ permalink raw reply
* Re: resend: tcp: performance issue with fastopen connections (mss > window)
From: Eric Dumazet @ 2017-01-13 17:14 UTC (permalink / raw)
To: Alexey Kodanev
Cc: Eric Dumazet, David Miller, netdev, Vasily Isaenko, Neal Cardwell,
Yuchung Cheng
In-Reply-To: <22b07900-2151-a31f-34aa-7fb47c958423@oracle.com>
On Fri, Jan 13, 2017 at 9:07 AM, Alexey Kodanev
<alexey.kodanev@oracle.com> wrote:
> Hi Eric,
> On 13.01.2017 18:35, Eric Dumazet wrote:
>> Care to send a packetdrill test so that we have a clear picture of what
>> is going on ?
>
> Is it capable of making two connections in the single test, one after
> another?
Absolutely.
Neal, Yuchung would you be kind enough to send a Fastopen tpacketdrill
template showing a typical fastopen test
running on an upstream kernel ?
Thanks !
^ permalink raw reply
* Re: [PATCH v2 0/2] bpf: add longest prefix match map
From: David Miller @ 2017-01-13 17:15 UTC (permalink / raw)
To: daniel; +Cc: ast, dh.herrmann, daniel, netdev
In-Reply-To: <20170112172922.16636-1-daniel@zonque.org>
From: Daniel Mack <daniel@zonque.org>
Date: Thu, 12 Jan 2017 18:29:20 +0100
> Feedback is much appreciated.
Daniel and Alexei, can I get a review please?
^ permalink raw reply
* RE: [PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations
From: David Laight @ 2017-01-13 17:17 UTC (permalink / raw)
To: 'Naveen N. Rao', mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org, ast@fb.com,
daniel@iogearbox.net, davem@davemloft.net
In-Reply-To: <bb264395301754f43b77ddec68a16dd34220abb4.1484326337.git.naveen.n.rao@linux.vnet.ibm.com>
From: Naveen N. Rao
> Sent: 13 January 2017 17:10
> Generate instructions to perform the endian conversion using registers,
> rather than generating two memory accesses.
>
> The "way easier and faster" comment was obviously for the author, not
> the processor.
That rather depends on whether the processor has a store to load forwarder
that will satisfy the read from the store buffer.
I don't know about ppc, but at least some x86 will do that.
David
^ permalink raw reply
* Re: [PATCH net] net: systemport: Decouple flow control from __bcm_sysport_tx_reclaim
From: David Miller @ 2017-01-13 17:20 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <20170112200909.26825-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 12 Jan 2017 12:09:09 -0800
> The __bcm_sysport_tx_reclaim() function is used to reclaim transmit
> resources in different places within the driver. Most of them should
> not affect the state of the transit flow control.
>
> Introduce bcm_sysport_tx_clean() which cleans the ring, but does not
> re-enable flow control towards the networking stack, and make
> bcm_sysport_tx_reclaim() do the actual transmit queue flow control.
>
> Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] netlink: do not enter direct reclaim from netlink_trim()
From: Alexei Starovoitov @ 2017-01-13 17:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1484327482.13165.38.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Jan 13, 2017 at 09:11:22AM -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> In commit d35c99ff77ecb ("netlink: do not enter direct reclaim from
> netlink_dump()") we made sure to not trigger expensive memory reclaim.
>
> Problem is that a bit later, netlink_trim() might be called and
> trigger memory reclaim.
>
> netlink_trim() should be best effort, and really as fast as possible.
> Under memory pressure, it is fine to not trim this skb.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Thanks!
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [net PATCH 5/5] virtio_net: XDP support for adjust_head
From: Michael S. Tsirkin @ 2017-01-13 17:23 UTC (permalink / raw)
To: John Fastabend
Cc: jasowang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170112214519.3039.27879.stgit@john-Precision-Tower-5810>
On Thu, Jan 12, 2017 at 01:45:19PM -0800, John Fastabend wrote:
> Add support for XDP adjust head by allocating a 256B header region
> that XDP programs can grow into. This is only enabled when a XDP
> program is loaded.
>
> In order to ensure that we do not have to unwind queue headroom push
> queue setup below bpf_prog_add. It reads better to do a prog ref
> unwind vs another queue setup call.
>
> At the moment this code must do a full reset to ensure old buffers
> without headroom on program add or with headroom on program removal
> are not used incorrectly in the datapath. Ideally we would only
> have to disable/enable the RX queues being updated but there is no
> API to do this at the moment in virtio so use the big hammer. In
> practice it is likely not that big of a problem as this will only
> happen when XDP is enabled/disabled changing programs does not
> require the reset. There is some risk that the driver may either
> have an allocation failure or for some reason fail to correctly
> negotiate with the underlying backend in this case the driver will
> be left uninitialized. I have not seen this ever happen on my test
> systems and for what its worth this same failure case can occur
> from probe and other contexts in virtio framework.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> drivers/net/virtio_net.c | 155 ++++++++++++++++++++++++++++++++++++++++------
> drivers/virtio/virtio.c | 9 ++-
> include/linux/virtio.h | 3 +
> 3 files changed, 144 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 6041828..8b897e7 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -28,6 +28,7 @@
> #include <linux/slab.h>
> #include <linux/cpu.h>
> #include <linux/average.h>
> +#include <linux/pci.h>
> #include <net/busy_poll.h>
>
> static int napi_weight = NAPI_POLL_WEIGHT;
> @@ -159,6 +160,9 @@ struct virtnet_info {
> /* Ethtool settings */
> u8 duplex;
> u32 speed;
> +
> + /* Headroom allocated in RX Queue */
> + unsigned int headroom;
> };
>
> struct padded_vnet_hdr {
> @@ -359,6 +363,7 @@ static void virtnet_xdp_xmit(struct virtnet_info *vi,
> }
>
> if (vi->mergeable_rx_bufs) {
> + xdp->data -= sizeof(struct virtio_net_hdr_mrg_rxbuf);
> /* Zero header and leave csum up to XDP layers */
> hdr = xdp->data;
> memset(hdr, 0, vi->hdr_len);
> @@ -375,7 +380,9 @@ static void virtnet_xdp_xmit(struct virtnet_info *vi,
> num_sg = 2;
> sg_init_table(sq->sg, 2);
> sg_set_buf(sq->sg, hdr, vi->hdr_len);
> - skb_to_sgvec(skb, sq->sg + 1, 0, skb->len);
> + skb_to_sgvec(skb, sq->sg + 1,
> + xdp->data - xdp->data_hard_start,
> + xdp->data_end - xdp->data);
> }
> err = virtqueue_add_outbuf(sq->vq, sq->sg, num_sg,
> data, GFP_ATOMIC);
> @@ -401,7 +408,6 @@ static struct sk_buff *receive_small(struct net_device *dev,
> struct bpf_prog *xdp_prog;
>
> len -= vi->hdr_len;
> - skb_trim(skb, len);
>
> rcu_read_lock();
> xdp_prog = rcu_dereference(rq->xdp_prog);
> @@ -413,11 +419,15 @@ static struct sk_buff *receive_small(struct net_device *dev,
> if (unlikely(hdr->hdr.gso_type || hdr->hdr.flags))
> goto err_xdp;
>
> - xdp.data = skb->data;
> + xdp.data_hard_start = skb->data;
> + xdp.data = skb->data + vi->headroom;
> xdp.data_end = xdp.data + len;
> act = bpf_prog_run_xdp(xdp_prog, &xdp);
> switch (act) {
> case XDP_PASS:
> + /* Recalculate length in case bpf program changed it */
> + len = xdp.data_end - xdp.data;
> + __skb_pull(skb, xdp.data - xdp.data_hard_start);
> break;
> case XDP_TX:
> virtnet_xdp_xmit(vi, rq, &xdp, skb);
> @@ -432,6 +442,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
> }
> rcu_read_unlock();
>
> + skb_trim(skb, len);
> return skb;
>
> err_xdp:
> @@ -569,7 +580,11 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> if (unlikely(hdr->hdr.gso_type))
> goto err_xdp;
>
> + /* Allow consuming headroom but reserve enough space to push
> + * the descriptor on if we get an XDP_TX return code.
> + */
> data = page_address(xdp_page) + offset;
> + xdp.data_hard_start = data - vi->headroom + desc_room;
> xdp.data = data + desc_room;
> xdp.data_end = xdp.data + (len - vi->hdr_len);
> act = bpf_prog_run_xdp(xdp_prog, &xdp);
> @@ -748,20 +763,21 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
> static int add_recvbuf_small(struct virtnet_info *vi, struct receive_queue *rq,
> gfp_t gfp)
> {
> + int headroom = GOOD_PACKET_LEN + vi->headroom;
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> int err;
>
> - skb = __netdev_alloc_skb_ip_align(vi->dev, GOOD_PACKET_LEN, gfp);
> + skb = __netdev_alloc_skb_ip_align(vi->dev, headroom, gfp);
> if (unlikely(!skb))
> return -ENOMEM;
>
> - skb_put(skb, GOOD_PACKET_LEN);
> + skb_put(skb, headroom);
>
> hdr = skb_vnet_hdr(skb);
> sg_init_table(rq->sg, 2);
> sg_set_buf(rq->sg, hdr, vi->hdr_len);
> - skb_to_sgvec(skb, rq->sg + 1, 0, skb->len);
> + skb_to_sgvec(skb, rq->sg + 1, vi->headroom, skb->len - vi->headroom);
>
> err = virtqueue_add_inbuf(rq->vq, rq->sg, 2, skb, gfp);
> if (err < 0)
> @@ -829,24 +845,27 @@ static unsigned int get_mergeable_buf_len(struct ewma_pkt_len *avg_pkt_len)
> return ALIGN(len, MERGEABLE_BUFFER_ALIGN);
> }
>
> -static int add_recvbuf_mergeable(struct receive_queue *rq, gfp_t gfp)
> +static int add_recvbuf_mergeable(struct virtnet_info *vi,
> + struct receive_queue *rq, gfp_t gfp)
> {
> struct page_frag *alloc_frag = &rq->alloc_frag;
> + unsigned int headroom = vi->headroom;
> char *buf;
> unsigned long ctx;
> int err;
> unsigned int len, hole;
>
> len = get_mergeable_buf_len(&rq->mrg_avg_pkt_len);
> - if (unlikely(!skb_page_frag_refill(len, alloc_frag, gfp)))
> + if (unlikely(!skb_page_frag_refill(len + headroom, alloc_frag, gfp)))
> return -ENOMEM;
>
> buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset;
> + buf += headroom; /* advance address leaving hole at front of pkt */
> ctx = mergeable_buf_to_ctx(buf, len);
> get_page(alloc_frag->page);
> - alloc_frag->offset += len;
> + alloc_frag->offset += len + headroom;
> hole = alloc_frag->size - alloc_frag->offset;
> - if (hole < len) {
> + if (hole < len + headroom) {
> /* To avoid internal fragmentation, if there is very likely not
> * enough space for another buffer, add the remaining space to
> * the current buffer. This extra space is not included in
> @@ -880,7 +899,7 @@ static bool try_fill_recv(struct virtnet_info *vi, struct receive_queue *rq,
> gfp |= __GFP_COLD;
> do {
> if (vi->mergeable_rx_bufs)
> - err = add_recvbuf_mergeable(rq, gfp);
> + err = add_recvbuf_mergeable(vi, rq, gfp);
> else if (vi->big_packets)
> err = add_recvbuf_big(vi, rq, gfp);
> else
> @@ -1675,12 +1694,90 @@ static void virtnet_init_settings(struct net_device *dev)
> .set_settings = virtnet_set_settings,
> };
>
> +#define VIRTIO_XDP_HEADROOM 256
> +
> +static int init_vqs(struct virtnet_info *vi);
> +static void remove_vq_common(struct virtnet_info *vi, bool lock);
> +
> +/* Reset virtio device with RTNL held this is very similar to the
> + * freeze()/restore() logic except we need to ensure locking. It is
> + * possible that this routine may fail and leave the driver in a
> + * failed state. However assuming the driver negotiated correctly
> + * at probe time we _should_ be able to (re)negotiate driver again.
> + */
> +static int virtnet_xdp_reset(struct virtnet_info *vi)
> +{
> + struct virtio_device *vdev = vi->vdev;
> + unsigned int status;
> + int i, ret;
> +
> + /* Disable and unwind rings */
> + virtio_config_disable(vdev);
> + vdev->failed = vdev->config->get_status(vdev) & VIRTIO_CONFIG_S_FAILED;
> +
> + netif_device_detach(vi->dev);
After this point, netif_device_present
will return false, and then we have a bunch of code
that does
if (!netif_device_present(dev))
return -ENODEV;
so we need to audit this code to make sure it's
all called under rtnl, correct?
We don't want it to fail because of timing.
Maybe add an assert there.
> + cancel_delayed_work_sync(&vi->refill);
> + if (netif_running(vi->dev)) {
> + for (i = 0; i < vi->max_queue_pairs; i++)
> + napi_disable(&vi->rq[i].napi);
> + }
> +
> + remove_vq_common(vi, false);
> +
> + /* Do a reset per virtio spec recommendation */
> + vdev->config->reset(vdev);
> +
> + /* Acknowledge that we've seen the device. */
> + status = vdev->config->get_status(vdev);
> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_ACKNOWLEDGE);
> +
> + /* Notify driver is up and finalize features per specification. The
> + * error code from finalize features is checked here but should not
> + * fail because we assume features were previously synced successfully.
> + */
> + status = vdev->config->get_status(vdev);
> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_DRIVER);
> + ret = virtio_finalize_features(vdev);
I'd rather we put all this in virtio core, maybe call it virtio_reset or
something.
> + if (ret) {
> + netdev_warn(vi->dev, "virtio_finalize_features failed during reset aborting\n");
> + goto err;
> + }
> +
> + ret = init_vqs(vi);
> + if (ret) {
> + netdev_warn(vi->dev, "init_vqs failed during reset aborting\n");
> + goto err;
> + }
> + virtio_device_ready(vi->vdev);
> +
> + if (netif_running(vi->dev)) {
> + for (i = 0; i < vi->curr_queue_pairs; i++)
> + if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL))
> + schedule_delayed_work(&vi->refill, 0);
> +
> + for (i = 0; i < vi->max_queue_pairs; i++)
> + virtnet_napi_enable(&vi->rq[i]);
> + }
> + netif_device_attach(vi->dev);
> + /* Finally, tell the device we're all set */
> + status = vdev->config->get_status(vdev);
> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_DRIVER_OK);
> + virtio_config_enable(vdev);
> +
> + return 0;
> +err:
> + status = vdev->config->get_status(vdev);
> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_FAILED);
And maybe virtio_fail ?
> + return ret;
> +}
> +
> static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> {
> unsigned long int max_sz = PAGE_SIZE - sizeof(struct padded_vnet_hdr);
> struct virtnet_info *vi = netdev_priv(dev);
> struct bpf_prog *old_prog;
> u16 xdp_qp = 0, curr_qp;
> + unsigned int old_hr;
> int i, err;
>
> if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||
> @@ -1712,18 +1809,31 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> return -ENOMEM;
> }
>
> - err = virtnet_set_queues(vi, curr_qp + xdp_qp);
> - if (err) {
> - dev_warn(&dev->dev, "XDP Device queue allocation failure.\n");
> - return err;
> - }
> -
> + old_hr = vi->headroom;
> if (prog) {
> prog = bpf_prog_add(prog, vi->max_queue_pairs - 1);
> - if (IS_ERR(prog)) {
> - virtnet_set_queues(vi, curr_qp);
> + if (IS_ERR(prog))
> return PTR_ERR(prog);
> - }
> + vi->headroom = VIRTIO_XDP_HEADROOM;
> + } else {
> + vi->headroom = 0;
> + }
> +
> + /* Changing the headroom in buffers is a disruptive operation because
> + * existing buffers must be flushed and reallocated. This will happen
> + * when a xdp program is initially added or xdp is disabled by removing
> + * the xdp program.
> + */
> + if (old_hr != vi->headroom) {
> + err = virtnet_xdp_reset(vi);
> + if (err)
> + goto err_reset;
> + }
> +
> + err = virtnet_set_queues(vi, curr_qp + xdp_qp);
> + if (err) {
> + dev_warn(&dev->dev, "XDP Device queue allocation failure.\n");
> + goto err_reset;
> }
>
> vi->xdp_queue_pairs = xdp_qp;
> @@ -1737,6 +1847,11 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> }
>
> return 0;
> +err_reset:
> + if (prog)
> + bpf_prog_sub(prog, vi->max_queue_pairs - 1);
> + vi->headroom = old_hr;
> + return err;
> }
>
> static bool virtnet_xdp_query(struct net_device *dev)
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index 7062bb0..0e922b9 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -145,14 +145,15 @@ void virtio_config_changed(struct virtio_device *dev)
> }
> EXPORT_SYMBOL_GPL(virtio_config_changed);
>
> -static void virtio_config_disable(struct virtio_device *dev)
> +void virtio_config_disable(struct virtio_device *dev)
> {
> spin_lock_irq(&dev->config_lock);
> dev->config_enabled = false;
> spin_unlock_irq(&dev->config_lock);
> }
> +EXPORT_SYMBOL_GPL(virtio_config_disable);
>
> -static void virtio_config_enable(struct virtio_device *dev)
> +void virtio_config_enable(struct virtio_device *dev)
> {
> spin_lock_irq(&dev->config_lock);
> dev->config_enabled = true;
> @@ -161,8 +162,9 @@ static void virtio_config_enable(struct virtio_device *dev)
> dev->config_change_pending = false;
> spin_unlock_irq(&dev->config_lock);
> }
> +EXPORT_SYMBOL_GPL(virtio_config_enable);
>
> -static int virtio_finalize_features(struct virtio_device *dev)
> +int virtio_finalize_features(struct virtio_device *dev)
> {
> int ret = dev->config->finalize_features(dev);
> unsigned status;
> @@ -182,6 +184,7 @@ static int virtio_finalize_features(struct virtio_device *dev)
> }
> return 0;
> }
> +EXPORT_SYMBOL_GPL(virtio_finalize_features);
>
> static int virtio_dev_probe(struct device *_d)
> {
> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> index d5eb547..eac8f05 100644
> --- a/include/linux/virtio.h
> +++ b/include/linux/virtio.h
> @@ -137,6 +137,9 @@ static inline struct virtio_device *dev_to_virtio(struct device *_dev)
>
> void virtio_break_device(struct virtio_device *dev);
>
> +void virtio_config_disable(struct virtio_device *dev);
> +void virtio_config_enable(struct virtio_device *dev);
> +int virtio_finalize_features(struct virtio_device *dev);
> void virtio_config_changed(struct virtio_device *dev);
> #ifdef CONFIG_PM_SLEEP
> int virtio_device_freeze(struct virtio_device *dev);
^ permalink raw reply
* Re: [RFC PATCH] tcp: accept RST for rcv_nxt - 1 after receiving a FIN
From: Jason Baron @ 2017-01-13 17:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1484149690.21472.53.camel@edumazet-glaptop3.roam.corp.google.com>
On 01/11/2017 10:48 AM, Eric Dumazet wrote:
> On Thu, 2017-01-05 at 16:33 -0500, Jason Baron wrote:
>
>>
>> +/* Accept RST for rcv_nxt - 1 after a FIN.
>> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
>> + * FIN is sent followed by a RST packet. The RST is sent with the same
>> + * sequence number as the FIN, and thus according to RFC 5961 a challenge
>> + * ACK should be sent. However, Mac OSX does not reply to the challenge ACK
>> + * with a RST on the closed socket, hence accept this class of RSTs.
>> + */
>> +static bool tcp_reset_check(struct sock *sk, struct sk_buff *skb)
> const struct sock *sk, const struct sk_buff *skb
>
>> +{
>> + struct tcp_sock *tp = tcp_sk(sk);
>> +
>> + return unlikely((TCP_SKB_CB(skb)->seq == (tp->rcv_nxt - 1)) &&
>> + (TCP_SKB_CB(skb)->end_seq == (tp->rcv_nxt - 1)) &&
> Why is the test on end_seq needed ?
Hi,
(Re-sending - seems like my reply was lost)
I wanted to define this condition as narrowly as I could. I'm ok
dropping it -
I'm not sure its going to make much difference in practice. So to that end,
dropping this extra check makes sense.
I posted this as RFC because RFC 5961, I don't think says anything about
accepting rcv_nxt - 1 in this case, so I was wondering what people
thought...
Thanks,
-Jason
>> + (sk->sk_state == TCP_CLOSE_WAIT ||
>> + sk->sk_state == TCP_LAST_ACK ||
>> + sk->sk_state == TCP_CLOSING));
>> +}
> Testing many states can be done more efficiently :
>
> (1 << sk->sk_state) & (TCPF_CLOSE_WAIT | TCPF_LAST_ACK |
> TCPF_CLOSING)
>
> Thanks
>
^ permalink raw reply
* Re: [net PATCH v3 2/5] net: virtio: wrap rtnl_lock in test for calling with lock already held
From: John Fastabend @ 2017-01-13 17:31 UTC (permalink / raw)
To: Stephen Hemminger
Cc: jasowang, mst, john.r.fastabend, netdev, alexei.starovoitov,
daniel
In-Reply-To: <20170113083408.202d6e30@xeon-e3>
On 17-01-13 08:34 AM, Stephen Hemminger wrote:
> On Thu, 12 Jan 2017 18:51:00 -0800
> John Fastabend <john.fastabend@gmail.com> wrote:
>
>>
>> -static void free_receive_bufs(struct virtnet_info *vi)
>> +static void free_receive_bufs(struct virtnet_info *vi, bool need_lock)
>> {
>> struct bpf_prog *old_prog;
>> int i;
>>
>> - rtnl_lock();
>> + if (need_lock)
>> + rtnl_lock();
>> for (i = 0; i < vi->max_queue_pairs; i++) {
>> while (vi->rq[i].pages)
>> __free_pages(get_a_page(&vi->rq[i], GFP_KERNEL), 0);
>> @@ -1879,7 +1880,8 @@ static void free_receive_bufs(struct virtnet_info *vi)
>> if (old_prog)
>> bpf_prog_put(old_prog);
>> }
>> - rtnl_unlock();
>> + if (need_lock)
>> + rtnl_unlock();
>> }
>
> Conditional locking is bad idea; sparse complains about it and is later source
> of bugs. The more typical way of doing this in kernel is:
OK I'll use the normal form.
>
> void _foo(some args)
> {
> ASSERT_RTNL();
>
> ...
> }
>
> void foo(some args)
> {
> rtnl_lock();
> _foo(some args)
> rtnl_unlock();
> }
>
>
^ permalink raw reply
* Re: [PATCH v2] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: David Miller @ 2017-01-13 17:31 UTC (permalink / raw)
To: shannon.nelson
Cc: netdev, sparclinux, linux-kernel, eric.dumazet, rob.gardner
In-Reply-To: <1484259898-30719-1-git-send-email-shannon.nelson@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Thu, 12 Jan 2017 14:24:58 -0800
> Fix up a data alignment issue on sparc by swapping the order
> of the cookie byte array field with the length field in
> struct tcp_fastopen_cookie, and making it a proper union
> to clean up the typecasting.
>
> This addresses log complaints like these:
> log_unaligned: 113 callbacks suppressed
> Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
> Kernel unaligned access at TPC[9764ac] tcp_try_fastopen+0x2ec/0x360
> Kernel unaligned access at TPC[9764c8] tcp_try_fastopen+0x308/0x360
> Kernel unaligned access at TPC[9764e4] tcp_try_fastopen+0x324/0x360
> Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
> ---
> v2: Use Eric's suggestion for a union in the struct
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: resend: tcp: performance issue with fastopen connections (mss > window)
From: Neal Cardwell @ 2017-01-13 17:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Kodanev, Eric Dumazet, David Miller, netdev,
Vasily Isaenko, Yuchung Cheng
In-Reply-To: <CANn89i+5m2uUBmHRHG32_oPyR53vQoG4SfOY6xWG_RNxPz6dZw@mail.gmail.com>
On Fri, Jan 13, 2017 at 12:14 PM, Eric Dumazet <edumazet@google.com> wrote:
>
> On Fri, Jan 13, 2017 at 9:07 AM, Alexey Kodanev
> <alexey.kodanev@oracle.com> wrote:
> > Hi Eric,
> > On 13.01.2017 18:35, Eric Dumazet wrote:
>
> >> Care to send a packetdrill test so that we have a clear picture of what
> >> is going on ?
> >
> > Is it capable of making two connections in the single test, one after
> > another?
>
> Absolutely.
>
> Neal, Yuchung would you be kind enough to send a Fastopen tpacketdrill
> template showing a typical fastopen test
> running on an upstream kernel ?
>
> Thanks !
Sure, here is an example packetdrill script, IIRC written by Yuchung,
which demonstrates TCP fast open and consecutive active connections:
`sysctl -q net.ipv4.tcp_timestamps=0`
// Cache warmup: send a Fast Open cookie request
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
+0 sendto(3, ..., 0, MSG_FASTOPEN, ..., ...) = -1 EINPROGRESS
(Operation is now in progress)
+0 > S 0:0(0) <mss 1460,nop,nop,sackOK,nop,wscale 8,FO,nop,nop>
+.010 < S. 123:123(0) ack 1 win 5840 <mss
1040,nop,nop,sackOK,nop,wscale 6,FO abcd1234,nop,nop>
+0 > . 1:1(0) ack 1
+0 close(3) = 0
+0 > F. 1:1(0) ack 1
+.010 < F. 1:1(0) ack 2 win 92
+0 > . 2:2(0) ack 2
//
// TEST1: Servers sends SYN-ACK with data and another two data packets
//
+0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4
+0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
+0 sendto(4, ..., 1000, MSG_FASTOPEN, ..., ...) = 1000
+0 > S 0:1000(1000) <mss 1460,nop,nop,sackOK,nop,wscale 8,FO
abcd1234,nop,nop>
+.010 < S. 1000000:1001400(1400) ack 1001 win 5840 <mss
1040,nop,nop,sackOK,nop,wscale 6>
+0 < . 1401:2801(1400) ack 1001 win 257
+0 < P. 2801:3001(200) ack 1001 win 257
neal
^ permalink raw reply
* Re: Setting link down or up in software
From: Mason @ 2017-01-13 17:35 UTC (permalink / raw)
To: Zefir Kurtisi, netdev
Cc: Mans Rullgard, Florian Fainelli, Andrew Lunn, Thibaud Cornic
In-Reply-To: <bfe5bd8b-d4eb-8c8e-45d8-6ea1c133b4a7@neratec.com>
On 13/01/2017 17:28, Zefir Kurtisi wrote:
> As for your specific problem: since I fought myself with the PHY/ETH subsystems
> over the past months, I might remember something relevant to your issue. Could you
> give some more info on your setup (PHY driver, opmode (SGMII, RGMII, etc.), ETH).
Hello Zefir,
My boards are using these drivers:
http://lxr.free-electrons.com/source/drivers/net/ethernet/aurora/nb8800.c
http://lxr.free-electrons.com/source/drivers/net/phy/at803x.c
The relevant device tree nodes are:
eth0: ethernet@26000 {
compatible = "sigma,smp8734-ethernet";
reg = <0x26000 0x800>;
interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clkgen SYS_CLK>;
};
ð0 {
phy-connection-type = "rgmii";
phy-handle = <ð0_phy>;
#address-cells = <1>;
#size-cells = <0>;
/* Atheros AR8035 */
eth0_phy: ethernet-phy@4 {
compatible = "ethernet-phy-id004d.d072",
"ethernet-phy-ieee802.3-c22";
interrupts = <37 IRQ_TYPE_EDGE_RISING>;
reg = <4>;
};
};
If I comment the PHY "interrupts" property, then the PHY framework
falls back to polling.
Am I forgetting important information?
Regards.
^ permalink raw reply
* Re: [PATCH net v3] ipv6: sr: fix several BUGs when preemption is enabled
From: David Miller @ 2017-01-13 17:30 UTC (permalink / raw)
To: david.lebrun; +Cc: netdev
In-Reply-To: <1484253001-29677-1-git-send-email-david.lebrun@uclouvain.be>
From: David Lebrun <david.lebrun@uclouvain.be>
Date: Thu, 12 Jan 2017 21:30:01 +0100
> When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
> seg6_hmac_init() is called during the initialization of the ipv6 module.
> This causes a subsequent call to smp_processor_id() with preemption
> enabled, resulting in the following trace.
...
> Moreover, dst_cache_* functions also call smp_processor_id(), generating
> a similar trace.
>
> This patch uses raw_cpu_ptr() in seg6_hmac_init() rather than this_cpu_ptr()
> and disable preemption when using dst_cache_* functions.
>
> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
Applied, thanks.
^ permalink raw reply
* Re: resend: tcp: performance issue with fastopen connections (mss > window)
From: Eric Dumazet @ 2017-01-13 17:41 UTC (permalink / raw)
To: Neal Cardwell
Cc: Eric Dumazet, Alexey Kodanev, David Miller, netdev,
Vasily Isaenko, Yuchung Cheng
In-Reply-To: <CADVnQykVj0CdHVYkfuogy6nOxfL+ODXue-3siKh_oACCBjVrtg@mail.gmail.com>
On Fri, 2017-01-13 at 12:32 -0500, Neal Cardwell wrote:
> On Fri, Jan 13, 2017 at 12:14 PM, Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Fri, Jan 13, 2017 at 9:07 AM, Alexey Kodanev
> > <alexey.kodanev@oracle.com> wrote:
> > > Hi Eric,
> > > On 13.01.2017 18:35, Eric Dumazet wrote:
> >
> > >> Care to send a packetdrill test so that we have a clear picture of what
> > >> is going on ?
> > >
> > > Is it capable of making two connections in the single test, one after
> > > another?
> >
> > Absolutely.
> >
> > Neal, Yuchung would you be kind enough to send a Fastopen tpacketdrill
> > template showing a typical fastopen test
> > running on an upstream kernel ?
> >
> > Thanks !
>
> Sure, here is an example packetdrill script, IIRC written by Yuchung,
> which demonstrates TCP fast open and consecutive active connections:
>
> `sysctl -q net.ipv4.tcp_timestamps=0`
>
> // Cache warmup: send a Fast Open cookie request
> 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> +0 sendto(3, ..., 0, MSG_FASTOPEN, ..., ...) = -1 EINPROGRESS
> (Operation is now in progress)
> +0 > S 0:0(0) <mss 1460,nop,nop,sackOK,nop,wscale 8,FO,nop,nop>
> +.010 < S. 123:123(0) ack 1 win 5840 <mss
> 1040,nop,nop,sackOK,nop,wscale 6,FO abcd1234,nop,nop>
> +0 > . 1:1(0) ack 1
> +0 close(3) = 0
> +0 > F. 1:1(0) ack 1
> +.010 < F. 1:1(0) ack 2 win 92
> +0 > . 2:2(0) ack 2
>
> //
> // TEST1: Servers sends SYN-ACK with data and another two data packets
> //
> +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4
> +0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> +0 sendto(4, ..., 1000, MSG_FASTOPEN, ..., ...) = 1000
> +0 > S 0:1000(1000) <mss 1460,nop,nop,sackOK,nop,wscale 8,FO
> abcd1234,nop,nop>
> +.010 < S. 1000000:1001400(1400) ack 1001 win 5840 <mss
> 1040,nop,nop,sackOK,nop,wscale 6>
> +0 < . 1401:2801(1400) ack 1001 win 257
> +0 < P. 2801:3001(200) ack 1001 win 257
>
> neal
Thanks Neal
Also worth adding that packetdrill has the following option to tune the
MTU on the tun device :
--mtu=xxxxx
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: bpf: implement in-register swap for 64-bit endian operations
From: 'Naveen N. Rao' @ 2017-01-13 17:52 UTC (permalink / raw)
To: David Laight
Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
netdev@vger.kernel.org, ast@fb.com, daniel@iogearbox.net,
davem@davemloft.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB02635FB@AcuExch.aculab.com>
On 2017/01/13 05:17PM, David Laight wrote:
> From: Naveen N. Rao
> > Sent: 13 January 2017 17:10
> > Generate instructions to perform the endian conversion using registers,
> > rather than generating two memory accesses.
> >
> > The "way easier and faster" comment was obviously for the author, not
> > the processor.
>
> That rather depends on whether the processor has a store to load forwarder
> that will satisfy the read from the store buffer.
> I don't know about ppc, but at least some x86 will do that.
Interesting - good to know that.
However, I don't think powerpc does that and in-register swap is likely
faster regardless. Note also that gcc prefers this form at higher
optimization levels.
Thanks,
Naveen
^ 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