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

[interduo]

When doing partial reload (--update-only) there is a packet loss.

There are many different situations when we need to reload.

1. Tariff/speed change only: We could ommit packet loss using command: tc class change / tc class replace. No XDP filters changing needed.

2. Adding new circuits: We could use tc class add to random/last node. Only one XDP filter adding needed.

3. Removed circuits: We could use tc class del. Only one XDP filter deletetion needed.

I couldn't find implementation in python/rust code. Is there any reason why it could be done in this way and not doing big implementations like @thebracket says some month ago on Zullip?

connected? https://github.com/LibreQoE/LibreQoS/issues/208

If we would not using XDP there would be no packet loss?

[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?

[interduo]

Ok - it's good to add solution for this problem (packet loss during reload).

This problem could be "ommited" outside libre just:

1. Change the cost of the path on border router/switch (lower cost on libreqos path) - this will result in sending outgoing traffic to customers on path where there is no libreqos.
2. Change the cost of the patch on core router/switch (lower cost on libreqos path) - this will result in sending inbound traffic to customers on path where there is no libreqos.
3. Make reload on libreqos
4. Revert the costs back on both devices.