Re: [PATCH v2] ravb: add support for changing MTU

Hello! On 2/16/2018 7:10 PM, Niklas Söderlund wrote: Allow for changing the MTU within the limit of the maximum size of a descriptor (2048 bytes). Add the callback to change MTU from user-space and take the configurable MTU into account when configuring the hardware. Signed-off-by: Niklas

Re: TCP and BBR: reproducibly low cwnd and bandwidth

Hi. On pátek 16. února 2018 23:59:52 CET Eric Dumazet wrote: > Well, no effect here on e1000e (1 Gbit) at least > > # ethtool -K eth3 sg off > Actual changes: > scatter-gather: off > tx-scatter-gather: off > tcp-segmentation-offload: off > tx-tcp-segmentation: off [requested on] >

Re: [RFC PATCH v3 2/3] virtio_net: Extend virtio to use VF datapath when available

On Fri, Feb 16, 2018 at 7:04 PM, Jakub Kicinski wrote: > On Fri, 16 Feb 2018 10:11:21 -0800, Sridhar Samudrala 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

Re: [net-next v2 2/2] bpf: Add eBPF seccomp sample programs

On 02/16/2018 11:36 PM, Sargun Dhillon wrote: > + close(111); > + assert(errno == EBADF); > + close(999); > + assert(errno = EPERM); should that be == ? > + > + return 0; > +} -- ~Randy

Re: [PATCH RFC 0/4] net: add bpfilter

Hi Daniel, On Fri, Feb 16, 2018 at 09:44:01PM +0100, Daniel Borkmann wrote: > We started out with the > iptables part in the demo as the majority of bigger infrastructure projects > all still rely heavily on it (e.g. docker, k8s to just name two big ones). docker is exec'ing the iptables command

[PATCH 1/2] net: Allow a rule to track originating protocol

Allow a rule that is being added/deleted/modified or dumped to contain the originating protocol's id. The protocol is handled just like a routes originating protocol is. This is especially useful because there is starting to be a plethora of different user space programs adding rules.

[PATCH 2/2] drivers: Modify vrf device to specify it's rule as RTPROT_KERNEL

Allow the vrf device to specify that the kernel is the originator of the rule created for this device. Signed-off-by: Donald Sharp --- drivers/net/vrf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c index

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Fri, Feb 16, 2018 at 05:33:54PM -0500, David Miller wrote: > From: Florian Westphal > > > Any particular reason why translating iptables rather than nftables > > (it should be possible to monitor the nftables changes that are > > announced by kernel and act on

[PATCH 0/2] Allow rules to track originating protocol

Add the ability for the kernel to track the originating protocol for when new rules are added to the kernel. Donald Sharp (2): net: Allow a rule to track originating protocol drivers: Modify vrf device to specify it's rule as RTPROT_KERNEL drivers/net/vrf.c | 1 +

Re: [net-next PATCH v1 3/3] net: stmmac: dwmac-meson8b: make the clock configurations private

Hi Jerome, On Sat, Feb 17, 2018 at 5:41 PM, Jerome Brunet wrote: > On Sat, 2018-02-17 at 15:08 +0100, Martin Blumenstingl wrote: >> The common clock framework needs access to the "clock configuration" >> structs during runtime. >> However, only the common clock framework

Re: [net-next PATCH v1 3/3] net: stmmac: dwmac-meson8b: make the clock configurations private

On Sat, 2018-02-17 at 15:08 +0100, Martin Blumenstingl wrote: > The common clock framework needs access to the "clock configuration" > structs during runtime. > However, only the common clock framework should access these. Ensure > this by moving the configuration structs out of struct

Re: [PATCH RFC 0/4] net: add bpfilter

Hi Daniel, On Fri, Feb 16, 2018 at 02:40:19PM +0100, Daniel Borkmann wrote: > This is a very rough and early proof of concept that implements bpfilter. > The basic idea of bpfilter is that it can process iptables queries and > translate them in user space into BPF programs which can then get

Re: [net-next PATCH v1 1/3] net: stmmac: dwmac-meson8b: simplify clock registration

On Sat, 2018-02-17 at 15:08 +0100, Martin Blumenstingl wrote: > To goal of this patch is to simplify the registration of the RGMII TX > clock (and it's parent clocks). This is achieved by: > - introducing the meson8b_dwmac_register_clk helper-function to remove > code duplication when

Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device

On Fri, Feb 16, 2018 at 6:38 PM, Jakub Kicinski wrote: > On Fri, 16 Feb 2018 10:11:19 -0800, Sridhar Samudrala wrote: >> Ppatch 2 is in response to the community request for a 3 netdev >> solution. However, it creates some issues we'll get into in a moment. >> It extends

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Sat, 2018-02-17 at 11:01 +0100, Oleksandr Natalenko wrote: > Hi. > > On pátek 16. února 2018 23:59:52 CET Eric Dumazet wrote: > > Well, no effect here on e1000e (1 Gbit) at least > > > > # ethtool -K eth3 sg off > > Actual changes: > > scatter-gather: off > > tx-scatter-gather: off > >

Re: [PATCH v5 01/14] net: pch_gbe: Mark Minnow PHY reset GPIO active low

> @@ -2700,10 +2701,10 @@ static int pch_gbe_minnow_platform_init(struct > pci_dev *pdev) > return ret; > } > > - gpio_set_value(gpio, 0); > - usleep_range(1250, 1500); > gpio_set_value(gpio, 1); > usleep_range(1250, 1500); > + gpio_set_value(gpio,

Re: [PATCH v5 03/14] dt-bindings: net: Document Intel pch_gbe binding

> @@ -0,0 +1,25 @@ > +Intel Platform Controller Hub (PCH) GigaBit Ethernet (GBE) > + > +Required properties: > +- compatible:Should be the PCI vendor & device ID, eg. > "pci8086,8802". > +- reg: Should be a PCI device number as specified by > the PCI bus > +

[PATCH net-next5/5] ibmvnic: Allocate max queues stats buffers

To avoid losing any stats when the number of sub-crqs change, allocate the max number of stats buffers so a stats buffer exists all possible sub-crqs. Signed-off-by: Nathan Fontenot --- drivers/net/ethernet/ibm/ibmvnic.c |4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH net-next3/5] ibmvnic: Free and re-allocate scrqs when tx/rx scrqs change

When the driver resets it is possible that the number of tx/rx sub-crqs can change. This patch handles this so that the driver does not try to access non-existent sub-crqs. Additionally, a parameter is added to release_sub_crqs() so that we know if the h_call to free the sub-crq needs to be made.

[PATCH net-next1/5] ibmvnic: Rename active queue count variables

Rename the tx/rx active pool variables to be tx/rx active scrq counts. The tx/rx pools are per sub-crq so this is a more appropriate name. This also is a preparatory step for using thiese variables for handling updates to sub-crqs and napi based on the active count. Signed-off-by: Nathan Fontenot

[PATCH net-next2/5] ibmvnic: Move active sub-crq count settings

Inpreparation for using the active scrq count to track more active resources, move the setting of the active count to after initialization occurs in initial driver init and during driver reset. Signed-off-by: Nathan Fontenot --- drivers/net/ethernet/ibm/ibmvnic.c |

[PATCH net-next 0/5] ibmvnic: Make driver resources dynamic

The ibmvnic driver needs to be able to handle the number of tx/rx sub-crqs changing during a reset of the driver. To do this several changes need to be made. First the num_active_[tx|rx]_pools counters need to be re-named to num_active_[tc|rx]_scrqs, and updated after resource initialization.

[PATCH v5 08/14] net: pch_gbe: Fold pch_gbe_setup_[rt]ctl into pch_gbe_configure_[rt]x

The pch_gbe driver splits configuration of the receive path between pch_gbe_setup_rctl() & pch_gbe_configure_rx(), which are always called together and in that order. The split between the two functions seems somewhat arbitrary, as both are configuring registers for the receive path. Fold

[PATCH v5 10/14] net: pch_gbe: Disable TX DMA whilst configuring descriptors

The pch_gbe driver enables TX DMA the first time we call pch_gbe_configure_tx() and never disables it again, even if we reconfigure the device & modify the transmit descriptor ring. This seems unsafe, since the device may continue accessing descriptors whilst they are in an unpredictable &

[PATCH v5 03/14] dt-bindings: net: Document Intel pch_gbe binding

Introduce documentation for a device tree binding for the Intel Platform Controller Hub (PCH) GigaBit Ethernet (GBE) device. Although this is a PCIe device & thus largely auto-detectable, this binding will be used to provide the driver with the PHY reset GPIO. Signed-off-by: Paul Burton

[PATCH v5 04/14] net: pch_gbe: Add device tree support

Introduce support for retrieving the PHY reset GPIO from device tree, which will be used on the MIPS Boston development board. This requires support for probe deferral in order to work correctly, since the order of device probe is not guaranteed & typically the EG20T GPIO controller device will be

[PATCH v5 06/14] net: pch_gbe: Allow longer for resets

Resets of the EG20T MAC on the MIPS Boston development board take longer than the 1000 loops that pch_gbe_wait_clr_bit was performing. Rather than simply increasing the number of loops, switch to using readl_poll_timeout_atomic() from linux/iopoll.h in order to provide some independence from the

[PATCH v5 01/14] net: pch_gbe: Mark Minnow PHY reset GPIO active low

The Minnow PHY reset GPIO is set to 0 to enter reset & 1 to leave reset - that is, it is an active low GPIO. In order to allow for the code to be made more generic by further patches, indicate to the GPIO subsystem that the GPIO is active low & invert the values it is set to such that they reflect

[PATCH v5 12/14] net: pch_gbe: Fix TX RX descriptor accesses for big endian systems

From: Hassan Naveed Fix pch_gbe driver for ethernet operations for a big endian CPU. Values written to and read from transmit and receive descriptors in the pch_gbe driver are byte swapped from the perspective of a big endian CPU, since the ethernet controller always

[PATCH v5 00/14] net: pch_gbe: Fixes & MIPS support

The Intel EG20T Platform Controller Hub is used on the MIPS Boston development board to provide various peripherals including ethernet. This series fixes some issues with the pch_gbe driver discovered whilst in use on the Boston board, and implements support for device tree which we use to provide

RE: [net-next v2 1/1] tipc: avoid unnecessary copying of bundled messages

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Friday, February 16, 2018 21:33 > To: Jon Maloy > Cc: netdev@vger.kernel.org; Mohan Krishna Ghanta Krishnamurthy > ; Tung Quang Nguyen

Re: [PATCH RFC 0/4] net: add bpfilter

David Miller wrote: > From: Florian Westphal > Date: Fri, 16 Feb 2018 17:14:08 +0100 > > > Any particular reason why translating iptables rather than nftables > > (it should be possible to monitor the nftables changes that are > > announced by kernel and

[PATCH v5 02/14] net: pch_gbe: Pull PHY GPIO handling out of Minnow code

The MIPS Boston development board uses the Intel EG20T Platform Controller Hub, including its gigabit ethernet controller, and requires that its RTL8211E PHY be reset much like the Minnow platform. Pull the PHY reset GPIO handling out of Minnow-specific code such that it can be shared by later

[PATCH v5 09/14] net: pch_gbe: Use pch_gbe_disable_dma_rx() in pch_gbe_configure_rx()

The pch_gbe_configure_rx() function open-codes the equivalent of pch_gbe_disable_dma_rx(). Remove the duplication by moving pch_gbe_disable_dma_rx(), and pch_gbe_enable_dma_rx() for consistency, to be defined earlier than pch_gbe_configure_rx() and have pch_gbe_configure_rx() call

[PATCH v5 14/14] net: pch_gbe: Allow build on MIPS platforms

Allow the pch_gbe driver to be built on MIPS platforms, allowing its use on the MIPS Boston development board. Signed-off-by: Paul Burton Cc: David S. Miller Cc: linux-m...@linux-mips.org Cc: netdev@vger.kernel.org --- Changes in v5: None Changes in

Re: BUG: sleeping function called from invalid context at net/core/sock.c:LINE (3)

On 17.02.2018 11:15, Dmitry Vyukov wrote: > On Sat, Feb 17, 2018 at 4:00 AM, syzbot > wrote: >> Hello, >> >> syzbot hit the following crash on net-next commit >> 65bd449c32c2745df61913ab54087e77f9d9b70d (Fri Feb 16 20:26:35 2018 +) >>

Re: [PATCH v5 02/14] net: pch_gbe: Pull PHY GPIO handling out of Minnow code

Hi Andrew, On Sat, Feb 17, 2018 at 11:29:33PM +0100, Andrew Lunn wrote: > On Sat, Feb 17, 2018 at 12:10:25PM -0800, Paul Burton wrote: > > The MIPS Boston development board uses the Intel EG20T Platform > > Controller Hub, including its gigabit ethernet controller, and requires > > that its

Re: [PATCH 0/3] Allow 'ip rule' command to use protocol

On 2/17/18 5:47 AM, Donald Sharp wrote: > Fix iprule.c to use the actual `struct fib_rule_hdr` and to > allow the end user to see and use the protocol keyword > for rule manipulations. > > Donald Sharp (3): > ip: Use the `struct fib_rule_hdr` for rules > ip: Display ip rule protocol used >

Re: [PATCH v5 02/14] net: pch_gbe: Pull PHY GPIO handling out of Minnow code

> Note that this is a driver which is already in mainline, and I didn't > write it. Claiming that *I* am doing this all wrong is a bit of a > stretch - all this patch does is make small changes to some existing > code, which only tangentially relates to a PHY driver, such that it > ceases to be

Re: [PATCH RFC 0/4] net: add bpfilter

Florian Westphal wrote: > David Miller wrote: > > From: Florian Westphal > > Date: Fri, 16 Feb 2018 17:14:08 +0100 > > > > > Any particular reason why translating iptables rather than nftables > > > (it should be possible to monitor the

Re: [PATCH 0/3] Allow 'ip rule' command to use protocol

Got it. I'll send an update. donald On Sat, Feb 17, 2018 at 6:35 PM, David Ahern wrote: > On 2/17/18 5:47 AM, Donald Sharp wrote: >> Fix iprule.c to use the actual `struct fib_rule_hdr` and to >> allow the end user to see and use the protocol keyword >> for rule

[PATCH v5 13/14] ptp: pch: Allow build on MIPS platforms

Allow the ptp_pch driver to be built on MIPS platforms in preparation for use on the MIPS Boston board. Signed-off-by: Paul Burton Acked-by: Richard Cochran Cc: David S. Miller Cc: linux-m...@linux-mips.org Cc:

[PATCH v5 11/14] net: pch_gbe: Ensure DMA is ordered with descriptor writes

On weakly ordered systems writes to the RX or TX descriptors may be reordered with the write to the DMA control register that enables DMA. If this happens then the device may see descriptors in an intermediate & invalid state, leading to incorrect behaviour. Add barriers to ensure that DMA is

[PATCH v5 07/14] net: pch_gbe: Fix handling of TX padding

The ethernet controller found in the Intel EG20T Platform Controller Hub requires that we place 2 bytes of padding between the ethernet header & the packet payload. Our pch_gbe driver handles this by copying packets to be transmitted to a temporary struct skb with the padding bytes inserted,

[PATCH v2 net-next 1/2] ipvlan: drop ipv6 dependency

IPVlan has an hard dependency on IPv6. Refactor the ipvlan code to allow compiling it with IPv6 disabled. Signed-off-by: Matteo Croce --- drivers/net/Kconfig | 1 - drivers/net/ipvlan/ipvlan_core.c | 71 ++--

[PATCH v2 net-next 0/3] Remove IPVlan module dependencies on IPv6 and L3 Master dev

The IPVlan module currently depends on IPv6 and L3 Master dev. Refactor the code to allow building IPVlan module regardless of the value of CONFIG_IPV6 and CONFIG_NETFILTER, and change the CONFIG_NET_L3_MASTER_DEV dependency into a select, as compiling L3 Master device alone has no sense. $ grep

[PATCH v2 net-next 2/2] ipvlan: selects master_l3 device instead of depending on it

The L3 Master device is just a glue between the core networking code and device drivers, so it should be selected automatically rather than requiring to be enabled explicitly. Signed-off-by: Matteo Croce --- drivers/net/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v5 05/14] net: pch_gbe: Always reset PHY along with MAC

On the MIPS Boston development board, the EG20T MAC does not report receiving the RX clock from the (RGMII) RTL8211E PHY unless the PHY is reset at the same time as the MAC. Since the pch_gbe driver resets the MAC a number of times - twice during probe, and when taking down the network interface -

Re: [PATCH v5 02/14] net: pch_gbe: Pull PHY GPIO handling out of Minnow code

On Sat, Feb 17, 2018 at 12:10:25PM -0800, Paul Burton wrote: > The MIPS Boston development board uses the Intel EG20T Platform > Controller Hub, including its gigabit ethernet controller, and requires > that its RTL8211E PHY be reset much like the Minnow platform. Pull the > PHY reset GPIO

Re: [PATCH RFC 0/4] net: add bpfilter

Daniel Borkmann wrote: > Hi Florian, > > On 02/16/2018 05:14 PM, Florian Westphal wrote: > > Florian Westphal wrote: > >> Daniel Borkmann wrote: > >> Several questions spinning at the moment, I will probably come up with > >> more: >

Re: [PATCH v2 net-next 0/3] Remove IPVlan module dependencies on IPv6 and L3 Master dev

On Sat, Feb 17, 2018 at 8:11 PM, Matteo Croce wrote: > The IPVlan module currently depends on IPv6 and L3 Master dev. > Refactor the code to allow building IPVlan module regardless of the value of > CONFIG_IPV6 and CONFIG_NETFILTER, and change the CONFIG_NET_L3_MASTER_DEV >

[PATCH net-next4/5] ibmvnic: Make napi usage dynamic

In order to handle the number of rx sub crqs changing during a driver reset, the ibmvnic driver also needs to update the number of napi. To do this the code to init and free napi's is moved to their own routines so they can be called during the reset process. Signed-off-by: Nathan Fontenot

[PATCH 1/3] ip: Use the `struct fib_rule_hdr` for rules

The iprule.c code was using `struct rtmsg` as the data type to pass into the kernel for the netlink message. While 'struct rtmsg' and `struct fib_rule_hdr` are the same size and mostly the same, we should use the correct data structure. This commit translates the data structures to have iprule.c

[PATCH 0/3] Allow 'ip rule' command to use protocol

Fix iprule.c to use the actual `struct fib_rule_hdr` and to allow the end user to see and use the protocol keyword for rule manipulations. Donald Sharp (3): ip: Use the `struct fib_rule_hdr` for rules ip: Display ip rule protocol used ip: Allow rules to accept a specified protocol

[PATCH 3/3] ip: Allow rules to accept a specified protocol

Allow the specification of a protocol when the user adds/modifies/deletes a rule. Signed-off-by: Donald Sharp --- ip/iprule.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/ip/iprule.c b/ip/iprule.c index 5703d6e4..8fc6ac48 100644 --- a/ip/iprule.c +++

[PATCH 2/3] ip: Display ip rule protocol used

Newer kernels are now accepting a protocol from the installing program for who installed the rule. This change allows us to see this change if it is being specified by the installing program. Signed-off-by: Donald Sharp --- ip/iprule.c | 3 +++ 1 file changed, 3

[net-next PATCH v1 1/3] net: stmmac: dwmac-meson8b: simplify clock registration

To goal of this patch is to simplify the registration of the RGMII TX clock (and it's parent clocks). This is achieved by: - introducing the meson8b_dwmac_register_clk helper-function to remove code duplication when registering a single clock (this saves a few lines since we have 4 clocks

[net-next PATCH v1 3/3] net: stmmac: dwmac-meson8b: make the clock configurations private

The common clock framework needs access to the "clock configuration" structs during runtime. However, only the common clock framework should access these. Ensure this by moving the configuration structs out of struct meson8b_dwmac, so only meson8b_init_rgmii_tx_clk() and the common clock framework

[net-next PATCH v1 0/3] dwmac-meson8b: small cleanup

This is a follow-up to my previous series "dwmac-meson8b: clock fixes for Meson8b" from [0]. during the review of that series it was found that the clock registration could be simplified. now that the previous series has landed we can start cleaning up the clock registration. the goal of this

[net-next PATCH v1 2/3] net: stmmac: dwmac-meson8b: only keep struct device around

Nothing in the dwmac-meson8b driver (except .probe itself) requires the platform_device anymore after .probe has finished. Replace it with a pointer to struct device since this is what the functions inside the driver are actually accessing. No functional changes. Signed-off-by: Martin

Re: [PATCH RFC 0/4] net: add bpfilter

Harald Welte wrote: > I believe _if_ one wants to use the approach of "hiding" eBPF behind > iptables, then either [..] > b) you must introduce new 'tables', like an 'xdp' table which then has >the notion of processing very early in processing, way before the >normal