Hi Martin, On Wed, Feb 05, 2014 at 10:08:03AM +0000, Martin Townsend wrote: > Hi Alex, > > I have been testing your 6lowpan_pending branch with the fragmentation > updates (commit 5e47d2f516a6cf1acf9927125392484835d93552 - I don't think > this has the spin_lock patch below) using 2 devices pinging each other,
I thought I fix a little bit in the net branch which used the old fragmentation api. But David Miller said it already the synchornization of the fragmentation is a mess, so I decide to reimplement the fragmentation api of 6lowpan. That means you don't need this patch, I removed everything from the current fragmentation api and replace it. > one with 1000 byte ping and the other with a 777 byte ping and the good > news it was working fine for about 3/4 hour. The bad news is that it > gets to a point where something happens and then only sporadic pings are > getting through on one device and the other I've seen one ping get > through in about 10 minutes. Could this be a symptom of what your > describing here or would it completely freeze? If I stop the pings and > set them both off again withdefault packet sizes it works fine again. > As soon as I try to using a larger ping payload it becomes sporadic again. > I guess it's because the fragmentation queue and the memory managment. The new fragmentation have a garbage collector and some other things but it has basically a maximum memory size and if you reach this memory size... I don't know what happens then there. Maybe you experience this issue yet. The good news! You can change some parameters for the garbage collector and we should use some "good defaults" for 6lowpan. The bad news, you can't change these parameters at runtime (oh yea, ipv6 can do this but I dropped it... I will add the necessary sysfs entries there). Maybe you want to try it out now, then search for IPV6_FRAG_HIGH_THRESH IPV6_FRAG_LOW_THRESH in net/ieee802154/reassembly.c. This are the default values for ipv6. Currently I don't have any time to think about some default values for 6lowpan. Maybe you can help me there! It works after you stopped it because the garbage collector runs and drops many things out of the fragmentation queue. (I think). > I'll try and get some sort of tracing working to see if this shows > anything. If you have a branch with the inet_frag api changes I don't > mind trying them out too. > Give me some time, then I will create a new branch on current net-next with the necessary sysfs entries and will cleanup the code. Then I need you! If you have tested these patches for new fragmentation, then I can add a Tested-by <martin....> to these patches, so it's easier to get this patches mainline. That's a really big help :-) - Alex ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
