netatm: plan for removal unless an active maintainer is found (fwd)

[Robert Watson]

FYI: An e-mail thread relating to the following is taking place on the arch@ 
mailing list.  Please follow up to that list with any comments/discussion.

Robert N M Watson

---------- Forwarded message ----------
Date: Wed, 15 Mar 2006 01:00:57 +0000 (GMT)
From: Robert Watson <rwatson at FreeBSD.org>
To: arch at FreeBSD.org
Subject: netatm: plan for removal unless an active maintainer is found


For some time now, the FreeBSD Project has been carrying around at least three 
ATM stacks:

- netatm - HARP, the Host ATM Research Platform

- netnatm - A fairly minimal socket<->virtual circuit ATM wrapper for ATM
   device drivers

- ngatm - NetGraph ATM framework

For a variety of reasons, it would be desirable to do a bit of pruning of ATM 
stacks.  In my previous conversations with Harti and Bruce, the conclusion has 
generally been that ngatm and netnatm provide almost all functionality provided 
by netatm and more, but in modern, and actively maintained, frameworks.

The main motivator for pruning has to do with the SMP network stack work: we're 
reaching the point, discussed on a number of occasions previously on this 
mailing list, where jettisoning unmaintained network stack components that are 
unable to run MPSAFE, is highly desirable.  This would allow us to remove 
compatibility shims that are increasingly burdonsome in terms of performance 
and complexity.  Another aspect of this has to do with upcoming changes to the 
socket and pcb code, which will require maintainers of protocols to do a small 
but non-trivial amount of work to update protocols to fit the new socket 
behavior.  Right now, almost all other sections of the network stack have 
active maintainers who are able to do this work, both development and testing, 
except for the netatm code.

We've reached the point where continuing to carry around a third ATM stack is a 
significant impediment to continued work on network stack performance and 
reliability work.  This should not be a surprise to anyone who reads this 
mailing list regularly, since I sent out e-mail on this very topic on July 18, 
2005, warning that netatm (and several other components) were at risk as 
unmaintained but substantial network stack components.

The proposal is as follows:

In order to begin to merge revised socket/pcb code, required to fix a number of 
current races manifesting in the TCP code under load, and required for breaking 
out the tcbinfo lock which is a significant bottleneck in high performance TCP 
and multi-processor TCP scalability, I will disconnect netatm and dependent 
components from the build on April 1, 2006.  At that point, I will merge 
updated socket and pcb reference counting.

If a maintainer has not been found who can update and adequately test the 
netatm code for the new socket/pcb interfaces by June 30, 2006, the netatm code 
will be deleted from CVS HEAD (although remain available in Attic should 
someone turn up later).  I'm happy to provide some first cut patches for any 
maintainer that arrives that do implement the changes, but I am unable to test 
them, and suspect they will be significant deficient for this reason, so will 
not commit them myself.

This will leave us with at least two quite functional ATM implementations. 
Please let me know if netatm is critical to your work and you will be able to 
work with me to get netatm into shape.  For someone already familiar with the 
netatm implementation and set up to perform ATM network testing, this should be 
straight forward and I'm happy to help in any way I can.  If you are available 
to act in this role, my recommendation would be that we meet at BSDCan in 
Ottawa this May to discuss long term maintenance directions, and so that we can 
work out a plan for handling SMP behavior for netatm, as well as its 
integration with the socket code.

Robert N M Watson
_______________________________________________
freebsd-arch at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"