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
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
>
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
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
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
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
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
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
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
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
* 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
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
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
13 matches
Mail list logo