- 18 Nov, 2023 22 commits
-
-
Ido Schimmel authored
The flags are not used outside of the C file so move them there. Suggested-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Patrick Williams says: ==================== net/ncsi: Add NC-SI 1.2 Get MC MAC Address command NC-SI 1.2 has now been published[1] and adds a new command for "Get MC MAC Address". This is often used by BMCs to get the assigned MAC address for the channel used by the BMC. This change set has been tested on a Broadcomm 200G NIC with updated firmware for NC-SI 1.2 and at least one other non-public NIC design. 1. https://www.dmtf.org/sites/default/files/standards/documents/DSP0222_1.2.0.pdf ==================== Signed-off-by:
-
Peter Delevoryas authored
This change adds support for the NC-SI 1.2 Get MC MAC Address command, specified here: https://www.dmtf.org/sites/default/files/standards/documents/DSP0222_1.2.0.pdf It serves the exact same function as the existing OEM Get MAC Address commands, so if a channel reports that it supports NC-SI 1.2, we prefer to use the standard command rather than the OEM command. Verified with an invalid MAC address and 2 valid ones: [ 55.137072] ftgmac100 1e690000.ftgmac eth0: NCSI: Received 3 provisioned MAC addresses [ 55.137614] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 0: 00:00:00:00:00:00 [ 55.138026] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 1: fa:ce:b0:0c:20:22 [ 55.138528] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 2: fa:ce:b0:0c:20:23 [ 55.139241] ftgmac100 1e690000.ftgmac eth0: NCSI: Unable to assign 00:00:00:00:00:00 to device [ 55.140098] ftgmac100 1e690000.ftgmac eth0: NCSI: Set MAC address to fa:ce:b0:0c:20:22 Signed-off-by:
Peter Delevoryas <peter@pjd.dev> Signed-off-by:
Patrick Williams <patrick@stwcx.xyz> Signed-off-by:
-
Peter Delevoryas authored
The netlink interface for major and minor version numbers doesn't actually return the major and minor version numbers. It reports a u32 that contains the (major, minor, update, alpha1) components as the major version number, and then alpha2 as the minor version number. For whatever reason, the u32 byte order was reversed (ntohl): maybe it was assumed that the encoded value was a single big-endian u32, and alpha2 was the minor version. The correct way to get the supported NC-SI version from the network controller is to parse the Get Version ID response as described in 8.4.44 of the NC-SI spec[1]. Get Version ID Response Packet Format Bits +--------+--------+--------+--------+ Bytes | 31..24 | 23..16 | 15..8 | 7..0 | +-------+--------+--------+--------+--------+ | 0..15 | NC-SI Header | +-------+--------+--------+--------+--------+ | 16..19| Response code | Reason code | +-------+--------+--------+--------+--------+ |20..23 | Major | Minor | Update | Alpha1 | +-------+--------+--------+--------+--------+ |24..27 | reserved | Alpha2 | +-------+--------+--------+--------+--------+ | .... other stuff .... | The major, minor, and update fields are all binary-coded decimal (BCD) encoded [2]. The spec provides examples below the Get Version ID response format in section 8.4.44.1, but for practical purposes, this is an example from a live network card: root@bmc:~# ncsi-util 0x15 NC-SI Command Response: cmd: GET_VERSION_ID(0x15) Response: COMMAND_COMPLETED(0x0000) Reason: NO_ERROR(0x0000) Payload length = 40 20: 0xf1 0xf1 0xf0 0x00 <<<<<<<<< (major, minor, update, alpha1) 24: 0x00 0x00 0x00 0x00 <<<<<<<<< (_, _, _, alpha2) 28: 0x6d 0x6c 0x78 0x30 32: 0x2e 0x31 0x00 0x00 36: 0x00 0x00 0x00 0x00 40: 0x16 0x1d 0x07 0xd2 44: 0x10 0x1d 0x15 0xb3 48: 0x00 0x17 0x15 0xb3 52: 0x00 0x00 0x81 0x19 This should be parsed as "1.1.0". "f" in the upper-nibble means to ignore it, contributing zero. If both nibbles are "f", I think the whole field is supposed to be ignored. Major and minor are "required", meaning they're not supposed to be "ff", but the update field is "optional" so I think it can be ff. I think the simplest thing to do is just set the major and minor to zero instead of juggling some conditional logic or something. bcd2bin() from "include/linux/bcd.h" seems to assume both nibbles are 0-9, so I've provided a custom BCD decoding function. Alpha1 and alpha2 are ISO/IEC 8859-1 encoded, which just means ASCII characters as far as I can tell, although the full encoding table for non-alphabetic characters is slightly different (I think). I imagine the alpha fields are just supposed to be alphabetic characters, but I haven't seen any network cards actually report a non-zero value for either. If people wrote software against this netlink behavior, and were parsing the major and minor versions themselves from the u32, then this would definitely break their code. [1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0222_1.0.0.pdf [2] https://en.wikipedia.org/wiki/Binary-coded_decimal [2] https://en.wikipedia.org/wiki/ISO/IEC_8859-1Signed-off-by: -
Peter Delevoryas authored
Background: 1. CONFIG_NCSI_OEM_CMD_KEEP_PHY If this is enabled, we send an extra OEM Intel command in the probe sequence immediately after discovering a channel (e.g. after "Clear Initial State"). 2. CONFIG_NCSI_OEM_CMD_GET_MAC If this is enabled, we send one of 3 OEM "Get MAC Address" commands from Broadcom, Mellanox (Nvidida), and Intel in the *configuration* sequence for a channel. 3. mellanox,multi-host (or mlx,multi-host) Introduced by this patch: https://lore.kernel.org/all/20200108234341.2590674-1-vijaykhemka@fb.com/ Which was actually originally from cosmo.chou@quantatw.com: https://github.com/facebook/openbmc-linux/commit/9f132a10ec48db84613519258cd8a317fb9c8f1b Cosmo claimed that the Nvidia ConnectX-4 and ConnectX-6 NIC's don't respond to Get Version ID, et. al in the probe sequence unless you send the Set MC Affinity command first. Problem Statement: We've been using a combination of #ifdef code blocks and IS_ENABLED() conditions to conditionally send these OEM commands. It makes adding any new code around these commands hard to understand. Solution: In this patch, I just want to remove the conditionally compiled blocks of code, and always use IS_ENABLED(...) to do dynamic control flow. I don't think the small amount of code this adds to non-users of the OEM Kconfigs is a big deal. Signed-off-by:
-
David S. Miller authored
Kory Maincent says: ==================== net: Make timestamping selectable Up until now, there was no way to let the user select the layer at which time stamping occurs. The stack assumed that PHY time stamping is always preferred, but some MAC/PHY combinations were buggy. This series updates the default MAC/PHY default timestamping and aims to allow the user to select the desired layer administratively. Changes in v2: - Move selected_timestamping_layer variable of the concerned patch. - Use sysfs_streq instead of strmcmp. - Use the PHY timestamp only if available. Changes in v3: - Expose the PTP choice to ethtool instead of sysfs. You can test it with the ethtool source on branch feature_ptp of: https://github.com/kmaincent/ethtool - Added a devicetree binding to select the preferred timestamp. Changes in v4: - Move on to ethtool netlink instead of ioctl. - Add a netdev notifier to allow packet trapping by the MAC in case of PHY time stamping. - Add a PHY whitelist to not break the old PHY default time-stamping preference API. Changes in v5: - Update to ndo_hwstamp_get/set. This bring several new patches. - Add few patches to make the glue. - Convert macb to ndo_hwstamp_get/set. - Add netlink specs description of new ethtool commands. - Removed netdev notifier. - Split the patches that expose the timestamping to userspace to separate the core and ethtool development. - Add description of software timestamping. - Convert PHYs hwtstamp callback to use kernel_hwtstamp_config. Changes in v6: - Few fixes from the reviews. - Replace the allowlist to default_timestamp flag to know which phy is using old API behavior. - Rename the timestamping layer enum values. - Move to a simple enum instead of the mix between enum and bitfield. - Update ts_info and ts-set in software timestamping case. Changes in v7: - Fix a temporary build error. - Link to v6: https://lore.kernel.org/r/20231019-feature_ptp_netnext-v6-0-71affc27b0e5@bootlin.com ==================== Signed-off-by:
Kory Maincent <kory.maincent@bootlin.com> Signed-off-by:
-
Kory Maincent authored
Add a new commands allowing to set the time stamping. Example usage : ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema \ --do ts-list-get \ --json '{"header":{"dev-name":"eth0"}}' {'header': {'dev-index': 3, 'dev-name': 'eth0'}, 'ts-list-layer': b'\x02\x00\x00\x00\x01\x00\x00\x00\x05\x00\x00\x00'} ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do ts-set \ --json '{"header":{"dev-name":"eth0"}, "ts-layer":5}' none ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do ts-get \ --json '{"header":{"dev-name":"eth0"}}' {'header': {'dev-index': 3, 'dev-name': 'eth0'}, 'ts-layer': 5} Signed-off-by: -
Kory Maincent authored
Now that the current timestamp is saved in a variable lets add the ETHTOOL_MSG_TS_SET ethtool netlink socket to make it selectable. Signed-off-by:
-
Kory Maincent authored
As the default selected timestamp API change we have to change also the timestamp return by ethtool. This patch return now the current selected timestamp. Signed-off-by:
-
Kory Maincent authored
Change the API to select MAC default time stamping instead of the PHY. Indeed the PHY is closer to the wire therefore theoretically it has less delay than the MAC timestamping but the reality is different. Due to lower time stamping clock frequency, latency in the MDIO bus and no PHC hardware synchronization between different PHY, the PHY PTP is often less precise than the MAC. The exception is for PHY designed specially for PTP case but these devices are not very widespread. For not breaking the compatibility I introduce a default_timestamp flag in phy_device that is set by the phy driver to know we are using the old API behavior. The phy_set_timestamp function is called at each call of phy_attach_direct. In case of MAC driver using phylink this function is called when the interface is turned up. Then if the interface goes down and up again the last choice of timestamp will be overwritten by the default choice. A solution could be to cache the timestamp status but it can bring other issues. In case of SFP, if we change the module, it doesn't make sense to blindly re-set the timestamp back to PHY, if the new module has a PHY with mediocre timestamping capabilities. Signed-off-by:
-
Kory Maincent authored
Replace hwtstamp_source which is only used by the kernel_hwtstamp_config structure by the more widely use timestamp_layer structure. This is done to prepare the support of selectable timestamping source. Signed-off-by:
-
Kory Maincent authored
Add a new commands allowing to list available time stamping layers on a netdevice's link. Example usage : ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema \ --do ts-list-get \ --json '{"header":{"dev-name":"eth0"}}' {'header': {'dev-index': 3, 'dev-name': 'eth0'}, 'ts-list-layer': b'\x01\x00\x00\x00\x05\x00\x00\x00'} Signed-off-by: -
Kory Maincent authored
Introduce a new netlink message that lists all available time stamping layers on a given interface. Signed-off-by:
-
Kory Maincent authored
Add a new commands allowing to get the current time stamping on a netdevice's link. Example usage : ./ynl/cli.py --spec netlink/specs/ethtool.yaml --no-schema --do ts-get \ --json '{"header":{"dev-name":"eth0"}}' {'header': {'dev-index': 3, 'dev-name': 'eth0'}, 'ts-layer': 1} Signed-off-by: -
Kory Maincent authored
Time stamping on network packets may happen either in the MAC or in the PHY, but not both. In preparation for making the choice selectable, expose both the current layers via ethtool. In accordance with the kernel implementation as it stands, the current layer will always read as "phy" when a PHY time stamping device is present. Future patches will allow changing the current layer administratively. Signed-off-by:
-
Kory Maincent authored
Timestamping software or hardware flags are often used as a group, therefore adding these masks will easier future use. I did not use SOF_TIMESTAMPING_SYS_HARDWARE flag as it is deprecated and not use at all. Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Kory Maincent authored
In case of no phc we should not return SOFTWARE TIMESTAMPING flags as we do not know whether the netdev supports of timestamping. Remove it from the lan8841_ts_info and simply return 0. Signed-off-by:
-
Kory Maincent authored
Make the dev_set_hwtstamp_phylib function accessible in prevision to use it from ethtool to reset the tstamp current configuration. Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
Kory Maincent authored
The hardware timestamping through ndo_eth_ioctl() is going away. Convert the macb driver to the new API before that can be removed. Signed-off-by:
-
Richard Cochran authored
The vlan, macvlan and the bonding drivers call their "real" device driver in order to report the time stamping capabilities. Provide a core ethtool helper function to avoid copy/paste in the stack. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
-
Kory Maincent authored
__phy_hwtstamp_set function were calling the phy_mii_ioctl function which will then use the ifreq pointer to call the hwtstamp callback. Now that ifreq has been removed from the hwstamp callback parameters it seems more logical to not go through the phy_mii_ioctl function and pass directly kernel_hwtstamp_config parameter to the hwtstamp callback. Lets do the same for __phy_hwtstamp_get function and return directly EOPNOTSUPP as SIOCGHWTSTAMP is not supported for now for the PHYs. Signed-off-by:
-
Kory Maincent authored
The PHYs hwtstamp callback are still getting the timestamp config from ifreq and using copy_from/to_user. Get rid of these functions by using timestamp configuration in parameter. This also allow to move on to kernel_hwtstamp_config and be similar to net devices using the new ndo_hwstamp_get/set. This adds the possibility to manipulate the timestamp configuration from the kernel which was not possible with the copy_from/to_user. Signed-off-by:
-
- 17 Nov, 2023 4 commits
-
-
Eric Dumazet authored
It is suboptimal to attempt skb linearization from ndo_start_xmit() if a gso skb has pathological layout, or if host stack does not have access to the payload (TCP direct). Linearization of large skbs can also fail under memory pressure. We should instead have an ndo_features_check() so that we can fallback to GSO, which is supported even for TCP direct, and generally much more efficient (no payload copy). Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Bailey Forrest <bcf@google.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Jeroen de Borst <jeroendb@google.com> Cc: Praveen Kaligineedi <pkaligineedi@google.com> Cc: Shailend Chand <shailend@google.com> Cc: Ziwei Xiao <ziweixiao@google.com> Reviewed-by:
-
Marco von Rosenberg authored
The BCM54612E ethernet PHY supports IDDQ-SR. Therefore wire-up the suspend and resume callbacks to point to bcm54xx_suspend() and bcm54xx_resume(). Signed-off-by:
Marco von Rosenberg <marcovr@selfnet.de> Acked-by:
-
Shigeru Yoshida authored
The purpose of TLV_SPACE() is to add the TLV descriptor size to the size of the TLV value passed as argument and align the resulting size to TLV_ALIGNTO. tipc_tlv_alloc() calls TLV_SPACE() on its argument. In other words, tipc_tlv_alloc() takes its argument as the size of the TLV value. So the call to TLV_SPACE() in tipc_get_err_tlv() is redundant. Let's remove this redundancy. Acked-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Shigeru Yoshida <syoshida@redhat.com> Signed-off-by:
-
Lad Prabhakar authored
The Gigabit Ethernet IP block on the RZ/Five SoC is identical to one found on the RZ/G2UL SoC. "renesas,r9a07g043-gbeth" compatible string will be used on the RZ/Five SoC so to make this clear and to keep this file consistent, update the comment to include RZ/Five SoC. No driver changes are required as generic compatible string "renesas,rzg2l-gbeth" will be used as a fallback on RZ/Five SoC. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
- 16 Nov, 2023 14 commits
-
-
David S. Miller authored
Russell King says: ==================== net: Add linkmode_fill, use linkmode_*() in phylink/sfp code This small series adds a linkmode_fill() op, and uses it in phylink. The SFP code is also converted to use linkmode_*() ops. ==================== Signed-off-by: -
Russell King (Oracle) authored
Use the linkmode_*() helpers rather than open coding the calls to the bitmap operators. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King (Oracle) authored
Use linkmode_fill() rather than open coding the bitmap operation. Signed-off-by:
-
Russell King (Oracle) authored
Add a linkmode_fill() helper, which will allow us to convert phylink's open coded bitmap_fill() operations. Signed-off-by:
-
David S. Miller authored
Eric Dumazet says: ==================== tcp: change reaction to ICMP messages ICMP[v6] messages received for a socket in TCP_SYN_SENT currently abort the connection attempt, in violation of standards. This series changes our stack to adhere to RFC 6069 and RFC 1122 (4.2.3.9) ==================== Signed-off-by: -
Eric Dumazet authored
Currently, non fatal ICMP messages received on behalf of SYN_SENT sockets do call tcp_ld_RTO_revert() to implement RFC 6069, but immediately call tcp_done(), thus aborting the connect() attempt. This violates RFC 1122 following requirement: 4.2.3.9 ICMP Messages ... o Destination Unreachable -- codes 0, 1, 5 Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection, and it SHOULD make the information available to the application. This patch makes sure non 'fatal' ICMP[v6] messages do not abort the connection attempt. It enables RFC 6069 for SYN_SENT sockets as a result. Signed-off-by: -
Eric Dumazet authored
In commit ccce324d ("tcp: make the first N SYN RTO backoffs linear") David used icsk->icsk_backoff field to track the number of linear timeouts. Since then, tp->total_rto has been added. This commit uses tp->total_rto instead of icsk->icsk_backoff so that tcp_ld_RTO_revert() no longer can trigger an overflow in inet_csk_rto_backoff(). Other than the potential UBSAN report, there was no issue because receiving an ICMP message currently aborts the connect(). In the following patch, we want to adhere to RFC 6069 and RFC 1122 4.2.3.9. Signed-off-by:
-
Alce Lafranque authored
By default, VXLAN encapsulation over IPv6 sets the flow label to 0, with an option for a fixed value. This commits add the ability to inherit the flow label from the inner packet, like for other tunnel implementations. This enables devices using only L3 headers for ECMP to correctly balance VXLAN-encapsulated IPv6 packets. ``` $ ./ip/ip link add dummy1 type dummy $ ./ip/ip addr add 2001:db8::2/64 dev dummy1 $ ./ip/ip link set up dev dummy1 $ ./ip/ip link add vxlan1 type vxlan id 100 flowlabel inherit remote 2001:db8::1 local 2001:db8::2 $ ./ip/ip link set up dev vxlan1 $ ./ip/ip addr add 2001:db8:1::2/64 dev vxlan1 $ ./ip/ip link set arp off dev vxlan1 $ ping -q 2001:db8:1::1 & $ tshark -d udp.port==8472,vxlan -Vpni dummy1 -c1 [...] Internet Protocol Version 6, Src: 2001:db8::2, Dst: 2001:db8::1 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... 1011 0001 1010 1111 1011 = Flow Label: 0xb1afb [...] Virtual eXtensible Local Area Network Flags: 0x0800, VXLAN Network ID (VNI) Group Policy ID: 0 VXLAN Network Identifier (VNI): 100 [...] Internet Protocol Version 6, Src: 2001:db8:1::2, Dst: 2001:db8:1::1 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... 1011 0001 1010 1111 1011 = Flow Label: 0xb1afb ``` Signed-off-by:Alce Lafranque <alce@lafranque.net> Co-developed-by:
Vincent Bernat <vincent@bernat.ch> Signed-off-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Lucas Karpinski authored
The sockets used by udpgso_bench_tx aren't always ready when udpgso_bench_tx transmits packets. This issue is more prevalent in -rt kernels, but can occur in both. Replace the hacky sleep calls with a function that checks whether the ports in the namespace are ready for use. Suggested-by:
Lucas Karpinski <lkarpins@redhat.com> Reviewed-by:
-
David S. Miller authored
Pedro Tammela says: ==================== selftests: tc-testing: updates to tdc - Patch 1 removes an obscure feature from tdc - Patch 2 reworks the namespace and devices setup giving a nice speed boost - Patch 3 preloads all tc modules when running kselftests - Patch 4 turns on parallel testing in kselftests ==================== Signed-off-by: -
Pedro Tammela authored
Leverage parallel tests in kselftests using all the available cpus. We tested this in tuxsuite and locally extensively and it seems it's ready for prime time. Signed-off-by:
Pedro Tammela <pctammela@mojatatu.com> Reviewed-by:
-
Pedro Tammela authored
While running tdc tests in parallel it can race over the module loading done by tc and fail the run with random errors. So avoid this by preloading all modules before running tdc in kselftests. Signed-off-by:
-
Pedro Tammela authored
As mentioned in the TC Workshop 0x17, our recent changes to tdc broke downstream CI systems like tuxsuite. The issue is the classic problem with rcu/workqueue objects where you can miss them if not enough wall time has passed. The latter is subjective to the system and kernel config, in my machine could be nanoseconds while in another could be microseconds or more. In order to make the suite deterministic, poll for the existence of the objects in a reasonable manner. Talking netlink directly is the the best solution in order to avoid paying the cost of multiple 'fork()' calls, so introduce a netlink based setup routine using pyroute2. We leave the iproute2 one as a fallback when pyroute2 is not available. Also rework the iproute2 side to mimic the netlink routine where it creates DEV0 as the peer of DEV1 and moves DEV1 into the net namespace. This way when the namespace is deleted DEV0 is also deleted automatically, leaving no margin for resource leaks. Another bonus of this change is that our setup time sped up by a factor of 2 when using netlink. Signed-off-by:
-
Pedro Tammela authored
This argument would bypass the net namespace creation and run the test in the root namespace, even if nsPlugin was specified. Drop it as it's the same as commenting out the nsPlugin from a test and adds additional complexity to the plugin code. Signed-off-by:
-
