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.
And maybe the last explanation about the "buggy vis output" wasn't clear enough. With the current vis raw output we're loosing the information with _which_ interface we are seeing another nodes's interface (currently we are always starting a vis raw output line with the primary interface mac instead of the according interface's mac).
Cheers, Linus
On Thu, Mar 04, 2010 at 12:39:46AM +0100, Linus L??ssing wrote:
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.
A comment about the mainline development process. Changes which are clearly bug fixes we should be able to get merged into the -rc kernels at any time. Changes which look like development work have to wait until the next merge window.
This vis problem about it showing the wrong interface will be in -rc1. It would be nice to get it fixed. We are more likely to get such a fix accepted if it is small and looks like a bug fix. I expect it will get rejected if it is big and looks like development work.
So can we develop two fixes? Something small and simple for -rc1 and an optimizing fix which will go into linux-next and then into mainline during the next merge window?
Andrew
Hi Andrew,
Ah, okay, that makes sense. I was wondering about how the compatibility version would have to bedone anyway in such a case :D. So it should probably also be a general thing to better not change the compat-version during one merge window, right?
I'll try to make too patches now then, that's fine.
Cheers, Linus
On Thu, Mar 04, 2010 at 10:03:55AM +0100, Andrew Lunn wrote:
On Thu, Mar 04, 2010 at 12:39:46AM +0100, Linus L??ssing wrote:
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.
A comment about the mainline development process. Changes which are clearly bug fixes we should be able to get merged into the -rc kernels at any time. Changes which look like development work have to wait until the next merge window.
This vis problem about it showing the wrong interface will be in -rc1. It would be nice to get it fixed. We are more likely to get such a fix accepted if it is small and looks like a bug fix. I expect it will get rejected if it is big and looks like development work.
So can we develop two fixes? Something small and simple for -rc1 and an optimizing fix which will go into linux-next and then into mainline during the next merge window?
Andrew
Hi,
Ah, okay, that makes sense. I was wondering about how the compatibility version would have to bedone anyway in such a case :D. So it should probably also be a general thing to better not change the compat-version during one merge window, right?
if you change the vis packet format we will need to increase the compat version, hence it will go into the development branch (gearing towards 0.3 at the moment). If your patch maintains compatibility it can be merged into the maint branch.
Regards, Marek
b.a.t.m.a.n@lists.open-mesh.org