[net-next 0/5] tipc: obsolete zone concept

Functionality related to the 'zone' concept was never implemented in TIPC. In this series we eliminate the remaining traces of it in the code, and can hence take a first step in reducing the footprint and complexity of the binding table. Jon Maloy (5): tipc: obsolete TIPC_ZONE_SCOPE tipc:

[net-next 3/5] tipc: remove zone_list member in struct publication

As a further consequence of the previous commits, we can also remove the member 'zone_list 'in struct name_info and struct publication. Instead, we now let the member cluster_list take over the role a container of all publications of a given . We also remove the counters for the

Re: [PATCH] Bluetooth: btrsi: rework dependencies

On Thu, Mar 15, 2018 at 4:50 PM, Marcel Holtmann wrote: >> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile >> index 03cfc1b20c4a..9e8d22712ff3 100644 >> --- a/drivers/bluetooth/Makefile >> +++ b/drivers/bluetooth/Makefile >> @@ -28,7 +28,7 @@

[PATCH net 2/3] vti6: Keep set MTU on link creation or change, validate it

In vti6_link_config(), if MTU is already given on link creation or change, validate and use it instead of recomputing it. To do that, we need to propagate the knowledge that MTU was set by userspace all the way down to vti6_link_config(). To keep this simple, vti6_dev_init() sets the new

[PATCH net 1/3] vti6: Properly adjust vti6 MTU from MTU of lower device

If a lower device is found, we don't need to subtract LL_MAX_HEADER to calculate our MTU: just use its MTU, the link layer headers are already taken into account by it. If the lower device is not found, start from ETH_DATA_LEN instead, and only in this case subtract a worst-case LL_MAX_HEADER.

[PATCH net 3/3] vti6: Fix dev->max_mtu setting

We shouldn't allow a tunnel to have IP_MAX_MTU as MTU, because another IPv6 header is going on top of our packets. Without this patch, we might end up building packets bigger than IP_MAX_MTU. Fixes: b96f9afee4eb ("ipv4/6: use core net MTU range checking") Signed-off-by: Stefano Brivio

[PATCH net 0/3] vti6: Fixes for MTU assignment and validation

This series introduces fixes to ensure that default MTU assignment for vti6 is properly calculated (and to make it consistent with vti4), to ensure we always use the MTU from userspace (and validate it), if given, when a link is created or changed, and that the MTU upper bound is properly set.

RE: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE

No, it won't. I just moved those functions and #defines to the bottom of the same file, and marked them as 'deprecated'. BR ///jon > -Original Message- > From: Jiri Pirko [mailto:j...@resnulli.us] > Sent: Thursday, March 15, 2018 12:11 > To: Jon Maloy > Cc:

Re: [Intel-wired-lan] [RFC PATCH 2/2] ixgbe: setup XPS via netif_set_xps()

On Thu, Mar 15, 2018 at 10:05 AM, Paolo Abeni wrote: > Hi, > > On Thu, 2018-03-15 at 09:43 -0700, Alexander Duyck wrote: >> On Thu, Mar 15, 2018 at 8:08 AM, Paolo Abeni wrote: >> > Before this commit, ixgbe with the default setting lacks XPS mapping >> > for

[PATCH] Bluetooth: btrsi: rework dependencies

The linkage between the bluetooth driver and the wireless driver is not defined properly, leading to build problems such as: warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)

Re: [PATCH net-next 1/6] net: Convert l2tp_net_ops

On Thu, Mar 15, 2018 at 12:10:57PM +0300, Kirill Tkhai wrote: > Init method is rather simple. Exit method queues del_work > for every tunnel from per-net list. This seems to be safe > to be marked async. > Acked-by: Guillaume Nault

Re: [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer

On Tue, Mar 06, 2018 at 06:18:04PM +, Edward Cree wrote: > On 06/03/18 18:03, Florian Westphal wrote: > > I don't know. I suspect we should go for naive algorithm only, > > but I would defer such decision to Alexei/Daniel. > > > > f.e. i don't know if using llvm is a good idea or not, > Yeah,

[net-next 5/5] tipc: some name changes

We rename some lists and fields in struct publication both to make the naming more consistent and to better reflect their roles. We also update the descriptions of those lists. node_list -> local_publ cluster_list -> all_publ pport_list -> binding_sock ref -> port There are no functional changes

[net-next 4/5] tipc: merge two lists in struct publication

The size of struct publication can be reduced further. Membership in lists 'nodesub_list' and 'local_list' is mutually exlusive, in that remote publications use the former and local publications the latter. We replace the two lists with one single, named 'binding_node' which reflects what it

Re: [PATCH] Bluetooth: btrsi: rework dependencies

Hi Arnd, > The linkage between the bluetooth driver and the wireless > driver is not defined properly, leading to build problems > such as: > > warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies > (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X) >

[net-next 2/5] tipc: remove zone publication list in name table

As a consequence of the previous commit we nan now eliminate zone scope related lists in the name table. We start with name_table::publ_list[3], which can now be replaced with two lists, one for node scope publications and one for cluster scope publications. Acked-by: Ying Xue

Re: [RFC PATCH 0/2] net:setup XPS mapping for each online CPU

Hi, On Thu, 2018-03-15 at 15:31 +, Eric Dumazet wrote: > On Thu, Mar 15, 2018 at 8:08 AM Paolo Abeni wrote: > > > Currently, most MQ netdevice setup the default XPS configuration mapping > > 1-1 > > the first real_num_tx_queues queues and CPUs and no mapping is created

Re: [PATCH] Bluetooth: btrsi: rework dependencies

Hi Arnd, >>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile >>> index 03cfc1b20c4a..9e8d22712ff3 100644 >>> --- a/drivers/bluetooth/Makefile >>> +++ b/drivers/bluetooth/Makefile >>> @@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA)+= btqca.o >>> >>>

[PATCH net 1/3] vti4: Don't count header length twice on tunnel setup

This re-introduces the effect of commit a32452366b72 ("vti4: Don't count header length twice.") which was accidentally reverted by merge commit f895f0cfbb77 ("Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec"). The commit message from Steffen Klassert said:

[PATCH net 3/3] vti4: Don't override MTU passed on link creation via IFLA_MTU

Don't hardcode a MTU value on vti tunnel initialization, ip_tunnel_newlink() is able to deal with this already. See also commit ffc2b6ee4174 ("ip_gre: fix IFLA_MTU ignored on NEWLINK"). Fixes: 1181412c1a67 ("net/ipv4: VTI support new module for ip_vti.") Signed-off-by: Stefano Brivio

[PATCH net 2/3] ip_tunnel: Clamp MTU to bounds on new link

Otherwise, it's possible to specify invalid MTU values directly on creation of a link (via 'ip link add'). This is already prevented on subsequent MTU changes by commit b96f9afee4eb ("ipv4/6: use core net MTU range checking"). Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")

[PATCH net 0/3] vti4, ip_tunnel: Fixes for MTU assignment and validation

Patch 1/3 re-introduces a fix to ensure that default MTU on new link is not lowered unnecessarily because of double counting of headers. This fix was originally introduced in 2014 and got lost in a merge commit shortly afterwards. Patches 2/3 and 3/3 ensure that MTU passed from userspace on link

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On 3/15/2018 10:32 AM, Alexander Duyck wrote: > We tend to do something like: > update tx_buffer_info > update tx_desc > wmb() > point first tx_buffer_info next_to_watch value at last tx_desc > update next_to_use > notify device via writel > > We do it this way because we have to

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On 3/15/2018 12:21 PM, Sinan Kaya wrote: > On 3/15/2018 10:32 AM, Alexander Duyck wrote: >> We tend to do something like: >> update tx_buffer_info >> update tx_desc >> wmb() >> point first tx_buffer_info next_to_watch value at last tx_desc >> update next_to_use >> notify device via

Re: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE

Thu, Mar 15, 2018 at 05:27:17PM CET, jon.ma...@ericsson.com wrote: >No, it won't. I just moved those functions and #defines to the bottom of the >same file, and marked them as 'deprecated'. Ah. That I missed. Thanks!

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon wrote: > - shmulik.ladk...@gmail.com wrote: > > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon > > wrote: > > > > > > I still think that default behavior should be to zero skb->mark

[PATCH] [v2] Bluetooth: btrsi: rework dependencies

The linkage between the bluetooth driver and the wireless driver is not defined properly, leading to build problems such as: warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)

[PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface

According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only available when PHY is configured in RGMII mode with 10Mbps speed. It will cause some networking issues without RGMII mode, such as carrier sense errors and

Re: [Intel-wired-lan] [PATCH 03/15] ice: Start hardware initialization

On 3/14/2018 3:05 PM, Venkataramanan, Anirudh wrote: On Mon, 2018-03-12 at 19:05 -0700, Shannon Nelson wrote: On 3/9/2018 9:21 AM, Anirudh Venkataramanan wrote: + +/** + * ice_read_sr_aq - Read Shadow RAM. + * @hw: pointer to the HW structure + * @offset: offset in words from module start +

Re: [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer

Alexei Starovoitov wrote: > The way this IMR defined today looks pretty much like nft and > it feels a bit too low level than iptable conversion would need. It wasn't so much about a specific IMR but to avoid code duplication between nft and iptables translators. >

Re: Fw: [Bug 199109] New: pptp: kernel printk "recursion detected", and then reboot itself

On Wed, Mar 14, 2018 at 08:02:17AM -0700, Stephen Hemminger wrote: > > > Begin forwarded message: > > Date: Wed, 14 Mar 2018 06:56:09 + > From: bugzilla-dae...@bugzilla.kernel.org > To: step...@networkplumber.org > Subject: [Bug 199109] New: pptp: kernel printk "recursion detected", and

Re: [PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface

On 03/15/2018 11:56 AM, SZ Lin (林上智) wrote: According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only available when PHY is configured in RGMII mode with 10Mbps speed. It will cause some networking issues without

Re: [PATCH] hv_netvsc: Make sure out channel is fully opened on send

On Thu, 15 Mar 2018 17:24:13 +0100 Mohammed Gamal wrote: > On Wed, 2018-03-14 at 10:22 +0100, Mohammed Gamal wrote: > > On Tue, 2018-03-13 at 12:35 -0700, Stephen Hemminger wrote: > > > On Tue, 13 Mar 2018 20:06:50 +0100 > > > Mohammed Gamal wrote: > > >

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On 03/15/2018 04:54 PM, Shmulik Ladkani wrote: > On Thu, 15 Mar 2018 16:13:39 +0100 Daniel Borkmann > wrote: >> On 03/15/2018 01:50 PM, Shmulik Ladkani wrote: >>> >>> It would be beneficial to have the mark preserved when skb is injected >>> to the slave device's rx path

Re: [Intel-wired-lan] [RFC PATCH 0/2] net:setup XPS mapping for each online CPU

On Thu, Mar 15, 2018 at 10:20 AM, Paolo Abeni wrote: > Hi, > > On Thu, 2018-03-15 at 15:59 +, Eric Dumazet wrote: >> On Thu, Mar 15, 2018 at 8:51 AM Paolo Abeni wrote: >> > I'm sorry, I do not follow. AFAICS with unconnected sockets without XPS >> > we

Re: [PATCH net-next] rds: tcp: must use spin_lock_irq* and not spin_lock_bh with rds_tcp_conn_lock

On 3/15/2018 3:54 AM, Sowmini Varadhan wrote: rds_tcp_connection allocation/free management has the potential to be called from __rds_conn_create after IRQs have been disabled, so spin_[un]lock_bh cannot be used with rds_tcp_conn_lock. Bottom-halves that need to synchronize for critical

[PATCH net-next 3/9] selftests: pmtu: Introduce support for multiple tests

Introduce list of tests and loop on it in main body. Tests will now just take care of calling setup with a list of "units" they need, and return 0 for failure, 1 for success, 2 if the test had to be skipped. Main script body will take care of displaying results and cleaning up after every test.

[PATCH net-next 5/9] selftests: pmtu: Add pmtu_vti6_default_mtu test

Same as pmtu_vti4_default_mtu, but on IPv6 with vti6. Signed-off-by: Stefano Brivio --- tools/testing/selftests/net/pmtu.sh | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/pmtu.sh

Re: rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote: > I have a patchset that creates a vsprintf extension for > print_vma_addr and removes all the uses similar to the > print_symbol() removal. > > This now avoids any possible printk interleaving. > > Unfortunately, without some #ifdef

Re: rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

On Thu, 2018-03-15 at 10:08 -0700, Matthew Wilcox wrote: > On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote: > > I have a patchset that creates a vsprintf extension for > > print_vma_addr and removes all the uses similar to the > > print_symbol() removal. > > > > This now avoids any

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

- shmulik.ladk...@gmail.com wrote: > On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon > wrote: > > - shmulik.ladk...@gmail.com wrote: > > > > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon > > > wrote: > > > > > > > > I still

Re: [RFC PATCH 0/2] net:setup XPS mapping for each online CPU

Hi, On Thu, 2018-03-15 at 15:59 +, Eric Dumazet wrote: > On Thu, Mar 15, 2018 at 8:51 AM Paolo Abeni wrote: > > I'm sorry, I do not follow. AFAICS with unconnected sockets without XPS > > we always hit the netdev_pick_tx()/skb_tx_hash()/skb_flow_dissect() > > overhead in

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 16:13:39 +0100 Daniel Borkmann wrote: > On 03/15/2018 01:50 PM, Shmulik Ladkani wrote: > > > > It would be beneficial to have the mark preserved when skb is injected > > to the slave device's rx path (especially when it's on the same netns). > >

Re: [net-next 1/5] tipc: obsolete TIPC_ZONE_SCOPE

Thu, Mar 15, 2018 at 04:48:51PM CET, jon.ma...@ericsson.com wrote: >Publications for TIPC_CLUSTER_SCOPE and TIPC_ZONE_SCOPE are in all >aspects handled the same way, both on the publishing node and on the >receiving nodes. > >Despite previous ambitions to the contrary, this is never going to

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon wrote: > > I still think that default behavior should be to zero skb->mark only when skb > cross netdevs in different netns. But the previous default was scrub the mark in *both* xnet and non-xnet situations.

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On Wed, Mar 14, 2018 at 8:37 PM, Alexei Starovoitov wrote: > On Wed, Mar 14, 2018 at 05:17:54PM -0700, Eric Dumazet wrote: >> >> >> On 03/14/2018 11:41 AM, Alexei Starovoitov wrote: >> > On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov >> >

Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns

- shmulik.ladk...@gmail.com wrote: > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon > wrote: > > > > I still think that default behavior should be to zero skb->mark only > when skb > > cross netdevs in different netns. > > But the previous default was scrub the

rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

On Thu, 2018-03-15 at 10:48 +0100, Geert Uytterhoeven wrote: > Hi David, > > On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote: > > Do we have anything left that still implements NOMMU? > > Sure: arm, c6x, m68k, microblaze, and sh. I have a patchset that creates a

Re: [Intel-wired-lan] [RFC PATCH 2/2] ixgbe: setup XPS via netif_set_xps()

Hi, On Thu, 2018-03-15 at 09:43 -0700, Alexander Duyck wrote: > On Thu, Mar 15, 2018 at 8:08 AM, Paolo Abeni wrote: > > Before this commit, ixgbe with the default setting lacks XPS mapping > > for CPUs id greater than the number of tx queues. > > > > As a consequence the

Re: [PATCH 2/2] net: phy: relax error checking when creating sysfs link netdev->phydev

On 03/14/2018 09:26 PM, Greg Kroah-Hartman wrote: > On Wed, Mar 14, 2018 at 05:26:24PM -0500, Grygorii Strashko wrote: >> Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per >> one netdevice, as result such drivers will produce warning during system >> boot and fail to

Re: [PATCH] hv_netvsc: Make sure out channel is fully opened on send

On Wed, 2018-03-14 at 10:22 +0100, Mohammed Gamal wrote: > On Tue, 2018-03-13 at 12:35 -0700, Stephen Hemminger wrote: > > On Tue, 13 Mar 2018 20:06:50 +0100 > > Mohammed Gamal wrote: > > > > > Dring high network traffic changes to network interface > > > parameters > > > such

[PATCH] net: hns: Fix ethtool private flags

The driver implementation returns support for private flags, while no private flags are present. When asked for the number of private flags it returns the number of statistic flag names. Fix this by returning EOPNOTSUPP for not implemented ethtool flags. Signed-off-by: Matthias Brugger

[PATCH net-next v3 7/7] ibmvnic: Update TX pool cleaning routine

Update routine that cleans up any outstanding transmits that have not received completions when the device needs to close. Introduces a helper function that cleans one TX pool to make code more readable. Signed-off-by: Thomas Falcon ---

[PATCH net-next v3 4/7] ibmvnic: Update TX pool initialization routine

Introduce function that initializes one TX pool. Use that to create each pool entry in both the standard TX pool and TSO pool arrays. Signed-off-by: Thomas Falcon --- drivers/net/ethernet/ibm/ibmvnic.c | 90 -- 1 file changed, 48

[PATCH net-next v3 0/7] ibmvnic: Update TX pool and TX routines

This patch restructures the TX pool data structure and provides a separate TX pool array for TSO transmissions. This is already used in some way due to our unique DMA situation, namely that we cannot use single DMA mappings for packet data. Previously, both buffer arrays used the same pool entry.

[PATCH net-next v3 5/7] ibmvnic: Update TX and TX completion routines

Update TX and TX completion routines to account for TX pool restructuring. TX routine first chooses the pool depending on whether a packet is GSO or not, then uses it accordingly. For the completion routine to know which pool it needs to use, set the most significant bit of the correlator index

[PATCH net-next v3 1/7] ibmvnic: Generalize TX pool structure

Remove some unused fields in the structure and include values describing the individual buffer size and number of buffers in a TX pool. This allows us to use these fields for TX pool buffer accounting as opposed to using hard coded values. Finally, split TSO buffers out and provide an additional

[PATCH net-next v3 3/7] ibmvnic: Update release TX pool routine

Introduce function that frees one TX pool. Use that to release each pool in both the standard TX pool and TSO pool arrays. Signed-off-by: Thomas Falcon --- drivers/net/ethernet/ibm/ibmvnic.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-)

[PATCH net-next v3 6/7] ibmvnic: Improve TX buffer accounting

Improve TX pool buffer accounting to prevent the producer index from overruning the consumer. First, set the next free index to an invalid value if it is in use. If next buffer to be consumed is in use, drop the packet. Finally, if the transmit fails for some other reason, roll back the consumer

[PATCH net-next v3 2/7] ibmvnic: Update and clean up reset TX pool routine

Update TX pool reset routine to accommodate new TSO pool array. Introduce a function that resets one TX pool, and use that function to initialize each pool in both pool arrays. Signed-off-by: Thomas Falcon --- drivers/net/ethernet/ibm/ibmvnic.c | 45

[PATCH net-next 1/9] selftests: pmtu: Use namespace command prefix to fetch route mtu

In commit 7af137b72131 ("selftests: net: Introduce first PMTU test") I accidentally assumed route_get_* helpers would run from a single namespace. Make them a bit more generic, by passing the namespace command prefix as a parameter instead. Fixes: 7af137b72131 ("selftests: net: Introduce first

[PATCH net-next 0/9] selftests: pmtu: Add further vti/vti6 MTU and PMTU tests

Patches 4/9 to 9/9 add tests to verify default MTU assignment for vti4 and vti6 interfaces, to check that MTU values set on new link and link changes are properly taken and validated, and to verify PMTU exceptions on vti4 interfaces. Patch 1/9 fixes the helper to fetch exceptions MTU to run in

[PATCH net-next 2/9] selftests: pmtu: Factor out MTU parsing helper

...so that it can be used for any iproute command output. Signed-off-by: Stefano Brivio --- tools/testing/selftests/net/pmtu.sh | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/net/pmtu.sh

[PATCH net-next 4/9] selftests: pmtu: Add pmtu_vti4_default_mtu test

This test checks that the MTU assigned by default to a vti (IPv4) interface created on top of veth is simply veth's MTU minus the length of the encapsulated IPv4 header. Signed-off-by: Stefano Brivio --- tools/testing/selftests/net/pmtu.sh | 89

[PATCH net-next 9/9] selftests: pmtu: Add pmtu_vti6_link_change_mtu test

This test checks that MTU configured from userspace is used on link creation and changes, and that when it's not passed from userspace, it's calculated properly from the MTU of the lower layer. Signed-off-by: Stefano Brivio --- tools/testing/selftests/net/pmtu.sh | 58

[PATCH net-next 8/9] selftests: pmtu: Add pmtu_vti6_link_add_mtu test

Same as pmtu_vti4_link_add_mtu test, but for IPv6. Signed-off-by: Stefano Brivio --- tools/testing/selftests/net/pmtu.sh | 43 - 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/pmtu.sh

[PATCH net-next 6/9] selftests: pmtu: Add pmtu_vti4_exception test

This test checks that PMTU exceptions are created only when needed on IPv4 routes with vti and xfrm, and their PMTU value is checked as well. We can't adopt the same approach as test_pmtu_vti6_exception() here, because on IPv4 administrative MTU changes won't be reflected directly on PMTU.

[PATCH net-next 7/9] selftests: pmtu: Add pmtu_vti4_link_add_mtu test

This test checks that MTU given on vti link creation is actually configured, and that tunnel is not created with an invalid MTU. Signed-off-by: Stefano Brivio --- tools/testing/selftests/net/pmtu.sh | 45 - 1 file changed, 44

Re: [Intel-wired-lan] [RFC PATCH 2/2] ixgbe: setup XPS via netif_set_xps()

On Thu, Mar 15, 2018 at 8:08 AM, Paolo Abeni wrote: > Before this commit, ixgbe with the default setting lacks XPS mapping > for CPUs id greater than the number of tx queues. > > As a consequence the xmit path for such CPUs experience a relevant cost > in __netdev_pick_tx,

Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs

On Thu, Mar 15, 2018 at 9:27 AM, Sinan Kaya wrote: > On 3/15/2018 12:21 PM, Sinan Kaya wrote: >> On 3/15/2018 10:32 AM, Alexander Duyck wrote: >>> We tend to do something like: >>> update tx_buffer_info >>> update tx_desc >>> wmb() >>> point first tx_buffer_info

Re: [net-next 0/9][pull request] 40GbE Intel Wired LAN Driver Updates 2018-03-14

From: Jeff Kirsher Date: Wed, 14 Mar 2018 13:44:39 -0700 > This series contains updates to i40e and i40evf only. Series applied, thanks Jeff.

Re: [PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface

On 03/15/2018 11:18 AM, Grygorii Strashko wrote: > > > On 03/15/2018 12:39 PM, Grygorii Strashko wrote: >> >> >> On 03/15/2018 11:56 AM, SZ Lin (林上智) wrote: >>> According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and >>> DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register

Re: [PATCH] net: drivers/net: Remove unnecessary skb_copy_expand OOM messages

From: Joe Perches Date: Mon, 12 Mar 2018 08:07:12 -0700 > skb_copy_expand without __GFP_NOWARN already does a dump_stack > on OOM so these messages are redundant. > > Signed-off-by: Joe Perches Ok, applied to net-next, thanks.

Re: [bpf-next PATCH v2 06/18] bpf: sockmap, add bpf_msg_apply_bytes() helper

From: John Fastabend Date: Mon, 12 Mar 2018 12:23:34 -0700 > A single sendmsg or sendfile system call can contain multiple logical > messages that a BPF program may want to read and apply a verdict. But, > without an apply_bytes helper any verdict on the data applies to

[pci PATCH v7 0/5] Add support for unmanaged SR-IOV

This series is meant to add support for SR-IOV on devices when the VFs are not managed by the kernel. Examples of recent patches attempting to do this include: virto - https://patchwork.kernel.org/patch/10241225/ pci-stub - https://patchwork.kernel.org/patch/10109935/ vfio -

Re: [bpf-next PATCH v2 05/18] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data

From: John Fastabend Date: Mon, 12 Mar 2018 12:23:29 -0700 > This implements a BPF ULP layer to allow policy enforcement and > monitoring at the socket layer. In order to support this a new > program type BPF_PROG_TYPE_SK_MSG is used to run the policy at > the

Re: [bpf-next PATCH v2 07/18] bpf: sockmap, add msg_cork_bytes() helper

From: John Fastabend Date: Mon, 12 Mar 2018 12:23:39 -0700 > In the case where we need a specific number of bytes before a > verdict can be assigned, even if the data spans multiple sendmsg > or sendfile calls. The BPF program may use msg_cork_bytes(). > > The extreme

Re: [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer

On Thu, Mar 15, 2018 at 06:00:22PM +0100, Florian Westphal wrote: > Alexei Starovoitov wrote: > > The way this IMR defined today looks pretty much like nft and > > it feels a bit too low level than iptable conversion would need. > > It wasn't so much about a

[RFC 1/2] mm: Use page->mapping to indicate pfmemalloc

From: Matthew Wilcox I want to use page->index for a different purpose, so move the pfmemalloc indicator from page->index to page->mapping. Signed-off-by: Matthew Wilcox --- include/linux/mm.h | 16 +--- mm/page_alloc.c| 8

[RFC 0/2] Shrink page_frag_cache

From: Matthew Wilcox I've just learned about the page_frag_cache allocator, and now I want to use it everywhere ;-) But before I start using it in other places, I want to see if it can be improved at all. The pfmemalloc flag is pretty specific to how the network stack

[RFC 2/2] page_frag_cache: Store metadata in struct page

From: Matthew Wilcox Shrink page_frag_cache from 24 to 8 bytes (a single pointer to the currently-in-use struct page) by using the page's refcount directly (instead of maintaining a bias) and storing our current progress through the page in the same bits currently used

Re: [PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface

On 03/15/2018 12:39 PM, Grygorii Strashko wrote: On 03/15/2018 11:56 AM, SZ Lin (林上智) wrote: According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only available when PHY is configured in RGMII mode with

Re: [Intel-wired-lan] [PATCH 03/15] ice: Start hardware initialization

On Thu, 2018-03-15 at 10:00 -0700, Shannon Nelson wrote: > On 3/14/2018 3:05 PM, Venkataramanan, Anirudh wrote: > > On Mon, 2018-03-12 at 19:05 -0700, Shannon Nelson wrote: > > > On 3/9/2018 9:21 AM, Anirudh Venkataramanan wrote: > > > > > > + > > > > +/** > > > > + * ice_read_sr_aq - Read

Re: [bpf-next PATCH v2 03/18] net: do_tcp_sendpages flag to avoid SKBTX_SHARED_FRAG

From: John Fastabend Date: Mon, 12 Mar 2018 12:23:19 -0700 > When calling do_tcp_sendpages() from in kernel and we know the data > has no references from user side we can omit SKBTX_SHARED_FRAG flag. > This patch adds an internal flag, NO_SKBTX_SHARED_FRAG that can be

Re: [bpf-next PATCH v2 08/18] bpf: sk_msg program helper bpf_sk_msg_pull_data

From: John Fastabend Date: Mon, 12 Mar 2018 12:23:45 -0700 > Currently, if a bpf sk msg program is run the program > can only parse data that the (start,end) pointers already > consumed. For sendmsg hooks this is likely the first > scatterlist element. For sendpage this

[pci PATCH v7 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources

From: Alexander Duyck This patch adds a common configuration function called pci_sriov_configure_simple that will allow for managing VFs on devices where the PF is not capable of managing VF resources. Signed-off-by: Alexander Duyck ---

Re: [bpf-next PATCH v2 11/18] bpf: sockmap sample, add option to attach SK_MSG program

From: John Fastabend Date: Mon, 12 Mar 2018 12:24:00 -0700 > Add sockmap option to use SK_MSG program types. > > Signed-off-by: John Fastabend Acked-by: David S. Miller

Re: [bpf-next PATCH v2 12/18] bpf: sockmap sample, add sendfile test

From: John Fastabend Date: Mon, 12 Mar 2018 12:24:05 -0700 > To exercise TX ULP sendpage implementation we need a test that does > a sendfile. Add sendfile test option here. > > Signed-off-by: John Fastabend Acked-by: David S. Miller

Re: [bpf-next PATCH v2 10/18] bpf: add verifier tests for BPF_PROG_TYPE_SK_MSG

From: John Fastabend Date: Mon, 12 Mar 2018 12:23:55 -0700 > Test read and writes for BPF_PROG_TYPE_SK_MSG. > > Signed-off-by: John Fastabend Acked-by: David S. Miller

Re: [bpf-next PATCH v2 09/18] bpf: add map tests for BPF_PROG_TYPE_SK_MSG

From: John Fastabend Date: Mon, 12 Mar 2018 12:23:50 -0700 > Add map tests to attach BPF_PROG_TYPE_SK_MSG types to a sockmap. > > Signed-off-by: John Fastabend Acked-by: David S. Miller

[PATCH v4 2/2] Remove false-positive VLAs when using max()

As part of removing VLAs from the kernel[1], we want to build with -Wvla, but it is overly pessimistic and only accepts constant expressions for stack array sizes, instead of also constant values. The max() macro triggers the warning, so this refactors these uses of max() to use the new

[PATCH v4 0/2] Remove false-positive VLAs when using max()

I'm calling this "v4" since the last effort at this was v3, even if it's a different approach. Patch 1 adds const_max(), patch 2 uses it in all the places max() was used for stack arrays. Commit log from patch 1: ---snip--- kernel.h: Introduce const_max() for VLA removal In the effort to remove

[PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One case of this is the evaluation of the max()

Re: [RFC 0/2] Shrink page_frag_cache

On Thu, Mar 15, 2018 at 12:53 PM, Matthew Wilcox wrote: > From: Matthew Wilcox > > I've just learned about the page_frag_cache allocator, and now I want > to use it everywhere ;-) > > But before I start using it in other places, I want to see if it

Re: [bpf-next PATCH v2 08/18] bpf: sk_msg program helper bpf_sk_msg_pull_data

On 03/12/2018 08:23 PM, John Fastabend wrote: [...] > /* integer value in 'imm' field of BPF_CALL instruction selects which helper > * function eBPF program intends to call > diff --git a/net/core/filter.c b/net/core/filter.c > index 2c73af0..7b9e63e 100644 > --- a/net/core/filter.c > +++

[PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in CPSW_CONTROL register. VLAN header encapsulation word has following format: HDR_PKT_Priority bits 29-31 - Header Packet VLAN prio (Highest prio: 7)

Re: [bpf-next PATCH v2 15/18] bpf: sockmap sample support for bpf_msg_cork_bytes()

On Mon, Mar 12, 2018 at 12:24:21PM -0700, John Fastabend wrote: > Add sample application support for the bpf_msg_cork_bytes helper. This > lets the user specify how many bytes each verdict should apply to. > > Similar to apply_bytes() tests these can be run as a stand-alone test > when used

Re: [RFC 2/2] page_frag_cache: Store metadata in struct page

On 03/15/2018 12:53 PM, Matthew Wilcox wrote: > From: Matthew Wilcox > > Shrink page_frag_cache from 24 to 8 bytes (a single pointer to the > currently-in-use struct page) by using the page's refcount directly > (instead of maintaining a bias) and storing our current

Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies

Hi Arnd, > The linkage between the bluetooth driver and the wireless > driver is not defined properly, leading to build problems > such as: > > warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies > (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X) >

Re: [bpf-next PATCH v2 16/18] bpf: sockmap add SK_DROP tests

From: John Fastabend Date: Mon, 12 Mar 2018 12:24:26 -0700 > Add tests for SK_DROP. > > Signed-off-by: John Fastabend Acked-by: David S. Miller

  1   2   3   4   >