tcpcb (was Re: sockbuf (was Re: BGL-free net stack))

[Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>]

On Monday 05 May 2008, Aggelos Economopoulos wrote:
> On Wednesday 16 April 2008, Aggelos Economopoulos wrote:
> > Hello all,
> > 
> > for my diploma thesis, I've arranged to work on getting the DragonFlyBSD
> > network stack[*] to run without the BGL. Now, it would be great if the
> > code changes would become part of the project. So, my plan is to study
> > the net code over easter vacation (it's been a long while since I last 
> looked 
> > at it and I've never been a network guy in any case) and then post a 
> > preliminary roadmap on kernel@. At that point, everyone can give an opinion 
> > before any code gets written.
> 
> On second thought, let me ask for input sooner rather than later.

[this email was supposed to be much more organized, but this will have to do]

OK, same thing, but now it's the pcbs. TCP is "easy". The inpcb is inserted on
a per-cpu hash table so that the corresponding protocol thread runs on the
same cpu. Some tcpcb fields however, are accessed directly from user-thread
context. The interesting fields are:

t_flags:
	need to do early copyin / delayed copyout in so_pr_ctloutput

snd_una, snd_recover, snd_next, t_rxtcur, t_maxopd, t_rtttime, t_rtseq,
t_softerror:

Those fields are touched by tcp_mtudisc() or tcp_notify(). AFAICT, these two
are only reached along the path transport_processing_oncpu->icmp_input->
tcp_ctlinput [resume writing email 10 days later, hopefully my notes are
complete] which shouldn't be a problem.

snd_cwnd, snd_wacked, t_rxtcur:
Are touched by tcp_quench() which again is called only by tcp_ctlinput().

In other news, the new sockbuf code is operational and after I squash an nfs
bug and simplify it a bit I'm going to ask for testers. I expected it to be at
this stage at least a couple of weeks ago but life and a few silly bugs
intervened. My plan is to start a discussion on the more interesting in_pcb
situation on kernel@ this weekend.

Aggelos