Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice

(put discussions back on list which got accidentally removed) On Tue, Apr 3, 2018 at 4:08 PM, Stephen Hemminger wrote: > On Tue, 3 Apr 2018 12:04:38 -0700 > Siwei Liu wrote: > >> On Tue, Apr 3, 2018 at 10:35 AM, Stephen Hemminger >>

kernel BUG at drivers/vhost/vhost.c:LINE! (2)

Hello, syzbot hit the following crash on upstream commit 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +) Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc syzbot dashboard link:

Re: [PATCH net 2/2] net: systemport: Fix sparse warnings in bcm_sysport_insert_tsb()

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 80105befdb4b net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver. The bot has also determined it's probably a bug fixing patch. (score: 50.4075) The bot has tested the

Re: [PATCH net-next 6/6] netdevsim: Add simple FIB resource controller via devlink

On 4/5/18 11:52 PM, Jiri Pirko wrote: > Thu, Apr 05, 2018 at 11:06:41PM CEST, d...@cumulusnetworks.com wrote: >> On 4/5/18 2:10 PM, David Ahern wrote: >>> >>> The ASIC here is the kernel tables in a namespace. It does not make >>> sense to have 2 devlink instances for a single namespace. >> >> I

Re: [PATCH iproute2-next v1] rdma: Print net device name and index for RDMA device

On 4/2/18 10:29 PM, Leon Romanovsky wrote: > From: Leon Romanovsky > > The RDMA devices are operated in RoCE and iWARP modes have net device > underneath. Present their names in regular output and their net index > in detailed mode. > > [root@nps ~]# rdma link show mlx5_3/1

[PATCH v4] net: thunderx: rework mac addresses list to u64 array

From: Vadim Lomovtsev It is too expensive to pass u64 values via linked list, instead allocate array for them by overall number of mac addresses from netdev. This eventually removes multiple kmalloc() calls, aviod memory fragmentation and allow to put single null

Re: [PATCH net] net: dsa: b53: Fix sparse warnings in b53_mmap.c

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 967dd82ffc52 net: dsa: b53: Add support for Broadcom RoboSwitch. The bot has also determined it's probably a bug fixing patch. (score: 8.8847) The bot has tested the following

Re: [PATCH net v6 4/4] ipv6: udp: set dst cache for a connected sk if current not valid

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 33c162a980fe ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update. The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92. v4.16:

Re: [PATCH net 1/2] net: bcmgenet: Fix sparse warnings in bcmgenet_put_tx_csum()

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 1c1008c793fa net: bcmgenet: add main driver file. The bot has also determined it's probably a bug fixing patch. (score: 49.2621) The bot has tested the following trees: v4.16,

[RFC PATCH bpf-next 5/6] samples/bpf: add a test for bpf_get_stack helper

The test attached a kprobe program to kernel function sys_write. It tested to get stack for user space, kernel space and user space with build_id request. It also tested to get user and kernel stack into the same buffer with back-to-back bpf_get_stack helper calls. Whenever the kernel stack is

[RFC PATCH bpf-next 3/6] tools/bpf: add bpf_get_stack helper to tools headers

Signed-off-by: Yonghong Song --- tools/include/uapi/linux/bpf.h| 17 +++-- tools/testing/selftests/bpf/bpf_helpers.h | 2 ++ 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index

[RFC PATCH bpf-next 2/6] bpf: add bpf_get_stack helper

Currently, stackmap and bpf_get_stackid helper are provided for bpf program to get the stack trace. This approach has a limitation though. If two stack traces have the same hash, only one will get stored in the stackmap table, so some stack traces are missing from user perspective. This patch

[RFC PATCH bpf-next 0/6] bpf: add bpf_get_stack_helper

Currently, stackmap and bpf_get_stackid helper are provided for bpf program to get the stack trace. This approach has a limitation though. If two stack traces have the same hash, only one will get stored in the stackmap table, so some stack traces are missing from user perspective. This patch

[RFC PATCH bpf-next 6/6] tools/bpf: add a test case for bpf_get_stack helper

The test_stacktrace_map is enhanced to call bpf_get_stack in the helper to get the stack trace as well. The stack traces from bpf_get_stack and bpf_get_stackid are compared to ensure that for the same stack as represented as the same hash, their ip addresses must be the same. Signed-off-by:

[RFC PATCH bpf-next 1/6] bpf: change prototype for stack_map_get_build_id_offset

This patch didn't incur functionality change. The function prototype got changed so that the same function can be reused later. Signed-off-by: Yonghong Song --- kernel/bpf/stackmap.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git

[RFC PATCH bpf-next 4/6] samples/bpf: move common-purpose perf_event functions to bpf_load.c

There is no functionality change in this patch. The common-purpose perf_event functions are moved from trace_output_user.c to bpf_load.c so that these function can be reused later. Signed-off-by: Yonghong Song --- samples/bpf/bpf_load.c | 104

Re: [RFC PATCH net-next v5 2/4] net: Introduce generic bypass module

On 4/6/2018 5:57 AM, Jiri Pirko wrote: Thu, Apr 05, 2018 at 11:08:21PM CEST, sridhar.samudr...@intel.com wrote: This provides a generic interface for paravirtual drivers to listen for netdev register/unregister/link change events from pci ethernet devices with the same MAC and takeover their

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

> From: Gomes, Vinicius > Sent: Thursday, April 5, 2018 11:00 AM > To: Brown, Aaron F ; intel-wired- > l...@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com> > Subject: RE: [Intel-wired-lan] [next-queue PATCH v6 08/10] igb: Add MAC

Re: [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF datapath when available

On 4/6/2018 5:48 AM, Jiri Pirko wrote: Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@intel.com wrote: + +static void virtnet_bypass_set_rx_mode(struct net_device *dev) +{ + struct virtnet_bypass_info *vbi = netdev_priv(dev); + struct net_device *child_netdev;

[Patch net] net_sched: fix a missing idr_remove() in u32_delete_key()

When we delete a u32 key via u32_delete_key(), we forget to call idr_remove() to remove its handle from IDR. Fixes: e7614370d6f0 ("net_sched: use idr to allocate u32 filter handles") Reported-by: Marcin Kabiesz Cc: Linus Torvalds Cc: Jamal

Fwd: Problem with the kernel 4.15 - cutting the band (tc)

Forwarding a report about what looks like a regression between 4.14 and 4.15. New ENOSPC issue? I don't even knew where to start guessing where to look. Help me, Davem-Wan Kenobi, you are my only hope. (But adding netdev just in case somebody else goes "That's obviously Xyz")

Re: Problem with the kernel 4.15 - cutting the band (tc)

On Fri, Apr 6, 2018 at 2:56 PM, Linus Torvalds wrote: > Forwarding a report about what looks like a regression between 4.14 and 4.15. > > New ENOSPC issue? I don't even knew where to start guessing where to look. > > Help me, Davem-Wan Kenobi, you are my only hope.

RE: [Intel-wired-lan] [next-queue PATCH v6 10/10] igb: Add support for adding offloaded clsflower filters

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Vinicius Costa Gomes > Sent: Thursday, March 29, 2018 2:08 PM > To: intel-wired-...@lists.osuosl.org > Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus palen...@intel.com> > Subject: [Intel-wired-lan]

Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice

On Wed, Apr 4, 2018 at 10:37 AM, David Miller wrote: > From: David Ahern > Date: Wed, 4 Apr 2018 11:21:54 -0600 > >> It is a netdev so there is no reason to have a separate ip command to >> inspect it. 'ip link' is the right place. > > I agree on this.

[PATCH net 3/5] ibmvnic: Fix reset scheduler error handling

In some cases, if the driver is waiting for a reset following a device parameter change, failure to schedule a reset can result in a hang since a completion signal is never sent. If the device configuration is being altered by a tool such as ethtool or ifconfig, it could cause the console to hang

[PATCH net 5/5] ibmvnic: Do not reset CRQ for Mobility driver resets

From: Nathan Fontenot When resetting the ibmvnic driver after a partition migration occurs there is no requirement to do a reset of the main CRQ. The current driver code does the required re-enable of the main CRQ, then does a reset of the main CRQ later. What we

[PATCH net 4/5] ibmvnic: Fix failover case for non-redundant configuration

There is a failover case for a non-redundant pseries VNIC configuration that was not being handled properly. The current implementation assumes that the driver will always have a redandant device to communicate with following a failover notification. There are cases, however, when a non-redundant

[PATCH net 2/5] ibmvnic: Zero used TX descriptor counter on reset

The counter that tracks used TX descriptors pending completion needs to be zeroed as part of a device reset. This change fixes a bug causing transmit queues to be stopped unnecessarily and in some cases a transmit queue stall and timeout reset. If the counter is not reset, the remaining

[PATCH net 0/5] ibmvnic: Fix driver reset and DMA bugs

This patch series introduces some fixes to the driver reset routines and a patch that fixes mistakes caught by the kernel DMA debugger. The reset fixes include a fix to reset TX queue counters properly after a reset as well as updates to driver reset error-handling code. It also provides updates

[PATCH net 1/5] ibmvnic: Fix DMA mapping mistakes

Fix some mistakes caught by the DMA debugger. The first change fixes a unnecessary unmap that should have been removed in an earlier update. The next hunk fixes another bad unmap by zeroing the bit checked to determine that an unmap is needed. The final change fixes some buffers that are unmapped

[Patch net] tipc: use the right skb in tipc_sk_fill_sock_diag()

Commit 4b2e6877b879 ("tipc: Fix namespace violation in tipc_sk_fill_sock_diag") tried to fix the crash but failed, the crash is still 100% reproducible with it. In tipc_sk_fill_sock_diag(), skb is the diag dump we are filling, it is not correct to retrieve its NETLINK_CB(), instead, like other

Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice

Hi Siwei > I think everyone seems to agree not to fiddle with the ":" prefix, but > rather have a new class of network subsystem under /sys/class thus a > separate device namespace e.g. /sys/class/net-kernel for those > auto-managed lower netdevs is needed. How do you get a device into this new

Re: [virtio-dev] Re: [RFC PATCH 1/3] qemu: virtio-bypass should explicitly bind to a passthrough device

(click the wrong reply button again, sorry) On Thu, Apr 5, 2018 at 8:31 AM, Paolo Bonzini wrote: > On 04/04/2018 10:02, Siwei Liu wrote: >>> pci_bus_num is almost always a bug if not done within >>> a context of a PCI host, bridge, etc. >>> >>> In particular this will not

[PATCH 6/8] ipconfig: Correctly initialise ic_nameservers

ic_nameservers, which stores the list of name servers discovered by ipconfig, is initialised (i.e. has all of its elements set to NONE, or 0x) by ic_nameservers_predef() in the following scenarios: - before the "ip=" and "nfsaddrs=" kernel command line parameters are parsed (in

[PATCH 7/8] ipconfig: Write NTP server IPs to /proc/net/ntp

Distributed filesystems are most effective when the server and client clocks are synchronised. Embedded devices often use NFS for their root filesystem but typically do not contain an RTC, so the clocks of the NFS server and the embedded device will be out-of-sync when the root filesystem is

[PATCH 8/8] CREDITS: Add Chris Novakovic

Signed-off-by: Chris Novakovic --- CREDITS | 4 1 file changed, 4 insertions(+) diff --git a/CREDITS b/CREDITS index 989cda91c427..5a13bf62c569 100644 --- a/CREDITS +++ b/CREDITS @@ -2765,6 +2765,10 @@ E: nor...@nocrew.org W: http://www.lysator.liu.se/~noring/ D:

[PATCH 0/8] ipconfig: NTP server support, bug fixes, documentation improvements

This series (against net-next) makes various improvements to ipconfig: - Patch #1 correctly documents the behaviour of parameter 4 in the "ip=" and "nfsaddrs=" command line parameter. - Patch #2 tidies up the printk()s for reporting configured name servers. - Patch #3 fixes a bug in

[PATCH 5/8] ipconfig: Document /proc/net/pnp

Fully document the format used by the /proc/net/pnp file written by ipconfig, explain where its values originate from, and clarify that the tertiary name server IP and DNS domain name are only written to the file when autoconfiguration is used. Signed-off-by: Chris Novakovic

[PATCH 4/8] ipconfig: BOOTP: Request CONF_NAMESERVERS_MAX name servers

When ipconfig is autoconfigured via BOOTP, the request packet initialised by ic_bootp_init_ext() always allocates 8 bytes for the name server option, limiting the BOOTP server to responding with at most 2 name servers even though ipconfig in fact supports an arbitrary number of name servers (as

[PATCH 1/8] ipconfig: Document setting of NIS domain name

ic_do_bootp_ext() is responsible for parsing the "ip=" and "nfsaddrs=" kernel parameters. If a "." character is found in parameter 4 (the client's hostname), everything before the first "." is used as the hostname, and everything after it is used as the NIS domain name (but not necessarily the DNS

[PATCH 2/8] ipconfig: Tidy up reporting of name servers

Commit 5e953778a2aab04929a5e7b69f53dc26e39b079e ("ipconfig: add nameserver IPs to kernel-parameter ip=") adds the IP addresses of discovered name servers to the summary printed by ipconfig when configuration is complete. It appears the intention in ip_auto_config() was to print the name servers on

[PATCH 3/8] ipconfig: BOOTP: Don't request IEN-116 name servers

When ipconfig is autoconfigured via BOOTP, the request packet initialised by ic_bootp_init_ext() allocates 8 bytes for tag 5 ("Name Server" [1, §3.7]), but tag 5 in the response isn't processed by ic_do_bootp_ext(). Instead, allocate the 8 bytes to tag 6 ("Domain Name Server" [1, §3.8]), which is

Re: TCP one-by-one acking - RFC interpretation question

On 04/06/2018 03:05 AM, Michal Kubecek wrote: > Hello, > > I encountered a strange behaviour of some (non-linux) TCP stack which > I believe is incorrect but support engineers from the company producing > it claim is OK. > > Assume a client (sender, Linux 4.4 kernel) sends a stream of MSS

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

Hi Robin, On Fri, Apr 06, 2018 at 12:48:40PM +0100, Robin Murphy wrote: > On 06/04/18 12:14, Vadim Lomovtsev wrote: > > From: Vadim Lomovtsev > > > > It is too expensive to pass u64 values via linked list, instead > > allocate array for them by overall number of mac

Re: [RFC PATCH net-next v5 2/4] net: Introduce generic bypass module

Thu, Apr 05, 2018 at 11:08:21PM CEST, sridhar.samudr...@intel.com wrote: >This provides a generic interface for paravirtual drivers to listen >for netdev register/unregister/link change events from pci ethernet >devices with the same MAC and takeover their datapath. The notifier and >event

Re: [PATCH net-next] netns: filter uevents correctly

On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote: > >> On 05.04.2018 17:07, Christian Brauner wrote: > >> > On Thu, Apr 05, 2018 at 04:01:03PM +0300,

Re: [RFC PATCH net-next v5 3/4] virtio_net: Extend virtio to use VF datapath when available

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudr...@intel.com wrote: >This patch enables virtio_net to switch over to a VF datapath when a VF >netdev is present with the same MAC address. It allows live migration >of a VM with a direct attached VF without the need to setup a bond/team >between

[PATCH] ARM: dts: ls1021a: Specify TBIPA register address

From: Esben Haabendal The current (mildly evil) fsl_pq_mdio code uses an undocumented shadow of the TBIPA register on LS1021A, which happens to be read-only. Changing TBI PHY address therefore does not work on LS1021A. The real (and documented) address of the TBIPA registere lies

[PATCH 1/2] net/fsl_pq_mdio: Allow explicit speficition of TBIPA address

From: Esben Haabendal This introduces a simpler and generic method for for finding (and mapping) the TBIPA register. Instead of relying of complicated logic for finding the TBIPA register address based on the MDIO or MII register block base address, which even in some cases

[PATCH net-next 5/5] net: stmmac: Switch stmmac_mode_ops to generic HW Interface Helpers

Switch stmmac_mode_ops to generic Hardware Interface Helpers instead of using hard-coded callbacks. This makes the code more readable and more flexible. No functional change. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto

[PATCH net-next 2/5] net: stmmac: Switch stmmac_dma_ops to generic HW Interface Helpers

Switch stmmac_dma_ops to generic Hardware Interface Helpers instead of using hard-coded callbacks. This makes the code more readable and more flexible. No functional change. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto

[PATCH net-next 1/5] net: stmmac: Switch stmmac_desc_ops to generic HW Interface Helpers

Switch stmmac_desc_ops to generic Hardware Interface Helpers instead of using hard-coded callbacks. This makes the code more readable and more flexible. No functional change. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto

[PATCH net-next 0/5] net: stmmac: Stop using hard-coded callbacks

This a starting point for a cleanup and re-organization of stmmac. In this series we stop using hard-coded callbacks along the code and use instead helpers which are defined in a single place ("hwif.h"). This brings several advantages: 1) Less typing :) 2) Guaranteed function

[PATCH net-next 3/5] net: stmmac: Switch stmmac_ops to generic HW Interface Helpers

Switch stmmac_ops to generic Hardware Interface Helpers instead of using hard-coded callbacks. This makes the code more readable and more flexible. No functional change. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto

[PATCH net-next 4/5] net: stmmac: Switch stmmac_hwtimestamp to generic HW Interface Helpers

Switch stmmac_hwtimestamp to generic Hardware Interface Helpers instead of using hard-coded callbacks. This makes the code more readable and more flexible. No functional change. Signed-off-by: Jose Abreu Cc: David S. Miller Cc: Joao Pinto

[iovisor-dev] Best userspace programming API for XDP features query to kernel?

On 04/05/2018 10:51 PM, Jesper Dangaard Brouer wrote: > On Thu, 5 Apr 2018 12:37:19 +0200 > Daniel Borkmann wrote: > >> On 04/04/2018 02:28 PM, Jesper Dangaard Brouer via iovisor-dev wrote: >>> Hi Suricata people, >>> >>> When Eric Leblond (and I helped) integrated XDP in

Re: WARNING: CPU: 3 PID: 0 at net/sched/sch_hfsc.c:1388 hfsc_dequeue+0x319/0x350 [sch_hfsc]

> Il 19 marzo 2018 alle 11.07 Jamal Hadi Salim ha scritto: > > On 18-03-15 08:48 PM, Cong Wang wrote: > > > On Wed, Mar 14, 2018 at 1:10 AM, Marco Berizzi wrote: > > > > > > Il 9 marzo 2018 alle 0.14 Cong Wang ha > > > >

Re: [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings

David Miller writes: > From: Andrew Lunn > Date: Thu, 5 Apr 2018 22:40:49 +0200 > >> Or could it still contain whatever state the last boot of Linux, or >> maybe the bootloader, left the PHY in? > > Right, this is my concern as well. I don't think that

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

On 06/04/18 12:14, Vadim Lomovtsev wrote: From: Vadim Lomovtsev It is too expensive to pass u64 values via linked list, instead allocate array for them by overall number of mac addresses from netdev. This eventually removes multiple kmalloc() calls, aviod memory

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

On Fri, Apr 06, 2018 at 06:47:26AM -0500, Gustavo A. R. Silva wrote: > > > On 04/06/2018 06:43 AM, Vadim Lomovtsev wrote: > > Hi Gustavo, > > > > On Fri, Apr 06, 2018 at 06:36:28AM -0500, Gustavo A. R. Silva wrote: > > > Hi Vadim, > > > > > > On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote: > >

TCP one-by-one acking - RFC interpretation question

Hello, I encountered a strange behaviour of some (non-linux) TCP stack which I believe is incorrect but support engineers from the company producing it claim is OK. Assume a client (sender, Linux 4.4 kernel) sends a stream of MSS sized segments but segments 2, 4 and 6 do not reach the server

[RFC bpf-next] bpf: document eBPF helpers and add a script to generate man page

eBPF helper functions can be called from within eBPF programs to perform a variety of tasks that would be otherwise hard or impossible to do with eBPF itself. There is a growing number of such helper functions in the kernel, but documentation is scarce. The main user space header file does contain

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

Hi Gustavo, On Fri, Apr 06, 2018 at 06:36:28AM -0500, Gustavo A. R. Silva wrote: > Hi Vadim, > > On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote: > > From: Vadim Lomovtsev > > > > It is too expensive to pass u64 values via linked list, instead > > allocate array for

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

On 04/06/2018 06:43 AM, Vadim Lomovtsev wrote: Hi Gustavo, On Fri, Apr 06, 2018 at 06:36:28AM -0500, Gustavo A. R. Silva wrote: Hi Vadim, On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote: From: Vadim Lomovtsev It is too expensive to pass u64 values via linked

tcp hang when socket fills up ?

(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 -EWOULDBLOCK) and it doesn't seem to ever "unfill" until the tcp

[PATCH v2] net: thunderx: rework mac addresses list to u64 array

From: Vadim Lomovtsev It is too expensive to pass u64 values via linked list, instead allocate array for them by overall number of mac addresses from netdev. This eventually removes multiple kmalloc() calls, aviod memory fragmentation and allow to put single null

[PATCH iproute2] bridge: fix typo in hairpin error message

No 'g' to hairpin. Signed-off-by: Guillaume Nault --- bridge/link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bridge/link.c b/bridge/link.c index 579d57e7..8d89aca2 100644 --- a/bridge/link.c +++ b/bridge/link.c @@ -312,7 +312,7 @@ static int

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

Hi Vadim, On 04/06/2018 06:14 AM, Vadim Lomovtsev wrote: From: Vadim Lomovtsev It is too expensive to pass u64 values via linked list, instead allocate array for them by overall number of mac addresses from netdev. This eventually removes multiple kmalloc() calls,

Re: [iovisor-dev] Best userspace programming API for XDP features query to kernel?

On Thu, 5 Apr 2018 14:47:16 -0700 Jakub Kicinski wrote: > On Thu, 5 Apr 2018 22:51:33 +0200, Jesper Dangaard Brouer wrote: > > > What about nfp in terms of XDP > > > offload capabilities, should they be included as well or is probing to > > > load > > > the program

Re: [RFC] ethtool: Support for driver private ioctl's

On Thu, Apr 05, 2018 at 08:50:49AM -0700, Florian Fainelli wrote: > On 04/05/2018 03:47 AM, Jose Abreu wrote: > > Background: Synopsys Ethernet IP's have a certain number of > > features which can be reconfigured at runtime. Giving you two > > examples: One of the most recent one is the safety

[PATCH net 1/3] lan78xx: PHY DSP registers initialization to address EEE link drop issues with long cables

The patch is to configure DSP registers of PHY device to handle Gbe-EEE failures with >40m cable length. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Raghuram Chary J ---

[PATCH net 0/3] lan78xx: Fixes and enhancements

These series of patches have fix and enhancements for lan78xx driver. Raghuram Chary J (3): lan78xx: PHY DSP registers initialization to address EEE link drop issues with long cables lan78xx: Add support to dump lan78xx registers lan78xx: Lan7801 Support for Fixed PHY

[PATCH net 2/3] lan78xx: Add support to dump lan78xx registers

In order to dump lan78xx family registers using ethtool, add support at lan78xx driver level. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Raghuram Chary J --- drivers/net/usb/lan78xx.c |

[PATCH net 3/3] lan78xx: Lan7801 Support for Fixed PHY

Adding Fixed PHY support to the lan78xx driver. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Raghuram Chary J --- drivers/net/usb/Kconfig | 1 + drivers/net/usb/lan78xx.c | 42

[PATCH] vhost-net: set packet weight of tx polling to 2 * vq size

handle_tx will delay rx for tens or even hundreds of milliseconds when tx busy polling udp packets with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT takes into account only sent-bytes but no single packet length. Ping-Latencies shown below were tested between two Virtual

Re: marvell switch

On Thu, Apr 5, 2018 at 11:46 PM, Andrew Lunn wrote: >> > Hi Ran >> > >> > The Marvell driver makes each port act like a normal Linux network >> > interface. So if you want to enable a port, do >> > >> > ip link set lan0 up >> > >> > Want to add an ip address to a port >> > >> > ip

Re: WARNING in xfrm6_tunnel_net_exit

syzbot has found reproducer for the following crash on upstream commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 (Sat Mar 31 01:52:36 2018 +) kernel.h: Retain constant expression output for max()/min() syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=777bf170a89e7b326405 So

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

From: Vadim Lomovtsev Date: Fri, 6 Apr 2018 04:14:25 -0700 > diff --git a/drivers/net/ethernet/cavium/thunder/nic.h > b/drivers/net/ethernet/cavium/thunder/nic.h > index 5fc46c5a4f36..448d1fafc827 100644 > --- a/drivers/net/ethernet/cavium/thunder/nic.h >

Re: [PATCH] dp83640: Ensure against premature access to PHY registers after reset

From: Andrew Lunn Date: Fri, 6 Apr 2018 16:14:10 +0200 > On Fri, Apr 06, 2018 at 04:05:40PM +0200, Esben Haabendal wrote: >> From: Esben Haabendal >> >> Signed-off-by: Esben Haabendal >> --- >> drivers/net/phy/dp83640.c | 17 + >>

Re: [PATCH net-next 0/5] net: stmmac: Stop using hard-coded callbacks

From: Jose Abreu Date: Fri, 6 Apr 2018 14:08:14 +0100 > This a starting point for a cleanup and re-organization of stmmac. > > In this series we stop using hard-coded callbacks along the code and use > instead helpers which are defined in a single place ("hwif.h"). >

Re: [PATCH v3] net: thunderx: rework mac addresses list to u64 array

Self-NACK here, because of https://lkml.org/lkml/2018/4/6/724 Sorry for noise. Vadim On Fri, Apr 06, 2018 at 07:04:43AM -0700, Vadim Lomovtsev wrote: > From: Vadim Lomovtsev > > It is too expensive to pass u64 values via linked list, instead > allocate array for

Re: [PATCH net] net/sched: fix NULL dereference in the error path of tcf_bpf_init()

On Thu, Apr 5, 2018 at 7:19 PM, Davide Caratti wrote: > when tcf_bpf_init_from_ops() fails (e.g. because of program having invalid > number of instructions), tcf_bpf_cfg_cleanup() calls bpf_prog_put(NULL) or > bpf_prog_destroy(NULL). Unless CONFIG_BPF_SYSCALL is unset, this

Re: [PATCH net] net: dsa: Discard frames from unused ports

On Thu, Apr 05, 2018 at 03:20:14PM -0700, Florian Fainelli wrote: > On 04/04/2018 07:17 PM, Andrew Lunn wrote: > > On Wed, Apr 04, 2018 at 05:49:10PM -0700, Florian Fainelli wrote: > >> On 04/04/2018 04:56 PM, Andrew Lunn wrote: > >>> The Marvell switches under some conditions will pass a frame to

Re: [PATCH net-next] netns: filter uevents correctly

Christian Brauner writes: > On Thu, Apr 05, 2018 at 10:59:49PM -0500, Eric W. Biederman wrote: >> Christian Brauner writes: >> >> > On Thu, Apr 05, 2018 at 05:26:59PM +0300, Kirill Tkhai wrote: >> >> On 05.04.2018 17:07,

Re: [RFC] ethtool: Support for driver private ioctl's

On Fri, Apr 06, 2018 at 02:51:15PM +0100, Jose Abreu wrote: > Hi Florian, > > On 05-04-2018 16:50, Florian Fainelli wrote: > > > > On 04/05/2018 03:47 AM, Jose Abreu wrote: > >> Hi All, > >> > >> I would like to know your opinion regarding adding support for > >> driver private ioctl's in

Re: [RFC] ethtool: Support for driver private ioctl's

Hi Andrew, On 06-04-2018 15:47, Andrew Lunn wrote: > On Fri, Apr 06, 2018 at 02:51:15PM +0100, Jose Abreu wrote: >> Hi Florian, >> >> On 05-04-2018 16:50, Florian Fainelli wrote: >>> On 04/05/2018 03:47 AM, Jose Abreu wrote: Hi All, I would like to know your opinion regarding

Re: TCP one-by-one acking - RFC interpretation question

On Fri, Apr 06, 2018 at 05:01:29AM -0700, Eric Dumazet wrote: > > > On 04/06/2018 03:05 AM, Michal Kubecek wrote: > > Hello, > > > > I encountered a strange behaviour of some (non-linux) TCP stack which > > I believe is incorrect but support engineers from the company producing > > it claim is

Re: [RFC 0/9] bpf: Add buildid check support

On Thu, Apr 05, 2018 at 06:37:23PM -0700, Alexei Starovoitov wrote: > On Thu, Apr 05, 2018 at 05:16:36PM +0200, Jiri Olsa wrote: > > hi, > > eBPF programs loaded for kprobes are allowed to read kernel > > internal structures. We check the provided kernel version > > to ensure that the program is

Re: [PATCH v2] net: thunderx: rework mac addresses list to u64 array

On Fri, Apr 06, 2018 at 11:06:03AM -0400, David Miller wrote: > From: Vadim Lomovtsev > Date: Fri, 6 Apr 2018 04:14:25 -0700 > > > diff --git a/drivers/net/ethernet/cavium/thunder/nic.h > > b/drivers/net/ethernet/cavium/thunder/nic.h > > index

Re: [PATCH net 1/3] lan78xx: PHY DSP registers initialization to address EEE link drop issues with long cables

From: Andrew Lunn Date: Fri, 6 Apr 2018 16:43:42 +0200 > On Fri, Apr 06, 2018 at 11:42:02AM +0530, Raghuram Chary J wrote: >> The patch is to configure DSP registers of PHY device >> to handle Gbe-EEE failures with >40m cable length. >> >> Fixes: 55d7de9de6c3 ("Microchip's

[net 2/2] ice: Bug fixes in ethtool code

From: Anirudh Venkataramanan 1) Return correct size from ice_get_regs_len. 2) Fix incorrect use of ARRAY_SIZE in ice_get_regs. Fixes: fcea6f3da546 (ice: Add stats and ethtool support) Signed-off-by: Anirudh Venkataramanan

[net 1/2] ice: Fix error return code in ice_init_hw()

From: Wei Yongjun Fix to return error code ICE_ERR_NO_MEMORY from the alloc error handling case instead of 0, as done elsewhere in this function. Fixes: dc49c7723676 ("ice: Get MAC/PHY/link info and scheduler topology") Signed-off-by: Wei Yongjun

[net 0/2][pull request] Intel Wired LAN Driver Updates 2018-04-06

This series contains a couple of fixes for the new ice driver. Wei Yongjun fixes the return error code for error case during init. Anirudh fixes the incorrect use of ARRAY_SIZE() in the ice ethtool code and fixed "for" loop calculations. The following are changes since commit

Re: [net 0/2][pull request] Intel Wired LAN Driver Updates 2018-04-06

From: Jeff Kirsher Date: Fri, 6 Apr 2018 08:36:28 -0700 > This series contains a couple of fixes for the new ice driver. > > Wei Yongjun fixes the return error code for error case during init. > > Anirudh fixes the incorrect use of ARRAY_SIZE() in the ice ethtool

Re: [RFC] ethtool: Support for driver private ioctl's

Hi Florian, On 05-04-2018 16:50, Florian Fainelli wrote: > > On 04/05/2018 03:47 AM, Jose Abreu wrote: >> Hi All, >> >> I would like to know your opinion regarding adding support for >> driver private ioctl's in ethtool. >> >> Background: Synopsys Ethernet IP's have a certain number of >>

[PATCH v3] net: thunderx: rework mac addresses list to u64 array

From: Vadim Lomovtsev It is too expensive to pass u64 values via linked list, instead allocate array for them by overall number of mac addresses from netdev. This eventually removes multiple kmalloc() calls, aviod memory fragmentation and allow to put single null

Re: [PATCH] dp83640: Ensure against premature access to PHY registers after reset

On Fri, Apr 06, 2018 at 04:05:40PM +0200, Esben Haabendal wrote: > From: Esben Haabendal > > Signed-off-by: Esben Haabendal > --- > drivers/net/phy/dp83640.c | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/drivers/net/phy/dp83640.c

Re: [PATCH net 1/3] lan78xx: PHY DSP registers initialization to address EEE link drop issues with long cables

On Fri, Apr 06, 2018 at 11:42:02AM +0530, Raghuram Chary J wrote: > The patch is to configure DSP registers of PHY device > to handle Gbe-EEE failures with >40m cable length. > > Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 > Ethernet device driver") > Signed-off-by:

Re: Enable and configure storm prevention in a network device

On Thu, Apr 05, 2018 at 03:35:06PM -0700, Florian Fainelli wrote: > On 04/05/2018 01:20 PM, David Miller wrote: > > From: Murali Karicheri > > Date: Thu, 5 Apr 2018 16:14:49 -0400 > > > >> Is there a standard way to implement and configure storm prevention > >> in a Linux

Re: [RFC] ethtool: Support for driver private ioctl's

Hi Michal, On 06-04-2018 10:07, Michal Kubecek wrote: > On Thu, Apr 05, 2018 at 08:50:49AM -0700, Florian Fainelli wrote: >> On 04/05/2018 03:47 AM, Jose Abreu wrote: >>> Background: Synopsys Ethernet IP's have a certain number of >>> features which can be reconfigured at runtime. Giving you two

  1   2   >