netatm: plan for removal unless an active maintainer is found

Andrew R. Reiter arr at
Wed Mar 15 16:24:53 UTC 2006

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  

So, I guess you see my stance on this :-).


On Wed, 15 Mar 2006, Harti Brandt wrote:

:On Wed, 15 Mar 2006, Robert Watson wrote:
:RW>For some time now, the FreeBSD Project has been carrying around at least
:RW>three ATM stacks:
:RW>- netatm - HARP, the Host ATM Research Platform
:RW>- netnatm - A fairly minimal socket<->virtual circuit ATM wrapper for ATM
:RW>  device drivers
:RW>- ngatm - NetGraph ATM framework
: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>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>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>The proposal is as follows:
: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>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>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.
:freebsd-arch at mailing list
:To unsubscribe, send any mail to "freebsd-arch-unsubscribe at"

arr at

More information about the freebsd-arch mailing list