Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on Dec 9, 2025. It is now read-only.

Conversation

@gauravkghildiyal
Copy link
Member

The e2e tests will fail and need changes, but I want to discuss the direction first before diving in too deep to modify the tests

@gauravkghildiyal gauravkghildiyal changed the title [WIP] TODO: Use PCI Device as the immutable device and add network interface data as it's (mutable) attributes [WIP] TODO: Use PCI Device as the immutable device and add network interface data as its (mutable) attributes Aug 8, 2025
@michaelasp
Copy link
Collaborator

So effectively the idea is here to use PCI addresses as the real device and update them depending on what we discover on the pci bus. This is far less likely to change but wondering if it's not ideal that we are adding a full dependence on it being a PCI device. Are there cases where a network device wouldn't be on a PCI lane? E.g dummy devices but that's not a convincing argument imo.

@gauravkghildiyal
Copy link
Member Author

You are correct and I personally am also a bit on the fence. It certainly isn't ideal. But I also think that there's lot of unknowns about how network interfaces relate to other hardware on machines and maybe we should start with building the most common use cases involving HPC/GPU/TPU machines and later on extend this as more cases come to light. I expect PCI devices should also play out well with how we extend this to SR-IOV #179. (I still want to test and research a bit more before I fully commit

@gauravkghildiyal
Copy link
Member Author

Working on an alternate approach. Please do not review this. Keeping it open for the sake of comparison for now.

@gauravkghildiyal gauravkghildiyal changed the title [WIP] TODO: Use PCI Device as the immutable device and add network interface data as its (mutable) attributes [OBSOLETE - TO_BE_DELETED] TODO: Use PCI Device as the immutable device and add network interface data as its (mutable) attributes Aug 14, 2025
@gauravkghildiyal
Copy link
Member Author

Going from a PCI Device to it's associated network device felt like lot's of unknowns right now. Trying to model this in the reverse manner of only picking network interfaces that have some "stable" identifier. Continuing in #194

@aojea
Copy link
Collaborator

aojea commented Aug 16, 2025

I think that we do not need to overcomplicate this:

  • we detect all network devices in the root namespaces independently if they are virtual or physical, the existing netlink logic is valid.
  • some of these interface are physical, we already have logic to detect those

We want physical devices to be stable and do not disappear from the resourceslice, so we need to discover them from the pcibus, a gemini query tells me we can use the class for that, I double checked and indeed 0x02 is for network controllers https://sigops.acm.illinois.edu/old/roll_your_own/7.c.1.html

#!/bin/bash

# Find all 'class' files within PCI device directories
find /sys/devices/pci* -name class | while read -r class_file; do
  
  # Check if the class code starts with 0x02 (Network Controller)
  if grep -q "^0x02" "$class_file"; then
  
    # Get the parent directory of the 'class' file (the device's main directory)
    device_dir=$(dirname "$class_file")
    
    echo "Found Network Device at: $device_dir"
    echo "---"
  fi
done

In my example it works, it finds the 3 network devices, despite one of them is already in a namespace

 ./find_network_devices.sh 
Found Network Device at: /sys/devices/pci0000:00/0000:00:04.0
---
Found Network Device at: /sys/devices/pci0000:00/0000:00:06.0
---
Found Network Device at: /sys/devices/pci0000:00/0000:00:05.0
---

}

devices := []resourceapi.Device{}
ifaces, err := nlHandle.LinkList()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this logic remains

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or we just use sys/class/net but we keep the existing behavior working, just we have two source of truth now, the sys/devices and (sys/class/net or netlink)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants