From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [net-next rfc v7 1/3] virtio-net: separate fields of sending/receiving queue from virtnet_info Date: Tue, 04 Dec 2012 17:23:21 +0800 Message-ID: <1586636.MnKZJZo7n1@jason-thinkpad-t430s> References: <1354011360-39479-1-git-send-email-jasowang@redhat.com> <3524590.ZWGua7A8ne@jason-thinkpad-t430s> <87zk1uh48g.fsf@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: krkumar2@in.ibm.com, kvm@vger.kernel.org, mst@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, bhutchings@solarflare.com, jwhan@filewood.snu.ac.kr, shiyer@redhat.com To: Rusty Russell Return-path: In-Reply-To: <87zk1uh48g.fsf@rustcorp.com.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: kvm.vger.kernel.org On Tuesday, December 04, 2012 02:13:11 PM Rusty Russell wrote: > Jason Wang writes: > > On Monday, December 03, 2012 12:25:42 PM Rusty Russell wrote: > >> > + > >> > + /* Work struct for refilling if we run low on memory. */ > >> > + struct delayed_work refill; > >> > >> I can't really see the justificaiton for a refill per queue. Just have > >> one work iterate all the queues if it happens, unless it happens often > >> (in which case, we need to look harder at this anyway). > > > > But during this kind of iteration, we may need enable/disable the napi > > regardless of whether the receive queue has lots to be refilled. This may > > add extra latency. > > Sure, but does it actually happen? We only use the work when we run out > of memory. If this happens in normal behaviour we need to change > something else... True, I will change to use a global one. Thanks > > Thanks, > Rusty. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html