Date: Thu, 13 Feb 2014 13:38:22 -0500 (EST) From: wollman@bimajority.org To: scott4long@yahoo.com Cc: freebsd-net@freebsd.org Subject: Re: Use of contiguous physical memory in cxgbe driver Message-ID: <201402131838.s1DIcM8i047896@hergotha.csail.mit.edu> In-Reply-To: <5CAE71A4-EA1D-481D-AFBA-3738F8E66087@yahoo.com> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <CAJ-VmonCdNQPUCQwm0OhqQ3Kt_7x6-g-JwGVZQfzWTgrDYfmqw@mail.gmail.com> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> <21245.1163.754141.154430@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <5CAE71A4-EA1D-481D-AFBA-3738F8E66087@yahoo.com>, Scott Long writes: >So what you’re saying is that all of the other memory allocations that >go along with >moving data through a socket wind up fragmenting the free memory pool to >the point >where it becomes impossible to find 3 contig pages for a 9k jumbo RX frame. Yes. I don't think it's even all that difficult, because drivers that are of this type only ever allocate 9k clusters, and for outbound packets the kernel never allocates anyting bigger than a page. Since the NIC driver allocates a new mbuf immediately to replenish its rx ring, before the upper layers have had a chance to process the packet, it's not hard to see how even a moderately busy system will soon checkerboard all of physical memory. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402131838.s1DIcM8i047896>