[Top] [All Lists]

Re: NAPI, e100, and system performance problem

To: Stephen Hemminger <shemminger@xxxxxxxx>
Subject: Re: NAPI, e100, and system performance problem
From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Sat, 23 Apr 2005 19:54:13 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, gnb@xxxxxxx, hadi@xxxxxxxxxx, ak@xxxxxx, akepner@xxxxxxx, jesse.brandeburg@xxxxxxxxx, netdev@xxxxxxxxxxx, davem@xxxxxxxxxx
In-reply-to: <20050423125153.65189ea0@localhost.localdomain>
References: <C925F8B43D79CC49ACD0601FB68FF50C03A633C7@orsmsx408> <> <1113855967.7436.39.camel@localhost.localdomain> <> <> <1114173195.7679.30.camel@localhost.localdomain> <> <1114193902.7978.39.camel@localhost.localdomain> <> <20050423094038.72a8da73@localhost.localdomain> <> <20050423125153.65189ea0@localhost.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
Stephen Hemminger writes:

 > One of the problem with the dynamic schemes, is there is no generic 
 > infrastructure
 > to support it. There are some drivers that have tried dynamic schemes
 > but each seems to reinvent some adhoc scheme. Seems like a good area
 > for future research.

 Well how do decorrelate bursty network and more interesing at what 
 time level? I said this before... the only useful measure for mitigation
 setting was packets on RX ring.
 > Another related problem is some drivers use NAPI for both TX and RX and
 > this can cause asymmetric behavior and scheduling issues. The whole
 > dev->weight limit stuff assumes RX not TX usage of NAPI

 Well in the very beginning it was thought only RX yes, But it is possible 
 also to have TX buffer cleared etc in the ->poll routine to simplify 
 intr. acking. As implemented only RX packets updates the budget.
 From what I see in real life use this works well. Guess you noticed the 
 tests with e1000 and TCP just posted. 

 Anyway MSI will give us some new options in this area..


<Prev in Thread] Current Thread [Next in Thread>