Hi, On Wed, Sep 09, 2015 at 05:26:29PM +0200, Stefan Schmidt wrote: > Hello. > > This is a first stab at RFC7400. So far we only hook into the NHC framework to > detect the three registered GHC types (extension header, UDP and ICMPv6). > This is aligned with how we detect the NHC frames. > can we add a "nhc_..." prefix to all module names? Then we have something like what netfilter does with "nf_...". > TODO items: > o How to handle reserved and unassigned ranges in the HEADER TYPE? Maybe it's better to remove the current nhc_id evaluation. I did this stuff with rb-tree by knowning RFC6282 only, there was the one information given that "nhc id" is a variable length bitfield only. I don't know how the "logic" about assign these nhc id's is, if iana has one. What I see when I look at [0]. Maybe we could grab the same mechanism like evaluate 6lowpan dispatch values, by returning RX_CONTINUE if the nhc_id doesn't match. Determined by nhc_id length mask and id. The rb-tree mechanism is MAYBE faster, but this depends on amount of registered entries. I don't think there is ever so much many nhc ids that a rb-tree give "huge" benefits that we should use a rb-tree now, or it making thinks too much complex. :-/ I just stumble over rb-tree's to search a right datastructure for matching variable length bitfields -> "strings". Now I am not sure if this was a good idea to do this in that way. These rbtree's are getting also a benefits only when the nhc_id is more than one byte long and this also doesn't exist right now. Also the first byte need to have one or more subtree's. Means e.g. the first byte need to indicate that another bytes follows. I suppose they will add some nhc_id byte like "1111 1111" which indicates one byte will follows. If this will be only one byte, e.g. the "1111 1111" then rbtree is surely the wrong datastructure... but maybe they will also add some "1111 1110" which also indicates anothers subtree of nhc_id's. I don't know it because there is no information about that. Maybe iana [0] will say that with "Unassigned, reserved for extensions" and it should stand somewhere in RFC6282, but I don't see that somewhere inside of RFC6282 which describes "1111 1111". :-/ They describes something about a nhc class: "(i.e., k one-bits followed by one zero-bit identify the general class of NHC, followed by class-specific bit assignments)." Maybe they meant something that: "1111 1111" -> BAR nhc classes "1111 1110" -> FOO nhc classes .... -> ... nhc classes Then a rbtree _maybe_ gives some benefit but I also think it doesn't matter then, because it's simple not a huge amount of entries there. - Alex [0] https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#lowpan_nhc -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
