netisr

[Giovanni P. Tirloni]

* Terry Lambert (tlambert2 at mindspring.com) wrote:

> No.  NETISR is a software interrupt that runs when software
> interrupts run, which is to say, when the SPL is lowered as
> a result of returning from the last nested hardware interrupt,
> which means on hardware and clock interrupts.

 Yes, I missed the page in 4.4BSD D&I.

> No.  There are two LRP papers from Rice University.  The first
> was against FreeBSD 3.2, and dealt with just the idea of LRP.
> The scond makes things much more complicated than they need to
> be, in order to introduce a concept called "ResCon", or resource
> containers.  Neither set of code is really production, because
> it uses an alternate protocol family definition and a seperately
> hacked uipc_socket.c and uipc_socket2.c, along with the totally
> parallel TCP/IP stack.

 I've read their first paper.

> The closest you can come to LRP in FreeBSD 5.x is to use the
> sysctl's for "direct dispatch", which will, in fact, directly
> call ip_input() from interrupt.

 I'll be experimenting with it this week (like rwatson requested).

> This isn't a full LRP, since it doesn't add a receive buffer
> into the proc structure for per-process enqueuing of packets.
> 
> When I implemented the 3.x version of Rice's LRP in FreeBSD 4.3,
> I avoided this hack.  The main reason for the hack was to deal
> with accepting connections, since at interrupt, without a proc
> structure, there was no way to deal with the socket creation for
> the accept, due to a lack of an appropriate credential.  The
> sneaky approach I used for this was to create the accept socket
> using the cred that was present on the listen socket on which
> the connection had come in.  For this to be at all useful, you
> need to extend kevent accept filters to allow creation of accepted
> descriptor instances in the process context, and throw them onto
> the kqueue that was set up against the listen socket.
> 
> I recommend that if you want to play with LRP, you add an attribute
> flag to the protocol stack structure to indicate an LRP capable vs.
> an LRP incapable stack, and then implement it inline, rather than
> as a separate thing.  I also recommend that if you do this, you do
> it using the Rice 3.x code, and ignore the "ResCon" stuff, which I
> think is an interesting idea, but which adds very little in the way
> of real value to things (though it does add overhead).

 I'll have to research more about it but I'm taking notes about all
 this.
  
> If you are asking about NETISR, then I recommend W. Richard Steven's
> books, specifically "TCP/IP Illustrated, Volume 2: The Implementation".

 Yes. I found the page about it 5 minutes after I sent this email. Shame
 on me..

> FWIW: Interrupt threads, as they are used in 5.x, are pretty much
> antithetical to an LRP implementation, since you can still end up
> live-locked under heavy load (or denial of service attack), which
> is why you wanted LRP in the first place: to make progress under a
> load heavier than you could possibly respond to in a reasonable
> time.  The problem is that the requeing to the interrupt thread adds
> back in the same type of transition boundary you were trying to take
> out by getting rid of NETISR in the first place.

 Thank you very much for answering my question.  Things are much clear 
 now!

 --
 Giovanni P. Tirloni <gpt at tirloni.org>
 Fingerprint: 8C3F BEC5 79BD 3E9B EDB8  72F4 16E8 BA5E D031 5C26