Coordinating TCP projects
rwatson at FreeBSD.org
Wed Dec 19 05:24:52 PST 2007
It is rapidly becoming clear that quite a few of us have Big Plans for the TCP
implementation over the next 12-18 months. It's important that we get the
plans out on the table now so that everyone working on these projects is aware
of the larger context. This will encourage collaboration, but also allow us
to manage the risks inevitably associated with having several simultaneous
projects going on in a very complex software base. With that in mind, here
are the large projects I'm currently aware of:
Project Flag Wavers Status
------- ----------- ------
TCP offload Kip Macy Moving to CVS and under
review and testing; one
supporting device driver.
TCP congestion control Sam Leffler, At least one prototype
Rui Paulo, implementation, to move to p4
TCP overhaul Andre Oppermann Glimmer in eye, to move to
TCP lock granularity/ Robert Watson Glimmer in eye, to occur in
increased parallelism p4.
TCP timer unification Andre Oppermann, Previously committed, and to
Mike Silbersack be reintroduced via p4.
Monitoring ABI cleanup Robert Watson Glimmer in eye, to occur in
Looking at the above, it sounds like a massive amount of work taking place, so
we will need to coordinate carefully. I'd like to encourage people to avoid
creating unnecessary dependencies between changes, and to be especially
careful in coordinating potentially MFCable changes. There are (at least) two
conflicting scheduling desires in play here:
- A desire to merge MFCable changes early, so that they aren't entangled with
un-mergeable changes. This will simplify merging and also maximize the
extent to which testing in HEAD will apply to them once merged to RELENG_7.
- A desire to merge large-scale infrastructural changes early so that they see
the greatest exposure, and so that they can be introduced incrementally over
a longer period of time to shake each out.
Both of these are valid perspectives, and will need to be balanced. I have a
few questions, then, for people involved in these or other projects:
(0) Is your project in the above list? If not, could you send out a reply
talking a bit about the project, who's involved, where it's taking place,
(1) What is your availability to shepherd the project through its entire
cycle, including early prototyping, design review, development,
implementation review, testing, and the inevitable long debugging tail
that all TCP projects have.
(2) When do you think your implementation will reach a prototype phase
appropriate for an expanded circle of reviewers? When do you think it
might be ready for commit? Keep in mind that we're now a month or so into
the 18-month cycle for 8.0, and that all serious TCP work should be
completed at least six months before the end of the cycle.
(3) What potential interactions of note exist between your project and the
others being planned. Are there explicit dependencies?
(4) Do you anticipate an MFC cycle for your work to RELENG_7?
I'd like for us to create a wiki page tracking these various projects, and
pointing at per-project resources. Once the discussion has settled a bit, I
can take responsibility for creating such a page, but will need everyone
involved to help maintain it, as well as to maintain pages (on the wiki or
elsewhere) regarding the status of the projects. I think it also makes a lot
of sense for participants in the projects to send occasional updates and
reports to net@/arch@ in order to keep people who can't track things
day-to-date in the loop, and to invite review.
At the end of the day, we must be clear: the only way even a fraction of these
projects can happen in time for 8.0 is if there is careful planning,
coordination, and exception care taken in the review and testing of the
changes. We cannot have the 8.0 release cycle put at risk the way the 7.0
cycle was due to inadequately reviwed and tested patches entering the tree
under the assumption that problems would somehow be magically found and fixed
before the release by the relatively small population of -CURRENT users.
Experience tells us that changes must be extensively reviewed and tested
before they enter the tree.
I'm really looking forward to the 8 development cycle, and the work that's in
the pipeline is really very exciting. It will take quite a bit of dedication
to make it all happen, but if even only a small part of it happens, it will
still be very good news.
Robert N M Watson
University of Cambridge
More information about the freebsd-net