DragonFly kernel List (threaded) for 2008-06
tcpcb (was Re: sockbuf (was Re: BGL-free net stack))
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
> > 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:
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,
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.