diff options
Diffstat (limited to 'Documentation/networking')
| -rw-r--r-- | Documentation/networking/batman-adv.rst | 2 | ||||
| -rw-r--r-- | Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst | 44 | ||||
| -rw-r--r-- | Documentation/networking/devlink/index.rst | 1 | ||||
| -rw-r--r-- | Documentation/networking/devlink/sja1105.rst | 49 | ||||
| -rw-r--r-- | Documentation/networking/dsa/dsa.rst | 29 | ||||
| -rw-r--r-- | Documentation/networking/dsa/sja1105.rst | 218 | ||||
| -rw-r--r-- | Documentation/networking/ethtool-netlink.rst | 23 | ||||
| -rw-r--r-- | Documentation/networking/mptcp-sysctl.rst | 12 | ||||
| -rw-r--r-- | Documentation/networking/nf_conntrack-sysctl.rst | 7 | ||||
| -rw-r--r-- | Documentation/networking/pktgen.rst | 18 | ||||
| -rw-r--r-- | Documentation/networking/vrf.rst | 13 |
11 files changed, 125 insertions, 291 deletions
diff --git a/Documentation/networking/batman-adv.rst b/Documentation/networking/batman-adv.rst index 74821d29a22f..b85563ea3682 100644 --- a/Documentation/networking/batman-adv.rst +++ b/Documentation/networking/batman-adv.rst @@ -157,7 +157,7 @@ Contact Please send us comments, experiences, questions, anything :) IRC: - #batman on irc.freenode.org + #batadv on ircs://irc.hackint.org/ Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription at https://lists.open-mesh.org/mailman3/postorius/lists/b.a.t.m.a.n.lists.open-mesh.org/) diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index ef8cb62e82a1..4b59cf2c599f 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -656,3 +656,47 @@ Bridge offloads tracepoints: $ cat /sys/kernel/debug/tracing/trace ... ip-5387 [000] ...1 573713: mlx5_esw_bridge_vport_cleanup: vport_num=1 + +Eswitch QoS tracepoints: + +- mlx5_esw_vport_qos_create: trace creation of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_create >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-23496 [018] .... 73136.838831: mlx5_esw_vport_qos_create: (0000:82:00.0) vport=2 tsar_ix=4 bw_share=0, max_rate=0 group=000000007b576bb3 + +- mlx5_esw_vport_qos_config: trace configuration of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_config >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-26548 [023] .... 75754.223823: mlx5_esw_vport_qos_config: (0000:82:00.0) vport=1 tsar_ix=3 bw_share=34, max_rate=10000 group=000000007b576bb3 + +- mlx5_esw_vport_qos_destroy: trace deletion of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_destroy >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-27418 [004] .... 76546.680901: mlx5_esw_vport_qos_destroy: (0000:82:00.0) vport=1 tsar_ix=3 + +- mlx5_esw_group_qos_create: trace creation of transmit scheduler arbiter for rate group:: + + $ echo mlx5:mlx5_esw_group_qos_create >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-26578 [008] .... 75776.022112: mlx5_esw_group_qos_create: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 + +- mlx5_esw_group_qos_config: trace configuration of transmit scheduler arbiter for rate group:: + + $ echo mlx5:mlx5_esw_group_qos_config >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-27303 [020] .... 76461.455356: mlx5_esw_group_qos_config: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 bw_share=100 max_rate=20000 + +- mlx5_esw_group_qos_destroy: trace deletion of transmit scheduler arbiter for group:: + + $ echo mlx5:mlx5_esw_group_qos_destroy >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-27418 [006] .... 76547.187258: mlx5_esw_group_qos_destroy: (0000:82:00.0) group=000000007b576bb3 tsar_ix=1 diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 03f56ed2961f..45b5f8b341df 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -43,7 +43,6 @@ parameters, info versions, and other features it supports. mv88e6xxx netdevsim nfp - sja1105 qed ti-cpsw-switch am65-nuss-cpsw-switch diff --git a/Documentation/networking/devlink/sja1105.rst b/Documentation/networking/devlink/sja1105.rst deleted file mode 100644 index e2679c274085..000000000000 --- a/Documentation/networking/devlink/sja1105.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -======================= -sja1105 devlink support -======================= - -This document describes the devlink features implemented -by the ``sja1105`` device driver. - -Parameters -========== - -.. list-table:: Driver-specific parameters implemented - :widths: 5 5 5 85 - - * - Name - - Type - - Mode - - Description - * - ``best_effort_vlan_filtering`` - - Boolean - - runtime - - Allow plain ETH_P_8021Q headers to be used as DSA tags. - - Benefits: - - - Can terminate untagged traffic over switch net - devices even when enslaved to a bridge with - vlan_filtering=1. - - Can terminate VLAN-tagged traffic over switch net - devices even when enslaved to a bridge with - vlan_filtering=1, with some constraints (no more than - 7 non-pvid VLANs per user port). - - Can do QoS based on VLAN PCP and VLAN membership - admission control for autonomously forwarded frames - (regardless of whether they can be terminated on the - CPU or not). - - Drawbacks: - - - User cannot use VLANs in range 1024-3071. If the - switch receives frames with such VIDs, it will - misinterpret them as DSA tags. - - Switch uses Shared VLAN Learning (FDB lookup uses - only DMAC as key). - - When VLANs span cross-chip topologies, the total - number of permitted VLANs may be less than 7 per - port, due to a maximum number of 32 VLAN retagging - rules per switch. diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 20baacf2bc5c..89bb4fa4c362 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -200,19 +200,6 @@ receive all frames regardless of the value of the MAC DA. This can be done by setting the ``promisc_on_master`` property of the ``struct dsa_device_ops``. Note that this assumes a DSA-unaware master driver, which is the norm. -Hardware manufacturers are strongly discouraged to do this, but some tagging -protocols might not provide source port information on RX for all packets, but -e.g. only for control traffic (link-local PDUs). In this case, by implementing -the ``filter`` method of ``struct dsa_device_ops``, the tagger might select -which packets are to be redirected on RX towards the virtual DSA user network -interfaces, and which are to be left in the DSA master's RX data path. - -It might also happen (although silicon vendors are strongly discouraged to -produce hardware like this) that a tagging protocol splits the switch-specific -information into a header portion and a tail portion, therefore not falling -cleanly into any of the above 3 categories. DSA does not support this -configuration. - Master network devices ---------------------- @@ -663,6 +650,22 @@ Bridge layer CPU port, and flooding towards the CPU port should also be enabled, due to a lack of an explicit address filtering mechanism in the DSA core. +- ``port_bridge_tx_fwd_offload``: bridge layer function invoked after + ``port_bridge_join`` when a driver sets ``ds->num_fwd_offloading_bridges`` to + a non-zero value. Returning success in this function activates the TX + forwarding offload bridge feature for this port, which enables the tagging + protocol driver to inject data plane packets towards the bridging domain that + the port is a part of. Data plane packets are subject to FDB lookup, hardware + learning on the CPU port, and do not override the port STP state. + Additionally, replication of data plane packets (multicast, flooding) is + handled in hardware and the bridge driver will transmit a single skb for each + packet that needs replication. The method is provided as a configuration + point for drivers that need to configure the hardware for enabling this + feature. + +- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoken when a driver + leaves a bridge port which had the TX forwarding offload feature enabled. + Bridge VLAN filtering --------------------- diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index da4057ba37f1..564caeebe2b2 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -65,199 +65,6 @@ If that changed setting can be transmitted to the switch through the dynamic reconfiguration interface, it is; otherwise the switch is reset and reprogrammed with the updated static configuration. -Traffic support -=============== - -The switches do not have hardware support for DSA tags, except for "slow -protocols" for switch control as STP and PTP. For these, the switches have two -programmable filters for link-local destination MACs. -These are used to trap BPDUs and PTP traffic to the master netdevice, and are -further used to support STP and 1588 ordinary clock/boundary clock -functionality. For frames trapped to the CPU, source port and switch ID -information is encoded by the hardware into the frames. - -But by leveraging ``CONFIG_NET_DSA_TAG_8021Q`` (a software-defined DSA tagging -format based on VLANs), general-purpose traffic termination through the network -stack can be supported under certain circumstances. - -Depending on VLAN awareness state, the following operating modes are possible -with the switch: - -- Mode 1 (VLAN-unaware): a port is in this mode when it is used as a standalone - net device, or when it is enslaved to a bridge with ``vlan_filtering=0``. -- Mode 2 (fully VLAN-aware): a port is in this mode when it is enslaved to a - bridge with ``vlan_filtering=1``. Access to the entire VLAN range is given to - the user through ``bridge vlan`` commands, but general-purpose (anything - other than STP, PTP etc) traffic termination is not possible through the - switch net devices. The other packets can be still by user space processed - through the DSA master interface (similar to ``DSA_TAG_PROTO_NONE``). -- Mode 3 (best-effort VLAN-aware): a port is in this mode when enslaved to a - bridge with ``vlan_filtering=1``, and the devlink property of its parent - switch named ``best_effort_vlan_filtering`` is set to ``true``. When - configured like this, the range of usable VIDs is reduced (0 to 1023 and 3072 - to 4094), so is the number of usable VIDs (maximum of 7 non-pvid VLANs per - port*), and shared VLAN learning is performed (FDB lookup is done only by - DMAC, not also by VID). - -To summarize, in each mode, the following types of traffic are supported over -the switch net devices: - -+-------------+-----------+--------------+------------+ -| | Mode 1 | Mode 2 | Mode 3 | -+=============+===========+==============+============+ -| Regular | Yes | No | Yes | -| traffic | | (use master) | | -+-------------+-----------+--------------+------------+ -| Management | Yes | Yes | Yes | -| traffic | | | | -| (BPDU, PTP) | | | | -+-------------+-----------+--------------+------------+ - -To configure the switch to operate in Mode 3, the following steps can be -followed:: - - ip link add dev br0 type bridge - # swp2 operates in Mode 1 now - ip link set dev swp2 master br0 - # swp2 temporarily moves to Mode 2 - ip link set dev br0 type bridge vlan_filtering 1 - [ 61.204770] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering - [ 61.239944] sja1105 spi0.1: Disabled switch tagging - # swp3 now operates in Mode 3 - devlink dev param set spi/spi0.1 name best_effort_vlan_filtering value true cmode runtime - [ 64.682927] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering - [ 64.711925] sja1105 spi0.1: Enabled switch tagging - # Cannot use VLANs in range 1024-3071 while in Mode 3. - bridge vlan add dev swp2 vid 1025 untagged pvid - RTNETLINK answers: Operation not permitted - bridge vlan add dev swp2 vid 100 - bridge vlan add dev swp2 vid 101 untagged - bridge vlan - port vlan ids - swp5 1 PVID Egress Untagged - - swp2 1 PVID Egress Untagged - 100 - 101 Egress Untagged - - swp3 1 PVID Egress Untagged - - swp4 1 PVID Egress Untagged - - br0 1 PVID Egress Untagged - bridge vlan add dev swp2 vid 102 - bridge vlan add dev swp2 vid 103 - bridge vlan add dev swp2 vid 104 - bridge vlan add dev swp2 vid 105 - bridge vlan add dev swp2 vid 106 - bridge vlan add dev swp2 vid 107 - # Cannot use mode than 7 VLANs per port while in Mode 3. - [ 3885.216832] sja1105 spi0.1: No more free subvlans - -\* "maximum of 7 non-pvid VLANs per port": Decoding VLAN-tagged packets on the -CPU in mode 3 is possible through VLAN retagging of packets that go from the -switch to the CPU. In cross-chip topologies, the port that goes to the CPU -might also go to other switches. In that case, those other switches will see -only a retagged packet (which only has meaning for the CPU). So if they are -interested in this VLAN, they need to apply retagging in the reverse direction, -to recover the original value from it. This consumes extra hardware resources -for this switch. There is a maximum of 32 entries in the Retagging Table of -each switch device. - -As an example, consider this cross-chip topology:: - - +-------------------------------------------------+ - | Host SoC | - | +-------------------------+ | - | | DSA master for embedded | | - | | switch (non-sja1105) | | - | +--------+-------------------------+--------+ | - | | embedded L2 switch | | - | | | | - | | +--------------+ +--------------+ | | - | | |DSA master for| |DSA master for| | | - | | | SJA1105 1 | | SJA1105 2 | | | - +--+---+--------------+-----+--------------+---+--+ - - +-----------------------+ +-----------------------+ - | SJA1105 switch 1 | | SJA1105 switch 2 | - +-----+-----+-----+-----+ +-----+-----+-----+-----+ - |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| - +-----+-----+-----+-----+ +-----+-----+-----+-----+ - -To reach the CPU, SJA1105 switch 1 (spi/spi2.1) uses the same port as is uses -to reach SJA1105 switch 2 (spi/spi2.2), which would be port 4 (not drawn). -Similarly for SJA1105 switch 2. - -Also consider the following commands, that add VLAN 100 to every sja1105 user -port:: - - devlink dev param set spi/spi2.1 name best_effort_vlan_filtering value true cmode runtime - devlink dev param set spi/spi2.2 name best_effort_vlan_filtering value true cmode runtime - ip link add dev br0 type bridge - for port in sw1p0 sw1p1 sw1p2 sw1p3 \ - sw2p0 sw2p1 sw2p2 sw2p3; do - ip link set dev $port master br0 - done - ip link set dev br0 type bridge vlan_filtering 1 - for port in sw1p0 sw1p1 sw1p2 sw1p3 \ - sw2p0 sw2p1 sw2p2; do - bridge vlan add dev $port vid 100 - done - ip link add link br0 name br0.100 type vlan id 100 && ip link set dev br0.100 up - ip addr add 192.168.100.3/24 dev br0.100 - bridge vlan add dev br0 vid 100 self - - bridge vlan - port vlan ids - sw1p0 1 PVID Egress Untagged - 100 - - sw1p1 1 PVID Egress Untagged - 100 - - sw1p2 1 PVID Egress Untagged - 100 - - sw1p3 1 PVID Egress Untagged - 100 - - sw2p0 1 PVID Egress Untagged - 100 - - sw2p1 1 PVID Egress Untagged - 100 - - sw2p2 1 PVID Egress Untagged - 100 - - sw2p3 1 PVID Egress Untagged - - br0 1 PVID Egress Untagged - 100 - -SJA1105 switch 1 consumes 1 retagging entry for each VLAN on each user port -towards the CPU. It also consumes 1 retagging entry for each non-pvid VLAN that -it is also interested in, which is configured on any port of any neighbor -switch. - -In this case, SJA1105 switch 1 consumes a total of 11 retagging entries, as -follows: - -- 8 retagging entries for VLANs 1 and 100 installed on its user ports - (``sw1p0`` - ``sw1p3``) -- 3 retagging entries for VLAN 100 installed on the user ports of SJA1105 - switch 2 (``sw2p0`` - ``sw2p2``), because it also has ports that are - interested in it. The VLAN 1 is a pvid on SJA1105 switch 2 and does not need - reverse retagging. - -SJA1105 switch 2 also consumes 11 retagging entries, but organized as follows: - -- 7 retagging entries for the bridge VLANs on its user ports (``sw2p0`` - - ``sw2p3``). -- 4 retagging entries for VLAN 100 installed on the user ports of SJA1105 - switch 1 (``sw1p0`` - ``sw1p3``). - Switching features ================== @@ -282,33 +89,10 @@ untagged), and therefore this mode is also supported. Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but all bridges should have the same level of VLAN awareness (either both have -``vlan_filtering`` 0, or both 1). Also an inevitable limitation of the fact -that VLAN awareness is global at the switch level is that once a bridge with -``vlan_filtering`` enslaves at least one switch port, the other un-bridged -ports are no longer available for standalone traffic termination. +``vlan_filtering`` 0, or both 1). Topology and loop detection through STP is supported. -L2 FDB manipulation (add/delete/dump) is currently possible for the first -generation devices. Aging time of FDB entries, as well as enabling fully static -management (no address learning and no flooding of unknown traffic) is not yet -configurable in the driver. - -A special comment about bridging with other netdevices (illustrated with an -example): - -A board has eth0, eth1, swp0@eth1, swp1@eth1, swp2@eth1, swp3@eth1. -The switch ports (swp0-3) are under br0. -It is desired that eth0 is turned into another switched port that communicates -with swp0-3. - -If br0 has vlan_filtering 0, then eth0 can simply be added to br0 with the -intended results. -If br0 has vlan_filtering 1, then a new br1 interface needs to be created that -enslaves eth0 and eth1 (the DSA master of the switch ports). This is because in -this mode, the switch ports beneath br0 are not capable of regular traffic, and -are only used as a conduit for switchdev operations. - Offloads ======== diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index c86628e6a235..d9b55b7a1a4d 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -595,6 +595,14 @@ Link extended substates: that is not formally supported, which led to signal integrity issues + + ``ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_REFERENCE_CLOCK_LOST`` The external clock signal for + SerDes is too weak or + unavailable. + + ``ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_ALOS`` The received signal for + SerDes is too weak because + analog loss of signal. ================================================================= ============================= Cable issue substates: @@ -939,12 +947,25 @@ Kernel response contents: ``ETHTOOL_A_COALESCE_TX_USECS_HIGH`` u32 delay (us), high Tx ``ETHTOOL_A_COALESCE_TX_MAX_FRAMES_HIGH`` u32 max packets, high Tx ``ETHTOOL_A_COALESCE_RATE_SAMPLE_INTERVAL`` u32 rate sampling interval + ``ETHTOOL_A_COALESCE_USE_CQE_TX`` bool timer reset mode, Tx + ``ETHTOOL_A_COALESCE_USE_CQE_RX`` bool timer reset mode, Rx =========================================== ====== ======================= Attributes are only included in reply if their value is not zero or the corresponding bit in ``ethtool_ops::supported_coalesce_params`` is set (i.e. they are declared as supported by driver). +Timer reset mode (``ETHTOOL_A_COALESCE_USE_CQE_TX`` and +``ETHTOOL_A_COALESCE_USE_CQE_RX``) controls the interaction between packet +arrival and the various time based delay parameters. By default timers are +expected to limit the max delay between any packet arrival/departure and a +corresponding interrupt. In this mode timer should be started by packet +arrival (sometimes delivery of previous interrupt) and reset when interrupt +is delivered. +Setting the appropriate attribute to 1 will enable ``CQE`` mode, where +each packet event resets the timer. In this mode timer is used to force +the interrupt if queue goes idle, while busy queues depend on the packet +limit to trigger interrupts. COALESCE_SET ============ @@ -977,6 +998,8 @@ Request contents: ``ETHTOOL_A_COALESCE_TX_USECS_HIGH`` u32 delay (us), high Tx ``ETHTOOL_A_COALESCE_TX_MAX_FRAMES_HIGH`` u32 max packets, high Tx ``ETHTOOL_A_COALESCE_RATE_SAMPLE_INTERVAL`` u32 rate sampling interval + ``ETHTOOL_A_COALESCE_USE_CQE_TX`` bool timer reset mode, Tx + ``ETHTOOL_A_COALESCE_USE_CQE_RX`` bool timer reset mode, Rx =========================================== ====== ======================= Request is rejected if it attributes declared as unsupported by driver (i.e. diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 76d939e688b8..b0d4da71e68e 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -45,3 +45,15 @@ allow_join_initial_addr_port - BOOLEAN This is a per-namespace sysctl. Default: 1 + +stale_loss_cnt - INTEGER + The number of MPTCP-level retransmission intervals with no traffic and + pending outstanding data on a given subflow required to declare it stale. + The packet scheduler ignores stale subflows. + A low stale_loss_cnt value allows for fast active-backup switch-over, + an high value maximize links utilization on edge scenarios e.g. lossy + link with high BER or peer pausing the data processing. + + This is a per-namespace sysctl. + + Default: 4 diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index 024d784157c8..34ca762ea56f 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -184,6 +184,13 @@ nf_conntrack_gre_timeout_stream - INTEGER (seconds) This extended timeout will be used in case there is an GRE stream detected. +nf_hooks_lwtunnel - BOOLEAN + - 0 - disabled (default) + - not 0 - enabled + + If this option is enabled, the lightweight tunnel netfilter hooks are + enabled. This option cannot be disabled once it is enabled. + nf_flowtable_tcp_timeout - INTEGER (seconds) default 30 diff --git a/Documentation/networking/pktgen.rst b/Documentation/networking/pktgen.rst index 7afa1c9f1183..1225f0f63ff0 100644 --- a/Documentation/networking/pktgen.rst +++ b/Documentation/networking/pktgen.rst @@ -248,26 +248,24 @@ Usage::: -i : ($DEV) output interface/device (required) -s : ($PKT_SIZE) packet size - -d : ($DEST_IP) destination IP + -d : ($DEST_IP) destination IP. CIDR (e.g. 198.18.0.0/15) is also allowed -m : ($DST_MAC) destination MAC-addr + -p : ($DST_PORT) destination PORT range (e.g. 433-444) is also allowed -t : ($THREADS) threads to start + -f : ($F_THREAD) index of first thread (zero indexed CPU number) -c : ($SKB_CLONE) SKB clones send before alloc new SKB + -n : ($COUNT) num messages to send per thread, 0 means indefinitely -b : ($BURST) HW level bursting of SKBs -v : ($VERBOSE) verbose -x : ($DEBUG) debug + -6 : ($IP6) IPv6 + -w : ($DELAY) Tx Delay value (ns) + -a : ($APPEND) Script will not reset generator's state, but will append its config The global variables being set are also listed. E.g. the required interface/device parameter "-i" sets variable $DEV. Copy the pktgen_sampleXX scripts and modify them to fit your own needs. -The old scripts:: - - pktgen.conf-1-2 # 1 CPU 2 dev - pktgen.conf-1-1-rdos # 1 CPU 1 dev w. route DoS - pktgen.conf-1-1-ip6 # 1 CPU 1 dev ipv6 - pktgen.conf-1-1-ip6-rdos # 1 CPU 1 dev ipv6 w. route DoS - pktgen.conf-1-1-flows # 1 CPU 1 dev multiple flows. - Interrupt affinity =================== @@ -398,7 +396,7 @@ Current commands and configuration options References: - ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/ -- tp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/ +- ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/ Paper from Linux-Kongress in Erlangen 2004. - ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/pktgen_paper.pdf diff --git a/Documentation/networking/vrf.rst b/Documentation/networking/vrf.rst index 0dde145043bc..0a9a6f968cb9 100644 --- a/Documentation/networking/vrf.rst +++ b/Documentation/networking/vrf.rst @@ -144,6 +144,19 @@ default VRF are only handled by a socket not bound to any VRF:: netfilter rules on the VRF device can be used to limit access to services running in the default VRF context as well. +Using VRF-aware applications (applications which simultaneously create sockets +outside and inside VRFs) in conjunction with ``net.ipv4.tcp_l3mdev_accept=1`` +is possible but may lead to problems in some situations. With that sysctl +value, it is unspecified which listening socket will be selected to handle +connections for VRF traffic; ie. either a socket bound to the VRF or an unbound +socket may be used to accept new connections from a VRF. This somewhat +unexpected behavior can lead to problems if sockets are configured with extra +options (ex. TCP MD5 keys) with the expectation that VRF traffic will +exclusively be handled by sockets bound to VRFs, as would be the case with +``net.ipv4.tcp_l3mdev_accept=0``. Finally and as a reminder, regardless of +which listening socket is selected, established sockets will be created in the +VRF based on the ingress interface, as documented earlier. + -------------------------------------------------------------------------------- Using iproute2 for VRFs |