Re: [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

[Alexander Aring <alex.aring@gmail.com>]

On Tue, Sep 09, 2014 at 11:46:52AM +0200, Alexander Aring wrote:
> 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.

Forget this one, I failed here. We should complete get out the draft
implementations when it's not selected by buildsystem.

We need something like this here. "Adding dummy functions with ifdefs".

#idef CONFIG_FOO
/* real prototype */
int lowpan_nhc_add_fancy_format(foo);
...
#else
static inline int lowpan_nhc_add_fancy_format(foo) { }
...
#endif

also according to Makefile that we don't build the files which
implements "lowpan_nhc_add_fancy_format".

- Alex