netdev - Re: [PATCH] igb: Record hardware RX overruns in net

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:	Tue, 5 May 2009 14:32:04 -0700
From:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:	Jesper Dangaard Brouer <hawk@...u.dk>
Cc:	David Miller <davem@...emloft.net>, hawk@...x.dk,
	netdev <netdev@...r.kernel.org>,
	e1000-devel@...ts.sourceforge.net, jesse.brandeburg@...el.com,
	bruce.w.allan@...el.com, peter.p.waskiewicz.jr@...el.com,
	john.ronciak@...el.com
Subject: Re: [PATCH] igb: Record hardware RX overruns in net_stats

On Tue, May 5, 2009 at 2:24 PM, Jesper Dangaard Brouer <hawk@...u.dk> wrote:
> On Tue, 5 May 2009, David Miller wrote:
>
>> From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
>> Date: Tue, 5 May 2009 11:47:09 -0700
>>
>>> NAK.  RNBC is not a counter for buffer overruns, and so should not be
>>> counted as such.
>>
>> I'd say technically it is, it indicates that more packets arrived than
>> the available receive buffers could handle.
>
> I agree with DaveM. Technically it _is_ a buffer overflow, but in the host
> memory not the NIC. I'm sort of pushing the system into a situation where it
> cannot empty the receive buffers fast enough.
>
> I can fairly easily provoke this situation by adding too many iptables
> rules, which (intentionally) cause high CPU load and causes ksoftirqd to run
> (I'm Oprofiling netfilter modules).
>
>
>> If anything, this is the closest this device has for this kind of
>> situation, and it's useful for diagnosing problems.
>
> Its really useful for diagnosing problems, and I'm betting that this is a
> real-life situation which people is going to experience. We might as well
> help our self to more easily identify this issue when people report drop
> problems.
>
> Notice that I'm seeing:
>
>  rx_no_buffer_count: 136955
>  rx_missed_errors: 0
>
> Thus, the rx_missed_errors is zero, which according to the datasheet is the
> "real" fifo drop (the MPC register, Missed Packets Count) and PCI bandwidth
> problem indications.
>
> If we really should nitpick, then:
>
>  adapter->net_stats.rx_missed_errors = adapter->stats.mpc
>
> Should then have been stored in the rx_fifo_errors.  Notice that
> rx_missed_errors is presented to userspace as drops (see
> net/core/dev.c:2624).
>
> I think that both MPC and RNBC should be stored in rx_fifo_errors (and of
> cause still keeping them seperate to ethtool -S).
>
> I'll post two patches with these changes tomorrow, for you evaluation.
>
> Please reconsider you NAK.
>
> Greetings,
>  Jesper Brouer
>
> --

the manual[1] for the hardware says:
RNBC:
This register counts the number of times that frames were received
when there were no available buffers in host memory to store those
frames (receive descriptor head and tail pointers were equal). The
packet is still received if there is space in the FIFO. This register
only increments if receives are enabled. This register does not
increment when flow control packets are received.

The critical bit "The packet is still received if there is space in
the FIFO" (AND a host memory buffer becomes available) So the reason
we don't want to put it in the net_stats stats for drops is that the
packet
*wasn't* necessarily dropped.

The rx_missed errors is for packets that were definitely dropped, and
is already stored in the net_stats structure.



-- 
Cheers,
Jeff
--
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