Conversation
sk4zuzu
commented
May 24, 2026
sk4zuzu
commented
- Add 'set_switchdev' option
- Manage eswitch mode in UDEV
- Make VF;PF;FN detection safer (fix)
- Update README.md
- Add 'set_switchdev' option - Manage eswitch mode in UDEV - Make VF;PF;FN detection safer (fix) - Update README.md Signed-off-by: Michal Opala <sk4zuzu@gmail.com>
|
Hi @sk4zuzu the mode activation is being managed by a udev rule. Testing the node:
hosts:
sm15:
ansible_host: sm15
pci_devices:
- address: "0000:81:00.1"
set_driver: omit
set_numvfs: max
set_switchdev: trueyields this rule The issue is that the command execution is being hooked by the presence of the first virtual function of the PF being set to switchdev. Setting the mode has to be done with 0 VFs, otherwise it fails The result is that ansible succeeds, the rule is created, but the mode remains in legacy. We need to make sure that in the current power cycle, the mode is set, as well as in the next power cycle. This rule worked for me |
|
@dann1 This is interesting because with netdevsim I've seen otherwise, hence the implementation. I mean setting switchdev mode after VFs are created seems to be working fine + I used UDEV specifically so this survives reboot. 🤔 I will research further then thanks, I hope I will not have to implement different procedures for different cards.. 😅 |
|
@dann1 So the procedure I implemented is not entirely incorrect. ☝️😌
This statement is imprecise, your conclusion is actually not true, as if you unbind drivers of all VFs then change the mode, and finally then bind them again: It works.. 🤗 Of course doing this with 0 VFs is easier, though 👍 🥰 |
|
Whatever works best. I tried binding From the intel 810 eswitch guide
However, since you mention driver re-binding, please consider for the follow-up commit(s) that most likely we will use sm15:
ansible_host: sm15
pci_devices:
- vendor: "15b3"
device: "1015"
class: "0200"
set_switchdev: true
set_driver: omit
set_numvfs: 1
set_name: "pf{0[1]}{0[3]}"
unlisted: false
- vendor: "15b3"
device: "1016"
class: "0200"
set_name: "pf{1[1]}{1[3]}vf{2}"
set_driver: vfio-pci
virtual: true
unlisted: false |
|
@dann1 so yes there are 2 obvious cases:
Because of 2. is always possible we cannot assume 1. will be the only situation we deal with. So actually we need to combine both cases into a single solution. I'd say the best would be to extend sriov-manage.sh script, but it has to include code that would deal with devices that have already VFs enabled. Then it's probably easier to see sometihng fails than looking at UDEV logs in the end. 🤔 |
- Migrate bash/systemd code to 'template' tasks - Extend sriov-manage.sh script to accept switchdev option - Revert UDEV attempt Signed-off-by: Michal Opala <sk4zuzu@gmail.com>
|
What about 84bd83c ? I think this should be much simpler approach (mostly what you suggested). 🤔 I also simplified my mock https://github.com/sk4zuzu/libvirt-qemu-research/blob/ba34a6853e093b0dd749d3882c1924ff50f0e751/files/switchdevmock.sh kept only essential stuff, so kernel no longer panics.. 🤭 |
2 participants
