- 07 May, 2019 22 commits
-
-
Eric Dumazet authored
FQ packet scheduler assumed that packets could be classified based on their owning socket. This means that if a UDP server uses one UDP socket to send packets to different destinations, packets all land in one FQ flow. This is unfair, since each TCP flow has a unique bucket, meaning that in case of pressure (fully utilised uplink), TCP flows have more share of the bandwidth. If we instead detect unconnected sockets, we can use a stochastic hash based on the 4-tuple hash. This also means a QUIC server using one UDP socket will properly spread the outgoing packets to different buckets, and in-kernel pacing based on EDT model will no longer risk having big rb-tree on one flow. Note that UDP application might provide the skb->hash in an ancillary message at sendmsg() time to avoid the cost of a dissection in fq packet scheduler. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
TCP stack makes sure packets for a given flow are monotically increasing, but we want to allow UDP packets to use EDT as well, so that QUIC servers can use in-kernel pacing. This patch adds a per-flow rb-tree on which packets might be stored. We still try to use the linear list for the typical cases where packets are queued with monotically increasing skb->tstamp, since queue/dequeue packets on a standard list is O(1). Note that the ability to store packets in arbitrary EDT order will allow us to implement later a per TCP socket mechanism adding delays (with jitter eventually) and reorders, to implement convenient network emulators. Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== cleanup & optimizations & bugfixes for HNS3 driver This patchset contains some cleanup related to hns3_enet_ring struct and tx bd filling process, optimizations related to rx page reusing, barrier using and tso handling process, bugfixes related to tunnel type handling and error handling for desc filling. ==================== Signed-off-by: -
Yunsheng Lin authored
This patch uses devm_kcalloc instead of kcalloc when allocating ring->desc_cb, because devm_kcalloc not only ensure to free the memory when the dev is deallocted, but also allocate the memory from it's device memory node. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Yunsheng Lin authored
This patch removes some unused field in struct hns3_enet_ring, use ring->dev for ring_to_dev macro, and use dev consistently in hns3_fill_desc. Signed-off-by:
-
Yunsheng Lin authored
When page size is 64K, RX buffer is currently not reused when the page_offset is moved to last buffer. This patch adds checking to decide whether the buffer page can be reused when last_offset is moved beyond last offset. If the driver is the only user of page when page_offset is moved to beyond last offset, then buffer can be reused and page_offset is set to zero. Signed-off-by:
-
Yunsheng Lin authored
Currently, a barrier is used when cleaning each TX BD, which may cause performance degradation. This patch optimizes it to use one barrier when cleaning TX BD each round. Signed-off-by:
-
Yunsheng Lin authored
When desc filling fails in hns3_nic_net_xmit, it will call hns3_clear_desc to unmap the dma mapping. But currently the ring->next_to_use points to the desc where the desc filling or dma mapping return error, which means the desc that ring->next_to_use points to has not done the dma mapping, the desc that need unmapping is before the ring->next_to_use. This patch fixes it by calling ring_ptr_move_bw(next_to_use) before doing unmapping operation, and set desc_cb->dma to zero to avoid freeing it again when unloading. Also, when filling skb head or frag fails, both need to unmap all the way back to next_to_use_head, so remove one desc filling error handling. Fixes: 76ad4f0e ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by:
-
Yunsheng Lin authored
When filling len and checksum info to description, there is some similar checking or calculation. So this patch adds hns3_set_l2l3l4 to fill the inner(/normal) header's len and checksum info. If it is a encapsulation skb, it calls hns3_set_outer_l2l3l4 to handle the outer header's len and checksum info, in order to avoid some similar checking or calculation. Signed-off-by:
-
Yunsheng Lin authored
This patch separates the inner and outer l2l3l4 len handling in hns3_set_l2l3l4_len, this is a preparation to combine the l2l3l4 len and checksum handling for inner and outer header. Signed-off-by:
-
Yunsheng Lin authored
According to hardware user manual, the tunnel packet type is available in the rx.ol_info field of struct hns3_desc. Currently the tunnel packet type is decided by the rx.l234_info, which may cause RX checksum handling error. This patch fixes it by using the correct field in struct hns3_desc to decide the tunnel packet type. Fixes: 76ad4f0e ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by:
-
Yunsheng Lin authored
HW requires every continuous 8 buffer data to be larger than MSS, we simplify it by ensuring skb_headlen + the first continuous 7 frags to to be larger than GSO header len + mss, and the remaining continuous 7 frags to be larger than MSS except the last 7 frags. This patch adds hns3_skb_need_linearized to handle it for TSO case. Signed-off-by:
-
Yunsheng Lin authored
Currently, using "ethtool --statistics" can show how many time RX page have been reused, but there is no counter for RX page not being reused. This patch adds non_reuse_pg counter to better debug the performance issue, because it is hard to determine when the RX page is reused or not if there is no such counter. Signed-off-by:
-
Yunsheng Lin authored
napi_schedule_irqoff is introduced to be used from hard interrupts handlers or when irqs are already masked, see: https://lists.openwall.net/netdev/2014/10/29/2 So this patch replaces napi_schedule with napi_schedule_irqoff. Signed-off-by:
-
Yunsheng Lin authored
Currently, maybe_stop_tx ops for TSO and non-TSO case share some BD calculation code, so this patch unifies the maybe_stop_tx by removing the maybe_stop_tx ops. skb_is_gso() can be used to differentiate the case between TSO and non-TSO case if there is need to handle special case for TSO case. This patch also add tx_copy field in "ethtool --statistics" to help better debug the performance issue caused by calling skb_copy. Signed-off-by:
-
David S. Miller authored
Hauke Mehrtens says: ==================== net: dsa: lantiq: Add bridge offloading This adds bridge offloading for the Intel / Lantiq GSWIP 2.1 switch. Changes since: v2: - Added Fixes tag to patch 1 - Fixed typo - added GSWIP_TABLE_MAC_BRIDGE_STATIC and made use of it - used GSWIP_TABLE_MAC_BRIDGE in more places v1: - fix typo signle -> single ==================== Signed-off-by: -
Hauke Mehrtens authored
This adds functions to add and remove static entries to and from the forwarding database and dump the full forwarding database. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Hauke Mehrtens authored
Fast aging per port is not supported directly by the hardware, it is only possible to configure a global aging time. Do the fast aging by iterating over the MAC forwarding table and remove all dynamic entries for a given port. Signed-off-by:
-
Hauke Mehrtens authored
The VLAN aware bridge offloading is similar to the VLAN unaware offloading, this makes it possible to offload the VLAN bridge functionalities. The hardware supports up to 64 VLAN bridge entries, we already use one entry for each LAN port to prevent forwarding of packets between the ports when the ports are not in a bridge, so in the end we have 57 possible VLANs. The VLAN filtering is currently only active when the ports are in a bridge, VLAN filtering for ports not in a bridge is not implemented. It is currently not possible to change between VLAN filtering and not filtering while the port is already in a bridge, this would make the driver more complicated. The VLANs are only defined on bridge entries, so we will not add anything into the hardware when the port joins a bridge if it is doing VLAN filtering, but only when an allowed VLAN is added. Signed-off-by:
-
Hauke Mehrtens authored
This allows to offload bridges with DSA to the switch hardware and do the packet forwarding in hardware. This implements generic functions to access the switch hardware tables, which are used to control many features of the switch. This patch activates the MAC learning by removing the MAC address table lock, to prevent uncontrolled forwarding of packets between all the LAN ports, they are added into individual bridge tables entries with individual flow ids and the switch will do the MAC learning for each port separately before they are added to a real bridge. Each bridge consist of an entry in the active VLAN table and the VLAN mapping table, table entries with the same index are matching. In the VLAN unaware mode we configure everything with VLAN ID 0, but we use different flow IDs, the switch should handle all VLANs as normal payload and ignore them. When the hardware looks for the port of the destination MAC address it only takes the entries which have the same flow ID of the ingress packet. The bridges are configured with 64 possible entries with these information: Table Index, 0...63 VLAN ID, 0...4095: VLAN ID 0 is untagged flow ID, 0..63: Same flow IDs share entries in MAC learning table port map, one bit for each port number tagged port map, one bit for each port number Signed-off-by:
-
Hauke Mehrtens authored
Allow the special tag in ingress only on the CPU port and not on all ports. A packet with a special tag could circumvent the hardware forwarding and should only be allowed on the CPU port where Linux controls the port. Fixes: 14fceff4 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200)" Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2019-05-06 The following pull-request contains BPF updates for your *net-next* tree. The main changes are: 1) Two AF_XDP libbpf fixes for socket teardown; first one an invalid munmap and the other one an invalid skmap cleanup, both from Björn. 2) More graceful CONFIG_DEBUG_INFO_BTF handling when pahole is not present in the system to generate vmlinux btf info, from Andrii. 3) Fix libbpf and thus fix perf build error with uClibc on arc architecture, from Vineet. 4) Fix missing libbpf_util.h header install in libbpf, from William. 5) Exclude bash-completion/bpftool from .gitignore pattern, from Masahiro. 6) Fix up rlimit in test_libbpf_open kselftest test case, from Yonghong. 7) Minor misc cleanups. ==================== Signed-off-by:
-
- 06 May, 2019 18 commits
-
-
Björn Töpel authored
The patches with fixes tags added a cast-to-void in the places when the return value of a function was ignored. This is not common practice in the kernel, and is therefore removed in this patch. Reported-by:
Daniel Borkmann <daniel@iogearbox.net> Fixes: 5750902a ("libbpf: proper XSKMAP cleanup") Fixes: 0e6741f0 ("libbpf: fix invalid munmap call") Signed-off-by:
Björn Töpel <bjorn.topel@intel.com> Signed-off-by:
-
Andrii Nakryiko authored
When BTF generation is enabled through CONFIG_DEBUG_INFO_BTF, scripts/link-vmlinux.sh detects if pahole version is too old and gracefully continues build process, skipping BTF generation build step. But if pahole is not available, build will still fail. This patch adds check for whether pahole exists at all and bails out gracefully, if not. Cc: Alexei Starovoitov <ast@fb.com> Reported-by:
Yonghong Song <yhs@fb.com> Fixes: e83b9f55 ("kbuild: add ability to generate BTF type info for vmlinux") Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: replace some magic with more speaking functions Based on info from Realtek replace some magic with speaking functions even though the exact meaning of certain values isn't known. ==================== Signed-off-by: -
Heiner Kallweit authored
Based on info from Realtek add a function for defining the thresholds controlling ethernet flow control. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Based on info from Realtek replace FIFO size config magic with a function. Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: spectrum: Implement loopback ethtool feature This patchset from Jiri allows users to enable loopback feature for individual ports using ethtool. The loopback feature is useful for testing purposes and will also be used by upcoming patchsets to enable the monitoring of buffer drops. Patch #1 adds the relevant device register. Patch #2 Implements support in the driver. Patch #3 adds a selftest. ==================== Signed-off-by: -
Jiri Pirko authored
Add selftest for loopback feature Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Jiri Pirko authored
Allow user to enable loopback feature for individual ports using ethtool. Signed-off-by:
-
Jiri Pirko authored
The PPLR register allows configuration of the port's loopback mode. Signed-off-by:
-
Cong Wang authored
In commit 3c75f6ee ("net_sched: sch_htb: add per class overlimits counter") we added an overlimits counter for each HTB class which could properly reflect how many times we use up all the bandwidth on each class. However, the overlimits counter in HTB qdisc does not, it is way bigger than the sum of each HTB class. In fact, this qdisc overlimits counter increases when we have no skb to dequeue, which happens more often than we run out of bandwidth. It makes more sense to make this qdisc overlimits counter just be a sum of each HTB class, in case people still get confused. I have verified this patch with one single HTB class, where HTB qdisc counters now always match HTB class counters as expected. Eric suggested we could fold this field into 'direct_pkts' as we only use its 32bit on 64bit CPU, this saves one cache line. Cc: Eric Dumazet <edumazet@google.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by:
-
Heiner Kallweit authored
Move adjusting the EEE LED frequency to rtl8168_config_eee_mac. Exclude RTL8411 (version 38) like in the existing code. Signed-off-by:
-
Heiner Kallweit authored
Make both functions macros to allow omitting the ARRAY_SIZE(x) argument. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Traffic support for SJA1105 DSA driver This patch set is a continuation of the "NXP SJA1105 DSA driver" v3 series, which was split in multiple pieces for easier review. Supporting a fully-featured (traffic-capable) driver for this switch requires some rework in DSA and also leaves behind a more generic infrastructure for other dumb switches that rely on 802.1Q pseudo-switch tagging for port separation. Among the DSA changes required are: * Generic xmit and rcv functions for pushing/popping 802.1Q tags on skb's. These are modeled as a tagging protocol of its own but which must be customized by drivers to fit their own hardware possibilities. * Permitting the .setup callback to invoke switchdev operations that will loop back into the driver through the switchdev notifier chain. The SJA1105 driver then proceeds to extend this 8021q switch tagging protocol while adding its own (tag_sja1105). This is done because the driver actually implements a "dual tagger": * For normal traffic it uses 802.1Q tags * For management (multicast DMAC) frames the switch has native support for recognizing and annotating these with source port and switch id information. Because this is a "dual tagger", decoding of management frames should still function when regular traffic can't (under a bridge with VLAN filtering). There was intervention in the DSA receive hotpath, where a new filtering function called from eth_type_trans() is needed. This is useful in the general sense for switches that might actually have some limited means of source port decoding, such as only for management traffic, but not for everything. In order for the 802.1Q tagging protocol (which cannot be enabled under all conditions, unlike the management traffic decoding) to not be an all-or-nothing choice, the filtering function matches everything that can be decoded, and everything else is left to pass to the master netdevice. Lastly, DSA core support was added for drivers to request skb deferral. SJA1105 needs this for SPI intervention during transmission of link-local traffic. This is not done from within the tagger. Some patches were carried over unchanged from the previous patchset (01/09). Others were slightly reworked while adapting to the recent changes in "Make DSA tag drivers kernel modules" (02/09). The introduction of some structures (DSA_SKB_CB, dp->priv) may seem a little premature at this point and the new structures under-utilized. The reason is that traffic support has been rewritten with PTP timestamping in mind, and then I removed the timestamping code from the current submission (1. it is a different topic, 2. it does not work very well yet). On demand I can provide the timestamping patchset as a RFC though. "NXP SJA1105 DSA driver" v3 patchset can be found at: https://lkml.org/lkml/2019/4/12/978 v1 patchset can be found at: https://lkml.org/lkml/2019/5/3/877 Changes in v2: * Made the deferred xmit workqueue also be drained on the netdev suspend callback, not just on ndo_stop. * Added clarification about how other netdevices may be bridged with the switch ports. v2 patchset can be found at: https://www.spinics.net/lists/netdev/msg568818.html Changes in v3: * Exported the dsa_port_vid_add and dsa_port_vid_del symbols to fix an error reported by the kbuild test robot * Fixed the following checkpatch warnings in 05/10: Macro argument reuse 'skb' - possible side-effects? Macro argument reuse 'clone' - possible side-effects? * Added a commit description to the documentation patch (10/10) ==================== Signed-off-by:
-
Vladimir Oltean authored
This adds a table which illustrates what combinations of management / regular traffic work depending on the state the switch ports are in. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
-
Vladimir Oltean authored
While not explicitly documented as supported in UM10944, compliance with the STP states can be obtained by manipulating 3 settings at the (per-port) MAC config level: dynamic learning, inhibiting reception of regular traffic, and inhibiting transmission of regular traffic. In all these modes, transmission and reception of special BPDU frames from the stack is still enabled (not inhibited by the MAC-level settings). On ingress, BPDUs are classified by the MAC filter as link-local (01-80-C2-00-00-00) and forwarded to the CPU port. This mechanism works under all conditions (even without the custom 802.1Q tagging) because the switch hardware inserts the source port and switch ID into bytes 4 and 5 of the MAC-filtered frames. Then the DSA .rcv handler needs to put back zeroes into the MAC address after decoding the source port information. On egress, BPDUs are transmitted using management routes from the xmit worker thread. Again this does not require switch tagging, as the switch port is programmed through SPI to hold a temporary (single-fire) route for a frame with the programmed destination MAC (01-80-C2-00-00-00). STP is activated using the following commands and was tested by connecting two front-panel ports together and noticing that switching loops were prevented (one port remains in the blocking state): $ ip link add name br0 type bridge stp_state 1 && ip link set br0 up $ for eth in $(ls /sys/devices/platform/soc/2100000.spi/spi_master/spi0/spi0.1/net/); do ip link set ${eth} master br0 && ip link set ${eth} up; done Signed-off-by:Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Vladimir Oltean authored
In order to support this, we are creating a make-shift switch tag out of a VLAN trunk configured on the CPU port. Termination of normal traffic on switch ports only works when not under a vlan_filtering bridge. Termination of management (PTP, BPDU) traffic works under all circumstances because it uses a different tagging mechanism (incl_srcpt). We are making use of the generic CONFIG_NET_DSA_TAG_8021Q code and leveraging it from our own CONFIG_NET_DSA_TAG_SJA1105. There are two types of traffic: regular and link-local. The link-local traffic received on the CPU port is trapped from the switch's regular forwarding decisions because it matched one of the two DMAC filters for management traffic. On transmission, the switch requires special massaging for these link-local frames. Due to a weird implementation of the switching IP, by default it drops link-local frames that originate on the CPU port. It needs to be told where to forward them to, through an SPI command ("management route") that is valid for only a single frame. So when we're sending link-local traffic, we are using the dsa_defer_xmit mechanism. Signed-off-by: -
Vladimir Oltean authored
This is supposed to share information between the driver and the tagger, or used by the tagger to keep some state. Its use is optional. Signed-off-by:
Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Some hardware needs to take work to get convinced to receive frames on the CPU port (such as the sja1105 which takes temporary L2 forwarding rules over SPI that last for a single frame). Such work needs a sleepable context, and because the regular .ndo_start_xmit is atomic, this cannot be done in the tagger. So introduce a generic DSA mechanism that sets up a transmit skb queue and a workqueue for deferred transmission. The new driver callback (.port_deferred_xmit) is in dsa_switch and not in the tagger because the operations that require sleeping typically also involve interacting with the hardware, and not simply skb manipulations. Therefore having it there simplifies the structure a bit and makes it unnecessary to export functions from the driver to the tagger. The driver is responsible of calling dsa_enqueue_skb which transfers it to the master netdevice. This is so that it has a chance of performing some more work afterwards, such as cleanup or TX timestamping. To tell DSA that skb xmit deferral is required, I have thought about changing the return type of the tagger .xmit from struct sk_buff * into a enum dsa_tx_t that could potentially encode a DSA_XMIT_DEFER value. But the trailer tagger is reallocating every skb on xmit and therefore making a valid use of the pointer return value. So instead of reworking the API in complicated ways, right now a boolean property in the newly introduced DSA_SKB_CB is set. Signed-off-by:
-
