netdev - Re: RFC: issues concerning the next NAPI interface

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, 28 Aug 2007 13:48:20 +0200
From:	Jan-Bernd Themann <ossthema@...ibm.com>
To:	James Chapman <jchapman@...alix.com>
Cc:	David Miller <davem@...emloft.net>,
	shemminger@...ux-foundation.org, akepner@....com,
	netdev@...r.kernel.org, raisch@...ibm.com, themann@...ibm.com,
	linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
	meder@...ibm.com, tklein@...ibm.com, stefan.roscher@...ibm.com
Subject: Re: RFC: issues concerning the next NAPI interface

On Tuesday 28 August 2007 11:22, James Chapman wrote:
> > So in this scheme what runs ->poll() to process incoming packets?
> > The hrtimer?
> 
> No, the regular NAPI networking core calls ->poll() as usual; no timers 
> are involved. This scheme simply delays the napi_complete() from the 
> driver so the device stays in the poll list longer. It means that its 
> ->poll() will be called when there is no work to do for 1-2 jiffies, 
> hence the optimization at the top of ->poll() to efficiently handle that 
> case. The device's ->poll() is called by the NAPI core until it has 
> continuously done no work for 1-2 jiffies, at which point it finally 
> does the netif_rx_complete() and re-enables its interrupts.
> 
I'm not sure if I understand your approach correctly.
This approach may reduce the number of interrupts, but it does so
by blocking the CPU for up to 1 jiffy (that can be quite some time
on some platforms). So no other application / tasklet / softIRQ type
can do anything in between. The CPU utilization does not drop at all, 
and I thought that is one reason why we try to reduce the number of interrupts.

> If people feel that holding the device in the poll list for 1-2 jiffies 
> is too long (because there are too many wasted polls), a counter could 
> be used to to delay the netif_rx_complete() by N polls instead. N would 
> be a value depending on CPU speed. I use the jiffy sampling method 
> because it results in some natural randomization of the actual delay 
> depending on when the jiffy value was sampled in relation to the jiffy tick.
> 

Waiting for N polls seems to make no sense if there are no further network adapters
in that machine. It would take no time to call poll N times in a row when no
new packets arrive. There is no real delay as the net_rx_action function will
do nothing else between the poll calls.

Please correct me if I'm wrong.

Regards,
Jan-Bernd
-
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