Return-Path: Message-ID: <540EC844.2040008@xsilon.com> Date: Tue, 09 Sep 2014 10:28:36 +0100 From: Martin Townsend MIME-Version: 1.0 To: Alexander Aring CC: Marcel Holtmann , linux-zigbee-devel@lists.sourceforge.net, linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org Subject: Re: [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped. References: <53DCE75C.2030305@xsilon.com> <20140821083945.GA29484@omega> <3DF0C18C-4A97-4A00-AB0F-9E01F72CE967@holtmann.org> <53FE446D.6040805@xsilon.com> <20140908104008.GB6981@omega> <540DF1AE.2070709@xsilon.com> <20140908183652.GA633@omega> <20140908185519.GB633@omega> In-Reply-To: <20140908185519.GB633@omega> Content-Type: text/plain; charset=utf-8 List-ID: 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