- Apr 16, 2019
-
-
John Hurley authored
Recent FW modifications allow the offloading of non repr ports. These ports exist internally on the NFP. So if a rule outputs to an 'internal' port, then the packet will recirculate back into the system but will now have this internal port as it's incoming port. These ports are indicated by a specific type field combined with an 8 bit port id. Add private app data to assign additional port ids for use in offloads. Provide functions to lookup or create new ids when a rule attempts to match on an internal netdev - the only internal netdevs currently supported are of type openvswitch. Have a netdev notifier to release port ids on netdev unregister. OvS offloads rules that match on internal ports as TC egress filters. Ensure that such rules are accepted by the driver. Signed-off-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
John Hurley authored
Write to a FW symbol to indicate that the driver supports flow merging. If this symbol does not exist then flow merging and recirculation is not supported on the FW. If support is available, add a stub to deal with FW to kernel merge hint messages. Full flow merging requires the firmware to support of flow mods. If it does not, then do not attempt to 'turn on' flow merging. Signed-off-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: fixes sparse: warning and type error This patchset fixes a sparse warning and a overflow problem. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yunsheng Lin authored
When setting vport->bw_limit to hdev->tm_info.pg_info[0].bw_limit in hclge_tm_vport_tc_info_update, vport->bw_limit can be as big as HCLGE_ETHER_MAX_RATE (100000), which can not fit into u16 (65535). So this patch fixes it by using u32 for vport->bw_limit. Fixes: 84844054 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jian Shen authored
The input parameter "proto" in function hclge_set_vlan_filter_hw() is asked to be __be16, but got u16 when calling it in function hclge_update_port_base_vlan_cfg(). This patch fixes it by converting it with htons(). Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 21e043cd ("net: hns3: fix set port based VLAN for PF") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Xin Long says: ==================== sctp: fully support memory accounting sctp memory accounting is added in this patchset by using these kernel APIs on send side: - sk_mem_charge() - sk_mem_uncharge() - sk_wmem_schedule() - sk_under_memory_pressure() - sk_mem_reclaim() and these on receive side: - sk_mem_charge() - sk_mem_uncharge() - sk_rmem_schedule() - sk_under_memory_pressure() - sk_mem_reclaim() With sctp memory accounting, we can limit the memory allocation by either sysctl: # sysctl -w net.sctp.sctp_mem="10 20 50" or cgroup: # echo $((8<<14)) > \ /sys/fs/cgroup/memory/sctp_mem/memory.kmem.tcp.limit_in_bytes When the socket is under memory pressure, the send side will block and wait, while the receive side will renege or drop. v1->v2: - add the missing Reported/Tested/Acked/-bys. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Xin Long authored
sk_forward_alloc's updating is also done on rx path, but to be consistent we change to use sk_mem_charge() in sctp_skb_set_owner_r(). In sctp_eat_data(), it's not enough to check sctp_memory_pressure only, which doesn't work for mem_cgroup_sockets_enabled, so we change to use sk_under_memory_pressure(). When it's under memory pressure, sk_mem_reclaim() and sk_rmem_schedule() should be called on both RENEGE or CHUNK DELIVERY path exit the memory pressure status as soon as possible. Note that sk_rmem_schedule() is using datalen to make things easy there. Reported-by:
Matteo Croce <mcroce@redhat.com> Tested-by:
Matteo Croce <mcroce@redhat.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Xin Long authored
Now when sending packets, sk_mem_charge() and sk_mem_uncharge() have been used to set sk_forward_alloc. We just need to call sk_wmem_schedule() to check if the allocated should be raised, and call sk_mem_reclaim() to check if the allocated should be reduced when it's under memory pressure. If sk_wmem_schedule() returns false, which means no memory is allowed to allocate, it will block and wait for memory to become available. Note different from tcp, sctp wait_for_buf happens before allocating any skb, so memory accounting check is done with the whole msg_len before it too. Reported-by:
Matteo Croce <mcroce@redhat.com> Tested-by:
Matteo Croce <mcroce@redhat.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Add neighbour offload indication Neighbour entries are programmed to the device's table so that the correct destination MAC will be specified in a packet after it was routed. Despite being programmed to the device and unlike routes and FDB entries, neighbour entries are currently not marked as offloaded. This patchset changes that. Patch #1 is a preparatory patch to make sure we only mark a neighbour as offloaded in case it was successfully programmed to the device. Patch #2 sets the offload indication on neighbours. Patch #3 adds a test to verify above mentioned functionality. Patched iproute2 version that prints the offload indication is available here [1]. [1] https://github.com/idosch/iproute2/tree/idosch-next ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Test that neighbour entries are marked as offloaded. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In a similar fashion to routes and FDB entries, the neighbour table is reflected to the device. Set an offload indication on the neighbour in case it was programmed to the device. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Next patch will add offload indication to neighbours, but the indication should only be altered in case the neighbour was successfully added to / deleted from the device. Propagate neighbour update errors, so that they could be taken into account by the next patch. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter/IPVS updates for net-next The following patchset contains Netfilter updates for net-next: 1) Remove the broute pseudo hook, implement this from the bridge prerouting hook instead. Now broute becomes real table in ebtables, from Florian Westphal. This also includes a size reduction patch for the bridge control buffer area via squashing boolean into bitfields and a selftest. 2) Add OS passive fingerprint version matching, from Fernando Fernandez. 3) Support for gue encapsulation for IPVS, from Jacky Hu. 4) Add support for NAT to the inet family, from Florian Westphal. This includes support for masquerade, redirect and nat extensions. 5) Skip interface lookup in flowtable, use device in the dst object. 6) Add jiffies64_to_msecs() and use it, from Li RongQing. 7) Remove unused parameter in nf_tables_set_desc_parse(), from Colin Ian King. 8) Statify several functions, patches from YueHaibing and Florian Westphal. 9) Add an optimized version of nf_inet_addr_cmp(), from Li RongQing. 10) Merge route extension to core, also from Florian. 11) Use IS_ENABLED(CONFIG_NF_NAT) instead of NF_NAT_NEEDED, from Florian. 12) Merge ip/ip6 masquerade extensions, from Florian. This includes netdevice notifier unification. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Stephen Rothwell authored
After merging the netfilter-next tree, today's linux-next build (powerpc ppc44x_defconfig) failed like this: In file included from net/bridge/br_input.c:19: include/net/netfilter/nf_queue.h:16:23: error: field 'state' has incomplete type struct nf_hook_state state; ^~~~~ Fixes: 971502d7 ("bridge: netfilter: unroll NF_HOOK helper in bridge input path") Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
- Apr 15, 2019
-
-
Heiner Kallweit authored
This check isn't really needed and we can simplify the code and save some CPU cycles by removing it. Only in case of an error none of these bits are set, and calling the NAPI callback doesn't hurt in this case. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: create function pointer arrays for PHY and chip hw init functions Using function pointer arrays makes the code easier to read and better maintainable. AFAIK function pointer arrays cause some performance drawback due to Spectre mitigation, but we're not in a hot path. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Using a function pointer array makes this easier to read and better maintainable. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Using a function pointer array makes this easier to read and better maintainable. AFAIK function pointer arrays cause some performance drawback due to Spectre mitigation, but we're not in a hot path here. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Huazhong Tan says: ==================== code optimizations & bugfixes for HNS3 driver This patch-set includes code optimizations and bugfixes for the HNS3 ethernet controller driver. [patch 1/12 - 4/12] optimizes the VLAN freature and adds support for port based VLAN, fixes some related bugs about the current implementation. [patch 5/12 - 12/12] includes some other code optimizations for the HNS3 ethernet controller driver. Change log: V1->V2: modifies some patches' commint log and code. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Peng Li authored
This patch removes some redundant BH disable when initializing and uninitializing command queue. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Peng Li authored
If there is pending skb in RX flow when close the port, and the pending buffer is not cleaned, the new packet will be added to the pending skb when the port opens again, and the first new packet has error data. This patch cleans the pending skb when clean RX ring. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jian Shen authored
For some cases, PHY may not be connected to MDIO bus, then the driver will initialize fail since MDIO bus initialization fails. This patch fixes it by skipping the MDIO bus initialization when PHY is inexistent. Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Weihang Li authored
According to hardware description, reset level that should be triggered are not consistent in a module. For example, in SSU common errors, the first two bits has no need to do reset, but the other bits need global reset. This patch sets separate reset level for all RAS and MSI-X interrupts by adding a reset_lvel field in struct hclge_hw_error, and fixes some incorrect reset level. Signed-off-by:
Weihang Li <liweihang@hisilicon.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yunsheng Lin authored
Currently hardware may have not enough buffer to receive packet when it has used more than two MPS(maximum packet size) of buffer, but there are still a lot of shared buffer left unused when TC num is small. This patch divides shared buffer to be used between TC when the port supports DCB, and adjusts the waterline and threshold according to user manual for the port that does not support DCB. This patch also change hclge_get_tc_num's return type to u32 to avoid signed-unsigned mix with divide. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yunsheng Lin authored
Currently RX shared buffer' threshold size for speific TC is set to smaller value when the TC's PFC is not enabled, which may cause performance problem because hardware may not have enough hardware buffer when PFC is not enabled. This patch sets the same threshold size for all TC no matter if the specific TC's PFC is enabled. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yunsheng Lin authored
When a GRO packet is received by driver, the cwr field in the struct tcphdr needs to be checked to decide whether to set the SKB_GSO_TCP_ECN for skb_shinfo(skb)->gso_type. So this patch adds hns3_gro_complete to do that, and adds the hns3_handle_bdinfo to handle the hns3_gro_complete and hns3_rx_checksum. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yunsheng Lin authored
Change the parameters of hns3_rx_checksum to be more specific to what is used internally, rather than passing in a pointer to the whole hns3_desc. Reduces duplicate code and bring this function inline with the approach used in hns3_set_gro_param. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jian Shen authored
In original codes, ndo_set_vf_vlan() in hns3 driver was implemented wrong. It adds or removes VLAN into VLAN filter for VF, but VF is unaware of it. This patch fixes it. When VF loads up, it firstly queries the port based VLAN state from PF. When user change port based VLAN state from PF, PF firstly checks whether the VF is alive. If the VF is alive, then PF notifies the VF the modification; otherwise PF configure the port based VLAN state directly. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jian Shen authored
In original codes, ndo_set_vf_vlan() in hns3 driver was implemented wrong. It adds or removes VLAN into VLAN filter for VF, but VF is unaware of it. Indeed, ndo_set_vf_vlan() is expected to enable or disable port based VLAN (hardware inserts a specified VLAN tag to all TX packets for a specified VF) . When enable port based VLAN, we use port based VLAN id as VLAN filter entry. When disable port based VLAN, we use VLAN id of VLAN device. This patch fixes it for PF, enable/disable port based VLAN when calls ndo_set_vf_vlan(). Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jian Shen authored
Currently, in TX direction, driver implements the TX VLAN offload by checking the VLAN header in skb, and filling it into TX descriptor. Usually it works well, but if enable inserting VLAN header based on port, it may conflict when out_tag field of TX descriptor is already used, and cause RAS error. In RX direction, hardware supports stripping max two VLAN headers. For vlan_tci in skb can only store one VLAN tag, when RX VLAN offload enabled, driver tells hardware to strip one VLAN header from RX packet; when RX VLAN offload disabled, driver tells hardware not to strip VLAN header from RX packet. Now if port based insert VLAN enabled, all RX packets will have the port based VLAN header. This header is useless for stack, driver needs to ask hardware to strip it. Unfortunately, hardware can't drop this VLAN header, and always fill it into RX descriptor, so driver has to identify and drop it. Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jian Shen authored
Our hardware supports inserting a specified VLAN header for each function when sending packets. User can enable it with command "ip link set <devname> vf <vfid> vlan <vlan id>". For this VLAN header is inserted by hardware, not from stack, hardware also needs to strip it from received packets before sending to stack. In this case, driver needs to tell hardware which VLAN to insert or strip. The current VLAN initialization doesn't allow inserting VLAN header by hardware, this patch modifies it, in order be compatible with VLAN inserted base on port. Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: shrink PHY settings array and add 200Gbps support The definition of array settings[] is quite lengthy meanwhile. Add a macro to shrink the definition. When doing this I saw that the new 200Gbps modes and few 100Gbps/50Gbps modes aren't supported in phylib yet. So add this. To avoid ethtool and phylib mode definitions getting out of sync, add a build bug to check for this. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
If new PHY modes are added people may miss to update all relevant places in the kernel. Therefore add a build bug check for new modes in enum ethtool_link_mode_bit_indices that haven't been added to phylib yet. Suggested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Recently new modes have been added to ethtool.h, but the related extension to phylib hasn't been done yet. So add support for these modes. v2: - add missing 100Gbps and 50Gbps modes Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
The definition of array settings[] is quite lengthy meanwhile. Add a macro to shrink the definition. v2: - Fix an indentation issue Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Apr 13, 2019
-
-
David S. Miller authored
NeilBrown says: ==================== Fix rhashtable bit-locking for m68k As reported by Guenter Roeck, the new rhashtable bit-locking doesn't work on m68k as it only requires 2-byte alignment, so BIT(1) is addresses is not unused. We current use BIT(0) to identify a NULLS marker, but that is only needed in ->next pointers. The bucket head does not need a NULLS marker, so the lsb there can be used for locking. the first 4 patches make some small improvements and re-arrange some code. The final patch converts to using only BIT(0) for these two different special purposes. I had previously suggested dropping the series until I fix it. Given that this was fairly easy, I retract that I think it best simply to add these patches to fix the code. ==================== Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
NeilBrown authored
As reported by Guenter Roeck, the new bit-locking using BIT(1) doesn't work on the m68k architecture. m68k only requires 2-byte alignment for words and longwords, so there is only one unused bit in pointers to structs - We current use two, one for the NULLS marker at the end of the linked list, and one for the bit-lock in the head of the list. The two uses don't need to conflict as we never need the head of the list to be a NULLS marker - the marker is only needed to check if an object has moved to a different table, and the bucket head cannot move. The NULLS marker is only needed in a ->next pointer. As we already have different types for the bucket head pointer (struct rhash_lock_head) and the ->next pointers (struct rhash_head), it is fairly easy to treat the lsb differently in each. So: Initialize buckets heads to NULL, and use the lsb for locking. When loading the pointer from the bucket head, if it is NULL (ignoring the lock big), report as being the expected NULLS marker. When storing a value into a bucket head, if it is a NULLS marker, store NULL instead. And convert all places that used bit 1 for locking, to use bit 0. Fixes: 8f0db018 ("rhashtable: use bit_spin_locks to protect hash bucket.") Reported-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
NeilBrown authored
The only times rht_ptr_locked() is used, it is to store a new value in a bucket-head. This is the only time it makes sense to use it too. So replace it by a function which does the whole task: Sets the lock bit and assigns to a bucket head. Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
NeilBrown authored
Rather than dereferencing a pointer to a bucket and then passing the result to rht_ptr(), we now pass in the pointer and do the dereference in rht_ptr(). This requires that we pass in the tbl and hash as well to support RCU checks, and means that the various rht_for_each functions can expect a pointer that can be dereferenced without further care. There are two places where we dereference a bucket pointer where there is no testable protection - in each case we know that we much have exclusive access without having taken a lock. The previous code used rht_dereference() to pretend that holding the mutex provided protects, but holding the mutex never provides protection for accessing buckets. So instead introduce rht_ptr_exclusive() that can be used when there is known to be exclusive access without holding any locks. Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
NeilBrown authored
This patch only moves some code around, it doesn't change the code at all. A subsequent patch will benefit from this as it needs to add calls to functions which are now defined before the call-site, but weren't before. Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-