Hi Martin, On Tue, Sep 09, 2014 at 10:28:36AM +0100, Martin Townsend wrote: ... > > I thought more about that, you mean the receiving part only? So the > > uncompression. The point is that we don't have no interface for an user > > that can decide if he like to use UDP compression like RFC 6282 or UDP > > compression like GHC. This is only relevant for the transmit part. So > > compression is optionally. (We should have some interface to make this > > configurable by user -> adding this to the nhc layer, later). > I've implemented compression and decompression. You are right in that we need a mechanism of configuring what gets compressed by what method. ok. But how we deal with that currently with GHC UDP and UDP RFC6282 compression. We can't not support both compression methods. btw. how we should call it now? Uncompression or decompression, I can also name the callbacks to decompression. I am not a native speaker so I will ask you which is better now. :-) > > On the uncompression part, means the receiving part we can support both. > > UDP RFC 6282 or UDP like GHC, the next header id value should be > > different there. That means currently we can receive every packets but > > transmit only RFC6282 compression formats. > > > > So for receiving this, it's okay. But for compression, since we don't > > have some interface to make this configurable we should use RFC 6282. > So I will ensure UDP is compressed by 6282. Then I was going to start out by just compressing ICMPv6 with GHC and monitor how much data is saved by using GHC. Later on we will implement a mechanism of configuring what gets compressed and by which compression method. Okay, you mean that you will leave UDP compression by 6282 but insert a receive handling (decompression) for UDP GHC? RFC6282 doesn't describe any compression/decompression(or uncompression) format for ICMPv6, so we could handle there compression and uncompression. I understand now you did it that way, or? About the mechanism by user: There are several ways about to do it from userspace. I know now sysfs or netlink. Do you have already some idea how you want to make this configurable by user? btw. This reminds me a little bit like setting led trigger type, (blink, heartbeat, mmc, net, etc...). This is done by sysfs. > > The GHC spec states that a device indicates it's GHC capability using a 6LoWPAN Capability Indication Option (6CIO), this is an ND option. As far as I can see there is no type assigned yet by IANA so I was wondering if we should have this as an experimental configuration item in the kernel? Yes, please make a bool into net/6lowpan/Kconfig and add support for drafts only if selected. In code you simple need to use "if (IS_ENABLED(CONFIG_FOO))" to registration the nhc format into the nhc framework/layer or not. Replace FOO with a propber 6LOWPAN_NHC_DRAFTS or something else. You can write in the help what exactly this means. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
