Hey Martin,
just my two cents: I agree to Antonio to keep the packet list struct alive at least for a few seconds. If your packet stream has less than 100 packets per second (which is quite common IMHO) for your 10ms send-and-free scenario, many packet list structs would be destroyed and reinitialized over the time.In worst case, this would happen for every single packet which comes by, for example if you have a steady 50 packets/s stream (typical VoIP streams with 20ms packetization).
Cheers Simon
On Mon, Oct 17, 2011 at 06:37:55PM +0200, Antonio Quartulli wrote:
Hello Martin,
and thank you for the explanation.
On Mon, Oct 17, 2011 at 03:16:25 +0200, Martin Hundebøll wrote:
Now here's the question: When a list of a certain coding_path becomes empty, should I free the coding_path right away, or should I timestamp it and mark it for removal at a later time. The thing is that I don't know whether a new packet for the same coding_path will arrive in a short moment. If I have just freed the coding_path struct, I would have to spend ressources to initialize it again...
It is probably a micro-optimiziation and the simplest solution would be to just free it right away, but I would like to have your comments anyways.
In my opinion it would be better to _keep_ the struct even if the corresponding packet list is empty.
Imagine there are two packet flows going through a relay node R. If the two coding paths of the two flows have an high coding correlation at R (coding opportunity?), one of the two packet lists on R will be emptied several times during the data transmission.
For this reason I think it would be better to wait a fixed time before freeing such structure. The overhead given by the freeing/reallocating/reinitialising operation could become not negligible.
I hope that I correctly understood the problem and that my idea was clear :-)
Cheers,
-- Antonio Quartulli
..each of us alone is worth nothing.. Ernesto "Che" Guevara