1. 23 9月, 2010 1 次提交
  2. 22 9月, 2010 5 次提交
  3. 14 9月, 2010 1 次提交
  4. 11 9月, 2010 10 次提交
  5. 03 9月, 2010 1 次提交
  6. 09 7月, 2010 1 次提交
  7. 08 7月, 2010 1 次提交
    • E
      net: fix 64 bit counters on 32 bit arches · 28172739
      Eric Dumazet 提交于
      There is a small possibility that a reader gets incorrect values on 32
      bit arches. SNMP applications could catch incorrect counters when a
      32bit high part is changed by another stats consumer/provider.
      
      One way to solve this is to add a rtnl_link_stats64 param to all
      ndo_get_stats64() methods, and also add such a parameter to
      dev_get_stats().
      
      Rule is that we are not allowed to use dev->stats64 as a temporary
      storage for 64bit stats, but a caller provided area (usually on stack)
      
      Old drivers (only providing get_stats() method) need no changes.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28172739
  8. 01 7月, 2010 2 次提交
  9. 26 6月, 2010 4 次提交
  10. 25 6月, 2010 6 次提交
  11. 13 6月, 2010 1 次提交
  12. 03 6月, 2010 3 次提交
  13. 02 6月, 2010 4 次提交
    • B
      sfc: Get port number from CS_PORT_NUM, not PCI function number · dd8f61d7
      Ben Hutchings 提交于
      A single shared memory region used to communicate with firmware is
      mapped into both PCI PFs of the SFC9020 and SFL9021.  Drivers must be
      able to identify which port they are addressing in order to use the
      correct sub-region.  Currently we use the PCI function number, but the
      PCI address may be virtualised.  Use the CS_PORT_NUM register field
      defined for just this purpose.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dd8f61d7
    • B
      sfc: Only count bad packets in rx_errors · d188ceeb
      Ben Hutchings 提交于
      rx_errors is defined as 'bad packets received', but we are currently
      including various overflow errors as well.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d188ceeb
    • S
      sfc: Allow shared pages to be recycled · 62b330ba
      Steve Hodgson 提交于
      Insert a structure at the start of the shared page that
      tracks the dma mapping refcnt. DMA into the next cache
      line of the (shared) page (plus EFX_PAGE_IP_ALIGN).
      
      When recycling a page, check the page refcnt. If the
      page is otherwise unused, then resurrect the other
      receive buffer that previously referenced the page.
      Be careful not to overflow the receive ring, since we
      can now resurrect n receive buffers in a row.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62b330ba
    • S
      sfc: Recycle discarded rx buffers back onto the queue · 24455800
      Steve Hodgson 提交于
      The cut-through design of the receive path means that packets that
      fail to match the appropriate MAC filter are not discarded at the MAC
      but are flagged in the completion event as 'to be discarded'.  On
      networks with heavy multicast traffic, this can account for a
      significant proportion of received packets, so it is worthwhile to
      recycle the buffer immediately in this case rather than freeing it
      and then reallocating it shortly after.
      
      The only complication here is dealing with a page shared
      between two receive buffers. In that case, we need to be
      careful to free the dma mapping when both buffers have
      been free'd by the kernel. This means that we can only
      recycle such a page if both receive buffers are discarded.
      Unfortunately, in an environment with 1500mtu,
      rx_alloc_method=PAGE, and a mixture of discarded and
      not-discarded frames hitting the same receive queue,
      buffer recycling won't always be possible.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24455800