Date: Wed, 14 Mar 2001 08:06:35 -0800 From: Lars Eggert <larse@ISI.EDU> To: Luigi Rizzo <luigi@info.iet.unipi.it> Cc: net@FreeBSD.ORG Subject: Re: Changing UDP select() behavior Message-ID: <3AAF970B.7A19438A@isi.edu> References: <200103140639.HAA14416@info.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Luigi Rizzo wrote: > > > Hi, > > > > I'm wondering if anyone has ever considered modifying the UDP behavior with > > regard to selecting: > > > > Currently, writing to a UDP socket either enqueues packets in the interface > > queue (returning success), or drops them on the floor (returning ENOBUFS) > > if the queue is full. Selecting-to-write on a UDP socket always succeeds, > > never blocks. > > I think it would require some substantial change to the network > stack structure (basically to let your sockets sleep on an interface, > and being woken up when the queue drains). Exactly. > There are fairness and efficiency issues here, because the device > queue has so many "users" that the usual low-water/high-water > strategy might cause a blocked socket to starve forever, so you > might need to effectively block queueing if there are sockets > sleeping on a queue, maybe issue a wakeup() on every single > transmission when you have sockets waiting, and probably implement > some ordering (maybe as simple as FIFO) for the waiting sockets. I agree that these are definitly issues. However, I think UDP blocking may actually improve some of the fairness issues. Right now, if a process loops doing UDP writes without any application-level sleeping scheme on failed writes, your system becomes really loaded. UDP blocking would improve fairness in some sense by letting other processes run while the queue drains. As for efficiency, I agree that the per-packet send overhead will be larger. I'm not sure it'll be large enough to become a problem, though. > All in all I think this approach would only help a bit if > if you were allowed to queue in the socket buffer > (on which you can think of having some control, because you either > opened the fd yourself or you inherited it from some parent), > in addition to the device queue. Could you explain this a little more? I think I know where you're going with this, but I'm not sure :-) Thanks, Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California [-- Attachment #2 --] 0# *H 01 0 + 0 *H 00A#0 *H 01 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.160 000824203008Z 010824203008Z0T10 UEggert1 0 U*Lars10U Lars Eggert1 0 *H larse@isi.edu00 *H 0 \p9 H;v r∩6"C?mxfJ f7I[3CF́L I - zHRVA怤2]0-bL)%X>nӅ w0u0*+e!0 00L2uMyffBNUbNJJcdZ2s0U 0 larse@isi.edu0 U 0 0 U #0`fUXF a#Ì0 *H _3 F=%nWY-HXD9UOc6ܰw f@uܶNԄR?Pr} E1֮23 mFhySwM_h|d yR= $P 00} 0 *H 01 0 UZA10U Western Cape10U Cape Town10U Thawte Consulting1(0&U Certification Services Division1$0"UThawte Personal Freemail CA1+0) *H personal-freemail@thawte.com0 990916140140Z 010915140140Z01 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.1600 *H 0 iZ z]!#rLK~r$BRW{azr98e^eyvL>hpu t ,O 1ArƦ]D.Mօ>lx~@эWs0FO 7050U 0 0 U #0rIs4U vr~wƲ0 *H kY1rr`HU{gapm¥7؝(V\uoƑlfq|ko!6- -mƃRt\~ orzg,ks n Νc) ~U10001 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.16#0 + 0 *H 1 *H 0 *H 1 010314160635Z0# *H 13<~HHHEQբ0R *H 1E0C0 *H 0*H 0+0 *H @0 *H (0 *H tnh,EQh^@nfGu <vV/K?;/JEKh&9&$)9- 5žƙ?Hf"" d <a+]92DoNS2*|NQq:H/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AAF970B.7A19438A>