From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B7F20A0524; Mon, 7 Dec 2020 11:55:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1394DF12; Mon, 7 Dec 2020 11:55:41 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by dpdk.org (Postfix) with ESMTP id DE10EE07 for ; Mon, 7 Dec 2020 11:55:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607338537; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DysXqwUJaQmlrofJKc4oRZP3iyW7srEXq55JmvDT2Gw=; b=FOsnuokVFGV/PO2PFqKrviumY16ZZH+0YmWbxxsbgCTnKMM0fh6YGZBOimbd0SNTjKiuSH DaLjg60ET6hcUdLew+mpp4yHZgIiCSIXdiLAHj6F4CeVkgJXiHcqRxMRPozepBPTcteNRI z4VQP0e/NEuGdT8ULtupn73OJj5fRFY= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-pWqPoP8GMjaS2tBxZuFjiw-1; Mon, 07 Dec 2020 05:55:32 -0500 X-MC-Unique: pWqPoP8GMjaS2tBxZuFjiw-1 Received: by mail-vs1-f71.google.com with SMTP id p4so680802vsq.13 for ; Mon, 07 Dec 2020 02:55:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DysXqwUJaQmlrofJKc4oRZP3iyW7srEXq55JmvDT2Gw=; b=WusFp3rkaS2DiyWyGCcVSwAXcFkpjPCpLsh2HqUeO+Zr3Z5ttQqfRJturwGgrTCwJV o4Lac7sOMTTffYmA611+GVWNkTAC8wLQuZf3Oxo2oLNESReIz6WmdetbaJY63EfGSUnh dnk1uiOyYlKp4OGEJenwAcJMAZXpI+SIo4KgbluGaA0yMzmPtNwR82YMa6uNJiUEhwa0 qEDGNBWfwJieCNkqLWORw62IpmP4ahlGIV0ziKBQaFZUnPtorp5eZr6SNMnI2RY5Iuwt nl/lyeoVNxZWz3rpJv0v1m/ospBettcpY5UcSfWnA+eykgMwBCliiT3tk4InTryCpoh0 LEww== X-Gm-Message-State: AOAM533YWVmftRnobetsxxsOwi9U8G9L5fr+XeWxsC0F/fath/IidU8Z HAkCn56h9Tqq+EL87A/YTleEIMHmB1ahWA6gT+RbwpWYRDb3bDz6f7019f0uC+kmFiMholq7ega 7KzMgIEKp5E3+LPgq2gw= X-Received: by 2002:a05:6102:212a:: with SMTP id f10mr11659535vsg.18.1607338531974; Mon, 07 Dec 2020 02:55:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJyLOIdNbiOogGrj1m5x9LhJVg0OZDGiM7AsAEp/8+QHR6R9EuI4gQ3FMPrHQrjOsi64oJV6xYUqLC2l5JOx1m0= X-Received: by 2002:a05:6102:212a:: with SMTP id f10mr11659524vsg.18.1607338531793; Mon, 07 Dec 2020 02:55:31 -0800 (PST) MIME-Version: 1.0 References: <9d5b0d3a3bb648d5a296eb794006db14@pantheon.tech> In-Reply-To: <9d5b0d3a3bb648d5a296eb794006db14@pantheon.tech> From: David Marchand Date: Mon, 7 Dec 2020 11:55:20 +0100 Message-ID: To: Beilei Xing , Jeff Guo Cc: "dev@dpdk.org" , "Kinsella, Ray" , "Andrew Yourtchenko (ayourtch)" , =?UTF-8?Q?Juraj_Linke=C5=A1?= , "Yigit, Ferruh" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] Faulty VF initialization during DPDK startup when multiple DPDK instances use different VFs with the same PF X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Dec 7, 2020 at 11:49 AM Juraj Linke=C5=A1 wrote: > > Hi DPDK devs, > > A while back I've submitted this bug: https://bugs.dpdk.org/show_bug.cgi?= id=3D578 and now we have a pretty good idea where the issue stems from. TL;= DL: it seems to be in either XL710 firmware or i40e driver, with downstream= effects which we may need to address in DPDK. > > What is the issue? > We're using an XL710 NIC with SR-IOV setup with multiple virtual function= s (VFs) that belong to the same physical function (PF). We're observing int= ermittent failures when multiple DPDK EAL instances are trying to initializ= e different VFs from the PF. One of the failures looks like this: > i40evf_check_api_version(): PF/VF API version mismatch:(0.0)-(1.1) > > This results in VPP (which uses DPDK to initialize these VFs) not being a= ble to use the VFs. There an associated syslog: > > [Thu Dec 3 02:30:56 2020] i40e 0000:05:00.1: Unable to send the message = to VF 49 aq_err 12 > > Digging in the sources we've found that this is the error message: > https://elixir.bootlin.com/linux/v4.15/source/drivers/net/ethernet/intel/= i40evf/i40e_adminq_cmd.h#L115 > > This suggests it's an issue with either the driver or firmware and that l= eads us to two questions: > 1) Is this an expected condition to happen? What is the reason for this c= ontention and is it normal to have it, and what is the expected correct beh= avior of the calling code? > 2) If "yes" to the previous question - then, since the caller in this cas= e initialization code of DPDK, should we address it there (e.g. some retrie= s or a lock)? > > Are there any Intel (or SR-IOV) experts who could help with answering the= first question? Or is it possible that no matter what the expected behavio= r is should we address it in DPDK? Added i40e maintainers. --=20 David Marchand