Re: v6/sit tunnels and VRFs

Thanks for the response, David. I'm not questioning the need to stop the fib lookup once the end of the VRF table is reached - I agree that is needed. I'm concerned with the difference in the response/error returned from the failed lookup. For instance, with vrf "unreachable default" route, I

Re: v6/sit tunnels and VRFs

On 4/13/18 2:23 PM, Jeff Barnhill wrote: > It seems that the ENETUNREACH response is still desirable in the VRF > case since the only difference (when using VRF vs. not) is that the > lookup should be restrained to a specific VRF. VRF is just policy routing to a table. If the table wants the

Re: SRIOV switchdev mode BoF minutes

On Fri, Apr 13, 2018 at 7:49 PM, Samudrala, Sridhar wrote: > On 4/13/2018 1:57 AM, Or Gerlitz wrote: >>> in overlay networks scheme, the uplink rep has the VTEP ip and is not >>> connected >>> to the bridge, e.g you use ovs you have vf reps and vxlan ports

Re: [PATCH] x86/cpufeature: guard asm_volatile_goto usage with CC_HAVE_ASM_GOTO

On 4/13/18 11:19 AM, Peter Zijlstra wrote: On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote: Instead of #ifdef CC_HAVE_ASM_GOTO we can replace it with #ifndef __BPF__ or some other name, I would prefer the BPF specific hack; otherwise we might be encouraging people to build

Re: XDP performance regression due to CONFIG_RETPOLINE Spectre V2

On Thu, Apr 12, 2018 at 05:31:31PM +0200, Jesper Dangaard Brouer wrote: > > I guess that is because x86 selects it as the default as soon as > > we have more than 4G memory. > > I were also confused why I ended up using SWIOTLB (SoftWare IO-TLB), > that might explain it. And I'm not hitting the

Re: SRIOV switchdev mode BoF minutes

On 4/13/2018 1:57 AM, Or Gerlitz wrote: On Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz wrote: On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar wrote: On 4/12/2018 1:20 PM, Or Gerlitz wrote: On Thu, Apr 12, 2018 at 8:05 PM, Samudrala,

Panic since 4.15.15 in tcp_retransmit_timer when doing ss -K

I started getting this since 4.15.15. It's easy to trigger, for example I get new IP address via dhcp (NetworkManager), then ss -K the_old_ip_address . Happens on Ryzen and SandyBridge systems. My guess of the cause: commit 960058fe196397aecb16bb14e64980e265d2bc5e (didn't try reverting) BUG:

[PATCH iproute2-next 1/1] tc: jsonify ife action

Signed-off-by: Roman Mashak --- tc/m_ife.c | 54 -- 1 file changed, 32 insertions(+), 22 deletions(-) diff --git a/tc/m_ife.c b/tc/m_ife.c index d7e61703f666..15d09a167450 100644 --- a/tc/m_ife.c +++ b/tc/m_ife.c @@ -240,22

Re: [PATCH net-next 2/3] dt-bindings: net: ave: add syscon-phy-mode property to configure phy-mode setting

On Mon, Apr 09, 2018 at 03:38:44PM +0900, Kunihiko Hayashi wrote: > Add "socionext,syscon-phy-mode" property to specify system controller that > configures the settings about phy-mode. > > Signed-off-by: Kunihiko Hayashi > --- >

Re: [PATCH net] team: avoid adding twice the same option to the event list

From: Paolo Abeni Date: Fri, 13 Apr 2018 13:59:25 +0200 > When parsing the options provided by the user space, > team_nl_cmd_options_set() insert them in a temporary list to send > multiple events with a single message. > While each option's attribute is correctly validated,

[PATCH] PCI: Add PCIe to pcie_print_link_status() messages

Currently the pcie_print_link_status() will print PCIe bandwidth and link width information but does not mention it is pertaining to the PCIe. Since this and related functions are used exclusively by networking drivers today users may get confused into thinking that it's the NIC bandwidth that is

[PATCH v2 net 3/3] sfc: limit ARFS workitems in flight per channel

A misconfigured system (e.g. with all interrupts affinitised to all CPUs) may produce a storm of ARFS steering events. With the existing sfc ARFS implementation, that could create a backlog of workitems that grinds the system to a halt. To prevent this, limit the number of workitems that may

[PATCH v2 net 2/3] sfc: pass the correctly bogus filter_id to rps_may_expire_flow()

When we inserted an ARFS filter for ndo_rx_flow_steer(), we didn't know what the filter ID would be, so we just returned 0. Thus, we must also pass 0 as the filter ID when calling rps_may_expire_flow() for it, and rely on the flow_id to identify what we're talking about. Fixes: 3af0f34290f6

[PATCH v2 net 1/3] sfc: insert ARFS filters with replace_equal=true

Necessary to allow redirecting a flow when the application moves. Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations") Signed-off-by: Edward Cree --- drivers/net/ethernet/sfc/rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: XDP performance regression due to CONFIG_RETPOLINE Spectre V2

On 04/12/2018 07:56 AM, Christoph Hellwig wrote: On Thu, Apr 12, 2018 at 04:51:23PM +0200, Christoph Hellwig wrote: On Thu, Apr 12, 2018 at 03:50:29PM +0200, Jesper Dangaard Brouer wrote: --- Implement support for keeping the DMA mapping through the XDP return call, to remove RX

Re: [RFC bpf-next v2 4/8] bpf: add documentation for eBPF helpers (23-32)

2018-04-12 17:28 UTC-0700 ~ Alexei Starovoitov > On Tue, Apr 10, 2018 at 03:41:53PM +0100, Quentin Monnet wrote: >> Add documentation for eBPF helper functions to bpf.h user header file. >> This documentation can be parsed with the Python script provided in >>

[PATCH iproute2] utils: Do not reset family for default, any, all addresses

Thomas reported a change in behavior with respect to autodectecting address families. Specifically, 'ip ro add default via fe80::1' syntax was failing to treat fe80::1 as an IPv6 address as it did in prior releases. The root causes appears to be a change in family when the default keyword is

[PATCH v2 net 0/3] sfc: ARFS fixes

Three issues introduced by my recent asynchronous filter handling changes: 1. The old filter_rfs_insert would replace a matching filter of equal priority; we need to pass the appropriate argument to filter_insert to make it do the same. 2. We're lying to the kernel with our return value from

[next-queue PATCH 1/1] ixgbe: cleanup sparse warnings

From: Cathy Zhou Sparse complains valid conversions between restricted types, force attribute is used to avoid those warnings. Signed-off-by: Cathy Zhou Reviewed-by: Shannon Nelson ---

Creating FOU tunnels to the same destination IP but different port

Hello, I am having trouble with a particular case of setting up a fou tunnel and I would really appreciate your help. I have a remote multihomed host behind a NAT box and I want to create a fou tunnel for each of its IP addresses, from my machine. A typical case would be something like that

Re: tcp hang when socket fills up ?

On Fri, Apr 06, 2018 at 11:07:20AM +0200, Dominique Martinet wrote: > 16:49:26.735042 IP .13317 > .31872: Flags > [.], seq 70476:71850, ack 4190, win 307, options [nop,nop,TS val 1313937641 > ecr 1617129473], length 1374 > 16:49:26.735046 IP .13317 > .31872: Flags > [.], seq 71850:73224, ack

ethtool 4.16 released

ethtool version 4.16 has been released. Home page: https://www.kernel.org/pub/software/network/ethtool/ Download link: https://www.kernel.org/pub/software/network/ethtool/ethtool-4.16.tar.xz Release notes: * Feature: add support for extra RSS contexts and RSS steering filters *

Re: XDP performance regression due to CONFIG_RETPOLINE Spectre V2

On Fri, Apr 13, 2018 at 10:12:41AM -0700, Tushar Dave wrote: > I guess there is nothing we need to do! > > On x86, in case of no intel iommu or iommu is disabled, you end up in > swiotlb for DMA API calls when system has 4G memory. > However, AFAICT, for 64bit DMA capable devices swiotlb DMA APIs

Re: [PATCH net-next 1/3] net: ethernet: ave: add multiple clocks and resets support as required property

On Mon, Apr 09, 2018 at 03:38:43PM +0900, Kunihiko Hayashi wrote: > When the link is becoming up for Pro4 SoC, the kernel is stalled > due to some missing clocks and resets. > > The AVE block for Pro4 is connected to the GIO bus in the SoC. > Without its clock/reset, the access to the AVE

Re: Crash due to NULL dereference in tcp_rearm_rto

On 04/13/2018 05:39 PM, Subash Abhinov Kasiviswanathan wrote: > We are seeing a warning followed by a crash on an ARM64 device with > Android 4.14 based kernel. > > It looks like both sk->sk_write_queue and sk->sk_send_head are NULL. > Since the sk->sk_write_queue is NULL and is dereferenced in

Re: tcp hang when socket fills up ?

On 04/13/2018 06:09 PM, Dominique Martinet wrote: > Thank you for the replies, > > Eric Dumazet wrote on Fri, Apr 13, 2018: >> There is no way a regular TCP stack (including linux) could send the >> following frame. >> >>> 16:49:27.048760 IP .13317 > .31872: >>> Flags [.], seq 32004:33378,

Re: tcp hang when socket fills up ?

Eric Dumazet wrote on Fri, Apr 13, 2018: > Ah sorry, your trace was truncated, we need more packets _before_ the excerpt. Ah, sorry as well. I tried to go far back enough to include the replayed packets, but I see it didn't include the original ack for that packet. I'm resending both full traces

RE: [Intel-wired-lan] [next-queue PATCH v7 06/10] igb: Allow filters to be added for the local MAC address

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com> > Subject: [Intel-wired-lan]

RE: [Intel-wired-lan] [next-queue PATCH v7 05/10] igb: Add support for enabling queue steering in filters

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com> > Subject: [Intel-wired-lan]

Re: Creating FOU tunnels to the same destination IP but different port

On Fri, Apr 13, 2018 at 9:57 AM, Kostas Peletidis wrote: > Hello, > > I am having trouble with a particular case of setting up a fou tunnel > and I would really appreciate your help. > > I have a remote multihomed host behind a NAT box and I want to create > a fou tunnel for

Re: tcp hang when socket fills up ?

Thank you for the replies, Eric Dumazet wrote on Fri, Apr 13, 2018: > There is no way a regular TCP stack (including linux) could send the > following frame. > > > 16:49:27.048760 IP .13317 > .31872: > > Flags [.], seq 32004:33378, ack 4190, win 307, options [nop,nop,TS val > > 1313937955 ecr

RE: [next-queue PATCH v7 07/10] igb: Enable nfc filters to specify MAC addresses

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: Gomes, Vinicius ; Kirsher, Jeffrey T > ;

RE: [next-queue PATCH v7 08/10] igb: Add MAC address support for ethtool nftuple filters

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: Gomes, Vinicius ; Kirsher, Jeffrey T > ;

RE: [Intel-wired-lan] [next-queue PATCH v7 09/10] igb: Add the skeletons for tc-flower offloading

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com> > Subject: [Intel-wired-lan]

RE: [Intel-wired-lan] [next-queue PATCH v7 02/10] igb: Fix queue selection on MAC filters on i210

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com> > Subject: [Intel-wired-lan]

RE: [next-queue PATCH v7 04/10] igb: Add support for MAC address filters specifying source addresses

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: Gomes, Vinicius ; Kirsher, Jeffrey T > ;

RE: [next-queue PATCH v7 01/10] igb: Fix not adding filter elements to the list

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: Gomes, Vinicius ; Kirsher, Jeffrey T > ;

RE: [Intel-wired-lan] [next-queue PATCH v7 03/10] igb: Enable the hardware traffic class feature bit for igb models

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com> > Subject: [Intel-wired-lan]

RE: [next-queue PATCH v7 10/10] igb: Add support for adding offloaded clsflower filters

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes > Sent: Tuesday, April 10, 2018 10:50 AM > To: intel-wired-...@lists.osuosl.org > Cc: Gomes, Vinicius ; Kirsher, Jeffrey T > ;

RE: [next-queue PATCH] igb: Fix the transmission mode of queue 0 for Qav mode

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes > Sent: Friday, March 30, 2018 5:07 PM > To: intel-wired-...@lists.osuosl.org > Cc: Gomes, Vinicius ; Kirsher, Jeffrey T > ;

RE: [Resend Patch 2/3] Netvsc: Use the vmbus functiton to calculate ring buffer percentage

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > On Behalf > Of Long Li > Sent: Tuesday, March 27, 2018 5:49 PM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen > Hemminger

RE: [Resend Patch 3/3] Storvsc: Select channel based on available percentage of ring buffer to write

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > On Behalf > Of Long Li > Sent: Tuesday, March 27, 2018 5:49 PM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen > Hemminger

Re: [PATCH iproute2-next 3/3] treewide: Use addattr_nest()/addattr_nest_end() to handle nested attributes

Hi, Serhey Popovych writes: [...] > diff --git a/tc/q_mqprio.c b/tc/q_mqprio.c > index 89b4600..207d644 100644 > --- a/tc/q_mqprio.c > +++ b/tc/q_mqprio.c > @@ -173,8 +173,7 @@ static int mqprio_parse_opt(struct qdisc_util *qu, int > argc, > argc--;

RE: [Resend Patch 3/3] Storvsc: Select channel based on available percentage of ring buffer to write

> Subject: RE: [Resend Patch 3/3] Storvsc: Select channel based on available > percentage of ring buffer to write > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org > > On Behalf Of Long Li > > Sent: Tuesday, March 27, 2018 5:49 PM >

Cavium Octeon III network driver.

Patches for Cavium's Octeon III network driver were submitted by David Daney back on 20180222. David has since left the company and I am now responsible for the upstreaming effort. When looking at they are marked as "Not Applicable". What steps do I take next? Thanks. Steve

Re: SRIOV switchdev mode BoF minutes

On 4/13/2018 1:16 PM, Or Gerlitz wrote: On Fri, Apr 13, 2018 at 7:49 PM, Samudrala, Sridhar wrote: On 4/13/2018 1:57 AM, Or Gerlitz wrote: in overlay networks scheme, the uplink rep has the VTEP ip and is not connected to the bridge, e.g you use ovs you have vf

Crash due to NULL dereference in tcp_rearm_rto

We are seeing a warning followed by a crash on an ARM64 device with Android 4.14 based kernel. It looks like both sk->sk_write_queue and sk->sk_send_head are NULL. Since the sk->sk_write_queue is NULL and is dereferenced in tcp_rto_delta_us() to get the skb->skb_mstamp, there is crash

Re: INFO: task hung in do_ip_vs_set_ctl (2)

syzbot has found reproducer for the following crash on net-next commit 17dec0a949153d9ac00760ba2f5b78cb583e995f (Wed Apr 4 02:15:32 2018 +) Merge branch 'userns-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace syzbot dashboard link:

Re: KMSAN: uninit-value in netif_skb_features

On 2018/04/12 17:03, Dmitry Vyukov wrote: > On Thu, Apr 12, 2018 at 10:01 AM, syzbot > wrote: >> Hello, >> >> syzbot hit the following crash on https://github.com/google/kmsan.git/master >> commit >> e2ab7e8abba47a2f2698216258e5d8727ae58717

[PATCH] net: stmmac: fix missing support for 802.1AD tag on reception

stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before calling napi_gro_receive(). The function assumes VLAN tagged frames are always tagged with 802.1Q protocol, and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call to __vlan_hwaccel_put_tag() . This causes

Re: [RFC v2] virtio: support packed ring

On Fri, Apr 13, 2018 at 12:30:24PM +0800, Jason Wang wrote: > On 2018年04月01日 22:12, Tiwei Bie wrote: > > Hello everyone, > > > > This RFC implements packed ring support for virtio driver. > > > > The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented > > by Jens at

Re: KMSAN: uninit-value in __netif_receive_skb_core

On Fri, Apr 13, 2018 at 10:20 AM, Toshiaki Makita wrote: > On 2018/04/12 17:03, Dmitry Vyukov wrote: >> On Thu, Apr 12, 2018 at 10:01 AM, syzbot >> wrote: >>> Hello, >>> >>> syzbot hit the following crash on

Re: [PATCH 3/5] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from device

/commits/Icenowy-Zheng/Add-support-in-dwmac-sun8i-for-accessing-EMAC-clock/20180413-004816 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse

[PATCH] net: stmmac: fix missing support for 802.1AD tag on reception

stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before calling napi_gro_receive(). The function assumes VLAN tagged frames are always tagged with 802.1Q protocol, and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call to __vlan_hwaccel_put_tag() . This

Re: KMSAN: uninit-value in __netif_receive_skb_core

On 2018/04/12 17:03, Dmitry Vyukov wrote: > On Thu, Apr 12, 2018 at 10:01 AM, syzbot > wrote: >> Hello, >> >> syzbot hit the following crash on https://github.com/google/kmsan.git/master >> commit >> e2ab7e8abba47a2f2698216258e5d8727ae58717

[RFC PATCH] net: stmmac: dwmac-sun8i: single_reg_field can be static

Fixes: 529123418105 ("net: stmmac: dwmac-sun8i: Allow getting syscon regmap from device") Signed-off-by: Fengguang Wu --- dwmac-sun8i.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c

[PATCH net] virtio-net: add missing virtqueue kick when flushing packets

We tends to batch submitting packets during XDP_TX. This requires to kick virtqueue after a batch, we tried to do it through xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So explicitly kick the virtqueue in this case. Reported-by: Kimitoshi Takahashi

[PATCH v2] selftests: add headers_install to lib.mk

If the kernel headers aren't installed we can't build all the tests. Add a new make target rule 'khdr' in the file lib.mk to generate the kernel headers and that gets include for every test-dir Makefile that includes lib.mk If the testdir in turn have its own sub-dirs the top_srcdir needs to be

Re: SRIOV switchdev mode BoF minutes

On Fri, Apr 13, 2018 at 11:56 AM, Or Gerlitz wrote: > On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar > wrote: >> On 4/12/2018 1:20 PM, Or Gerlitz wrote: >>> >>> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar >>>

Re: [net] xfrm: cover crypto status in xfrm_input

On Thu, Apr 12, 2018 at 12:03:15PM -0700, Jacek Kalwas wrote: > Status checking in xfrm_input doesn't cover CRYPTO_GENERIC_ERROR and > CRYPTO_INVALID_PACKET_SYNTAX. > > Given patch adds additional check for CRYPTO_INVALID_PACKET_SYNTAX and > treats CRYPTO_GENERIC_ERROR as status matching

Re: SRIOV switchdev mode BoF minutes

On Thu, Apr 12, 2018 at 11:33 PM, Samudrala, Sridhar wrote: > On 4/12/2018 1:20 PM, Or Gerlitz wrote: >> >> On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar >> wrote: >>> >>> On 11/12/2017 11:49 AM, Or Gerlitz wrote: Hi Dave

Re: tcp hang when socket fills up ?

Note this is mostly me talking to myself, but in case anyone else hits the same issues I might as well post my meagre progress. Dominique Martinet wrote on Fri, Apr 06, 2018: > (current kernel: vanilla 4.14.29) reproduced in a fedora VM on that host with a 4.16.1-300.fc28.x86_64 kernel, since

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

From: Edward Cree Date: Fri, 13 Apr 2018 15:52:25 +0100 > On 13/04/18 15:45, David Miller wrote: >> I understand the constraints you are working under, but do realize >> that the real root of the problems is that you are implementing what >> is defined clearly as a

Re: Build error for samples/bpf/ due to commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")

On Fri, Apr 13, 2018 at 03:22:37PM +0200, Jesper Dangaard Brouer wrote: > Hi Peter, > > Your commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS") broke build > for several samples/bpf programs. I'm unsure what the best way forward > is to unbreak these... > > The issue is that these samples

Re: [RFC v2] virtio: support packed ring

On Sun, Apr 01, 2018 at 10:12:16PM +0800, Tiwei Bie wrote: > +static inline bool more_used(const struct vring_virtqueue *vq) > +{ > + return vq->packed ? more_used_packed(vq) : more_used_split(vq); > +} > + > +void *virtqueue_get_buf_ctx_split(struct virtqueue *_vq, unsigned int *len, > +

Re: [PATCH net] virtio-net: add missing virtqueue kick when flushing packets

From: Jason Wang Date: Fri, 13 Apr 2018 14:58:25 +0800 > We tends to batch submitting packets during XDP_TX. This requires to > kick virtqueue after a batch, we tried to do it through > xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So > explicitly kick the

RE: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Friday, April 13, 2018 7:07 AM > To: Jakub Kicinski > Cc: Tal Gilboa ; Tariq Toukan ; > Keller, Jacob E ; Ariel Elior >

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

It turns out this may all be moot anyway: I figured out why I was seeing  ARFS storms and it wasn't the configuration issue I originally blamed. My current ndo_rx_flow_steer() implementation, efx_filter_rfs(), returns  0 for success, but the caller expects a filter ID to be returned (which  we

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote: > On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala > wrote: >> On 20.02.2018 18:26, Neil Horman wrote: >>> >>> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote: On Tue, Feb

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Thu, Apr 12, 2018 at 02:15:30PM +0200, Dmitry Vyukov wrote: > On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala > wrote: > > On 20.02.2018 18:26, Neil Horman wrote: > >> > >> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote: > >>> > >>> On Tue, Feb 20, 2018

[PATCH net] team: avoid adding twice the same option to the event list

When parsing the options provided by the user space, team_nl_cmd_options_set() insert them in a temporary list to send multiple events with a single message. While each option's attribute is correctly validated, the code does not check for duplicate entries before inserting into the event list.

Atlantic driver 4.16 stable request

Hi David, Could you please consider queuing to v4.16: 9a11aff net: aquantia: oops when shutdown on already stopped device cce96d1 net: aquantia: Regression on reset with 1.x firmware These are both critical and well tested by our team. Thanks in advance!

Re: Atlantic driver 4.16 stable request

From: Igor Russkikh Date: Fri, 13 Apr 2018 15:03:29 +0300 > Could you please consider queuing to v4.16: > > 9a11aff net: aquantia: oops when shutdown on already stopped device > cce96d1 net: aquantia: Regression on reset with 1.x firmware > > These are both critical

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

From: Edward Cree Date: Fri, 13 Apr 2018 13:36:28 +0100 > It turns out this may all be moot anyway: I figured out why I was seeing >  ARFS storms and it wasn't the configuration issue I originally blamed. > My current ndo_rx_flow_steer() implementation, efx_filter_rfs(),

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

On 13/04/18 13:36, Edward Cree wrote: > It turns out this may all be moot anyway: I figured out why I was seeing >  ARFS storms and it wasn't the configuration issue I originally blamed. Hmm, correction, while the fix I mentioned in my previous email is needed,  it doesn't prevent the ARFS storms

Re: [PATCH] netfilter: fix CONFIG_NF_REJECT_IPV6=m link error

On Fri, Apr 13, 2018 at 3:15 PM, Pablo Neira Ayuso wrote: > On Mon, Apr 09, 2018 at 04:43:40PM +0200, Arnd Bergmann wrote: >> On Mon, Apr 9, 2018 at 4:37 PM, Pablo Neira Ayuso >> wrote: >> > Hi Arnd, >> > >> > On Mon, Apr 09, 2018 at 12:53:12PM +0200,

Re: [PATCH net 1/3] l2tp: hold reference on tunnels in netlink dumps

From: Guillaume Nault Date: Thu, 12 Apr 2018 20:50:33 +0200 > l2tp_tunnel_find_nth() is unsafe: no reference is held on the returned > tunnel, therefore it can be freed whenever the caller uses it. > This patch defines l2tp_tunnel_get_nth() which works similarly, but > also

Re: tcp hang when socket fills up ?

On 04/06/2018 02:07 AM, Dominique Martinet wrote: > (current kernel: vanilla 4.14.29) > > I've been running into troubles recently where a sockets "fills up" (as > in, select() will no longer return it in its outfd / attempting to write > to it after setting it to NONBLOCK will return

Build error for samples/bpf/ due to commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")

Hi Peter, Your commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS") broke build for several samples/bpf programs. I'm unsure what the best way forward is to unbreak these... The issue is that these samples are build with LLVM/clang (which doesn't like 'asm goto' constructs). And they end up

Re: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited

On Thu, Apr 12, 2018 at 09:32:49PM -0700, Jakub Kicinski wrote: > On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote: > > + if (bw_avail >= bw_cap) > > + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n", > > +bw_cap, PCIE_SPEED2STR(speed_cap),

Re: [PATCH] netfilter: fix CONFIG_NF_REJECT_IPV6=m link error

On Mon, Apr 09, 2018 at 04:43:40PM +0200, Arnd Bergmann wrote: > On Mon, Apr 9, 2018 at 4:37 PM, Pablo Neira Ayuso wrote: > > Hi Arnd, > > > > On Mon, Apr 09, 2018 at 12:53:12PM +0200, Arnd Bergmann wrote: > >> We get a new link error with CONFIG_NFT_REJECT_INET=y and > >>

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Fri, Apr 13, 2018 at 2:43 PM, Dan Streetman wrote: > On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote: >> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala >> wrote: >>> On 20.02.2018 18:26, Neil Horman wrote: On

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

On 13/04/18 16:03, David Miller wrote: > Whilst you may not be able to program the filter into the hardware > synchronously, you should be able to allocate the ID and get all of > the software state setup. That's what we were doing before commit 3af0f34290f6 ("sfc: replace  asynchronous filter

Re: [PATCH net 1/3] l2tp: hold reference on tunnels in netlink dumps

On Fri, Apr 13, 2018 at 10:57:03AM -0400, David Miller wrote: > From: Guillaume Nault > Date: Thu, 12 Apr 2018 20:50:33 +0200 > > > l2tp_tunnel_find_nth() is unsafe: no reference is held on the returned > > tunnel, therefore it can be freed whenever the caller uses it. > >

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

From: Edward Cree Date: Fri, 13 Apr 2018 16:59:07 +0100 > On 13/04/18 16:03, David Miller wrote: >> Whilst you may not be able to program the filter into the hardware >> synchronously, you should be able to allocate the ID and get all of >> the software state setup. >

Re: [PATCH net 1/3] l2tp: hold reference on tunnels in netlink dumps

From: Guillaume Nault Date: Fri, 13 Apr 2018 18:09:12 +0200 > On Fri, Apr 13, 2018 at 10:57:03AM -0400, David Miller wrote: >> From: Guillaume Nault >> Date: Thu, 12 Apr 2018 20:50:33 +0200 >> >> > l2tp_tunnel_find_nth() is unsafe: no reference is

Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel

On 13/04/18 17:14, David Miller wrote: > Is the issue that you learn about the hardware reset asynchronously, > and therefore cannot determine if filter insertion programming > happened afterwards and thus is still in the chip? Yes, pretty much. > You must have a table of all the entries, so that