Polling vs Interrupts (was Re: NEW CODE: polling support...)

2001-10-27 Thread Luigi Rizzo
As the topic came out, i thought it would be useful to pass around a short discussion on the performance implications of interrupts and polling. In addition to the code that i already posted and which implements polling as discussed in Sec.4 below, I have another set of patches to implement devic

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Luigi Rizzo
And a few more comments on the technical side: On Sat, Oct 27, 2001 at 11:55:56AM -0700, Terry Lambert wrote: ... > PPS: The polling support for device drivers was something I > had discussed with Bill Paul previously. He did not like > the idea of externalizing the entry points for the tx_eof >

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Luigi Rizzo
On Sat, Oct 27, 2001 at 11:55:56AM -0700, Terry Lambert wrote: ... only one small note: you are probably confusing me with someone else here, all i had from you was (early this september) a short snippet of code for some device driver after you or somene else mentioned it on the lists. > PS: Luig

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Terry Lambert
Luigi Rizzo wrote: > > On Sat, Oct 27, 2001 at 04:52:54AM -0500, Mike Silbersack wrote: > ... > > Summary: The patch Terry posted was to loop a few more times in the > > interrupt handler. I was going to commit it this weekend for the dc > > driver, but it looks like Luigi's work overshadows th

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Terry Lambert
Mike Silbersack wrote: > > > Is it possible to implement all the basic packet forwarding to run to > > > completion at interrupt, ie, when a packet comes in, the interrupt code > > > would run until the packet has been sent out on another interface, and > > > then loop back to see if there's more

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Luigi Rizzo
On Sat, Oct 27, 2001 at 04:52:54AM -0500, Mike Silbersack wrote: ... > Summary: The patch Terry posted was to loop a few more times in the > interrupt handler. I was going to commit it this weekend for the dc > driver, but it looks like Luigi's work overshadows that. Terry was kind enough to se

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Luigi Rizzo
On Sat, Oct 27, 2001 at 01:43:44AM -0700, Soren Kristensen wrote: > Luigi and all, > > That looks very interesting to me I would like to follow up with a > question, just because of my interest in getting maximum packet > forwarding performance out of FreeBSD > > As I see it, the advanta

Reply Hazy (Encrypted VPN across FBSD, W2k, RHL, etc...)

2001-10-27 Thread Gary Jackson
I'm looking for the best way to get an encrypted VPN set up that's compatible with FreeBSD (on the permanent end), and clients running Win 2k and RedHat Linux. I'd like to do this without having to buy software from someone. I have a suspicion that the limiting factor here is going to be the Mi

kern/11238, kern/14848, kern/21771, sppp patch's patch_id #1

2001-10-27 Thread Roman Kurakin
Hi, This is the first patch of set of patches that I plan to make. These patches ware send several times as a big patch and last one wasn't even discussed. So I will try to send them by small pieces and will try to comment them. Last one big patch was kern/21771. Last our version of

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Mike Silbersack
On Sat, 27 Oct 2001, Alfred Perlstein wrote: > > Is it possible to implement all the basic packet forwarding to run to > > completion at interrupt, ie, when a packet comes in, the interrupt code > > would run until the packet has been sent out on another interface, and > > then loop back to see

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Alfred Perlstein
* Soren Kristensen <[EMAIL PROTECTED]> [011027 03:43] wrote: > Luigi and all, > > That looks very interesting to me I would like to follow up with a > question, just because of my interest in getting maximum packet > forwarding performance out of FreeBSD > > As I see it, the advantage of

Re: NEW CODE: polling support for device drivers.

2001-10-27 Thread Soren Kristensen
Luigi and all, That looks very interesting to me I would like to follow up with a question, just because of my interest in getting maximum packet forwarding performance out of FreeBSD As I see it, the advantage of the polling code is to avoid interrupts and context switches. Is it possi

NEW CODE: polling support for device drivers.

2001-10-27 Thread Luigi Rizzo
Maybe this can be of some interest to some of you using BSD boxes as routers, and who are concerned with performance and robustness to attacks. I would be grateful if some of you could have a look at this and possibly provide feedback. The patches attached here (for 4.4, i386 non-SMP) implement p