Packet type decision is not optimal
Bug #995598 reported by
Didier Barvaux
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
rohc |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
As found during correction of bug #767354, the algorithm that decides the best packet type is not optimal. It should be reworked.
An option is to split all conditionnals in small functions, one per packet type (IR, IR-DYN, UO-0, UO-1... UOR2-TS/NO-EXT, UOR2-TS/EXT0, UOR2-TS/EXT1, UOR2-TS/EXT2, UOR2-TS/EXT3...). The function would determine:
1/ whether the packet can be used or not?
2/ what length (in bytes) would the packet take?
The main function would then call every packet function and keep only the one that can be used and with the smaller length.
Caveat: too many CPU cycles?
Changed in rohc: | |
milestone: | 2.0.0 → 2.1.0 |
Changed in rohc: | |
status: | New → Incomplete |
status: | Incomplete → Confirmed |
Changed in rohc: | |
milestone: | 2.1.0 → 2.3.0 |
Changed in rohc: | |
milestone: | 2.3.0 → 2.5.0 |
To post a comment you must log in.
* When deciding packet type, nr_ipv4_ non_rnd_ with_bits >= 1 could be replaced by nr_ipv4_non_rnd >= 1. It might cause some packets to be larger if TS bits from the base header cause extension 3 to be selected for example, so more conditions should be added before to avoid this.
* merge decide_extension and decide_packet