Re: bce(4) - com_no_buffers (Again)

2010-09-24 Thread Tom Judge
On 09/23/2010 02:33 PM, Tom Judge wrote: > The throttle command I am using in the tests is the one from here: > > http://klicman.org/throttle/ > > > On 09/23/2010 02:26 PM, Tom Judge wrote: > >> On 09/23/2010 01:21 PM, David Christensen wrote: >> >> >> Under testing I have yet to see

Re: bce(4) - com_no_buffers (Again)

2010-09-23 Thread Tom Judge
On 09/23/2010 03:30 PM, David Christensen wrote: >>> 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?

RE: bce(4) - com_no_buffers (Again)

2010-09-23 Thread David Christensen
> > 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? > > > > > > The lockup is not from the NIC as s

Re: bce(4) - com_no_buffers (Again)

2010-09-23 Thread Tom Judge
The throttle command I am using in the tests is the one from here: http://klicman.org/throttle/ On 09/23/2010 02:26 PM, Tom Judge wrote: > On 09/23/2010 01:21 PM, David Christensen wrote: > > Under testing I have yet to see a memory fragmentation issue with > >

Re: bce(4) - com_no_buffers (Again)

2010-09-23 Thread Tom Judge
On 09/23/2010 01:39 PM, Pyun YongHyeon wrote: > On Thu, Sep 23, 2010 at 10:05:33AM -0500, Tom Judge wrote: > >> On 09/13/2010 03:53 PM, Pyun YongHyeon wrote: >> >>> On Mon, Sep 13, 2010 at 03:38:41PM -0500, Tom Judge wrote: >>> >>> On 09/13/2010 02:33 PM, Pyun YongHyeon wrote

Re: bce(4) - com_no_buffers (Again)

2010-09-23 Thread Tom Judge
On 09/23/2010 01:21 PM, David Christensen wrote: Under testing I have yet to see a memory fragmentation issue with >> this >> driver. I follow up if/when I find a problem with this again. >> So here we are again. The system is locking up again

Re: bce(4) - com_no_buffers (Again)

2010-09-23 Thread Pyun YongHyeon
On Thu, Sep 23, 2010 at 10:05:33AM -0500, Tom Judge wrote: > On 09/13/2010 03:53 PM, Pyun YongHyeon wrote: > > On Mon, Sep 13, 2010 at 03:38:41PM -0500, Tom Judge wrote: > > > >> On 09/13/2010 02:33 PM, Pyun YongHyeon wrote: > >> > >>> On Mon, Sep 13, 2010 at 02:07:58PM -0500, Tom Judge wro

RE: bce(4) - com_no_buffers (Again)

2010-09-23 Thread David Christensen
> >> Under testing I have yet to see a memory fragmentation issue with > this > >> driver. I follow up if/when I find a problem with this again. > >> > >> > So here we are again. The system is locking up again because of 9k > mbuf > allocation failures. Failure to allocate a new buffer should ca

Re: bce(4) - com_no_buffers (Again)

2010-09-23 Thread Tom Judge
On 09/13/2010 03:53 PM, Pyun YongHyeon wrote: > On Mon, Sep 13, 2010 at 03:38:41PM -0500, Tom Judge wrote: > >> On 09/13/2010 02:33 PM, Pyun YongHyeon wrote: >> >>> On Mon, Sep 13, 2010 at 02:07:58PM -0500, Tom Judge wrote: >>> >>> >> Without BCE_JUMBO_HDRSPLIT then we see no

RE: bce(4) - com_no_buffers (Again)

2010-09-13 Thread David Christensen
> I'm under the impression the header splitting in bce(4) is for > LRO(opposite of TSO), not for VM magic to enable page flipping > tricks. Header splitting was implemented in the Linux version of bce(4) to prevent jumbo memory allocations. Allocating 9KB frames was causing problems on systems us

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Pyun YongHyeon
On Mon, Sep 13, 2010 at 03:21:13PM -0700, David Christensen wrote: > > I'm under the impression the header splitting in bce(4) is for > > LRO(opposite of TSO), not for VM magic to enable page flipping > > tricks. > > Header splitting was implemented in the Linux version of bce(4) > to prevent jumb

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Pyun YongHyeon
On Mon, Sep 13, 2010 at 03:38:41PM -0500, Tom Judge wrote: > On 09/13/2010 02:33 PM, Pyun YongHyeon wrote: > > On Mon, Sep 13, 2010 at 02:07:58PM -0500, Tom Judge wrote: > > > >> On 09/13/2010 01:48 PM, Pyun YongHyeon wrote: > >> > >>> On Mon, Sep 13, 2010 at 10:04:25AM -0500, Tom Judge wro

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Tom Judge
On 09/13/2010 02:33 PM, Pyun YongHyeon wrote: > On Mon, Sep 13, 2010 at 02:07:58PM -0500, Tom Judge wrote: > >> On 09/13/2010 01:48 PM, Pyun YongHyeon wrote: >> >>> On Mon, Sep 13, 2010 at 10:04:25AM -0500, Tom Judge wrote: >>> >>> >> >> Does this mean tha

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Pyun YongHyeon
On Mon, Sep 13, 2010 at 09:11:25PM +0200, Andre Oppermann wrote: > On 13.09.2010 20:48, Pyun YongHyeon wrote: > >On Mon, Sep 13, 2010 at 10:04:25AM -0500, Tom Judge wrote: > >>Without BCE_JUMBO_HDRSPLIT then we see no errors. With it we see number > >>of errors, however the rate seems to be reduce

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Pyun YongHyeon
On Mon, Sep 13, 2010 at 02:07:58PM -0500, Tom Judge wrote: > On 09/13/2010 01:48 PM, Pyun YongHyeon wrote: > > On Mon, Sep 13, 2010 at 10:04:25AM -0500, Tom Judge wrote: > > > >> > > >> Does this mean that these cards are going to perform badly? This is was > >> what I gathered from the previou

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Tom Judge
On 09/13/2010 02:11 PM, Andre Oppermann wrote: > On 13.09.2010 20:48, Pyun YongHyeon wrote: >> On Mon, Sep 13, 2010 at 10:04:25AM -0500, Tom Judge wrote: >>> Without BCE_JUMBO_HDRSPLIT then we see no errors. With it we see >>> number >>> of errors, however the rate seems to be reduced compaired to

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Andre Oppermann
On 13.09.2010 20:48, Pyun YongHyeon wrote: On Mon, Sep 13, 2010 at 10:04:25AM -0500, Tom Judge wrote: Without BCE_JUMBO_HDRSPLIT then we see no errors. With it we see number of errors, however the rate seems to be reduced compaired to the previous version of the driver. It seems there are is

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Tom Judge
On 09/13/2010 01:48 PM, Pyun YongHyeon wrote: > On Mon, Sep 13, 2010 at 10:04:25AM -0500, Tom Judge wrote: > >> >> Does this mean that these cards are going to perform badly? This is was >> what I gathered from the previous thread. >> >> > I mean there are still many rooms to be done in dr

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Pyun YongHyeon
On Mon, Sep 13, 2010 at 10:04:25AM -0500, Tom Judge wrote: > On 09/09/2010 07:24 PM, Pyun YongHyeon wrote: > > On Thu, Sep 09, 2010 at 03:58:30PM -0500, Tom Judge wrote: > > > >> Hi, > >> I am just following up on the thread from March (I think) about this issue. > >> > >> We are seeing this iss

Re: bce(4) - com_no_buffers (Again)

2010-09-13 Thread Tom Judge
On 09/09/2010 07:24 PM, Pyun YongHyeon wrote: > On Thu, Sep 09, 2010 at 03:58:30PM -0500, Tom Judge wrote: > >> Hi, >> I am just following up on the thread from March (I think) about this issue. >> >> We are seeing this issue on a number of systems running 7.1. >> >> The systems in question are

Re: bce(4) - com_no_buffers (Again)

2010-09-09 Thread Pyun YongHyeon
On Thu, Sep 09, 2010 at 03:58:30PM -0500, Tom Judge wrote: > Hi, > > I am just following up on the thread from March (I think) about this issue. > > We are seeing this issue on a number of systems running 7.1. > > The systems in question are all Dell: > > * R710 R610 R410 > * PE2950 > > The l