netvsp: adding uevent logging to vf manager#2823
netvsp: adding uevent logging to vf manager#2823erfrimod wants to merge 3 commits intomicrosoft:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds diagnostic logging to the Network VF Manager's uevent processing to help investigate customer issues where ManaDeviceArrived work items are not scheduled. It introduces a new UeventNotification struct that carries both the device path and the action type (add/remove/rescan), replacing the previous approach where only the device path was passed. The existing logic that treats add, remove, and rescan events interchangeably is preserved, while new tracing statements provide visibility into which specific uevent actions are received.
Changes:
- Introduced
UeventActionenum andUeventNotificationstruct to categorize uevent types - Added tracing to log the uevent action, device path existence, and path when processing uevents
- Updated the uevent handler callback to send structured notifications instead of just device paths
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
| // It would be more correct to check that the uevent action is 'add' or 'rescan'. | ||
| // For now, adding tracing to help investigate uevent processing. | ||
| let exists = Path::new(&device_path).exists(); | ||
| tracing::info!(?action, exists, %device_path, "uevent received"); |
There was a problem hiding this comment.
How often are these events expected? Is this going to result in a ton of logging?
There was a problem hiding this comment.
I think there are going to be several of these for every arrival. You can add a new match arm (state, false) => {} and move the trace there since that is the only interesting one for the scenario you describe (got a uevent message but not acting on it because device is not found). You could probably filter even more since a removal and !exists is also not very interesting.
There was a problem hiding this comment.
Done. And I made it tracelimit just in case we do get spammed.
The Network VF Manager has a listener for uevents. These are Linux kernel notifications that tell UH in userspace that a device (MANA) has been added or removed. The UeventHandler squashes together
add,remove, andrescanevents and sends over a string representing the device path. VF Manager then uses the existence of the device path to determine whether to schedule a ManaDeviceArrived work item.In a recent investigation into a customer issue, it was difficult to work out why ManaDeviceArrived was not scheduled. There are several possibilities and nothing is logged when it is not scheduled.
UeventNotificationwhich specifies which uevent arrived along with the device path.add,remove, andrescaninterchangeably in VF Manager. I have no way of knowing what (if anything) would break if prevented remove uevents from scheduling ManaDeviceArrived.