need to understand how to use the sendmmsg

[harshitha-st]

when trying to run the application of the secnetperf with strace and trying to trace the sendmmsg, sendmsg, recvmmsg, recvmsg
only able to see the sendmsg,recvmsg,recvmmsg

any idea on how to run the secnetperf so that it uses the sendmmsg

[huoyaoyuan]

This doens't sound related to this project.

[johnkaram02]

secnetperf is MsQuic's perf tool, so the behaviour comes from MsQuic's Linux datapath (src/platform/datapath_epoll.c in microsoft/msquic), not from .NET. What you're seeing is expected: MsQuic only uses sendmmsg as a fallback when UDP GSO isn't available.

How it decides:

1. At startup, CxPlatDataPathCalculateFeatureSupport (src/platform/datapath_linux.c) opens two loopback UDP sockets and sends an 8 x 1476-byte buffer with a UDP_SEGMENT control message. If that sendmsg succeeds, it sets CXPLAT_DATAPATH_FEATURE_SEND_SEGMENTATION.
2. In CxPlatSendDataSend, UDP sends then go through:

SendData->SegmentationSupported ?
    CxPlatSendDataSendSegmented(SendData) : CxPlatSendDataSendMessages(SendData);

CxPlatSendDataSendSegmented coalesces the whole batch into one buffer and sends it with a single sendmsg carrying a UDP_SEGMENT cmsg, and the kernel splits it into packets. Only CxPlatSendDataSendMessages (the non-GSO path) calls sendmmsg.

So on any kernel from 4.18 up (where UDP_SEGMENT exists), you'll see sendmsg for sends and recvmmsg for receives, which matches your trace. To confirm GSO is what's happening, run strace with -f (sends happen on MsQuic's worker threads) and -v, and look for cmsg_type=UDP_SEGMENT in the sendmsg calls:

strace -f -v -e trace=sendmsg,sendmmsg ./secnetperf ... 2>&1 | grep -m5 UDP_SEGMENT

There's no runtime setting to turn GSO off and force the sendmmsg path. Your options:

• Run on a kernel or NIC/path where the probe fails. Also, if a GSO send ever returns EIO, MsQuic clears the segmentation feature globally and falls back to sendmmsg from then on.
• Build MsQuic yourself and stop CxPlatDataPathCalculateFeatureSupport from setting CXPLAT_DATAPATH_FEATURE_SEND_SEGMENTATION (for a quick experiment, comment out that line).
• Make sure it isn't built with QUIC_LINUX_IOURING_ENABLED (it's OFF by default), because the io_uring datapath submits I/O through the ring and you won't see these syscalls in strace at all.

Also, sendmmsg is only called directly if CMake found it (HAS_SENDMMSG). Otherwise MsQuic uses a shim that loops over sendmsg, so on an unusual libc you'd see sendmsg even on the fallback path.

For follow-ups, microsoft/msquic is the better place to ask, since this repo (dotnet/runtime) only consumes MsQuic for System.Net.Quic.