From a16dcd27de41cac7df56dffdf9a56b8ccdc4d660 Mon Sep 17 00:00:00 2001 From: Thomas Eizinger Date: Mon, 18 Nov 2024 15:06:19 +1100 Subject: [PATCH] Log GSO halt on info It is common to set up automated error reporting based on `ERROR` and potentially also `WARN` logs. Whilst GSO being unsupported is certainly something worthwhile logging, the `ERROR` log level seems a bit excessive and leads to unactionable errors reports. The system can still operate with `max_gso_segments == 1`. As such, this codepath "merely" indicates a state change in the system but not a fatal error. As such, logging this on INFO level seems more appropriate. --- quinn-udp/src/unix.rs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/quinn-udp/src/unix.rs b/quinn-udp/src/unix.rs index cf3518173..4978fa414 100644 --- a/quinn-udp/src/unix.rs +++ b/quinn-udp/src/unix.rs @@ -322,7 +322,9 @@ fn send( // Prevent new transmits from being scheduled using GSO. Existing GSO transmits // may already be in the pipeline, so we need to tolerate additional failures. if state.max_gso_segments() > 1 { - crate::log::error!("got transmit error, halting segmentation offload"); + crate::log::info!( + "`libc::sendmsg` failed with {e}; halting segmentation offload" + ); state .max_gso_segments .store(1, std::sync::atomic::Ordering::Relaxed);