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

[Martin Townsend <martin.townsend@xsilon.com>]

Hi Alex,

On 08/09/14 19:55, Alexander Aring wrote:
> Hi Martin,
>
> On Mon, Sep 08, 2014 at 08:36:52PM +0200, Alexander Aring wrote:
>> Hi Martin,
>>
>> On Mon, Sep 08, 2014 at 07:13:02PM +0100, Martin Townsend wrote:
>> ...
>>>>> Hi,
>>>>>
>>>>> I'll respin and include the memory leak fix and this patch and a couple of
>>>>> others I have and send as a series to bluetooth.  What bluetooth git
>>>>> repository should I base the series on?
>>>>>
>>>> What's the state about to fix this bad issue? :-)
>>>>
>>>> I didn't saw any new patches because of this.
>>>>
>>>> - Alex
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Sorry for the delay, been on hols for a few days, I will create the patches
>>> tomorrow if I get time.
>>>
>>> I have also implemented Generic Header Compression[0] which is still in
>>> draft at the moment but I can't imagine it will change much before being
>>> released.  I'm going to integrate it into our linux repository this week.
>>> Would you be interested in putting it in linux-wpan or linux-wpan-next or
>>> would you prefer to wait until it gets it RFC status?
>>>
>> no, for me it's okay to have this mainline. I heard that a draft becomes
>> no RFC when nobody implements it.
>>
> 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.
> 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.

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?
>
> Same opinion here? We can talk about that point.
>
> - Alex

- Martin