From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
by dpdk.org (Postfix) with ESMTP id 261DDA48A
for <dev@dpdk.org>; Sun, 21 Jan 2018 21:07:50 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga008.jf.intel.com ([10.7.209.65])
by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
21 Jan 2018 12:07:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.46,393,1511856000"; d="scan'208";a="11887960"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.26.249])
([10.252.26.249])
by orsmga008.jf.intel.com with ESMTP; 21 Jan 2018 12:07:46 -0800
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Matan Azrad <matan@mellanox.com>,
Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Gaetan Rivet <gaetan.rivet@6wind.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>,
Andrew Rybchenko <arybchenko@solarflare.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
Alejandro Lucero <alejandro.lucero@netronome.com>,
Jerin Jacob <jerin.jacob@caviumnetworks.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>, Shahaf Shuler
<shahafs@mellanox.com>, Olivier MATZ <olivier.matz@6wind.com>,
"Zhang, Helin" <helin.zhang@intel.com>
References: <1516220357-13013-1-git-send-email-matan@mellanox.com>
<1516274834-19755-1-git-send-email-matan@mellanox.com>
<1516274834-19755-5-git-send-email-matan@mellanox.com>
<03662190-8477-b218-21f7-ecfb806b5997@intel.com>
<AM6PR0502MB379763F57AF728E407B9CD54D2E80@AM6PR0502MB3797.eurprd05.prod.outlook.com>
<b044d0da-abd6-5602-8ae9-761fbffc4d1c@intel.com>
Message-ID: <be05a10f-c285-9bc5-19e8-9239143c7d8d@intel.com>
Date: Sun, 21 Jan 2018 20:07:46 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <b044d0da-abd6-5602-8ae9-761fbffc4d1c@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v6 4/6] ethdev: adjust APIs removal error
report
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://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: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2018 20:07:51 -0000
On 1/19/2018 4:19 PM, Ferruh Yigit wrote:
> On 1/18/2018 6:10 PM, Matan Azrad wrote:
>> Hi Ferruh
>>
>> From: Ferruh Yigit, Thursday, January 18, 2018 7:31 PM
>>> On 1/18/2018 11:27 AM, Matan Azrad wrote:
>>>> rte_eth_dev_is_removed API was added to detect a device removal
>>>> synchronously.
>>>>
>>>> When a device removal occurs during control command execution, many
>>>> different errors can be reported to the user.
>>>>
>>>> Adjust all ethdev APIs error reports to return -EIO in case of device
>>>> removal using rte_eth_dev_is_removed API.
>>>>
>>>> Signed-off-by: Matan Azrad <matan@mellanox.com>
>>>> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>>>> ---
>>>> lib/librte_ether/rte_ethdev.c | 192
>>>> +++++++++++++++++++++++++++---------------
>>>> lib/librte_ether/rte_ethdev.h | 51 ++++++++++-
>>>> 2 files changed, 170 insertions(+), 73 deletions(-)
>>>>
>>>> diff --git a/lib/librte_ether/rte_ethdev.c
>>>> b/lib/librte_ether/rte_ethdev.c index c93cec1..7044159 100644
>>>> --- a/lib/librte_ether/rte_ethdev.c
>>>> +++ b/lib/librte_ether/rte_ethdev.c
>>>> @@ -338,6 +338,16 @@ struct rte_eth_dev *
>>>> return -ENODEV;
>>>> }
>>>>
>>>> +static int
>>>> +eth_err(uint16_t port_id, int ret)
>>>> +{
>>>> + if (ret == 0)
>>>> + return 0;
>>>> + if (rte_eth_dev_is_removed(port_id))
>>>> + return -EIO;
>>>> + return ret;
>>>> +}
>>>> +
>>>> /* attach the new device, then store port_id of the device */ int
>>>> rte_eth_dev_attach(const char *devargs, uint16_t *port_id) @@ -492,7
>>>> +502,8 @@ struct rte_eth_dev *
>>>> return 0;
>>>> }
>>>>
>>>> - return dev->dev_ops->rx_queue_start(dev, rx_queue_id);
>>>> + return eth_err(port_id, dev->dev_ops->rx_queue_start(dev,
>>>> + rx_queue_id));
>>>>
>>>> }
>>>
>>> This patch updates *all* ethdev public APIs to add if device is removed
>>> check?
>>
>> Yes.
>>
>>> And each check goes to ethdev is_removed() dev_ops to ask if dev is
>>> removed.
>> Probably, if the REMOVED state setted in will not call device is_remove.
>>
>>> These must be better way of doing this, am I missing something.
>>
>> Suggest.
>
> With a silly analogy, this is like a blind person asking each time if he is dead
> before talking to other person.
>
> At first glance I can think of a kind of watchdog timer can be implemented in
> ethdev layer. It provides periodic checks and if device is dead it calls the
> registered user callback function.
>
> This method presented as synchronous method but not triggered from side where
> event happens, I mean not triggered from PMD but from application.
> So does application doing polling continuously if device is dead?
> Or if application is relying this patch to add a check in each API, what happens
> if device removed during data processing, will app rely on asynchronous method?
>
> I am including a few consumers of the ethdev to the mail thread, clearly I am
> not very supportive of this patch, but specially taking release is being close
> to the account, if there is no objection than me I will take as consensus to get
> the patch in.
It looks like there is no objection to the patch and it is already acked, I will
get latest version to next-net.
>
>>
>> This code will replace similar code in each PMD.
>>
>>> I definitely would like to see more comments for this patch.
>>>
>>> Another question is what happens if device removed while or before
>>> dev_ops called? There is no synchronizations in drivers for removal, right?
>>>
>>
>> Yes. You right, the device removal can be changed a moment after the call.
>> Actually the caller suspected in removal before call it(and want to validate it) - so it makes sense.
>> From this reason the check in ethdev APIs is called generally in error flows.
>>
>>
>>> <...>
>