Date: Tue, 26 Mar 2002 09:09:17 -0800 From: Lars Eggert <larse@ISI.EDU> To: Matthew Luckie <mjl@nlanr.net> Cc: Luigi Rizzo <rizzo@icir.org>, freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS Message-ID: <3CA0AB3D.5000300@isi.edu> References: <Pine.BSF.4.21.0203260819020.91970-100000@mave.nlanr.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Matthew Luckie wrote: > hmm, we looked at how other protocols handled the ENOBUFS case from > ip_output. > > tcp_output calls tcp_quench on this error. > > while the interface may not be able to send any more packets than it > does currently, closing the congestion window back to 1 segment > seems a severe way to handle this error, knowing that the network > did not drop the packet due to congestion. Ideally, there might be > some form of blocking until such time as a mbuf comes available. > This sounds as if it will be much easier come FreeBSD 5.0 TCP will almost never encouter this scenario, since it's self-clocking. The NIC is very rarely the bottleneck resource for a given network connection. Have you looked at mean queue lengths for NICs? They are typically zero or one. The NIC will only be the bottleneck if you are sending at a higher rate than line speed and your burt time is too long to be absorbed by the queue. > I'm aware that if people are hitting this condition, they need to > increase the number of mbufs to get maximum performance. No. ENOBUFS in ip_output almost always means that your NIC queue is full, which isn't controlled through mbufs. You can make the queue longer, but that won't help if you're sending too fast. > This section of code has previously been discussed here: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=119188+0+archive/2000/fr- > eebsd-net/20000730.freebsd-net and has been in use for many years (a This is a slightly different problem than you describe. What Archie saw was an ENOBUFS being handled like a loss inside the network, even though the sender has information locally that can allow it to make smarter retransmission decisions. 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 00 G0 *H 01 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.300 010824164000Z 020824164000Z0T10 UEggert1 0 U*Lars10U Lars Eggert1 0 *H larse@isi.edu00 *H 0 |\Pw v~~ FDooӦA\- Cˀ4.)&{肋 ,z (ܷر߈T7_'txGH^tt/ҹB8%t<#ֲN V0T0*+e!0 00L2uMyffBNUbNJJcdZ2s0U 0 larse@isi.edu0 U 0 0 *H aJPMՒ ]cѭC+kS+wZ1gY",YT41 j 6:~℩ D~Kؚl=u(ՎM?cF7@}T00 G0 *H 01 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.300 010824164000Z 020824164000Z0T10 UEggert1 0 U*Lars10U Lars Eggert1 0 *H larse@isi.edu00 *H 0 |\Pw v~~ FDooӦA\- Cˀ4.)&{肋 ,z (ܷر߈T7_'txGH^tt/ҹB8%t<#ֲN V0T0*+e!0 00L2uMyffBNUbNJJcdZ2s0U 0 larse@isi.edu0 U 0 0 *H aJPMՒ ]cѭC+kS+wZ1gY",YT41 j 6:~℩ D~Kؚl=u(ՎM?cF7@}T0)0 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 000830000000Z 020829235959Z01 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.3000 *H 0 32c %E>nx'gڈD)c5*mp<ܮto034qmOe KaU5u'rװ |CBPQ<9TIf - ki N0L0)U "0 0 10UPrivateLabel1-2970U 0 0 U 0 *H so&e4KYbDI j&*b ct mSK8P:l4撜n# KrgPo.X PW Ո9[9}4%MjÑ/<RbH10001 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.30G0 + a0 *H 1 *H 0 *H 1 020326170917Z0# *H 1 1fN O0R *H 1E0C0 *H 0*H 0 *H @0+0 *H (0 *H 101 0 UZA10U Western Cape10U Cape Town10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 2000.8.30G0 *H hyS=R@ ~(G!AKahdзf?[5`aOh5p>( :+%(Q RJdX {Q7ӂ<fxrPhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CA0AB3D.5000300>