On Tuesday 22 October 2013 23:47:10 Linus Lüssing wrote:
Or actually I just go ahead from the things which got mentioned in your email and on IRC by Antonio already.
The only reason I reply here is to give you pointers. I can only repeat what I wrote in the other mail: We need reasons why we need/want something instead of reasons why we could not not want something.
# Code complexity
Wouldn't this actually reduce code complexity? Now the code needs to distinguish which packet type it got and based on that needs to perform TVLV parsing. "Moving TVLVs down to the common header" does not duplicating the code to for every packet type in my understanding, but the contrary, unifying things, "just moving" the current concept.
Please consider the broader picture: We need TVLV parsers everywhere. batctl and wireshark still can't not decode the TVLVs we have today. On top of that, TVLVs require dynamic header / memory management involving lists, locks, size calculations, etc which you simply don't have with static headers.
# Network Traffic overhead
It's just 2 Bytes extra for the tvlv_len which doesn't seem much to me. Furthermore I'm wondering, whether saving these two bytes but not being able to run some new, more efficiant feature could be a net loss in terms of overhead in the future.
Please compare the original OGM size to the TVLV-OGM before starting to talk about '2 bytes extra' ...
# TVLV parsing speed overhead
If no TVLV were actually added, then this would be nearly zero parsing overhead, checking whether tvlv_len == 0 is trivial. Of course, if no other packet types than the current TVLV capable ones were actually having TVLVs one day, then wouldn't need this discussion, true. Broadcast packets, for instance, aren't really on the fastest fastpath, thre it wouldn't harm TVLVs, I think. But also in general, I don't quite see, why packets on the fastpath shouldn't have some TVLVs in the future: For one thing the parsing speed overhead heavily depends on the kind of TVLV, how complex it is to parse it. And why not having some easy to parse TVLVs for those too? Embedded systems already need to be able to parse Ethernet and IP headers as well as IP options on a hop-by-hop basis in layer 3 routing. Also, even embedded systems become faster and faster every day.
So, you are saying there is overhead but we should not care because systems get faster and faster anyway ? Or are you saying your coming proposal only contains tvlv_len = 0 ?
# Encapsulation speed overhead
Again, heavily depends on the kind of TVLV, doesn't it?
Your point being ? Actually, your last statement illustrates my point. Shortly after the start of the discussion we are already so abstract that I don't even know what we are talking about.
Cheers, Marek