netdev - Re: [PATCH net-next-2.6 00/10] sfc changes for 2.6.37

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Sep 2010 12:28:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	bhutchings@...arflare.com
Cc:	netdev@...r.kernel.org, linux-net-drivers@...arflare.com
Subject: Re: [PATCH net-next-2.6 00/10] sfc changes for 2.6.37

From: Ben Hutchings <bhutchings@...arflare.com>
Date: Fri, 10 Sep 2010 17:40:17 +0100

> One new feature - variable ring sizes - and a few bug fixes.
> 
> Ben.
> 
> Ben Hutchings (9):
>   sfc: Use MCDI RX_BAD_FCS_PKTS count as MAC rx_bad count
>   sfc: Accumulate RX_NODESC_DROP count in rx_dropped, not
>     rx_over_errors
>   sfc: Remove declarations of functions that no longer exist
>   sfc: Fix failure paths in efx_probe_port()
>   sfc: Allocate DMA and event rings using GFP_KERNEL
>   sfc: Abstract channel and index lookup for RX queues
>   sfc: Refactor channel and queue lookup and iteration
>   sfc: Allocate each channel separately, along with its RX and TX
>     queues
>   sfc: Allow changing the DMA ring sizes dynamically via ethtool
> 
> Steve Hodgson (1):
>   sfc: Make the dmaq size a run-time setting (rather than compile-time)

All applied, thanks Ben.

It could be argued that rx_over_errors is meant to count internal chip
FIFO overflows during receive, which occur when DMA cannot meet demand
for long periods of time.  Indicating that FIFO settings need to be
increased or PCI settings adjusted.

Anyways, just my view.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html