Date: Wed, 14 Mar 2001 08:32:44 -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: <3AAF9D2C.2A337CC8@isi.edu> References: <200103141622.RAA19510@info.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Luigi Rizzo wrote: > > > 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 :-) > > i think i meant you want to buffer your overflowing packets in the > socket buffer, and use them as an extension of the ipq. Basically > once the interface queue is full, you create a list of socket buffers > waiting for a transmit, then when a slot in the ifqueue becomes empty > you fill it up with the next pkt from next the socket buffer > without having to wakeup the process associated with it unless > you pass the lowwater mark. This is more elaborate that what I was proposing. I was only thinking about queueing one UDP packet per socket when blocking, so there are no socket buffer queueing issues. I think queueing more than one could be more problematic for some applications, since it might decouple the write call returning from the actual send time of the packet too much. It'd be interesting to make the number of packets allowed to be queued in a UDP socket buffer a parameter, though... > But again, it is quite a bit of work to put all this code together, > and you end up with something that other systems do not have so > when you want to write portable code you still have to handle > the old behaviour as well in userland. Yes. But we're talking research here :-) (E.g. once UDP blocking is there, I can use it to do other neat things in the networking stack...) 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 010314163244Z0# *H 1 $"aF!5f 0R *H 1E0C0 *H 0*H 0+0 *H @0 *H (0 *H 2<u{3v >lw 2Хj&"E䠴䧷}x1PTK`j8:u ;CFઌ__;q}% 1s"ӎˎG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AAF9D2C.2A337CC8>