[RFE] Individually set interface network type at a host level

[QuantumPosix]

Using the same concept that is already existing in --modify-switch-conf use this to individually set the type of network for the interface

quads --define-network --host $host --nic1 roce0 --nic2 qinq0 --nic3 pub --nic4 qinq0 --nic5 qinq0

[sadsfae]

quads --define-network --host $host --nic1 roce0 --nic2 qinq0 --nic3 pub --nic4 qinq0 --nic5 qinq0

if this is per-host level (and would be persistent) this can likely fall into --mod-interface and kept/tracked in the database.
If we're talking about an easier way to define new VLAN design modes then --define-network would be a good approach.

Can you explain a little more about your use case here?

[QuantumPosix]

These would not be persistent across hosts or assignments but could be configured / defined at a cloud or host level just as you would with our current qinq setting. The issue is that not every host interface needs to be one of the new types, but can be individually set based on hardware criteria. Dont want to keep the same logic where if you set it at the cloud level like this, every interface is roce. quads --define-cloud --cloud $cloud --description "ROCE testing" --cloud-owner $owner --cloud-ticket $ticket roce 0 but having the capability to have it set similarly to how --mod-switch-conf handles vlans we get better control from the start and proper network validation of the reservation. quads --define-cloud --cloud $cloud --description "ROCE testing" --cloud-owner $owner --cloud-ticket $ticket --nic1 roce0 --nic2 nvme0 --nic3 nvme0 --nic4 qinq0 --nic5 pub etc... If I have 5 servers in a reservation and nic1 is a 400g nic2 is a 100g nic3 is a 100g nic4 is a 25g and nic5 is a 25g i would want to apply the roce config to interfaces where its needed. Same thing if latency / drops were a concern I would not want to apply nvme settings that miss out on priority queue and flow control. ~ Thanks, Chris

…

On Thu, Jun 11, 2026 at 11:36 AM Will Foster ***@***.***> wrote: *sadsfae* left a comment (quadsproject/quads#684) <#684 (comment)> quads --define-network --host $host --nic1 roce0 --nic2 qinq0 --nic3 pub --nic4 qinq0 --nic5 qinq0 I think we don't need a new parser argument and model here, if this is per-host level (and would be persistent) this can likely fall into --mod-interface and kept/tracked in the database. Can you explain a little more about your use case here? — Reply to this email directly, view it on GitHub <#684?email_source=notifications&email_token=AG3IDEAA56OZ76QFFSESUKT47LGXBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRYGIZDMOBXGU2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4682268754>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3IDEC5WH6Q4VOK7KVJFET47LGXBAVCNFSNUABEKJSXA33TNF2G64TZHM3TGOJSHEZDEMZ3JFZXG5LFHM2DMNBRHA2DCOBTGSQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AG3IDECMXTLA7BSMDZ5QSB347LGXBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRYGIZDMOBXGU2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AG3IDEE3A4NSQIATJFRNTOL47LGXBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRYGIZDMOBXGU2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[sadsfae]

These would not be persistent across hosts or assignments but could be
configured / defined at a cloud or host level just as you would with our
current qinq setting. The issue is that not every host interface needs to
be one of the new types, but can be individually set based on hardware
criteria.

Dont want to keep the same logic where if you set it at the cloud level
like this, every interface is roce.
quads --define-cloud --cloud $cloud --description "ROCE testing"
--cloud-owner $owner --cloud-ticket $ticket roce 0

but having the capability to have it set similarly to how --mod-switch-conf
handles vlans we get better control from the start and proper network
validation of the reservation.

quads --define-cloud --cloud $cloud --description "ROCE testing"
--cloud-owner $owner --cloud-ticket $ticket --nic1 roce0 --nic2 nvme0
--nic3 nvme0 --nic4 qinq0 --nic5 pub etc...

This really sounds like day 1 stuff that can be done with --mod-switch-conf if it changes often.

I think in general a --define-network option to set/define VLAN mappings / changes similar to how --mod-switch-conf operations is generally useful, though.

This would be done at the cloud level but you'd give it a simple naming convention that makes sense to you (and your lab) and not need to pass vars to every interface. You could have as many as you needed, specific to you.

If I have 5 servers in a reservation and nic1 is a 400g nic2 is a 100g nic3
is a 100g nic4 is a 25g and nic5 is a 25g i would want to apply the roce
config to interfaces where its needed. Same thing if latency / drops were a
concern I would not want to apply nvme settings that miss out on priority
queue and flow control.

What's with the roce0 and nvme0 args? What does that mean?

If you intend to do really granular levels of switch changes, especially niche performance tunings I don't think that's something that will fit well with QUADS.
You should likely just use your own tools for day 0 / day 1 stuff.

A reasonable compromise might be to utilize the plugin architecture to write your own post-release / post validation callback plugin you can copy in and support that do these kinds of things for you, it's really too one-off to be something that fits well with QUADS - e.g. something we have to scope, develop, plan support when it's extremely niche.

We aren't in the business of switch performance tuning - especially niche setups, we're in the business of scheduling and shipping infra quickly and efficiently. That goes as far as port configuration only and connectivity, tuning knobs isn't something that's tenable to support inside the core project as we can't every tackle every scenario like that.

Instead, leveraging the plugin architecture to do that last mile for you is a more elegant and scalable solution. Nobody else can grow, adapt or evolve niche needs better than the person that thinks they need it.

I would like to see this issue instead be focused on providing a proper post-validation callback plugin structure so you can do what you think needs to be done specific to your lab use case that you can write and maintain.

~ Thanks,

Chris
…

[sadsfae]

I think we can tackle this here: #686 but leaving this issue as related to preserve the discussion.

[sadsfae]

patchset: https://review.gerrithub.io/c/quadsproject/quads/+/1239602