v1.5-beta: reloading All QoS rules - don't drop packets for customers when doing partial reloading (c.d.) about libreqos

[thebracket]

Related to: #394
Tagging to 1.6, since reworking this is one of the primary focuses of that version.

We've discussed this a few times in the chat, so I don't really want to go over it all again. So to summarize:

• tc class change and tc class replace still drop the contents of the qdisc's buffer, so you get packet loss.
• Adding to random is a really bad idea (collisions), adding to the end is great - and now requires the maintenance of state to handle the addition. Hence - we need a system to track the state. And what do you know? A state machine works quite well for that.

Remember that most people don't run flat networks, and changes can be quite dramatic in scope - especially if integration hasn't run for a while, topology has changed (especially because failover to backup circuits happened).

If you setup a completely XDP-free setup (and enjoy your single core performance), you'd still have packet loss when you change an active queue.

And no, nothing to do with 208.

Marking as invalid and closing.

[interduo]

Now its written here and related to first occured issue. Imo should be marked as duplicate instead of invalid.

Thanks for describing that "on paper" i will give a link for few persons.

[interduo]

Next idea of solution for that problem:

1. Create second subqueue (names: first, second)
2. When reloading just create structure into second root subqueue.
3. Change XDP filters to pass packets to newly created queues.
4. Wait sometime.
5. Destroy first subqueue

Is that technicaly possible?