Date: Thu, 27 Feb 2014 18:16:21 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Ryan Stone <rysto32@gmail.com> Cc: Johan Kooijman <mail@johankooijman.com>, freebsd-net <freebsd-net@freebsd.org>, Jack Vogel <jfvogel@gmail.com>, John Baldwin <jhb@freebsd.org> Subject: Re: Network loss Message-ID: <917817504.14529709.1393542981376.JavaMail.root@uoguelph.ca> In-Reply-To: <CAFMmRNzTBDD=qhoUPmEkWfuHr-rzFFRi847mXuh4jHmMXUKtug@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ryan Stone wrote: > On Wed, Feb 26, 2014 at 8:00 PM, Rick Macklem <rmacklem@uoguelph.ca> > wrote: > > And please email if you try it and let us know if it helps. > > > > I've think I've figured out how 64K NFS read replies can do this, > > but I'll admit "ping" is a mystery? (Doesn't it just send a single > > packet that would be in a single mbuf?) > > ixgbe currently returns an error from its if_transmit function if it > gets an error sending *any* packet that is queued for transmit. So > if > there is a 64K NFS request queued then ping could see an EFBIG error. > I can't explain the packet loss, unless ping is counting errors from > send() as lost packets (which would be completely reasonable). Yep, I just noticed that when I took another glance at the driver. (Things still look a bit weird, since if m_defrag() returns NULL, the second attempt fails with ENOBUFS in ixgbe_xmit(). It seems that m_defrag() returns a new mbuf list, but it is still > 32 mbufs in length?) rick > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?917817504.14529709.1393542981376.JavaMail.root>