From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tetsuya Mukawa <mukawa@igel.co.jp>
Subject: Re: [RFC PATCH 5/5] virtio: Extend virtio-net PMD to
 support container environment
Date: Tue, 26 Jan 2016 11:58:39 +0900
Message-ID: <56A6E0DF.9010800@igel.co.jp>
References: <1453108389-21006-2-git-send-email-mukawa@igel.co.jp>
 <1453374478-30996-6-git-send-email-mukawa@igel.co.jp>
 <C37D651A908B024F974696C65296B57B4C5ACAF4@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
To: "Xie, Huawei" <huawei.xie@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
 "yuanhan.liu@linux.intel.com" <yuanhan.liu@linux.intel.com>,
 "Tan, Jianfeng" <jianfeng.tan@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com
 [209.85.220.53]) by dpdk.org (Postfix) with ESMTP id 03F3591AB
 for <dev@dpdk.org>; Tue, 26 Jan 2016 03:58:44 +0100 (CET)
Received: by mail-pa0-f53.google.com with SMTP id cy9so90816381pac.0
 for <dev@dpdk.org>; Mon, 25 Jan 2016 18:58:43 -0800 (PST)
In-Reply-To: <C37D651A908B024F974696C65296B57B4C5ACAF4@SHSMSX101.ccr.corp.intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 2016/01/25 19:17, Xie, Huawei wrote:
> On 1/21/2016 7:09 PM, Tetsuya Mukawa wrote:
>> +static void
>> +qtest_handle_one_message(struct qtest_session *s, char *buf)
>> +{
>> +	int ret;
>> +
>> +	if (strncmp(buf, interrupt_message, strlen(interrupt_message)) == 0) {
>> +		if (rte_atomic16_read(&s->enable_intr) == 0)
>> +			return;
>> +
>> +		/* relay interrupt to pipe */
>> +		ret = write(s->irqfds.writefd, "1", 1);
> How about the interrupt latency? Seems it is quite long.

Yes, I agree with it.
Probably using evetfd or removing this read/write mechanism to handle
interrupts will be nice.
Let me check it more.

Tetsuya