Date: Wed, 15 Mar 2006 09:18:01 +0100 (CET) From: Harti Brandt <hartmut.brandt@dlr.de> To: Robert Watson <rwatson@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: netatm: plan for removal unless an active maintainer is found Message-ID: <20060315091218.E56469@beagle.kn.op.dlr.de> In-Reply-To: <20060315004530.B5861@fledge.watson.org> References: <20060315004530.B5861@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Mar 2006, Robert Watson wrote: RW> RW>For some time now, the FreeBSD Project has been carrying around at least RW>three ATM stacks: RW> RW>- netatm - HARP, the Host ATM Research Platform RW> RW>- netnatm - A fairly minimal socket<->virtual circuit ATM wrapper for ATM RW> device drivers RW> RW>- ngatm - NetGraph ATM framework RW> RW>For a variety of reasons, it would be desirable to do a bit of pruning of ATM RW>stacks. In my previous conversations with Harti and Bruce, the conclusion RW>has generally been that ngatm and netnatm provide almost all functionality RW>provided by netatm and more, but in modern, and actively maintained, RW>frameworks. RW> RW>The main motivator for pruning has to do with the SMP network stack work: RW>we're reaching the point, discussed on a number of occasions previously on RW>this mailing list, where jettisoning unmaintained network stack components RW>that are unable to run MPSAFE, is highly desirable. This would allow us to RW>remove compatibility shims that are increasingly burdonsome in terms of RW>performance and complexity. Another aspect of this has to do with upcoming RW>changes to the socket and pcb code, which will require maintainers of RW>protocols to do a small but non-trivial amount of work to update protocols to RW>fit the new socket behavior. Right now, almost all other sections of the RW>network stack have active maintainers who are able to do this work, both RW>development and testing, except for the netatm code. RW> RW>We've reached the point where continuing to carry around a third ATM stack is RW>a significant impediment to continued work on network stack performance and RW>reliability work. This should not be a surprise to anyone who reads this RW>mailing list regularly, since I sent out e-mail on this very topic on July RW>18, 2005, warning that netatm (and several other components) were at risk as RW>unmaintained but substantial network stack components. RW> RW>The proposal is as follows: RW> RW>In order to begin to merge revised socket/pcb code, required to fix a number RW>of current races manifesting in the TCP code under load, and required for RW>breaking out the tcbinfo lock which is a significant bottleneck in high RW>performance TCP and multi-processor TCP scalability, I will disconnect netatm RW>and dependent components from the build on April 1, 2006. At that point, I RW>will merge updated socket and pcb reference counting. RW> RW>If a maintainer has not been found who can update and adequately test the RW>netatm code for the new socket/pcb interfaces by June 30, 2006, the netatm RW>code will be deleted from CVS HEAD (although remain available in Attic should RW>someone turn up later). I'm happy to provide some first cut patches for any RW>maintainer that arrives that do implement the changes, but I am unable to RW>test them, and suspect they will be significant deficient for this reason, so RW>will not commit them myself. RW> RW>This will leave us with at least two quite functional ATM implementations. RW>Please let me know if netatm is critical to your work and you will be able to RW>work with me to get netatm into shape. For someone already familiar with the RW>netatm implementation and set up to perform ATM network testing, this should RW>be straight forward and I'm happy to help in any way I can. If you are RW>available to act in this role, my recommendation would be that we meet at RW>BSDCan in Ottawa this May to discuss long term maintenance directions, and so RW>that we can work out a plan for handling SMP behavior for netatm, as well as RW>its integration with the socket code. I'm all for this removal. The only two reasons for carrying this around is that it supports CLIP over SVCs and that the driver for the IDT77211 chips is HARP-only. I have half of an ngatm driver for these chips and sent them out two at least two people during the last two years, but never heard back. I have also code for CLIP over SVCs but due to ENOTIME was not yet able to make this commit ready. If anybody knows somebody who could finish the driver it would be great. The CLIP stuff is not so critical - almost all people use PVCs only. harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060315091218.E56469>