Date: Wed, 29 Mar 2006 11:13:34 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Harti Brandt <harti@freebsd.org> Cc: arch@FreeBSD.org Subject: Re: netatm: plan for removal unless an active maintainer is found Message-ID: <20060329110421.M19236@fledge.watson.org> In-Reply-To: <20060329123238.B87509@beagle.kn.op.dlr.de> References: <20060315004530.B5861@fledge.watson.org> <20060329100513.D19236@fledge.watson.org> <20060329123238.B87509@beagle.kn.op.dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Mar 2006, Harti Brandt wrote:
> On Wed, 29 Mar 2006, Robert Watson wrote:
>
> RW>On Wed, 15 Mar 2006, Robert Watson wrote:
> RW>
> RW>> In order to begin to merge revised socket/pcb code, required to fix a
> RW>> number of current races manifesting in the TCP code under load, and
> RW>> required for breaking out the tcbinfo lock which is a significant
> RW>> bottleneck in high performance TCP and multi-processor TCP scalability, I
> RW>> will disconnect netatm and dependent components from the build on April 1,
> RW>> 2006. At that point, I will merge updated socket and pcb reference
> RW>> counting.
> RW>
> RW>Reminder: April 1 approaches.
> RW>
> RW>I've merged changes to many non-netinet protocols in support of the
> RW>approaching socket/pcb reference model changes, but have the netinet changes
> RW>depend on completing socket layer changes that are believed not to work with
> RW>netatm as they stand. I'll be posting the socket and netinet changes to
> RW>arch@ today; I've posted them previously to other lists, such as current@.
>
> Skip Ford expressed interest in netatm, but he said also that he would
> continue to work on HARP even when it is removed. So I guess it could be
> revived in the future (just in the case). I've also sent him my half -IDT
> driver and he said he will first work on this. When this is ready we have
> all the hardware supported in ngATM which HARP also does.
I have patches, and plan to commit them, that keep netatm compilable. The
problem is that I am unable to test netatm, and have limited time to try to
figure it out (and it's significant enough that it requires figuring out).
There are really two sticking points with it remaining in the tree right now:
(1) It's not MPSAFE, and in absence of a maintainer is unlikely to become so.
This means it is a direct obstacle to removing the non-MPSAFEty crutches
in the network stack, which we're otherwise increasingly done with. The
other components with similar problems will be facing similar eviction
notices if they don't have maintainers.
(2) Continuing work to improve SMP performance requires significant changes to
the socket code (and other parts of the stack). Each change in itself is
relatively minor, but requires non-trivial protocol adaptation and
testing. In absense of a maintainer for netatm, this work will either
break netatm, or be unable to proceed.
I can keep hacking on netatm to keep it compiling, but I can't promise the
result will work, and given the complexity of the socket and protocol code,
it's highly likely that it won't work. Rather than break it further and
further, I'd rather either find a maintainer, or mark it as deprecated and on
the removal path. The April 1 date is simply the date where the fact that I
cannot test netatm no longer becomes a blocking factor for my committing
changes that may break it, since otherwise these changes, and the changes
dependent on them, won't have time to settle out before we reach 7.0,
effectively stalling all further work along these lines, which is undesirable
:-).
The April 1 date is also only for disabling the compile and marking it as
being on the removal path. The plan is not to remove it until late in the
summer, and only then if it hasn't been fixed to work in the new world order
or and shows no signs of moving in that direction. If there is significant
progress, plans are easy to change.
So all that aside, I continue to plan to commit my changes on April 1, but
welcome any work to keep netatm working. It sounds like bluetooth may also
briefly break; I've exchanged e-mail with emax and he has plans to fix it
shortly thereafter.
Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060329110421.M19236>