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. _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
