svn commit: r263957 - in head/sys: dev/age dev/alc dev/ale dev/bce dev/bge dev/fxp dev/jme dev/msk dev/nfe dev/sge pci

[Yonghyeon PYUN]

On Mon, Mar 31, 2014 at 01:25:35PM +0900, Yonghyeon PYUN wrote:
> On Sun, Mar 30, 2014 at 09:00:59PM -0700, John-Mark Gurney wrote:
> > Pyun YongHyeon wrote this message on Mon, Mar 31, 2014 at 01:54 +0000:
> > > Author: yongari
> > > Date: Mon Mar 31 01:54:59 2014
> > > New Revision: 263957
> > > URL: http://svnweb.freebsd.org/changeset/base/263957
> > > 
> > > Log:
> > >   Increase the number of TX DMA segments from 32 to 35.  It turned
> > >   out 32 is not enough to support a full sized TSO packet.
> > >   While I'm here fix a long standing bug introduced in r169632 in
> > >   bce(4) where it didn't include L2 header length of TSO packet in
> > >   the maximum DMA segment size calculation.
> > 
> > I assume all of the hardware supports this increase?
> > 
> 
> Yes.  Data sheet does not mention about such limitation.  txp(4)
> has a limitation on the number of TX segments but I didn't
> implement TSO in txp(4).
> 
> > Also, is there a reason to only increase up to 35 and not something
> > larger, like 64?  Is there a memory or performance penalty?
> > 
> 
> If 64 does not overflow kernel stack we can also bump the number to
> 64.

Hmm, I think I didn't answer on performance penalty. If hardware
allows only a single outstanding DMA read operation, having
multiple TX buffers would result in lower performance.  However
it's common to have multiple TX buffers in TSO so I don't think it
could change performance number in TSO path.  And I think most high
end server NICs support multiple outstanding DMA read operation.