From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 0215D5A3E for ; Wed, 8 Apr 2015 05:40:11 +0200 (CEST) Received: by wgsk9 with SMTP id k9so52303812wgs.3 for ; Tue, 07 Apr 2015 20:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XPpmZj3G0OmtXMyxFD2UisxiHoSVXVBgijBto2dm3NY=; b=saR2f2jXbgcasxaj8RUOosagHYN7UsDGaeqkCnyFS/pz3yK/YI2oseM1XXlvs9+Rac FhTz6H3Nb7VEeVquvDO2xGdHFdMSEXnD/qlbEI5/fa4hnav9s9uRJPcqOOfmlcoKzo/k DUPoy8k2m4R0KkRc7AGBQInaSPO5sIzF3/Q0ueo4zVjN92vcfCh5Npt2LD8gNY3TZ5fW OHIfYNbZk/wU1hhrT+mEgeUhuJBZKJFPBEhjtDgtFKxMcFi6Jw9f8xaKYye6dJmpHU1D 9DcIMH/BcTm5sSBbC2p4mu+NkZuSQd8AYY44A+JqMv6JscOkxv9rtEs61ZPhBxz0+9Zg /2lA== MIME-Version: 1.0 X-Received: by 10.180.216.103 with SMTP id op7mr10139354wic.90.1428464411828; Tue, 07 Apr 2015 20:40:11 -0700 (PDT) Sender: lukego@gmail.com Received: by 10.27.217.3 with HTTP; Tue, 7 Apr 2015 20:40:11 -0700 (PDT) In-Reply-To: <20150407172849-mutt-send-email-mst@redhat.com> References: <20150127160126.GA10651@redhat.com> <20150407172849-mutt-send-email-mst@redhat.com> Date: Wed, 8 Apr 2015 05:40:11 +0200 X-Google-Sender-Auth: cu_QyeZuyupBkgTeHCgECzIICpU Message-ID: From: Luke Gorrie To: "snabb-devel@googlegroups.com" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" , VirtualOpenSystems Technical Team , virtualization@lists.linux-foundation.org Subject: Re: [dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 03:40:12 -0000 On 7 April 2015 at 17:30, Michael S. Tsirkin wrote: > Just guessing from the available info: > > I think you refer to this: > The driver MUST handle spurious interrupts from the device. > > The intent is to be able to handle some spurious interrupts once in a > while. AFAIK linux triggers the message if it gets a huge number of > spurious interrupts for an extended period of time. > For example, this will trigger if the device does not clear interrupt > line after interrupt register read. > Thanks for that info. The only spurious interrupt that I think we need is one when vhost-user reconnects. That would be to cover the case where the vswitch is restarted after writing used->idx but before sending the interrupt. Or perhaps there is a better solution to that case? Looking forward to getting an upstream vhost-user reconnect. one thing at a time.. :) Cheers, -Luke