Date: Wed, 15 Mar 2006 11:25:44 -0500 (EST) From: "Andrew R. Reiter" <arr@watson.org> To: Harti Brandt <harti@freebsd.org> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: netatm: plan for removal unless an active maintainer is found Message-ID: <20060315112537.S54629@fledge.watson.org> In-Reply-To: <20060315091218.E56469@beagle.kn.op.dlr.de> References: <20060315004530.B5861@fledge.watson.org> <20060315091218.E56469@beagle.kn.op.dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry to top post, but I worked on trying to mold the netatm code to the various more recently implemented APIs (UMA for example) awhile back and even then I was kinda thinking to myself "Im all for netgraph instead of netatm". So, I guess you see my stance on this :-). $0.02, Andrew On Wed, 15 Mar 2006, Harti Brandt wrote: :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 :_______________________________________________ :freebsd-arch@freebsd.org mailing list :http://lists.freebsd.org/mailman/listinfo/freebsd-arch :To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" : : -- arr@watson.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060315112537.S54629>