]> CyberLeo.Net >> Repos - FreeBSD/stable/8.git/commit
MFC r227347,227367:
authoryongari <yongari@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Tue, 3 Jan 2012 21:17:59 +0000 (21:17 +0000)
committeryongari <yongari@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Tue, 3 Jan 2012 21:17:59 +0000 (21:17 +0000)
commit0478a4348634f80ed9a4aa7a6d66f7624df8aa00
treee5a519a7eb892925081ff2b219216e3b2034ceb7
parentb4be3351c20a62004cb2c6d99171867213949e36
MFC r227347,227367:
r227347:
  Retire 'options TI_PRIVATE_JUMBOS' and replace local jumbo
  allocator with UMA backed jumbo allocator by default. Previously
  ti(4) used sf_buf(9) interface for jumbo buffers but it was broken
  at this moment such that enabling jumbo frame caused instant panic.
  Due to the nature of sf_buf(9) it heavily relies on VM changes but
  it seems ti(4) was not received much blessing from VM gurus.  I
  don't understand VM magic and implications used in driver either.
  Switching to UMA backed jumbo allocator like other network drivers
  will make jumbo frame work on ti(4).
  While I'm here, fully allocate all RX buffers. This means ti(4) now
  uses 512 RX buffer and 1024 mini RX buffers.

  To use sf_buf(9) interface for jumbo buffers, introduce a new
  'options TI_SF_BUF_JUMBO'. If it is proven that sf_buf(9) is better
  for jumbo buffers, interesting developers can fix the issue in
  future.

  ti(4) still needs more bus_dma(9) cleanups and should use separate
  DMA tag/map for each ring(standard, jumbo, mini, command, event
  etc) but it should work on all platforms except PAE.

  Special thanks to Jay[1] who provided complete remote debugging
  access.

r227367:
  Comment out TI_JUMBO_HDRSPLIT. TI_JUMBO_HDRSPLIT requires TI_SF_BUF_JUMBO.

git-svn-id: svn://svn.freebsd.org/base/stable/8@229433 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/conf/NOTES
sys/conf/options
sys/dev/ti/if_ti.c
sys/dev/ti/if_tireg.h