Subject: Re: protocol drain routines: adding a "how despirate are we" parameter?
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-net
Date: 05/16/1999 22:32:55
In some email I received from Bill Sommerfeld, sie wrote:
> A friend of mine had problems with a NetBSD 1.4BETA system running out
> of mbufs and locking up due to a broken application which was using
> raw ip sockets.. it created ~20 ICMP sockets, sent out a few pings,
> and then, under certain circumstances, wouldn't read from them
> promptly due to a bug... and lots of traffic would pile up in these
> sockets and the system would run out of mbuf clusters and be sad.
> (this is the same system which convinced me that arp_drain is
> needed..)
> 
> So, the "obvious" fix here is to add protocol drain routines to the
> udp and raw protocol families to rip unread mbufs out of the socket
> queues under conditions of memory shortage.  (since the protocols are
> unreliable, i think you can get away with this..).  
> 
> However, this *is* fairly brutal; i'd think that it's something you'd
> want to put in as a last resort.. so it might make sense to add some
> sort of "despiration level" parameter to the drain routine, and change
> m_reclaim to look more like:
> 
> 	  for (despiration = 0; despiration < max; despiration++) {
> 	      for each protocol
> 		  if (pr->pr_drain) (*pr->pr_drain)(despiration);
> 	      for each interface
> 		  if (ifp->if_drain) (*ifp->if_drain)(ifp, despiration);
>               if (there are free mbufs & free clusters)
> 		  break;
> 	  }
> 
> ... and then have {tcp,udp,rip}_drain kick in with despiration=1.
> 
> I'm not convinced this is necessary. but i'm not convinced it isn't
> either.  Anyone have any opinions?

How about using high/low watermarks for "despiration" ?  These variables
would be sysctl'able, of course.

IMHO, the draining routines should also take into account how long a
packet has been waiting in the queue - that is, expire the oldest first,
in an FIFO type schedule.

Darren