netdev - Re: macb napi strange behavior

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]

Message-ID: <CAGVrzcZxPqyp3CDLc-UQejtVg1QVv5OBuGLQNVSrtfG9H1OUnA@mail.gmail.com>
Date:	Wed, 17 Jun 2015 13:20:45 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Nicolae Rosia <nicolae.rosia@...il.com>
Cc:	Jaeden Amero <jaeden.amero@...com>,
	netdev <netdev@...r.kernel.org>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Cyrille Pitchen <cyrille.pitchen@...el.com>,
	Josh Cartwright <joshc@...com>
Subject: Re: macb napi strange behavior

2015-06-17 12:00 GMT-07:00 Nicolae Rosia <nicolae.rosia@...il.com>:
> Hi,
>
> On Wed, Jun 17, 2015 at 9:54 PM, Jaeden Amero <jaeden.amero@...com> wrote:
>> On 06/17/2015 11:09 AM, Nicolae Rosia wrote:
>> The times we've seen tons of interrupts on Ethernet with interrupts
>> routed through the PL was when the FPGA was unprogrammed (or in the
>> process of being reprogrammed), or was configured with the interrupt
>> line tied to asserted.
>>
>> In the latter case, Linux would eventually stop handling any more
>> interrupts for that port due to the interrupt storm.
>>
> This isn't the case. The FPGA is programmed, and indeed I'm using the
> second MAC routed through PL to SFP.
> The interesting thing is that I'm seeing the exact behavior on the
> other side (another Zynq7 board), with eth0 having lots of interrupts.
> It seems that the interface receiving packets doesn't have a high IRQ
> activity in contrast to the one sending packets.

Typically, NAPI is used at the receive side of the Ethernet NIC/driver
to lower the hard/soft interrupt context switch, although there is
nothing that prevent you to implement a similar scheme for the
transmit side. Usually, for transmit you will be submitting one packet
for transmission and get a completion interrupt, so without interrupt
coalescing (software or hardware) you can end-up with 1 interrupt per
packet transmitted.
-- 
Florian
--
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