Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Dec 2001 13:54:07 -0800
From:      Luigi Rizzo <rizzo@aciri.org>
To:        Jonathan Lemon <jlemon@flugsvamp.com>
Cc:        Julian Elischer <julian@elischer.org>, Bruce Evans <bde@zeta.org.au>, arch@FreeBSD.ORG
Subject:   Re: swi_net
Message-ID:  <20011218135407.B89299@iguana.aciri.org>
In-Reply-To: <20011218125816.N377@prism.flugsvamp.com>
References:  <20011218104750.M377@prism.flugsvamp.com> <Pine.BSF.4.21.0112181017000.36281-100000@InterJet.elischer.org> <20011218125816.N377@prism.flugsvamp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> One thing to note is that so far, I haven't seen any benefit of using
> a direct dispatch over the netisr approach; but then again, it may be
> that I'm simply not stressing my system enough.

Direct dispatch is typically useful under heavy load, because:

 * it reduces the chance of livelock when you have lots of traffic
   coming from an interface (which gets queued without giving the
   netisr a chance to run);

 * as a side effect, it also works as a form of interrupt mitigation,
   because you stay longer in the ISR and so you might serve more
   packets on a single interrupt.

As a drawback, if your packet processing time is longer than
the packet interarrival time (which is sometimes possible under
attack), you might remain in your ISR forever, literally.

Just as a side note, the polling code deals very well with the above
problems, and is not subject to the last one.

I have been against deferred processing for a long time, but recently
have slightly changed my mind because i now see a reason in it (mentioned in
the previous msg, re. expensive processing), as long as you can reserve
some amount of CPU to the deferred processing, and you make sure that
interfaces are served in a fair way (early versions of the polling code had
this problem, fetching large chunks of packets from the first interface
and filling up the intermediate queue. The version in current has not,
because ether_pollmore() among other things makes sure that interfaces
are served in a round-robin fashion and with short bursts of packets
before calling the netisr).

	cheers
	luigi
----------------------------------+-----------------------------------------
 Luigi RIZZO, luigi@iet.unipi.it  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
----------------------------------+-----------------------------------------

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011218135407.B89299>