Networking Changes#

802.1Qav(CBS)#

Target Changes

Backward Compatible

Platform

OS

  1. CBS configuration is allowed only from Primary VF (value specified in ‘primary_vf_id’ DT property for Ethernet Server DT node).

  2. The CBS configuration command is not allowed after the NVIDIA DriveOS system transitions to operational mode.

No

NSR, SR

QNX

Migration Path

  • 6.5 to 7.2

Migration Rationale

Enhances the safety/security mechanisms by preventing unauthorized VFs from modifying core attributes in the MAC controller that control the bandwidth shaping across multiple DMA channels.

Steps to Migrate

Refer to the NVIDIA DriveOS Developer Guide

Behavioral Change with Broadcast Packets#

Target Changes

Backward Compatible

Platform

OS

  1. The Networking stack (io-sock) introduces the new socket option IP_ONESBCAST, and the SO_BROADCAST option must be enabled along with it for broadcast.

    • When this option is set to 1, the IPv4 destination address of outgoing broadcast datagrams is forced to the undirected broadcast address (255.255.255.255) before transmission (at L3). For this option to work, the destination address for sendto() / connect() should be a subnet broadcast address (such as 192.168.1.255).

    • When this option is not set or is set to 0, the IPv4 destination address (L3) of outgoing broadcast datagrams remains unchanged.

  2. For undirected broadcast packets (255.255.255.255), behavior is inconsistent with the io-sock stack. Use the subnet broadcast address (such as 192.168.1.255) instead of the undirected broadcast address, with or without IP_ONESBCAST, according to your use case.

No

NSR, SR

QNX

Migration Path

  • 6.5 (io-pkt stack) to 7.2 (io-sock)

Migration Rationale

Behavioral change from the networking stack provided by QNX.

Steps to Migrate

Networking applications that transmit broadcast packets need to incorporate the changes described above.

Behavioral Change for Multicast Rx Packets for io-sock and NvSocket#

Target Changes

Backward Compatible

Platform

OS

The behavior of QNX native network stack (io-sock) on SDP8.0.x is different from SDP7.1 (io-pkt). As a corollary, NvSocket follows io-sock stack behavior in DOS7.2

  • When multiple sockets bound to INADDR_ANY (and the same 4-tuple) and subscribe to the same multicast group with different VLAN interfaces (imr_interface), if rx multicast packet is destined for any of the subscribed VLAN IDs, in io-pkt stack, the packet is delivered to all the sockets, including the sockets subscribed to the different VLAN ID. Whereas in io-sock stack, packet is delivered only to the sockets subscribed to the same VLAN ID.

  • When a socket is subscribed to a multicast group with imr_interface as INADDR_ANY and bound to INADDR_ANY, in io-pkt stack, IP_ADD_MEMBERSHIP API returns the EADDRNOTAVAIL error. Whereas in io-sock stack, IP_ADD_MEMBERSHIP API returns 0 and only multicast packets that are received over the non-VLAN interface are delivered to the socket.

  • Both io-sock and NvSocket support IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP socket options in 7.2.

No

NSR, SR

QNX

Migration Path

  • 6.5 (io-pkt stack) to 7.2 (io-sock)

Migration Release Path

  • 6.x to 7.x

Migration Rationale

Multicast behavior changed in the native network stack from QNX between SDP7.1 and SDP8.0

Steps to Migrate

Networking applications using multicast rx packets need to be aware of the above changes in the multicast behavior.

QNX Access Control Policies for ioctl and devctl Commands#

Target Changes

Backward Compatible

Platform

OS

The Ethernet driver and NvEthMgr safeguards driver specific ioctls/ devctls through custom dynamic abilities. These are applicable to ioctl/ devctl applications running in non-root mode.

No

NSR, SR

QNX

Migration Path

  • 6.5 to 7.2

Migration Rationale

Security violation from 6.5 is resolved

Steps to Migrate

Refer to “QNX Access Control Policies for ioctl and devctl Commands” in the NVIDIA DriveOS Developer Guide

Deprecated Header Files Removed from the Nvethernet Sample App#

Target Changes

Backward Compatible

Platform

OS

The following header files are deprecated and removed from the Nvethernet Sample Application

  • net/ifdrvcom.h

  • hw/nicinfo.h

  • netdrvr/ptp.h

No

NSR, SR

QNX

Migration Path

  • 6.5 to 7.2

Migration Rationale

Deprecated header files are not compatible with the new version of QNX iosock stack and were removed from the Nvethernet Sample Application

Steps to Migrate

Refer to the Nvethernet Sample Application source code for the changes in the included header files

Nvethernet Sample App for NvSocket Statistics Changes for 7.2.4.0#

Target Changes

Backward Compatible

Platform

OS

Following are changes to the Nvethernet Sample Application for NvSocket Statistics (nvsocket_stats command) in release 7.2.4.0:

  • A new structure nvsocket_ipc_stat_msg_t with a verbose field is introduced for the IPC request message with pulse code NVSOCKET_PULSE_GET_STATS. This changes the IPC message shape sent from the sample application to the NvSocket server.

  • nvsocket_stats_t structure in nvsocket_export.h is changed to remove the embedded nvsocket_server_cfg_t structure, reducing the overall structure size and altering the memory layout. All server configuration info is now logged during boot time instead.

Old binaries compiled against prior headers will fail at runtime because:

  • The IPC message layout (nvsocket_ipc_stat_msg_t) has changed. The NvSocket server expects the new message format with the verbose field; old binaries send the previous format, causing the server to misinterpret the request.

  • The nvsocket_stats_t structure layout and size have changed due to removal of nvsocket_server_cfg_t. Old binaries reading the statistics response will have incorrect field offsets, resulting in corrupted or misaligned data.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

    Thor to Thor

Release Migration Path

  • 6.5 to 7.2

    7.2.3.0 to 7.2.4.0

Migration Rationale

The Nvethernet Sample Application nvsocket_stats IPC command is updated to support control of verbose output from NvSocket Server. The IPC message structure and statistics response structure have both changed, breaking binary compatibility with older builds.

Steps to Migrate

  1. Recompile the nvethernet_sample application with 7.2.4.0 headers. Old binaries must not be used — they will produce runtime failures due to IPC message and structure layout mismatches.

  2. By default, verbose is disabled. Use option -v to enable verbose output from NvSocket Server:

  • (SOCK=/<sockprefix> nvethernet_sample <interface> nvsocket_stats -v)

bus_setup_intr() to Attach to Interrupt#

Target Changes

Backward Compatible

Platform

OS

nveqos_io-sock driver uses bus_setup_intr() API to attach to an interrupt

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Release Path

  • 6.5 to 7.2

Migration Rationale

nveqos_io-sock driver is associated with Nexus Bus. Hence, we use the bus_setup_intr() for setting up the IST or allocating interrupt resources. Also this API internally calls InterruptAttachThread().

Steps to Migrate

Refer nveqos_io-sock driver.

Abilities#

Target Changes

Backward Compatible

Platform

OS

The iosock process needs the following abilities for nveqos_iosock driver launch

  • iofunc/chown: To change the ownership of the driver created files in /tmp/. This ability is required in root mode as the file is created during attach in root mode and later the root ownership is dropped by the process.

  • interrupt: For usage of the InterruptAttachThread API internally called by bus_setup_intr

No

SR

QNX

Migration Path

  • Orin to Thor

Release Path

  • 6.5 to 7.2

Migration Rationale

The Muon Kernel process adds new abilities, such as the iosock process

Steps to Migrate

Add the abilities in the abilities.txt file

Deprecated dcom_stats_ioctl Tool#

Target Changes

Backward Compatible

Platform

OS

  1. The deprecated dcom_stats_ioctl tool is removed, because the SIOCGDRVCOM ioctl is no longer supported in io-sock stack in 7.2. The same functionality is provided through the Nvethernet Sample app

  2. The “Internal TX Error” counter is not available in the output of Nvethernet Sample app. Refer to the netstat tool to get the “Internal TX Error” result

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Release Path

  • 6.5 to 7.2

Migration Rationale

SIOCGDRVCOM is no longer supported in the QNX io-sock network stack; the dcom_stats_ioctl tool is deprecated.

Steps to Migrate

  1. Use the Nvethernet Sample app instead: nvethernet_sample <interface> dcom_stats_ioctl

  2. For “Internal TX Error” information, use: netstat -bdI <interface> and look for the “Oerrs” field.

Behavioral Change with NvSocket Signals#

Target Changes

Backward Compatible

Platform

OS

  1. Previously, NvSocket Library internally used signals to unblock i/o calls (recv/recvfrom/recvmsg/recvmmsg/read/readv).

    • The signal number used was specified using a command-line option set in DT when launching nvethmgr (-s option).

    • This signal number is propagated from DT to nvethmgr to NvSocket Server to NvSocket Library, which then registers a signal handler for this signal number.

    • Consequently, applications which used NvSocket Library could not register a signal handler for the same signal number for their own use.

    • In case of conflicting usage of signal number between NvSocket Library and application, the DT setting for the nvethmgr signal number had to be changed to a signal unused by the application.

  2. NvSocket Library has been changed to use a different method (not signal-related) to unblock i/o calls.

    • Consequently, applications may register signal handlers for their own use without consideration for whether NvSocket Library is already using that signal number.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 (io-pkt stack) to 7.2 (io-sock)

Migration Rationale

Engineering research discovered a less intrusive method of unblocking i/o

Steps to Migrate

Networking applications using NvSocket Library may freely use signals without checking if the signal number conflicts with NvSocket Library. When configuring DT setting for launching nvethmgr program, delete the -s command line option if present.

NvSocket Memory Carveout Separated for Each Interface#

Target Changes

Backward Compatible

Platform

OS

In release 7.2.4.0, NvEthMgr memory carveout is separated for each interface. Each interface has its own memory carveout and SMMU addresses space instead of single memory carveout for all interfaces. Following is the list of carveouts and SMMU domains created for each supported interface for NvSocket.

No

NSR, SR

QNX

Migration Release Path

  • 7.0 to 7.2

  • 6.x to 7.x

Migration Rationale

Due to memory isolation requirements for DriveOS SEOOC compliance.

Steps to Migrate

To adjust NvSocket memory configuration, the following listed Carveout and SMMU configuration nodes are to be updated for the desired interfaces. Refer to the NvSocket FAQs section in the NVIDIA DriveOS Developer Guide for additional information.

Interface

NvEthMgr Memory carveout node name

SMMU addresses space node name

eqos_0

nvethmgr_eqos_0_smmu_static_mapping

niso1_nvethmgr_eqos_0_as

mgbe0_0

nvethmgr_mgbe0_0_smmu_static_mapping

nios0_nvethmgr_mgbe0_0_as

mgbe1_0

nvethmgr_mgbe1_0_smmu_static_mapping

nios0_nvethmgr_mgbe1_0_as

mgbe2_0

nvethmgr_mgbe2_0_smmu_static_mapping

nios0_nvethmgr_mgbe2_0_as

mgbe3_0

nvethmgr_mgbe3_0_smmu_static_mapping

nios0_nvethmgr_mgbe3_0_as

NvSocket Can be Enabled and Disabled on Supported Interfaces using PCT Flags#

Target Changes

Backward Compatible

Platform

OS

NvSocket can be enabled and disabled on supported interfaces using PCT flags by passing the corresponding PCT flag to bind_partitions command.

No

NSR, SR

QNX

Migration Path

  • 6.5 to 7.2

Migration Rationale

To provide flexibility to enable/disable NvSocket on supported interfaces with minimal DT modification as possible.

Steps to Migrate

To Enable/disable NvSocket on desired interface, corresponding PCT flag as per below table to be passed to bind_partitions command. Please refer to the NvSocket FAQs section in developer guide for more details.

Note: Default interface configuration for NvSocket still remains the same as before.

Interface

PCT Flag

eqos_0

ENABLE_NVSOCKET_EQOS_0

mgbe0_0

ENABLE_NVSOCKET_MGBE0_0

mgbe1_0

ENABLE_NVSOCKET_MGBE1_0

mgbe2_0

ENABLE_NVSOCKET_MGBE2_0

mgbe3_0

ENABLE_NVSOCKET_MGBE3_0

Thread Priority Configuration for io-sock#

Target Changes

Backward Compatible

Platform

OS

All the threads of io-sock process (including IST threads) will have the same priority configured through qnx.priority option in io-sock configuration file provided through -o config option in iolauncher command.

No

NSR, SR

QNX

Migration Path

  • 6.5 to 7.2

Migration Rationale

Behavioral change from the networking stack (io-sock) provided by QNX in 7.2

Steps to Migrate

io-sock thread priorities can be configured through qnx.priority option in io-sock configuration file provided through -o config option in iolauncher command. Please refer to the developer guide for more details.

Renaming the NvEthMgr Sample Application#

Target Changes

Backward Compatible

Platform

OS

Rename NvEthMgr sample application binary

  • Currently NvEthMgr sample application binary is named nvethernet_sample under drive-qnx-safety/samples/io-sock/nvethmgr

  • In release 7.2.3.0, the sample application binary is renamed to nvethmgr_sample under drive-qnx-safety/samples/io-sock/nvethmgr

Yes

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

To make the sample application binary name consistent with the nvethmgr sample application.

Steps to Migrate

Use the make command to build the sample application binary with the new name.

NvSocket DT Parameter Changes for 7.2.5.0#

Target Changes

Backward Compatible

Migration Path

Platform

OS

Release 7.2.5.0 introduces the following NvSocket device tree (DT) parameter changes:

  1. DT parameter nvsocket-tx-extra-loop-count is removed. This parameter previously controlled additional TX processing loop iterations and is no longer supported.

  2. DT parameter nvsocket-tx-batch-packet-min-count semantics changed from absolute packet count to percentage (%) of minimum of software ring size or hardware ring size. Default changed from 1 to 50, max changed from TX ring size to 90.

  3. DT parameter nvsocket-max-rx-buf-size minimum value increased from 10MB to 45MB and maximum value increased from ~90MB to 1GB.

  4. DT parameter nvsocket-max-tx-buf-size minimum value increased from 10MB to 45MB and maximum value increased from ~585MB to 1GB.

  5. New DT parameter nvsocket-tx-deq-batch-count is added. Controls the maximum number of TX packets dequeued and transmitted per iteration of the NvSocket server TX processing loop. Default is 4096, range 1–16384. Out of range values are capped to min/max.

  6. New DT parameter nvsocket-poll-delay-lo-rx-free-list-thread-ms is added. It controls the poll delay for the loopback rx free list thread in milliseconds. The default is 2, range 1–1000. Out of range values are capped to min/max.

  7. DT parameter nvsocket-flags is updated with new bit definitions: Bit 8 (TX server signalling), Bit 9 (RX client signalling in inline rx path), Bit 10 (RX client signalling in end of ring rx path), Bit 11 (TX server thread busy polling), Bit 12 (RX server thread busy polling). Bits 3, 4, 5 removed.

Yes

Orin to Orin

Orin to Thor

Migration Release Path

7.2.4.0 to 7.2.5.0

NSR

SR

QNX

Migration Rationale

  • The nvsocket-tx-extra-loop-count parameter is no longer needed due to TX path optimizations in 7.2.5.0. No action is required; the parameter is silently ignored if left in place.

  • The nvsocket-tx-batch-packet-min-count change to percentage-based values simplifies configuration by making it independent of the absolute ring size. No action is required unless this parameter was customized; the default changes from 1 to 50 and the semantics change from absolute count to percentage.

  • The minimum buffer sizes for nvsocket-max-rx-buf-size and nvsocket-max-tx-buf-size are increased from 10MB to 45MB, and maximum values are increased to 1GB, removing the previous upper bound constraints and allowing higher throughput configurations for jumbo frame (9000 MTU) use cases. No action is required as previously configured DT values remain within the new valid range.

  • The nvsocket-tx-deq-batch-count parameter allows tuning TX dequeue batch size to reduce mutex acquire/release kernel call frequency during TX processing. No action is required; default value of 4096 is used if not specified in device tree.

  • The nvsocket-poll-delay-lo-rx-free-list-thread-ms parameter enables tuning the loopback rx free list thread poll interval. No action required; default value of 2ms is used if not specified in device tree.

  • The nvsocket-flags parameter adds new signalling and busy polling control bits (8–12) for performance tuning. Bits 3, 4, 5 are removed. No action is required; default value of 0x80 remains unchanged.

Steps to Migrate

  1. Remove nvsocket-tx-extra-loop-count from device tree, if present. The parameter is silently ignored if left in place.

  2. Update nvsocket-tx-batch-packet-min-count DT property if customized — the value now represents a percentage (1–90%) instead of an absolute packet count. Default is 50%.

  3. nvsocket-max-rx-buf-size minimum increased from 10MB to 45MB and maximum increased to 1GB (previously ~90MB). Update any value below 45MB to at least 45MB.

  4. nvsocket-max-tx-buf-size minimum increased from 10MB to 45MB and maximum increased to 1GB (previously ~585MB). Update any value below 45MB to at least 45MB.

  5. nvsocket-tx-deq-batch-count is a new parameter with a default value of 4096. No action is required unless TX dequeue batch tuning is needed.

  6. nvsocket-poll-delay-lo-rx-free-list-thread-ms is a new parameter with default value 2ms. No action is required unless loopback rx free list poll tuning is needed.

  7. nvsocket-flags bits 3, 4, 5 are removed; new bits 8–12 are added for TX/RX signalling and busy polling control. No action isrequired if using the default value (0x80). If custom flags were set for bits 3, 4, or 5, remove them because they are no longer supported.

Changes to nvethernet_export.h#

MACsec Statistics IOCTL#

Target Changes

Backward Compatible

Platform

OS

A new IOCTL command ETHER_IOCTL_MACSEC_STATS (0x1017U) is added to retrieve MACsec-specific statistics from the Ethernet driver in release 7.2.4.0. This IOCTL is always enabled as the MACSEC_SUPPORT macro is always defined.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

Provides dedicated monitoring capabilities for MACsec layer performance and security metrics, enabling applications to track MACsec-specific statistics separately from general Ethernet statistics.

Steps to Migrate

Applications implementing MACsec security features can use this new IOCTL (ETHER_IOCTL_MACSEC_STATS) to retrieve MACsec-specific statistics. The Nvethernet Sample Application demonstrates this IOCTL usage with the dcom_stats_ioctl command: nvethernet_sample <interface> dcom_stats_ioctl

L2 Filter Packet Duplication#

Target Changes

Backward Compatible

Platform

OS

A new field, pkt_dup, is added to the struct ether_l2_filter structure used with the ETHER_L2_FILTER_CFG IOCTL command in release 7.2.4.0. This field controls whether received packets matching the L2 filter should be duplicated to multiple DMA channels. Values: 0 = disable duplication, 1 = enable duplication.

Yes (for Orin only)

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

Packet duplication enables the MAC to duplicate received packets to multiple DMA channels, which is useful for broadcast and multicast scenarios where the same packet needs to be delivered to multiple applications. This should be set to zero for unicast MAC address filtering.

Steps to Migrate

Refer to the Nvethernet Sample Application usage for L2 filter configuration. For unicast MAC address filtering, always pass pkt_dup = 0. For multicast, the pkt_dup = 1 should be passed.

Changes to nvethernet_type.h#

nveu64_t Type Definition Change#

Target Changes

Backward Compatible

Platform

OS

BREAKING CHANGE: The nveu64_t type definition changed from unsigned long to unsigned long long in release 7.2.4.0. The intermediate typedef my_uint64_t is removed.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

Type alignment standardization. While both types represent 64-bit unsigned integers, the underlying type change ensures consistent behavior across different platforms and compilers.

Steps to Migrate

  1. Update all printf/scanf format specifiers: use %llu instead of %lu for nveu64_t variables.

  2. Review any code that uses type overloading with nveu64_t.

  3. Recompile all code that depends on nveu64_t to ensure binary compatibility.

  4. Update casting or type conversion code that assumes unsigned long representation.

Warning

This is a breaking change that affects binary compatibility. All dependent code must be recompiled. Applications using incorrect format specifiers (%lu instead of %llu) may exhibit undefined behavior or produce incorrect output.

FRP Command Structure Changes (osi_core_frp_cmd)#

Target Changes

Backward Compatible

Platform

OS

BREAKING CHANGE: The osi_core_frp_cmd structure (Flexible Receive Parser command) is modified: (1) dma_sel field type changed from nveu32_t (32-bit) to nveu64_t (64-bit), and (2) new field dcht (type nveu8_t) added for DMA Channel Table configuration in release 7.2.4.0.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

The dma_sel field expansion from 32-bit to 64-bit allows up to 64 DMA channels to be specified (bits 0-63) for frame routing, supporting the increased channel count (OSI_MAX_NUM_CHANS = 48). The new dcht field provides additional DMA Channel Table configuration for FRP operations.

Steps to Migrate

  1. Update code that sets/reads dma_sel to handle 64-bit values.

  2. Initialize the new dcht field appropriately when configuring FRP commands.

  3. Update format specifiers for dma_sel from %u to %llu if printing values.

  4. Recompile all code using osi_core_frp_cmd structure (ETHER_CONFIG_FRP_CMD IOCTL).

Warning

This is a breaking change that affects binary compatibility. The osi_core_frp_cmd structure size and layout have changed. All code using FRP commands must be recompiled.

Changes to nvsocket_export.h#

Thread Poll Delay Constants#

Target Changes

Backward Compatible

Platform

OS

Release 7.2.4.0 adds macros for thread polling configuration validation:

  • NVSOCKET_THREAD_POLL_MIN_MS (1U) - Minimum delay in milliseconds

  • NVSOCKET_THREAD_POLL_MAX_MS (1000U) - Maximum delay in milliseconds

  • NVSOCKET_THREAD_POLL_MIN_NS (1000000U) - Minimum delay in nanoseconds (1ms)

  • NVSOCKET_THREAD_POLL_MAX_NS (1000000000U) - Maximum delay in nanoseconds (1s)

Yes

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

These macros provide the bounds for device tree configurable NvSocket thread poll delay parameters.

Steps to Migrate

Use these macros when configuring NvSocket thread poll delays via device tree properties. The following device tree properties use these macros for validation:

  • nvsocket-poll-delay-pcap-dumper-thread-ms: PCAP dumper thread poll delay (default: NVSOCKET_THREAD_POLL_MAX_MS)

  • nvsocket-poll-delay-rx-frag-expire-thread-ms: RX fragment expiration thread poll delay (default: NVSOCKET_THREAD_POLL_MAX_MS)

  • nvsocket-poll-delay-rx-free-list-thread-ms: RX free list thread poll delay (default: NVSOCKET_THREAD_POLL_MAX_MS)

  • nvsocket-poll-delay-shm-signal-thread-ns: SHM signal thread poll delay in nanoseconds (default: NVSOCKET_THREAD_POLL_MAX_NS)

Values must be >= minimum threshold; values below minimum will cause server initialization failure.

Usage Example

The constants define valid ranges for thread poll delay configuration:

/* Millisecond-based delays: valid range is 1ms to 1000ms */
#define NVSOCKET_THREAD_POLL_MIN_MS (1U)
#define NVSOCKET_THREAD_POLL_MAX_MS (1000U)

/* Nanosecond-based delays: valid range is 1ms (1000000ns) to 1s (1000000000ns) */
#define NVSOCKET_THREAD_POLL_MIN_NS (1000000U)
#define NVSOCKET_THREAD_POLL_MAX_NS (1000000000U)

Device Tree Configuration Example

nvsocket {
    nvsocket-poll-delay-pcap-dumper-thread-ms = <100>;
    nvsocket-poll-delay-rx-frag-expire-thread-ms = <500>;
    nvsocket-poll-delay-rx-free-list-thread-ms = <250>;
    nvsocket-poll-delay-shm-signal-thread-ns = <10000000>;  /* 10ms */
};

IP Multicast Group Membership Limit#

Target Changes

Backward Compatible

Platform

OS

Release 7.2.4.0 adds a macro, NV_IP_MAX_MEMBERSHIPS, (20U) defining the maximum number of IP multicast group memberships per NvSocket. This limits the number of multicast groups a single socket can join via IP_ADD_MEMBERSHIP socket option.

Yes

NSR, SR

QNX

Migration Path

  • Orin to Thor

Release Path

  • 6.5 to 7.2

Migration Rationale

This constant defines an explicit limit for multicast group memberships in NvSocket, similar to the standard BSD socket IP_MAX_MEMBERSHIPS constant. Having a defined limit enables consistent behavior and predictable resource allocation for multicast applications.

Steps to Migrate

Applications using IP multicast with NvSocket should be aware of this limit:

  • A single NvSocket can join up to 20 multicast groups

  • Use IP_DROP_MEMBERSHIP to leave groups before joining new ones if at limit

  • Consider using multiple sockets if more than 20 group memberships are required

Behavior When Limit Exceeded

When an application attempts to join more than NV_IP_MAX_MEMBERSHIPS (20) multicast groups on a single socket:

  • The setsockopt() call with IP_ADD_MEMBERSHIP returns -1

  • The multicast membership is not added

Comparison with BSD Sockets

Constant

Value

Scope

NV_IP_MAX_MEMBERSHIPS (NvSocket)

20

Per socket

IP_MAX_MEMBERSHIPS (BSD)

Platform-dependent (typically 20)

Per socket

Usage Example

#include <nvsocket_export.h>
#include <netinet/in.h>

/* Join multiple multicast groups (up to NV_IP_MAX_MEMBERSHIPS) */
for (int i = 0; i < NV_IP_MAX_MEMBERSHIPS; i++) {
    struct ip_mreq mreq;
    mreq.imr_multiaddr.s_addr = inet_addr(multicast_addrs[i]);
    mreq.imr_interface.s_addr = htonl(INADDR_ANY);

    if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP,
                   &mreq, sizeof(mreq)) < 0) {
        if (errno == ETOOMANYREFS) {
            /* Maximum membership limit reached */
            printf("Cannot join group: membership limit reached\n");
        }
        break;
    }
}

IP Multicast Source Membership Limit#

Target Changes

Backward Compatible

Platform

OS

Release 7.2.4.0 adds a macro, NV_IP_MAX_SOURCE_MEMBERSHIPS, (20U) defining the maximum number of source addresses for Source-Specific Multicast (SSM) membership per multicast group for NvSocket. This limits the number of sources that can be added via IP_ADD_SOURCE_MEMBERSHIP or blocked via IP_BLOCK_SOURCE socket options for a single multicast group for a socket.

Yes

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

This constant defines an explicit limit for source-specific multicast source addresses in NvSocket to reduce memory usage and ensure defined behavior. SSM allows applications to receive multicast traffic only from specific sources, and this limit bounds the number of sources per group membership. Having a defined limit reduces per-socket memory footprint and enables consistent, predictable resource allocation for SSM applications.

Steps to Migrate

Applications using Source-Specific Multicast (SSM) with NvSocket should be aware of this limit:

  • A single multicast group membership can have up to 20 source addresses via IP_ADD_SOURCE_MEMBERSHIP

  • Up to 20 sources can be blocked via IP_BLOCK_SOURCE per ASM group membership

  • Use IP_DROP_SOURCE_MEMBERSHIP or IP_UNBLOCK_SOURCE to remove sources before adding new ones if at limit

Behavior When Limit Exceeded

When an application attempts to add more than NV_IP_MAX_SOURCE_MEMBERSHIPS (20) source addresses for a single multicast group on a socket:

  • The setsockopt() call with IP_ADD_SOURCE_MEMBERSHIP or IP_BLOCK_SOURCE returns -1

  • errno is set to ENOSPC

  • The source membership is not added

Comparison with Related Constants

Constant

Value

Scope

NV_IP_MAX_MEMBERSHIPS (NvSocket)

20

Max multicast groups per socket (IP_ADD_MEMBERSHIP)

NV_IP_MAX_SOURCE_MEMBERSHIPS (NvSocket)

20

Max source addresses per multicast group per socket (IP_ADD_SOURCE_MEMBERSHIP / IP_BLOCK_SOURCE)

IP_MAX_GROUP_SRC_FILTER (FreeBSD)

512

Max source addresses per multicast group per socket (IP_ADD_SOURCE_MEMBERSHIP / IP_BLOCK_SOURCE)

Usage Example (IP_ADD_SOURCE_MEMBERSHIP - SSM)

#include <nvsocket_export.h>
#include <netinet/in.h>

/* Add multiple SSM sources for a multicast group (up to NV_IP_MAX_SOURCE_MEMBERSHIPS) */
for (unsigned int i = 0; i < NV_IP_MAX_SOURCE_MEMBERSHIPS; i++) {
    struct ip_mreq_source mreq_src;
    mreq_src.imr_multiaddr.s_addr = inet_addr("239.1.1.1");
    mreq_src.imr_interface.s_addr = inet_addr(interface_ip);
    mreq_src.imr_sourceaddr.s_addr = inet_addr(source_addrs[i]);

    if (setsockopt(sock, IPPROTO_IP, IP_ADD_SOURCE_MEMBERSHIP,
                   &mreq_src, sizeof(mreq_src)) < 0) {
        if (errno == ENOSPC) {
            /* Maximum source membership limit reached */
            printf("Cannot add source: source membership limit reached\n");
        }
        break;
    }
}

Usage Example (IP_BLOCK_SOURCE - ASM with blocked sources)

#include <nvsocket_export.h>
#include <netinet/in.h>

/* First join the multicast group using ASM (IP_ADD_MEMBERSHIP) */
struct ip_mreq group;
group.imr_multiaddr.s_addr = inet_addr("239.1.1.1");
group.imr_interface.s_addr = inet_addr(interface_ip);
setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &group, sizeof(group));

/* Block specific sources (up to NV_IP_MAX_SOURCE_MEMBERSHIPS) */
for (unsigned int i = 0; i < NV_IP_MAX_SOURCE_MEMBERSHIPS; i++) {
    struct ip_mreq_source mreq_src;
    mreq_src.imr_multiaddr.s_addr = inet_addr("239.1.1.1");
    mreq_src.imr_interface.s_addr = inet_addr(interface_ip);
    mreq_src.imr_sourceaddr.s_addr = inet_addr(blocked_sources[i]);

    if (setsockopt(sock, IPPROTO_IP, IP_BLOCK_SOURCE,
                   &mreq_src, sizeof(mreq_src)) < 0) {
        if (errno == ENOSPC) {
            /* Maximum blocked source limit reached */
            printf("Cannot block source: block list full\n");
        }
        break;
    }
}

NvSocket RX Flush Dequeue Statistics (Suspend/Resume)#

Target Changes

Backward Compatible

Platform

OS

Release 7.2.4.0 adds new fields, flush_deq_cnt and total_rx_flush_deq_cnt, to NvSocket statistics structures in nvsocket_export.h to track the number of stale packets flushed from the receive queue during suspend/resume cycles.

Yes

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

During system suspend/resume, stale packets may remain in the NvSocket receive queue from before the suspend. These packets are no longer valid and must be flushed. The new statistics fields provide visibility into this flush operation, enabling applications and system integrators to monitor and diagnose packet loss related to suspend/resume transitions.

Steps to Migrate

Applications or tools reading NvSocket statistics should be aware of the new fields:

  • flush_deq_cnt in net_shm_client_rx_stat_t: Per-client count of stale packets flushed from the RX queue due to suspend/resume

  • total_rx_flush_deq_cnt in nvsocket_server_stat_t: Aggregate count across all clients of stale packets flushed due to suspend/resume

  • Recompile applications (e.g., nvethernet_sample application) that directly access these structures

Structure Details

Field

Structure

Description

flush_deq_cnt

net_shm_client_rx_stat_t

Per-client count of stale RX packets flushed during suspend/resume

total_rx_flush_deq_cnt

nvsocket_server_stat_t

Server-wide aggregate count of stale RX packets flushed during suspend/resume across all clients

Socket Address Type Change (client_t)#

Target Changes

Backward Compatible

Platform

OS

BREAKING CHANGE: In the client_t structure, the name and peer fields changed from struct to union in release 7.2.4.0. Previously, these were structs containing both IPv4 (sockaddr_in) and IPv6 (sockaddr_in6) variants simultaneously. Now they are unions where only one address family is active at a time.

No

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5 to 7.2

Migration Rationale

This change reduces memory usage by using a union instead of a struct for socket addresses. Since a socket connection uses either IPv4 or IPv6 (not both simultaneously), the union provides more efficient memory utilization.

Steps to Migrate

  1. API usage patterns remain unchanged (.name.name_in or .name.name_in6)

  2. Ensure code does not assume simultaneous storage of both IPv4 and IPv6 addresses

  3. Recompile all applications using client_t structure

  4. Test thoroughly if code previously relied on both address variants being stored

Warning

This is a breaking change affecting binary compatibility. Structure size is reduced and memory layout has changed. All dependent code must be recompiled.

Maximum Fragments Constant (MAX_FRAGS)#

Target Changes

Backward Compatible

Platform

OS

Release 7.2.4.0 adds a macro, MAX_FRAGS, which defines the maximum number of IP fragments supported by NvSocket. The value is calculated as: ((65536U / (540U - 60U - 8U)) + 1U) resulting in approximately 139 fragments maximum.

Yes

NSR, SR

QNX

Migration Rationale

This constant defines the hard limit for IP fragmentation in NvSocket, accounting for MACsec MTU adjustments and protocol headers.

Steps to Migrate

No action is required. This constant is used internally by NvSocket for fragment management.

NvSocket Macro Changes for 7.2.5.0#

Target Changes

Backward Compatible

Platform

OS

  1. NVSOCKET_MIN_RX_BUF_SIZE increased from 10MB to 45MB.

  2. NVSOCKET_MIN_TX_BUF_SIZE increased from 10MB to 45MB.

  3. NVSOCKET_MAX_RX_BUF_SIZE changed from a derived value of approximately 90MB to a fixed 1GB.

  4. NVSOCKET_MAX_TX_BUF_SIZE changed from a derived value of approximately 585MB to a fixed 1GB.

  5. New macros NVSOCKET_TX_DEQ_BATCH_COUNT_MIN (1U), NVSOCKET_TX_DEQ_BATCH_COUNT_DEFAULT (4096U), and NVSOCKET_TX_DEQ_BATCH_COUNT_MAX (16384U) added for DT property nvsocket-tx-deq-batch-count.

  6. NVSOCKET_THREAD_POLL_MIN_MS and NVSOCKET_THREAD_POLL_MAX_MS now also apply to the new DT property nvsocket-poll-delay-lo-rx-free-list-thread-ms.

  7. New macro NVSOCKET_MIN_MTU (540U) added, defining the minimum MTU size used to derive the maximum number of IP fragments.

  8. MAX_FRAGS macro updated to use NVSOCKET_MIN_MTU instead of the previously hardcoded value of 540 and NVSOCKET_MIN_MTU has been set with 1460 (the minimum MTU value that can configured via device tree)

  9. All DT-configurable macros are now annotated with their corresponding DT property names for traceability.

  10. API decoration doxygen comments added for all exported macros and structures.

Yes

NSR, SR

QNX

Migration Path

  • Orin to Orin

  • Orin to Thor

  • Dimensity C-X1 to Dimensity C-X1

Migration Release Path

7.2.4.0 to 7.2.5.0

Migration Rationale

  • NVSOCKET_MIN_RX_BUF_SIZE and NVSOCKET_MIN_TX_BUF_SIZE increased from 10MB to 45MB to ensure sufficient buffer allocation for NvSocket operation.

  • NVSOCKET_MAX_RX_BUF_SIZE and NVSOCKET_MAX_TX_BUF_SIZE increased to 1GB (fixed values replacing previous derived calculations) to allow higher throughput configurations and enable reserving more buffers for jumbo frame (9000 MTU) use cases.

  • NVSOCKET_TX_DEQ_BATCH_COUNT_* macros provide bounds and default for the TX dequeue batch count, allowing tuning of TX processing to reduce mutex acquire/release kernel call frequency.

  • NVSOCKET_THREAD_POLL_MIN_MS/NVSOCKET_THREAD_POLL_MAX_MS scope extended to cover the new loopback rx free list thread poll delay DT property.

  • NVSOCKET_MIN_MTU improves code maintainability by extracting the hardcoded MTU value into a named constant. The minimum MTU accounts for MACsec adjustments (MACSEC_TAG_ICV_LEN of 34 bytes reduced from min MTU, further reduced by 2 bytes for optimal performance).

  • DT property name annotations on all configurable macros improve traceability between code and device tree configuration.

Steps to Migrate

No action is required for most applications. The MAX_FRAGS calculation result (approximately 139 fragments) remains unchanged. Applications that need to reference the minimum MTU value can now use the NVSOCKET_MIN_MTU macro. Applications using custom buffer sizes can now configure up to 1GB for both RX and TX buffers (minimum 45MB). Applications needing TX dequeue batch tuning can use the NVSOCKET_TX_DEQ_BATCH_COUNT_* macros for validation.

Changes to nvsocketzc_export.h#

New Header nvsocketzc_export.h for 7.2.5.0#

Target Changes

Backward Compatible

Platform

OS

Release 7.2.5.0 introduces a new public header, nvsocketzc_export.h, providing NvSocket zero-copy APIs for high-performance UDP packet processing.

This header exports the following APIs:

  1. zc_recv() – Receive data from socket in zero-copy mode.

  2. zc_recvfrom() – Receive data with source address in zero-copy mode.

  3. zc_recvmsg() – Receive data with message structure in zero-copy mode.

  4. zc_recvmmsg() – Receive multiple messages in zero-copy mode.

  5. zc_send() – Send data to socket in zero-copy mode.

  6. zc_sendto() – Send data with destination address in zero-copy mode.

  7. zc_sendmsg() – Send data with message structure in zero-copy mode.

  8. zc_sendmmsg() – Send multiple messages in zero-copy mode.

  9. zc_alloc_tx_buf() – Allocate transmit buffers in zero-copy mode.

  10. zc_free_tx_buf() – Free transmit buffers in zero-copy mode.

  11. zc_free_rx_buf() – Free receive buffers in zero-copy mode.

The header also defines NVSOCKETZC_EXPORT_VERSION (0x72500001U).

Usage: Include nvsocketzc_export.h (which internally includes nvsocket_export.h) and link with libnvsocket.so.

Yes

NSR, SR

QNX

Migration Path

  • Orin to Orin

  • Orin to Thor

  • Dimensity C-X1 to Dimensity C-X1

Migration Release Path

7.2.4.0 to 7.2.5.0

Migration Rationale

The zero-copy APIs eliminate data copies between application and NvSocket shared memory buffers, providing significant throughput improvement and CPU utilization reduction for high packet-rate UDP workloads. Applications can directly read from and write to NvSocket internal buffers, avoiding the memcpy overhead in standard recv/send paths.

Steps to Migrate

No action is required for existing applications. The zero-copy APIs are optional and additive. To adopt zero-copy mode, include nvsocketzc_export.h and replace standard recv/send calls with their zc_ counterparts. Applications must manage buffer lifecycle explicitly using zc_alloc_tx_buf()/zc_free_tx_buf() for TX and zc_free_rx_buf() for RX.

L2 LLA Filter Update IPC (NVSOCKET_PULSE_UPDATE_LLA_FILTER)#

Target Changes

Backward Compatible

Platform

OS

Release 7.2.5.0 introduces a new IPC path that lets the io-sock driver request NvEthMgr to reprogram the per-DMA-channel L2 unicast (LLA) filter on an NvSocket-enabled interface when the link-layer MAC address is changed (for example, via the ifconfig utility). The change adds the following public symbol:

  • NVSOCKET_PULSE_UPDATE_LLA_FILTER - new enumerator added to nvsocket_pulse_code_t in nvsocket_export.h. Sent from the io-sock driver to the NvSocket server to request an L2 filter reprogram.

The numeric value of the NVSOCKET_PULSE_MAX sentinel shifts up by one to accommodate the new enumerator.

NvEthMgr programs both an L2 broadcast filter and a per-DMA-channel L2 unicast filter at interface initialization. As of release 7.2.5.0, this IPC supports updates to the L2 unicast filter only; the L2 broadcast filter continues to be programmed at interface initialization and cannot be updated at runtime through this IPC.

Yes

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5 to 7.2

7.2.4.0 to 7.2.5.0

Migration Rationale

In 7.2.4.0, on NvSocket-enabled interfaces, the NvEthMgr resource manager owns L2 filter programming (both the L2 broadcast filter and the per-DMA-channel L2 unicast filter), so a runtime change of the interface MAC (link-layer address) issued against the io-sock stack could not be propagated to the per-DMA-channel L2 unicast filter. The new IPC closes that gap on NvSocket-enabled interfaces: io-sock detects an LLA mismatch at interface initialization and requests NvEthMgr to reprogram the unicast filter slot with the new MAC. Updates to the L2 broadcast filter are not supported through this IPC in 7.2.5.0; the broadcast filter continues to be programmed at interface initialization. Interfaces on which NvSocket is not enabled are unaffected by this change and continue to use the legacy in-driver L2 programming path.

Operational Constraint

The IPC is invoked from the io-sock interface-initialization path only, on NvSocket-enabled interfaces. Changing the MAC address through the ifconfig utility (or any equivalent) on an NvSocket-enabled interface is therefore recommended only before traffic is started or before the system is moved to the DVMS operational state. MAC address changes issued while such an interface is up and carrying traffic, or after the system has entered the DVMS operational state, are not propagated to the hardware filter and are not supported.

Steps to Migrate

  1. Applications that enumerate nvsocket_pulse_code_t values directly (for example, custom diagnostic or logging tools) should be recompiled against the 7.2.5.0 headers, because the numeric value of NVSOCKET_PULSE_MAX has shifted.

  2. To change the interface MAC on an NvSocket-enabled interface, use ifconfig <iface> lladdr <new-mac> (or an equivalent SIOCSIFLLADDR request) before traffic is started or before the system is moved to the DVMS operational state.

  3. No source change is required for typical NvSocket client applications; the IPC is internal to the io-sock driver and the NvSocket server.

DMA Channel Bound Increase (OSI_MTL_MAX_NUM_QUEUES Renamed and Widened)#

Target Changes

Backward Compatible

Platform

OS

In nvethernetrm_export.h:

  • The macro OSI_MTL_MAX_NUM_QUEUES (10U, gated by !OSI_STRIPPED_LIB) has been removed and replaced by OSI_MAX_NUM_CHANS (48U). The new name reflects DMA channels and the value increases from 10 to 48 to cover T264 hardware.

  • In struct osi_stats, four IRQ-count arrays (rx_buf_unavail_irq_n, tx_proc_stopped_irq_n, tx_buf_unavail_irq_n, rx_proc_stopped_irq_n) grew from [OSI_MTL_MAX_NUM_QUEUES] (10) to [OSI_MAX_NUM_CHANS] (48). Each array gains 38 * 8 = 304 bytes; the struct grows by a total of 1216 bytes and the offsets of every following member of osi_stats shift accordingly.

No. Source changes are required.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

Unifies queue/channel sizing across EQOS and MGBE on T234 and T264 and sizes the diagnostic-counter arrays for the maximum DMA channel count now supported on T264.

Steps to Migrate

  1. Replace every reference to OSI_MTL_MAX_NUM_QUEUES with OSI_MAX_NUM_CHANS. Compile-time signal of this break: 'OSI_MTL_MAX_NUM_QUEUES' undeclared.

    for (i = 0; i < OSI_MTL_MAX_NUM_QUEUES; i++) {
    handle(stats.rx_buf_unavail_irq_n[i]);
}

    becomes

    for (i = 0; i < OSI_MAX_NUM_CHANS; i++) {
    handle(stats.rx_buf_unavail_irq_n[i]);
}

  2. Recompile every consumer of struct osi_stats. Code that allocates, memcpys, or persists osi_stats by hard-coded size must be rebuilt against the new layout.

    struct osi_stats s;
for (i = 0; i < OSI_MTL_MAX_NUM_QUEUES; i++)
    total += s.rx_buf_unavail_irq_n[i];

    becomes

    struct osi_stats s;
for (i = 0; i < OSI_MAX_NUM_CHANS; i++)
    total += s.rx_buf_unavail_irq_n[i];

  3. Audit any IPC, file, or shared-memory boundary that carries osi_stats. The struct grows silently — out-of-date readers will read past the new array bounds with no compiler diagnostic.

OSI Documentation Contract Refinements (tcindex, btr)#

Target Changes

Backward Compatible

Platform

OS

Two field-level documentation contracts in nvethernetrm_export.h changed in 7.2.5.0:

  • osi_core_avb_algorithm.tcindex: the valid lower bound changed from 0 to 1. Traffic class index 0 is reserved; the valid range is now [1, OSI_MAX_TC_NUM-1].

  • osi_est_config.btr[2]: the base-time-register doc contract narrowed from “Valid values are from 0 to UINT32_MAX for each index” to “32 bits for Seconds, 32 bits for nanoseconds (max 10^9)” — the nanoseconds slot is now documented to cap at 1e9 rather than UINT32_MAX.

No. Documented value ranges changed; existing code outside the new bounds becomes non-conformant.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

Traffic class index 0 is reserved (valid range is [1, OSI_MAX_TC_NUM-1] inclusive). The base-time-register nanoseconds slot is bounded to one second per the IEEE 802.1Qbv base-time representation.

Steps to Migrate

  1. For osi_core_avb_algorithm.tcindex: code that programmed tcindex = 0 for a default/legacy traffic class must shift to tcindex = 1 or higher. Compile-time signal: none — this is a runtime contract violation.

  2. For osi_est_config.btr: code that programmed btr[0] (nanoseconds) with values up to UINT32_MAX relying on the old documented contract must now cap the nanoseconds field at 10^9.

Retired NvSocket Server-Configuration Public Surface#

Target Changes

Backward Compatible

Platform

OS

In nvethernet_export.h and nvsocket_export.h, the public surface used to drive nvsocket server-side configuration is retired in 7.2.5.0:

  • The unused macro ETHER_IOCTL_NVSOCKET_STATS (0x1016U) has been removed from nvethernet_export.h. This macro was defined in 6.x but never used — nvsocket statistics were always retrieved via the IPC path, not this ioctl.

  • The nvsocket_server_cfg_t typedef-struct (server-side configuration record covering interface name, channel ids, callback function pointers, batch sizing, log levels, route-lookup parameters and per-flag bits) is removed from the public header.

  • The five flag macros previously carried inside nvsocket_server_cfg_t are also removed: FLAGS_REUSEPORT_UNICAST, FLAGS_PERFECT_MATCH_MULTICAST, FLAGS_SKIP_UC_PKTS_TO_MC_CLIENTS, FLAGS_SKIP_MC_PKTS_TO_UC_CLIENTS, DISABLE_UDP_OVER_IOPKT.

No. Source changes are required.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

The nvsocket server configuration is now considered a private contract between nvsocket and its server process. Exposing the full callback function-pointer ABI through a public header was over-broad and coupled customers to internal driver-callback signatures. The nvsocket statistics retrieval process is unchanged from 6.x — it has always used the IPC path.

Steps to Migrate

  1. Remove any reference to ETHER_IOCTL_NVSOCKET_STATS. This was an unused macro in 6.x and was removed. Compile-time signal: 'ETHER_IOCTL_NVSOCKET_STATS' undeclared.

  2. Remove every declaration, persistence, or read of nvsocket_server_cfg_t and every reference to the FLAGS_* / DISABLE_UDP_OVER_IOPKT macros.

    nvsocket_server_cfg_t cfg = { 0 };
cfg.flags = FLAGS_REUSEPORT_UNICAST | FLAGS_PERFECT_MATCH_MULTICAST;
cfg.tx_callback_funcs.transmit = my_tx_cb;

    becomes

    /* nvsocket_server_cfg_t is no longer public. Server-side
 * configuration is now driven through device-tree properties and
 * the routed/nvsocketd internal control path; the FLAGS_* and
 * DISABLE_UDP_OVER_IOPKT macros have no replacement in the public
 * header. Refer to the nvsocket developer guide for the new
 * configuration mechanism. */

    Compile-time signal of this break: unknown type name 'nvsocket_server_cfg_t' / 'FLAGS_REUSEPORT_UNICAST' undeclared.

  3. For server-configuration introspection at runtime, refer to the nvsocket developer guide for the new configuration mechanism.

nvsocket_pulse_t Enum Reorganization#

Target Changes

Backward Compatible

Platform

OS

In nvsocket_export.h the previously anonymous nvsocket pulse enum was reorganised in 7.2.5.0:

  • The first member NVSOCKET_PULSE_EXIT is no longer fixed at 0 (which previously matched QDP_PULSE_EXIT). The enum now starts at NVSOCKET_PULSE_BIND = 1 and the relocated NVSOCKET_PULSE_EXIT is appended at the tail.

  • The helper member NVSOCKET_PULSE_UNBIND_KILLED_CLIENTS (formerly value 4) is removed; the killed-client path is now folded into the regular NVSOCKET_PULSE_UNBIND_PID flow.

  • Three new pulses are appended: NVSOCKET_PULSE_GET_SOCK_PREFIX_DATA, NVSOCKET_PULSE_ROUTE_SHM_READY, NVSOCKET_PULSE_ROUTE_SHM_UPDATE.

  • Under __DOXYGEN__ the enum acquires a tag name nvsocket_pulse_t.

No. Persisted data / wire values may differ.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

Decouples nvsocket pulses from QDP_PULSE_EXIT, retires the UNBIND_KILLED_CLIENTS helper (folded into the regular UNBIND_PID flow), and reserves stable integer codes for the new SOCK-prefix and route-SHM pulses.

Steps to Migrate

  1. Stop matching pulses by hard-coded integer code. Every symbolic pulse value used after the renumbering point now has a different integer code; numeric matching against 0 (for EXIT) or 4 (for the removed UNBIND_KILLED_CLIENTS slot) silently selects a different pulse.

    MsgSendPulse(coid, prio, 0 /* NVSOCKET_PULSE_EXIT */, 0);
...
case NVSOCKET_PULSE_UNBIND_KILLED_CLIENTS:
    cleanup_killed();
    break;

    becomes

    MsgSendPulse(coid, prio, NVSOCKET_PULSE_EXIT, 0);
/* NVSOCKET_PULSE_UNBIND_KILLED_CLIENTS is gone — handle the
 * killed-client path inside NVSOCKET_PULSE_UNBIND_PID instead. */

    Compile-time signal of this break: 'NVSOCKET_PULSE_UNBIND_KILLED_CLIENTS' undeclared.

  2. Audit any persistence or wire format that carries pulse codes across a reboot or upgrade. Old persisted codes will not map to the same symbolic pulses on 7.2.5.0.

On this page