From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 43A95A046B for ; Wed, 26 Jun 2019 09:01:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 064744C77; Wed, 26 Jun 2019 09:01:19 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id CB8B04C77; Wed, 26 Jun 2019 09:01:16 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BDEDF6696F; Wed, 26 Jun 2019 07:01:14 +0000 (UTC) Received: from [10.36.112.46] (ovpn-112-46.ams2.redhat.com [10.36.112.46]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B35971001B13; Wed, 26 Jun 2019 07:01:11 +0000 (UTC) To: Noa Ezra Cc: Matan Azrad , "dev@dpdk.org" , "stable@dpdk.org" References: <1560924960-221163-1-git-send-email-noae@mellanox.com> <45aa59ca-c4fd-dbc7-c158-0220c1494c55@redhat.com> From: Maxime Coquelin Message-ID: Date: Wed, 26 Jun 2019 09:01:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 26 Jun 2019 07:01:16 +0000 (UTC) Subject: Re: [dpdk-stable] [Suspected-Phishing][PATCH] net/vhost: fix redundant queue state event X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 6/26/19 8:37 AM, Noa Ezra wrote: > Hi, > >> -----Original Message----- >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >> Sent: Tuesday, June 25, 2019 11:24 AM >> To: Noa Ezra >> Cc: Matan Azrad ; dev@dpdk.org; stable@dpdk.org >> Subject: Re: [Suspected-Phishing][PATCH] net/vhost: fix redundant queue >> state event >> >> >> >> On 6/25/19 9:04 AM, Noa Ezra wrote: >>> Hi, >>> What do you think about this patch? >>> >>> Thanks, >>> Noa. >>> >>>> -----Original Message----- >>>> From: Noa Ezra [mailto:noae@mellanox.com] >>>> Sent: Wednesday, June 19, 2019 9:16 AM >>>> To: maxime.coquelin@redhat.com >>>> Cc: Matan Azrad ; dev@dpdk.org; Noa Ezra >>>> ; stable@dpdk.org >>>> Subject: [Suspected-Phishing][PATCH] net/vhost: fix redundant queue >>>> state event >>>> >>>> In some situations, when a virtual machine is starting, >>>> vring_state_changed can be called while there was no change in the >>>> queue state. This fix makes sure that there was really a change in >>>> the queue state before calling the callback for EVENT_QUEUE_STATE. >>>> >>>> Fixes: ee584e9710b9 ("vhost: add driver on top of the library") >>>> Cc: stable@dpdk.org >>>> Reviewed-by: Matan Azrad >>>> --- >>>> drivers/net/vhost/rte_eth_vhost.c | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/drivers/net/vhost/rte_eth_vhost.c >>>> b/drivers/net/vhost/rte_eth_vhost.c >>>> index cad1e5c..fbe7a37 100644 >>>> --- a/drivers/net/vhost/rte_eth_vhost.c >>>> +++ b/drivers/net/vhost/rte_eth_vhost.c >>>> @@ -855,6 +855,10 @@ struct vhost_xstats_name_off { >>>> /* won't be NULL */ >>>> state = vring_states[eth_dev->data->port_id]; >>>> rte_spinlock_lock(&state->lock); >>>> + if (state->cur[vring] == enable) { >>>> + rte_spinlock_unlock(&state->lock); >>>> + return 0; >>>> + } >>>> >>>> state->cur[vring] = enable; >>>> state->max_vring = RTE_MAX(vring, state->max_vring); >> >> Maybe the application would want to be notified a new queue is available, >> even if it is disabled? > > Can you please look again? As I understand it, "enable" is the "new state" parameter (can be enable/disable). > In this fix I make sure that there was really a change in the state before calling EVENT_QUEUE_STATE (with no change in the state). Ok, I get it. Maybe we would want to update state->max_vring even if we don't sent the event? Thanks, Maxime >> >>>> -- >>>> 1.8.3.1 >>>