- 03 Aug, 2023 32 commits
-
-
Vladimir Oltean authored
It is desirable that the new .ndo_hwtstamp_set() API gives more uniformity, less overhead and future flexibility w.r.t. the PHY timestamping behavior. Currently there are some drivers which allow PHY timestamping through the procedure mentioned in Documentation/networking/timestamping.rst. They don't do anything locally if phy_has_hwtstamp() is set, except for lan966x which installs PTP packet traps. Centralize that behavior in a new dev_set_hwtstamp_phylib() code function, which calls either phy_mii_ioctl() for the phylib PHY, or .ndo_hwtstamp_set() of the netdev, based on a single policy (currently simplistic: phy_has_hwtstamp()). Any driver converted to .ndo_hwtstamp_set() will automatically opt into the centralized phylib timestamping policy. Unconverted drivers still get to choose whether they let the PHY handle timestamping or not. Netdev drivers with integrated PHY drivers that don't use phylib presumably don't set dev->phydev, and those will always see HWTSTAMP_SOURCE_NETDEV requests even when converted. The timestamping policy will remain 100% up to them. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20230801142824.1772134-13-vladimir.oltean@nxp.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
net/core/dev_ioctl.c (built-in code) will want to call phy_mii_ioctl() for hardware timestamping purposes. This is not directly possible, because phy_mii_ioctl() is a symbol provided under CONFIG_PHYLIB. Do something similar to what was done in DSA in commit 5a178186 ("net: dsa: replace NETDEV_PRE_CHANGE_HWTSTAMP notifier with a stub"), and arrange some indirect calls to phy_mii_ioctl() through a stub structure containing function pointers, that's provided by phylib as built-in even when CONFIG_PHYLIB=m, and which phy_init() populates at runtime (module insertion). Note: maybe the ownership of the ethtool_phy_ops singleton is backwards, and the methods exposed by that should be later merged into phylib_stubs. Signed-off-by:
-
Vladimir Oltean authored
phy_init() and phy_exit() will have to do more stuff under rtnl_lock() in a future change. Since rtnl_unlock() -> netdev_run_todo() does a lot of stuff under the hood, it's a pity to lock and unlock the rtnetlink mutex twice in a row. Change the calling convention such that the only caller of ethtool_set_ethtool_phy_ops(), phy_device.c, provides a context where the rtnl_mutex is already acquired. Signed-off-by:
-
Vladimir Oltean authored
The hardware timestamping through ndo_eth_ioctl() is going away. Convert the lan966x driver to the new API before that can be removed. After removing the timestamping logic from lan966x_port_ioctl(), the rest is equivalent to phy_do_ioctl(). Signed-off-by:
-
Vladimir Oltean authored
The hardware timestamping through ndo_eth_ioctl() is going away. Convert the sparx5 driver to the new API before that can be removed. After removing the timestamping logic from sparx5_port_ioctl(), the rest is equivalent to phy_do_ioctl(). Signed-off-by:
Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/r/20230801142824.1772134-9-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
Commit 34074639 ("net: fec: fix hardware time stamping by external devices") was overly cautious with calling fec_ptp_disable_hwts() when cmd == SIOCSHWTSTAMP and use_fec_hwts == false, because use_fec_hwts is based on a runtime invariant (phy_has_hwtstamp()). Thus, if use_fec_hwts is false, then fep->hwts_tx_en and fep->hwts_rx_en cannot be changed at runtime; their values depend on the initial memory allocation, which already sets them to zeroes. If the core will ever gain support for switching timestamping layers, it will arrange for a more organized calling convention and disable timestamping in the previous layer as a first step. This means that the code in the FEC driver is not necessary in any case. The purpose of this change is to arrange the phy_has_hwtstamp() code in a way in which it can be refactored away into generic logic. Signed-off-by:
Wei Fang <wei.fang@nxp.com> Link: https://lore.kernel.org/r/20230801142824.1772134-8-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
The hardware timestamping through ndo_eth_ioctl() is going away. Convert the FEC driver to the new API before that can be removed. After removing the timestamping logic from fec_enet_ioctl(), the rest is equivalent to phy_do_ioctl_running(). Signed-off-by:
-
Maxim Georgiev authored
bonding is one of the stackable net devices which pass the hardware timestamping ops to the real device through ndo_eth_ioctl(). This prevents converting any device driver to the new hwtimestamping API without regressions. Remove that limitation in bonding by using the newly introduced helpers for timestamping through lower devices, that handle both the new and the old driver API. Signed-off-by:
Maxim Georgiev <glipus@gmail.com> Signed-off-by:
-
Maxim Georgiev authored
macvlan is one of the stackable net devices which pass the hardware timestamping ops to the real device through ndo_eth_ioctl(). This prevents converting any device driver to the new hwtimestamping API without regressions. Remove that limitation in macvlan by using the newly introduced helpers for timestamping through lower devices, that handle both the new and the old driver API. macvlan only implements ndo_eth_ioctl() for these 2 operations, so delete that method. Signed-off-by:
-
Maxim Georgiev authored
8021q is one of the stackable net devices which pass the hardware timestamping ops to the real device through ndo_eth_ioctl(). This prevents converting any device driver to the new hwtimestamping API without regressions. Remove that limitation in the vlan driver by using the newly introduced helpers for timestamping through lower devices, that handle both the new and the old driver API. Signed-off-by:
-
Maxim Georgiev authored
The stackable net devices with hwtstamping support (vlan, macvlan, bonding) only pass the hwtstamping ops to the lower (real) device. These drivers are the first that need to be converted to the new timestamping API, because if they aren't prepared to handle that, then no real device driver cannot be converted to the new API either. After studying what vlan_dev_ioctl(), macvlan_eth_ioctl() and bond_eth_ioctl() have in common, here we propose two generic implementations of ndo_hwtstamp_get() and ndo_hwtstamp_set() which can be called by those 3 drivers, with "dev" being their lower device. These helpers cover both cases, when the lower driver is converted to the new API or unconverted. We need some hacks in case of an unconverted driver, namely to stuff some pointers in struct kernel_hwtstamp_config which shouldn't have been there (since the new API isn't supposed to need it). These will be removed when all drivers will have been converted to the new API. Signed-off-by:
-
Maxim Georgiev authored
Current hardware timestamping API for NICs requires implementing .ndo_eth_ioctl() for SIOCGHWTSTAMP and SIOCSHWTSTAMP. That API has some boilerplate such as request parameter translation between user and kernel address spaces, handling possible translation failures correctly, etc. Since it is the same all across the board, it would be desirable to handle it through generic code. Here we introduce .ndo_hwtstamp_get() and .ndo_hwtstamp_set(), which implement that boilerplate and allow drivers to just act upon requests. Suggested-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: extend alloc_skb_with_frags() max size alloc_skb_with_frags(), while being able to use high order allocations, limits the payload size to PAGE_SIZE * MAX_SKB_FRAGS Reviewing Tahsin Erdogan patch [1], it was clear to me we need to remove this limitation. [1] https://lore.kernel.org/netdev/20230731230736.109216-1-trdgn@amazon.com/ v2: Addressed Willem feedback on 1st patch. ==================== Link: https://lore.kernel.org/r/20230801205254.400094-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
tap_alloc_skb() is currently calling sock_alloc_send_pskb() forcing order-0 page allocations. Switch to PAGE_ALLOC_COSTLY_ORDER, to increase max size by 8x. Also add logic to increase the linear part if needed. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Tahsin Erdogan <trdgn@amazon.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20230801205254.400094-5-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
packet_alloc_skb() is currently calling sock_alloc_send_pskb() forcing order-0 page allocations. Switch to PAGE_ALLOC_COSTLY_ORDER, to increase max size by 8x. Also add logic to increase the linear part if needed. Signed-off-by:
-
Eric Dumazet authored
tun_alloc_skb() is currently calling sock_alloc_send_pskb() forcing order-0 page allocations. Switch to PAGE_ALLOC_COSTLY_ORDER, to increase max allocation size by 8x. Also add logic to increase the linear part if needed. Signed-off-by:
-
Eric Dumazet authored
Refactor alloc_skb_with_frags() to allow bigger packets allocations. Instead of assuming that only order-0 allocations will be attempted, use the caller supplied max order. v2: try harder to use high-order pages, per Willem feedback. Link: https://lore.kernel.org/netdev/CANn89iJQfmc_KeUr3TeXvsLQwo3ZymyoCr7Y6AnHrkWSuz0yAg@mail.gmail.com/Signed-off-by:
-
Yue Haibing authored
These declarations are never implemented since beginning of git history. Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Simon Horman <horms@kernel.org> Acked-by:
Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/20230731141030.32772-1-yuehaibing@huawei.comSigned-off-by:
-
Jakub Kicinski authored
Leon Romanovsky says: ==================== mlx5 IPsec packet offload support in eswitch mode This series from Jianbo adds mlx5 IPsec packet offload support in eswitch offloaded mode. It works exactly like "regular" IPsec, nothing special, except now users can switch to switchdev before adding IPsec rules. devlink dev eswitch set pci/0000:06:00.0 mode switchdev Same configurations as here: https://lore.kernel.org/netdev/cover.1670005543.git.leonro@nvidia.com/ Packet offload mode: ip xfrm state offload packet dev <if-name> dir <in|out> ip xfrm policy .... offload packet dev <if-name> Crypto offload mode: ip xfrm state offload crypto dev <if-name> dir <in|out> or (backward compatibility) ip xfrm state offload dev <if-name> dir <in|out> v0: https://lore.kernel.org/all/cover.1689064922.git.leonro@nvidia.com ==================== Link: https://lore.kernel.org/r/cover.1690802064.git.leon@kernel.orgSigned-off-by:
-
Jianbo Liu authored
For IPsec packet offload mode, the order of TC offload and IPsec offload on the same netdevice is not aligned with the order in the non-offload software. For example, for RX, the software performs TC first and then IPsec transformation, but the implementation for offload does that in the opposite way. To resolve the difference for now, either IPsec offload or TC offload, not both, is allowed for a specific interface. Signed-off-by:
Jianbo Liu <jianbol@nvidia.com> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/8e2e5e3b0984d785066e8663aaf97b3ba1bb873f.1690802064.git.leon@kernel.orgSigned-off-by:
-
Jianbo Liu authored
As IPsec offload is supported in switchdev mode, HW stats can be can be obtained from uplink rep. Signed-off-by:
-
Jianbo Liu authored
After IPsec policy/state TX rules are added, any TC flow rule, which forwards packets to uplink, is modified to forward to IPsec TX tables. As these tables are destroyed dynamically, whenever there is no reference to them, the destinations of this kind of rules must be restored to uplink. There is a special case for packet encapsulation, as the packet_reformat_id in the extended destination is used to reformat packets, but only for the VPORT destination. To forward packet to IPsec table and do encapsulation in one FTE, move the packet_reformat_id to flow context, instead of using the extended destination. As a limitation, multiple encapsulations with table forwarding, and one together with other VPORT destinations, are not allowed, so add a check when offloading TC rules. TC rules are not allowed before IPsec TX rule is added, so only need to restore TC rules after flush IPSec TX rules. As they are saved in the vport_rep rhashtables, we walk all the rules in the rhashtables, and find TC rules with destinations pointing to IPsec tables, and modify them one by one. To avoid concurrent issue, this handling is done under the protection of eswitch mode_lock. Signed-off-by:
-
Jianbo Liu authored
The eswitch mode is not allowed to change if there are any IPsec rules. Besides, by using mlx5_esw_try_lock() to get eswitch mode lock, IPsec rules are not allowed to be offloaded if there are any TC rules. Signed-off-by:
-
Jianbo Liu authored
The rule destination must be compared with the old_dest passed in. Signed-off-by:
Mark Bloch <mbloch@nvidia.com> Signed-off-by:
-
Jianbo Liu authored
The IPsec encryption is done at the last, so add new prio for IPsec offload in FDB, and put it just lower than the slow path prio and higher than the per-vport prio. Three levels are added for TX. The first one is for ip xfrm policy. The sa table is created in the second level for ip xfrm state. The status table is created at the last to count the number of packets encrypted. The rules, which forward packets to uplink, are changed to forward them to IPsec TX tables first. These rules are restored after those tables are destroyed, which is done immediately when there is no reference to them, just as what does in legacy mode. The support for slow path is added here, by refreshing uplink's channels. But, the handling for TC fast path, which is more complicated, will be added later. Besides, reg c4 is used instead to match reqid. Signed-off-by:
-
Jianbo Liu authored
Add attribute for IPsec TX creation, pass all needed parameters in it, so tx_create() can be used by eswitch. Signed-off-by:
-
Jianbo Liu authored
Reuse tun opts bits in reg c1, to pass IPsec obj id to datapath. As this is only for RX SA and there are only 11 bits, xarray is used to map IPsec obj id to an index, which is between 1 and 0x7ff, and replace obj id to write to reg c1. Signed-off-by:
-
Jianbo Liu authored
As decryption must be done first, add new prio for IPsec offload in FDB, and put it just lower than BYPASS prio and higher than TC prio. Three levels are added for RX. The first one is for ip xfrm policy. SA table is created in the second level for ip xfrm state. The status table is created in the last to check the decryption result. If success, packets continue with the next process, or dropped otherwise. For now, the set of reg c1 is removed for swtichdev mode, and the datapath process will be added in the next patch. Signed-off-by:
-
Jianbo Liu authored
Add attribute for IPsec RX creation, so rx_create() can be used by eswitch in later patch. And move the code for TTC dest connect/disconnect, which are needed only in NIC mode, to individual functions. Signed-off-by:
-
Jianbo Liu authored
As the uplink representor is created only in switchdev mode, add a local variable for IPsec to indicate the device is in this mode. In this mode, IPsec ROCE is disabled, and crypto offload is kept as it is. However, as the tables for packet offload are created in FDB, ipsec->rx_esw and ipsec->tx_esw are added. Signed-off-by:
-
Jianbo Liu authored
Refactor the function to pass in reg B value only. Signed-off-by:
-
Jianbo Liu authored
Add function to get namespace in different directions. It will be extended for switchdev mode in later patch, but no functionality change for now. Signed-off-by:
-
- 02 Aug, 2023 8 commits
-
-
Brett Creeley authored
The documentation above pds_client_register states that it returns 0 on success and negative on error. However, it actually returns a positive client ID on success and negative on error. Fix the documentation to state exactly that. Signed-off-by:
Brett Creeley <brett.creeley@amd.com> Signed-off-by:
Shannon Nelson <shannon.nelson@amd.com> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Link: https://lore.kernel.org/r/20230801165833.1622-1-brett.creeley@amd.comSigned-off-by:
-
Yue Haibing authored
Commit 29ab586c ("net: switchdev: Remove bridge bypass support from switchdev") leave this unused. Signed-off-by:
-
Yue Haibing authored
Since commit b1edeb10 ("netlabel: Replace protocol/NetLabel linking with refrerence counts") this declaration is unused and can be removed. Signed-off-by:
Paul Moore <paul@paul-moore.com> Link: https://lore.kernel.org/r/20230801143453.24452-1-yuehaibing@huawei.comSigned-off-by:
-
Yue Haibing authored
Commit 642c2c95 ("ila: xlat changes") removed ila_xlat_outgoing() and ila_xlat_incoming() functions, then this file became unnecessary. Signed-off-by:
Larysa Zaremba <larysa.zaremba@intel.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20230801143129.40652-1-yuehaibing@huawei.comSigned-off-by:
-
Yue Haibing authored
commit 8a59f9d1 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()") left behind this. Signed-off-by:
-
Ruan Jinjie authored
There is no possible for platform_get_irq() to return 0 and the return value of platform_get_irq() is more sensible to show the error reason. And there is no need to call the dev_warn() function directly to print a custom message when handling an error from platform_get_irq() function as it is going to display an appropriate error message in case of a failure. Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by:
Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20230801133121.416319-1-ruanjinjie@huawei.comSigned-off-by:
-
Kurt Kanzenbach authored
Replace bogus comment about matching the latched timestamp to one of the received frames. That comment is probably copied from mv88e6xxx and true for these switches. However, the hellcreek switch is configured to insert the timestamp directly into the PTP packets. While here, remove the other comments regarding the list splicing and locking as well, because it doesn't add any value. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20230801131647.84697-1-kurt@linutronix.deSigned-off-by:
-
Ruan Jinjie authored
There are a little ternary operators, the true or false judgement of which is unnecessary in C language semantics. Signed-off-by:
-
