Date: Thu, 23 Sep 2010 13:30:42 -0700 From: "David Christensen" <davidch@broadcom.com> To: "Tom Judge" <tom@tomjudge.com> Cc: "pyunyh@gmail.com" <pyunyh@gmail.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "yongari@freebsd.org" <yongari@freebsd.org> Subject: RE: bce(4) - com_no_buffers (Again) Message-ID: <5D267A3F22FD854F8F48B3D2B52381933B5A78B544@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: <4C9BA9FD.50406@tomjudge.com> References: <4C894A76.5040200@tomjudge.com> <20100910002439.GO7203@michelle.cdnetworks.com> <4C8E3D79.6090102@tomjudge.com> <20100913184833.GF1229@michelle.cdnetworks.com> <4C8E768E.7000003@tomjudge.com> <20100913193322.GG1229@michelle.cdnetworks.com> <4C8E8BD1.5090007@tomjudge.com> <20100913205348.GJ1229@michelle.cdnetworks.com> <4C9B6CBD.2030408@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933B5A78B484@IRVEXCHCCR01.corp.ad.broadcom.com> <4C9BA9FD.50406@tomjudge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Failure to allocate a new buffer should cause the driver to > > drop the received frame and reuse the buffer, not lock up the > > system. Are you seeing the lockup come from bce(4) or does > > it come from somewhere else due to the dropped data? > > > > >=20 > The lockup is not from the NIC as such, the systems have the appearance > of locking up as home directories are on NFS and the user information > is > stored in a remote LDAP server. When the system starts to drop frames > due to lack of 9k memory regions it tends to last for a few minutes > (when it is really bad) and stop all traffic into the system. This > appears to the average user as a complete system pause. >=20 Ack. > > I am under the impression that the best solution is to tune the RX ring > so that flow control can be disabled but I not sure I could do this. >=20 Are small frames common in the actual failing case or are they=20 restricted to your test case? At least one of the Broadcom Linux drivers addresses this issue by copying frames < 128 bytes to a standard size buffer, saving the jumbo buffer allocation=20 and DMA mapping operation. If small frames are at the root of=20 your problem then I think this would be a better solution than=20 allocating more 9KB blocks by increasing the ring size.=20 Dave
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5D267A3F22FD854F8F48B3D2B52381933B5A78B544>