Hi,
Marek and I have been chatting a little about the buggy vis raw output yesterday. And there was either the option to sort the mixed list on the receiving vis server or on the sender already. For the second option there was also the idea of changing the vis packet format accordingly to also save some more overhead. Currently, we're sending a mixed list of (src,dest,quality) with the struct vis_info_entry. Instead, the idea for a new format was the following:
vis_packet.entries = number of source interfaces of this originator followed by tuples {src,num_neighbours,num_neighbours x {dest,quality}} for each source interface of a node.
Additionally, the first entry shall be the one of the primary interface already.
I've made a little prototype patch, see the attachment for this (it applies on top of Simon's last vis_refcount additions patch). I haven't done the more difficult part yet, the sorting and structuring that has to be done in the generate_vis_packet() instead now.
If you think this kind of format is ok, then I'd like to have some more opinions of how to deal with the structuring in the generate_vis_packet(). My idea so far is, to create num_if lists and malloc and copy the information for every neighbour of an originator during the locked orig_hash iteration and freeing as well as packing those list after realeasing the lock. Or, if the mallocs might take too much time for being used so often during the lock, to allocate num_ifs buffers with the maximum vis_packet size (currently 1000B) for each interface batman is using before entering the spinlock. And I guess, that anyway num_ifs would have to be made an atomic_t, right?
Cheers, Linus
PS: Could someone explain, why the recv_list_add() is being done with a sender_orig instead of vis_orig? Because if using vis_orig, then we could get rid of the sender_orig as well because of having this information in the ethernet header already.