- 30 Nov, 2023 40 commits
-
-
Kuniyuki Iwashima authored
We will support arbitrary SYN Cookie with BPF, and then kfunc at TC will preallocate reqsk and initialise some fields that should not be overwritten later by cookie_v[46]_check(). To simplify the flow in cookie_v[46]_check(), we move such fields' initialisation to cookie_tcp_reqsk_alloc() and factorise non-BPF SYN Cookie handling into cookie_tcp_check(), where we validate the cookie and allocate reqsk, as done by kfunc later. Note that we set ireq->ecn_ok in two steps, the latter of which will be shared by the BPF case. As cookie_ecn_ok() is one-liner, now it's inlined. Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
Simon Horman <horms@kernel.org> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20231129022924.96156-9-kuniyu@amazon.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Kuniyuki Iwashima authored
We will support arbitrary SYN Cookie with BPF, and then some reqsk fields are initialised in kfunc, and others are done in cookie_v[46]_check(). This patch factorises the common part as cookie_tcp_reqsk_init() and calls it in cookie_tcp_reqsk_alloc() to minimise the discrepancy between cookie_v[46]_check(). Signed-off-by:
-
Kuniyuki Iwashima authored
We initialise treq->af_specific in cookie_tcp_reqsk_alloc() so that we can look up a key later in tcp_create_openreq_child(). Initially, that change was added for MD5 by commit ba5a4fdd ("tcp: make sure treq->af_specific is initialized"), but it has not been used since commit d0f2b7a9 ("tcp: Disable header prediction for MD5 flow."). Now, treq->af_specific is used only by TCP-AO, so, we can move that initialisation into tcp_ao_syncookie(). In addition to that, l3index in cookie_v[46]_check() is only used for tcp_ao_syncookie(), so let's move it as well. While at it, we move down tcp_ao_syncookie() in cookie_v4_check() so that it will be called after security_inet_conn_request() to make functions order consistent with cookie_v6_check(). Signed-off-by:
-
Kuniyuki Iwashima authored
When we create a full socket from SYN Cookie, we initialise tcp_sk(sk)->tsoffset redundantly in tcp_get_cookie_sock() as the field is inherited from tcp_rsk(req)->ts_off. cookie_v[46]_check |- treq->ts_off = 0 `- tcp_get_cookie_sock |- tcp_v[46]_syn_recv_sock | `- tcp_create_openreq_child | `- newtp->tsoffset = treq->ts_off `- tcp_sk(child)->tsoffset = tsoff Let's initialise tcp_rsk(req)->ts_off with the correct offset and remove the second initialisation of tcp_sk(sk)->tsoffset. Signed-off-by: -
Kuniyuki Iwashima authored
tcp_hdr(skb) and SYN Cookie are passed to __cookie_v[46]_check(), but none of the callers passes cookie other than ntohl(th->ack_seq) - 1. Let's fetch it in __cookie_v[46]_check() instead of passing the cookie over and over. Signed-off-by:
-
Kuniyuki Iwashima authored
We will support arbitrary SYN Cookie with BPF, and then reqsk will be preallocated before cookie_v[46]_check(). Depending on how validation fails, we send RST or just drop skb. To make the error handling easier, let's clean up goto labels. Signed-off-by:
-
Kuniyuki Iwashima authored
sock_net(sk) is used repeatedly in cookie_v[46]_check(). Let's cache it in a variable. Signed-off-by:
-
Kuniyuki Iwashima authored
We will grow and cut the xmas tree in cookie_v[46]_check(). This patch cleans it up to make later patches tidy. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in struct field hc_tx_err_sqpdid_enforecement. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
Shradha Gupta <shradhagupta@linux.microsoft.com> Link: https://lore.kernel.org/r/20231128095304.515492-1-colin.i.king@gmail.comSigned-off-by:
-
Andy Shevchenko authored
BYTES_PER_KBIT is defined in units.h, use that definition. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20231128175027.394754-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: More selftest coverage and code cleanup for net-next Patches 1-5 and 7-8 add selftest coverage (and an associated subflow counter in the kernel) to validate the recently-updated handling of subflows with ID 0. Patch 6 renames a label in the userspace path manager for clarity. Patches 9-11 and 13-15 factor out common selftest code by moving certain functions to mptcp_lib.sh Patch 12 makes sure the random data file generated for selftest payloads has the intended size. v3: https://lore.kernel.org/r/20231115-send-net-next-2023107-v3-0-1ef58145a882@kernel.org v2: https://lore.kernel.org/r/20231114-send-net-next-2023107-v2-0-b650a477362c@kernel.org v1: https://lore.kernel.org/r/20231027-send-net-next-2023107-v1-0-03eff9452957@kernel.org ==================== Link: https://lore.kernel.org/r/20231128-send-net-next-2023107-v4-0-8d6b94150f6b@kernel.orgSigned-off-by:
-
Geliang Tang authored
To avoid duplicated code in different MPTCP selftests, we can add and use helpers defined in mptcp_lib.sh. wait_local_port_listen() helper is defined in diag.sh, mptcp_connect.sh, mptcp_join.sh and simult_flows.sh, export it into mptcp_lib.sh and rename it with mptcp_lib_ prefix. Use this new helper in all these scripts. Note: We only have IPv4 connections in this helper, not looking at IPv6 (tcp6) but that's OK because we only have IPv4 connections here in diag.sh. Reviewed-by:
Matthieu Baerts <matttbe@kernel.org> Signed-off-by:
Geliang Tang <geliang.tang@suse.com> Signed-off-by:
Mat Martineau <martineau@kernel.org> Link: https://lore.kernel.org/r/20231128-send-net-next-2023107-v4-15-8d6b94150f6b@kernel.orgSigned-off-by:
-
Geliang Tang authored
To avoid duplicated code in different MPTCP selftests, we can add and use helpers defined in mptcp_lib.sh. check_transfer() and print_file_err() helpers are defined both in mptcp_connect.sh and mptcp_sockopt.sh, export them into mptcp_lib.sh and rename them with mptcp_lib_ prefix. And use them in all scripts. Note: In mptcp_sockopt.sh it is OK to drop 'ret=1' in check_transfer() because it will be set in run_tests() anyway. Reviewed-by:
-
Geliang Tang authored
To avoid duplicated code in different MPTCP selftests, we can add and use helpers defined in mptcp_lib.sh. make_file() helper in mptcp_sockopt.sh and userspace_pm.sh are the same. Export it into mptcp_lib.sh and rename it as mptcp_lib_kill_wait(). Use it in both mptcp_connect.sh and mptcp_join.sh. Reviewed-by:
-
Geliang Tang authored
In mptcp_connect.sh we are missing something like "oflag=append" because this will write "${rem}" bytes at the beginning of the file where there is already some random bytes. It should write that at the end. This patch adds this missing 'oflag=append' flag for 'dd' command in make_file(). Suggested-by: -
Geliang Tang authored
To avoid duplicated code in different MPTCP selftests, we can add and use helpers defined in mptcp_lib.sh. The helper get_counter() in mptcp_join.sh and get_mib_counter() in mptcp_connect.sh have the same functionality, export get_counter() into mptcp_lib.sh and rename it as mptcp_lib_get_counter(). Use this new helper instead of get_counter() and get_mib_counter(). Use this helper in test_prio() in userspace_pm.sh too instead of open-coding. Reviewed-by:
-
Geliang Tang authored
To avoid duplicated code in different MPTCP selftests, we can add and use helpers defined in mptcp_lib.sh. is_v6() helper is defined in mptcp_connect.sh, mptcp_join.sh and mptcp_sockopt.sh, so export it into mptcp_lib.sh and rename it as mptcp_lib_is_v6(). Use this new helper in all scripts. Reviewed-by:
-
Geliang Tang authored
To avoid duplicated code in different MPTCP selftests, we can add and use helpers defined in mptcp_lib.sh. Export kill_wait() helper in userspace_pm.sh into mptcp_lib.sh and rename it as mptcp_lib_kill_wait(). It can be used to instead of kill_wait() in mptcp_join.sh. Use the new helper in both scripts. Reviewed-by:
-
Geliang Tang authored
This patch adds a selftest for userspace PM to remove id 0 address. Use userspace_pm_add_addr() helper to add an id 10 address, then use userspace_pm_rm_addr() helper to remove id 0 address. Reviewed-by:
-
Geliang Tang authored
This patch adds a selftest for userspace PM to remove the initial subflow. Use userspace_pm_add_sf() to add a subflow, and pass initial IP address to userspace_pm_rm_sf() to remove the initial subflow. Reviewed-by:
-
Geliang Tang authored
The value of 'err' will not be only '-EINVAL', but can be '0' in some cases. So it's better to rename the label 'remove_err' to 'out' to avoid confusions. Suggested-by:
-
Geliang Tang authored
This patch adds a selftest to create id 0 subflow. Pass id 0 to the helper userspace_pm_add_sf() to create id 0 subflow. chk_mptcp_info shows one subflow but chk_subflows_total shows two subflows in each namespace. Reviewed-by:
-
Geliang Tang authored
This patch adds a new argument namespace to userspace_pm_add_addr() and userspace_pm_add_sf() to make these two helper more versatile. Add two more versatile helpers for userspace pm remove subflow or address: userspace_pm_rm_addr() and userspace_pm_rm_sf(). The original test helpers userspace_pm_rm_sf_addr_ns1() and userspace_pm_rm_sf_addr_ns2() can be replaced by these new helpers. Reviewed-by:
-
Geliang Tang authored
This patch adds a new helper chk_subflows_total(), in it use the newly added counter mptcpi_subflows_total to get the "correct" amount of subflows, including the initial one. To be compatible with old 'ss' or kernel versions not supporting this counter, get the total subflows by listing TCP connections that are MPTCP subflows: ss -ti state state established state syn-sent state syn-recv | grep -c tcp-ulp-mptcp. Reviewed-by: -
Geliang Tang authored
This patch adds a new helper get_info_value(), using 'sed' command to parse the value of the given item name in the line with the given keyword, to make chk_mptcp_info() and pedit_action_pkts() more readable. Also add another helper evts_get_info() to use get_info_value() to parse the output of 'pm_nl_ctl events' command, to make all the userspace pm selftests more readable, both in mptcp_join.sh and userspace_pm.sh. Reviewed-by:
-
Geliang Tang authored
If the initial subflow has been removed, we cannot know without checking other counters, e.g. ss -ti <filter> | grep -c tcp-ulp-mptcp or getsockopt(SOL_MPTCP, MPTCP_FULL_INFO, ...) (or others except MPTCP_INFO of course) and then check mptcp_subflow_data->num_subflows to get the total amount of subflows. This patch adds a new counter mptcpi_subflows_total in mptcpi_flags to store the total amount of subflows, including the initial one. A new helper __mptcp_has_initial_subflow() is added to check whether the initial subflow has been removed or not. With this helper, we can then compute the total amount of subflows from mptcp_info by doing something like: mptcpi_subflows_total = mptcpi_subflows + __mptcp_has_initial_subflow(msk). Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/428Reviewed-by: -
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Support CFF flood mode The registers to configure to initialize a flood table differ between the controlled and CFF flood modes. In therefore needs to be an op. Add it, hook up the current init to the existing families, and invoke the op. PGT is an in-HW table that maps addresses to sets of ports. Then when some HW process needs a set of ports as an argument, instead of embedding the actual set in the dynamic configuration, what gets configured is the address referencing the set. The HW then works with the appropriate PGT entry. Among other allocations, the PGT currently contains two large blocks for bridge flooding: one for 802.1q and one for 802.1d. Within each of these blocks are three tables, for unknown-unicast, multicast and broadcast flooding: . . . | 802.1q | 802.1d | . . . | UC | MC | BC | UC | MC | BC | \______ _____/ \_____ ______/ v v FID flood vectors Thus each FID (which corresponds to an 802.1d bridge or one VLAN in an 802.1q bridge) uses three flood vectors spread across a fairly large region of PGT. This way of organizing the flood table (called "controlled") is not very flexible. E.g. to decrease a bridge scale and store more IP MC vectors, one would need to completely rewrite the bridge PGT blocks, or resort to hacks such as storing individual MC flood vectors into unused part of the bridge table. In order to address these shortcomings, Spectrum-2 and above support what is called CFF flood mode, for Compressed FID Flooding. In CFF flood mode, each FID has a little table of its own, with three entries adjacent to each other, one for unknown-UC, one for MC, one for BC. This allows for a much more fine-grained approach to PGT management, where bits of it are allocated on demand. . . . | FID | FID | FID | FID | FID | . . . |U|M|B|U|M|B|U|M|B|U|M|B|U|M|B| \_____________ _____________/ v FID flood vectors Besides the FID table organization, the CFF flood mode also impacts Router Subport (RSP) table. This table contains flood vectors for rFIDs, which are FIDs that reference front panel ports or LAGs. The RSP table contains two entries per front panel port and LAG, one for unknown-UC traffic, and one for everything else. Currently, the FW allocates and manages the table in its own part of PGT. rFIDs are marked with flood_rsp bit and managed specially. In CFF mode, rFIDs are managed as all other FIDs. The driver therefore has to allocate and maintain the flood vectors. Like with bridge FIDs, this is more work, but increases flexibility of the system. The FW currently supports both the controlled and CFF flood modes. To shed complexity, in the future it should only support CFF flood mode. Hence this patchset, which adds CFF flood mode support to mlxsw. Since mlxsw needs to maintain both the controlled mode as well as CFF mode support, we will keep the layout as compatible as possible. The bridge tables will stay in the same overall shape, just their inner organization will change from flood mode -> FID to FID -> flood mode. Likewise will RSP be kept as a contiguous block of PGT memory, as was the case when the FW maintained it. - The way FIDs get configured under the CFF flood mode differs from the currently used controlled mode. The simple approach of having several globally visible arrays for spectrum.c to statically choose from no longer works. Patch #1 thus privatizes all FID initialization and finalization logic, and exposes it as ops instead. - Patch #2 renames the ops that are specific to the controlled mode, to make room in the namespace for the CFF variants. Patch #3 extracts a helper to compute flood table base out of mlxsw_sp_fid_flood_table_mid(). - The op fid_setup configured fid_offset, i.e. the number of this FID within its family. For rFIDs in CFF mode, to determine this number, the driver will need to do fallible queries. Thus in patch #4, make the FID setup operation fallible as well. - Flood mode initialization routine differs between the controlled and CFF flood modes. The controlled mode needs to configure flood table layout, which the CFF mode does not need to do. In patch #5, move mlxsw_sp_fid_flood_table_init() up so that the following patch can make use of it. In patch #6, add an op to be invoked per table (if defined). - The current way of determining PGT allocation size depends on the number of FIDs and number of flood tables. RFIDs however have PGT footprint depending not on number of FIDs, but on number of ports and LAGs, because which ports an rFID should flood to does not depend on the FID itself, but on the port or LAG that it references. Therefore in patch #7, add FID family ops for determining PGT allocation size. - As elaborated above, layout of PGT will differ between controlled and CFF flood modes. In CFF mode, it will further differ between rFIDs and other FIDs (as described at previous patch). The way to pack the SFMR register to configure a FID will likewise differ from controlled to CFF. Thus in patches #8 and #9 add FID family ops to determine PGT base address for a FID and to pack SFMR. - Patches #10 and #11 add more bits for RSP support. In patch #10, add a new traffic type enumerator, for non-UC traffic. This is a combination of BC and MC traffic, but the way that mlxsw maps these mnemonic names to actual traffic type configurations requires that we have a new name to describe this class of traffic. Patch #11 then adds hooks necessary for RSP table maintenance. As ports come and go, and join and leave LAGs, it is necessary to update flood vectors that the rFIDs use. These new hooks will make that possible. - Patches #12, #13 and #14 introduce flood profiles. These have been implicit so far, but the way that CFF flood mode works with profile IDs requires that we make them explicit. Thus in patch #12, introduce flood profile objects as a set of flood tables that FID families then refer to. The FID code currently only uses a single flood profile. In patch #13, add a flood profile ID to flood profile objects. In patch #14, when in CFF mode, configure SFFP according to the existing flood profiles (or the one that exists as of that point). - Patches #15 and #16 add code to implement, respectively, bridge FIDs and RSP FIDs in CFF mode. - In patch #17, toggle flood_mode_prefer_cff on Spectrum-2 and above, which makes the newly-added code live. ==================== Link: https://lore.kernel.org/r/cover.1701183891.git.petrm@nvidia.comSigned-off-by: -
Petr Machata authored
Mark all Spectrum>2 systems as preferring CFF flood mode if supported by the firmware. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/8a3d2ad96b943f7e3f53f998bd333a14e19cd641.1701183892.git.petrm@nvidia.comSigned-off-by:
-
Petr Machata authored
In this patch, add the artifacts for the rFID family that works in CFF flood mode. The same that was said about PGT organization and lookup in bridge FID families applies for the rFID family as well. The main difference lies in the fact that in the controlled flood mode, the FW was taking care of maintaining the PGT tables for rFIDs. In CFF mode, the responsibility shifts to the driver. All rFIDs are based off either a front panel port, or a LAG port. For those based off ports, we need to maintain at worst one PGT block for each port, for those based off LAGs, one PGT block per LAG. This reflects in the pgt_size callback, which determines the PGT footprint based on number of ports and the LAG capacity. A number of FIDs may end up using the same PGT base. Unlike with bridges, where membership of a port in a given FID is highly dynamic, an rFID based of a port will just always need to flood to that port. Both the port and the LAG subtables need to be actively maintained. To that end, the CFF rFID family implements fid_port_init and fid_port_fini callbacks, which toggle the necessary bits. Both FID-MID translation and SFMR packing then point into either the port or the LAG subtable, to the block that corresponds to a given port or a given LAG, depending on what port the RIF bound to the rFID uses. As in the previous patch, the way CFF flood mode organizes PGT accesses allows for much more smarts and dynamism. As in the previous patch, we rather aim to keep things simple and static. Signed-off-by:
-
Petr Machata authored
In this patch, add the artifacts for 802.1d and 802.1q FID families that work in CFF flood mode. In CFF flood mode, the way flood vectors are looked up changes: there's a per-FID PGT base, to which a small offset is added depending on type of traffic. Thus each FID occupies a small contiguous block of PGT memory, whereas in the controlled flood mode, flood vectors for a given FID were spread across the PGT. The term "flood table" as used by the spectrum_fid module, borrows from controlled flood mode way of organizing the PGT table. There flood tables were actual tables, contiguous in the PGT. In the CFF flood mode, they are more abstract: a flood table becomes a collection of e.g. all first rows of the per-FID PGT blocks. Nonetheless we retain the nomenclature. FIDs are still configured through the SFMR register, but there are different fields to set under CFF mode: PGT base and profile. Thus register packing gets a dedicated op overload as well. The new organization of PGT makes it possible to treat the PGT as a block of an ordinary memory, allocate and deallocate on demand, and achieve better flexibility. Here instead, we aim to keep the code as close as possible to the previous controlled flood mode, support for which we need to retain for Spectrum-1 and older FW versions anyway. Thus the PGT footprint of the individual families is the same as before, just the internal organization of the per-family PGT region differs. Hence the pgt_size callback is reused between the controlled and CFF flood modes. Since the dummy family has no flood tables in either the CTL mode or in CFF mode, the existing one can be reused for the CFF family array. Users should not notice any changes between the controlled and CFF flood modes. Signed-off-by:
-
Petr Machata authored
In CFF flood mode, the way flood vectors are looked up changes: there's a per-FID PGT base, to which a small offset is added depending on type of traffic. Thus each FID occupies a small contiguous block of PGT memory, whereas in the controlled flood mode, flood vectors for a given FID were spread across the PGT. Each FID is associated with one of a handful of profiles. The profile and the traffic type are then used as keys to look up the PGT offset. This offset is then added to the per-FID PGT base. The profile / type / offset mapping needs to be configured by the driver, and is only relevant in CFF flood mode. In this patch, add the SFFP initialization code. Only initialize the one profile currently explicitly used. As follow-up patch add more profiles, this code will pick them up and initialize as well. Signed-off-by:
-
Petr Machata authored
In the CFF mode, flood profiles are identified by a unique numerical identifier. This is used for configuration of FIDs and for configuration of traffic-type to PGT offset rules. In both cases, the numerical identifier serves as a handle for the flood profile. Add the identifier to the flood profile structure. There is currently only one flood profile in use explicitly, the one used for all bridging. Eventually three will be necessary in total: one for bridges, one for rFIDs, one for NVE underlay. A total of four profiles are supported by the HW. Start allocating at 1, because 0 is currently used for underlay NVE flood. Signed-off-by:
-
Petr Machata authored
A flood profile is a mapping from traffic type to an offset at which a flood vector should be looked up. In mlxsw so far, a flood profile was somewhat implicitly represented by flood table array. When the CFF flood mode will be introduced, the flood profile will become more explicit: each will get a number and the profile ID / traffic-type / offset mapping will actually need to be initialized in the hardware. Therefore it is going to be handy to have a structure that keeps all the components that compose a flood profile. Add this structure, currently with just the flood table array bits. In the FID families that flood at all, reference the flood profile instead of just the table array. Signed-off-by:
-
Petr Machata authored
In the CFF flood mode, the driver has to allocate a table within PGT, which holds flood vectors for router subport FIDs. For LAGs, these flood vectors have to obviously be maintained dynamically as port membership in a LAG changes. But even for physical ports, the flood vectors have to be kept valid, and may not contain enabled bits corresponding to non-existent ports. It is therefore not possible to precompute the port part of the RSP table, it has to be maintained as ports come and go due to splits. To support the RSP table maintenance, add to FID ops two new ops: fid_port_init and fid_port_fini, for when a port comes to existence, or joins a lag, and vice versa. Invoke these ops from mlxsw_sp_port_fids_init() and mlxsw_sp_port_fids_fini(), which are called when port is added and removed, respectively. Also add two new hooks for LAG maintenance, mlxsw_sp_fid_port_join_lag() / _leave_lag() which transitively call into the same ops. Later patches will actually add the op implementations themselves, this just adds the scaffolding. Signed-off-by:
-
Petr Machata authored
In CFF flood mode, the rFID family will allocate two tables. One for unknown UC traffic, one for everything else. Add a traffic type for the everything else traffic. Signed-off-by:
-
Petr Machata authored
The way SFMR is packed differs between the controlled and CFF flood modes. Add an op to dispatch it dynamically. Signed-off-by:
-
Petr Machata authored
In the CFF flood mode, the way to determine a PGT address where a given FID / flood table resides is different from the controlled flood mode, which mlxsw currently uses. Furthermore, this will differ between rFID family and bridge families. The operation therefore needs to be dynamically dispatched. To that end, add an op to FID-family ops. Signed-off-by:
-
Petr Machata authored
In the CFF flood mode, the PGT allocation size of RFID family will not depend on number of FIDs, but rather number of ports and LAGs. Therefore introduce a FID family operation to calculate the PGT allocation size. The way that size is calculated in the CFF mode depends on calling fallible functions. Thus express the op as returning an int, with the size returned via a pointer argument. Signed-off-by:
-
Petr Machata authored
In controlled flood mode, for each bridge FID family (i.e., 802.1Q and 802.1D) and packet type (i.e., UUC/MC/BC), the hardware needs to be told which PGT address to use as the base address for the flood table and how to determine the offset from the base for each FID. The above is not needed in CFF mode where each FID has its own flood table instead of the FID family itself. Therefore, create a new FID family operation for the above configuration and only implement it for the 802.1Q and 802.1D families in controlled flood mode. No functional changes intended. Signed-off-by:
-
Petr Machata authored
Move the function to the point where it will need to be to be visible for the 802.1d ops. Signed-off-by:
-
