Re: [dpdk-dev] DPDK2.1 VF and NIC X552 PF - ixgbe SRIOV works?

[Zhongliang Shu <zshu11@yahoo.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 8354 bytes --]

Hi,  Wenzhuo:
The Dev ID is 15a8 (device_id = 5544, vendor_id = 32902)About SR-IOV between this NIC and DPDK2.1? 
Or when DPDK will support SR-IOV for this NIC?

Thanks. 


     On Tuesday, November 3, 2015 6:13 PM, "Lu, Wenzhuo" <wenzhuo.lu@intel.com> wrote:
   

 Hi Zhongliang,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhongliang Shu
> Sent: Wednesday, November 4, 2015 7:07 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] DPDK2.1 VF and NIC X552 PF - ixgbe SRIOV works?
> 
> Hi, Guys:
> I have developed a VM to use SRIOV VF of DPDK2.1 libraryand its PF NIC is
> interl X552 NIC. The VM is deployed on KVM on Linux box.
> NIC Inforoot@localhost:~# modinfo ixgbe
> filename:       /lib/modules/3.14.49-rt46-
> WR7.0.0.5_ovp/kernel/drivers/juniper/x552-nic/ixgbe.ko
> version:        4.2.0.4.1-unreleased
> license:        GPL
> description:    Intel(R) 10 Gigabit PCI Express Network Driver Linux Box
> InfoLinux localhost 3.14.49-rt46-WR7.0.0.5_ovp #1 SMP PREEMPT RT Mon Oct
> 26 12:24:18 PDT 2015 x86_64 GNU/Linux When the VM start, and its correct
> corresponding MAC is pushed into PF.
> 4: sxe0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP,LOWER_UP> mtu
> 1500 qdisc mq master eth1br state UP mode DEFAULT group default qlen
> 1000
>     link/ether 88:a2:5e:09:bd:c1 brd ff:ff:ff:ff:ff:ff
>     vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
>     vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
>     vf 2 MAC 52:54:00:ba:fa:f7, spoof checking on, link-state auto
>     vf 3 MAC 52:54:00:ee:e6:0d, spoof checking on, link-state auto Linux Host
> dmesg:root@localhost:/lib# dmesg [62995.451770] pci-stub 0000:03:10.4:
> claimed by stub [62995.465783] ixgbe 0000:03:00.0: setting MAC
> 52:54:00:ba:fa:f7 on VF 2 [62995.465785] ixgbe 0000:03:00.0: Reload the VF
> driver to make this change effective.
> [62995.520671] device vnet4 entered promiscuous mode [62995.520900]
> eth0br: port 4(vnet4) entered forwarding state [62995.520911] eth0br: port
> 4(vnet4) entered forwarding state [62995.666671] pci-stub 0000:03:10.4:
> enabling device (0000 -> 0002) [62998.148072] pci-stub 0000:03:10.4: kvm
> assign device [63010.548139] eth0br: port 4(vnet4) entered forwarding state
> [63050.387806] pci-stub 0000:03:10.4: irq 97 for MSI/MSI-X [63050.399811]
> pci-stub 0000:03:10.4: irq 97 for MSI/MSI-X [63289.573419] ixgbe 0000:03:00.0
> sxe0: VF Reset msg received from vf 2 [63290.033229] ixgbe 0000:03:00.0 sxe0:
> VF Reset msg received from vf 2 [63953.063867] ixgbe 0000:03:00.0: Malicious
> event on VF 2 tx:100000 rx:0 Several questions about the log msgs
> 1): its keep to see the log msgs:     [63289.573419] ixgbe 0000:03:00.0 sxe0: VF
> Reset msg received from vf 2
>      [63290.033229] ixgbe 0000:03:00.0 sxe0: VF Reset msg received from vf
> 2    what reason cause these msg?
> 2): When try ping from the VM,   it fails and there has msg:
>       [63953.063867] ixgbe 0000:03:00.0: Malicious event on VF 2 tx:100000
> rx:0
>     what reason causes this msg?
> 3): Does DPDK2.1 VF and X552 PF is tested and supported?
> By the way, the SRIOV of this VM work fine for X550 NIC and  82580 NIC,
> Thanks.
I'm afraid x552 is not supported yet. Would you like to give me the device id to confirm that?




From thomas.monjalon@6wind.com  Sat Nov  7 22:54:44 2015
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42])
 by dpdk.org (Postfix) with ESMTP id 61D145A53
 for <dev@dpdk.org>; Sat,  7 Nov 2015 22:54:44 +0100 (CET)
Received: by wmww144 with SMTP id w144so5451081wmw.0
 for <dev@dpdk.org>; Sat, 07 Nov 2015 13:54:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=6wind_com.20150623.gappssmtp.com; s 150623;
 h=from:to:cc:subject:date:message-id:organization:user-agent
 :in-reply-to:references:mime-version:content-transfer-encoding
 :content-type; bhéubLGufIJ+5LQnqb7P6f6AiVqj7q0K7tmcWbr6iDO4=;
 b=Z4tNC50UIZzA/xN5yayjP/tsQHAFLiULbxLt3piH/EAsVgcHnlQOeEP5gablv/PeCa
 Yvk1N2aapDBnkrX3e5R2YBkRKgXgAMVEuk7n7ayHz7YjiEnazTWqHmmlFwDemahmllcX
 QIGJtsLT0yooYvpOg1vB/BMGCt6qWRaK6bRfMuZ31yzdERClvZ/EhDPb/jbDhT3PA8iQ
 BIr0ThsvGYWmZ3KJdYVzNBBpO++pdUPfeAnDtGStaNMI1atSu7fMvBzCd/U8MAR61Ou5
 jtozeMqvbSY8Exv/bH/4ovxIGTlF5tROcRNxLVmy43HJNqQY9vv5PFyk6Vvhi1jzqndM
 2aSw=X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d\x1e100.net; s 130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
 :user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type;
 bhéubLGufIJ+5LQnqb7P6f6AiVqj7q0K7tmcWbr6iDO4=;
 b=i41ShqdeQn+8LbCSN1nG6rCjbMsvI4yUlQlm+msx1HJW1X3GAa1Lc44lo7F26JmSCV
 nD3w+hkWY9JbRgw23MMCZrdErhpp0DN9jh3ua5C+NyL9fxcyoBxk01hw5P8WS8/G7FET
 rQsFr7bYIDZ5Nda8Rf4AcLskqbD5LdLUOeT7c7/ZJD6uymhFy2G+FS5xISx1UXG5ZZk5
 0D3q2tZ5dg0SlriIPrK8ZUbGmUQ0EIsY3ofxtedE+xOzBUFUaw5DoPHpespTL/s9J5Sg
 At14cZbLWf2TR7qFJfBzGo1SJdLc+AfymlL5+r++u1/uGgYju0wZcl1MD3vUuFbq3DuK
 BklA=X-Gm-Message-State: ALoCoQmf98sVTZ9sIk6sM+Ettdei/zXosp/3kYQvUOB6XHZQOrunSEgMucQUDFXuN00C8aHXyLqo
X-Received: by 10.28.19.65 with SMTP id 62mr16922472wmt.35.1446933284199;
 Sat, 07 Nov 2015 13:54:44 -0800 (PST)
Received: from xps13.localnet ([2a01:e35:2e5e:ee00:7e7a:91ff:fe14:f0d2])
 by smtp.gmail.com with ESMTPSA id v9sm6946775wjv.45.2015.11.07.13.54.43
 (version=TLSv1.2 cipherìDHE-RSA-AES128-GCM-SHA256 bits\x128/128);
 Sat, 07 Nov 2015 13:54:43 -0800 (PST)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Harish Patil <harish.patil@qlogic.com>
Date: Sat, 07 Nov 2015 22:53:33 +0100
Message-ID: <5600189.IfZWYQEBpk@xps13>
Organization: 6WIND
User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; )
In-Reply-To: <D262A6A6.EB730%harish.patil@qlogic.com>
References: <1442018576-19981-1-git-send-email-rasesh.mody@qlogic.com>
 <6673500.WzqtfFB45U@xps13> <D262A6A6.EB730%harish.patil@qlogic.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org, Sony Chacko <sony.chacko@qlogic.com>
Subject: Re: [dpdk-dev] [PATCH 3/5] bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS
	config option
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Sat, 07 Nov 2015 21:54:44 -0000

> >Either other "debug" logs can be put as INFO level, or
> >you need a level 9 for verbose debug.
> >But I don't really understand what is the problem of a verbose debug.
> >
> >It is not critical for the acceptance of this patch. Just wanted to
> >discuss
> >it as we have many config options to tune the debug.
> >
> >Please, at least, use the DEBUG word in the option name as done for
> >CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX.
> >
>
> Currently PMD_DRV_LOG(DEBUG,..) is used all over the places and converting
> that into INFO/NOTICE levels results in lot of changes.

Having a lot of changes to do is not a good argument.
But that's an argument to reduce the size of the bnx2x driver.
And more generally, this driver would deserve some big changes.

> Even if we convert other debug logs as INFO level logs, since level 8 is
> the default debug level,  the user would have to edit config file to
> prevent flooding of the messages on the console.

The user *should* change the log evel in most cases.
Or we could raise the default level to INFO.
And users of packaged DPDK may already have a different configuration
from the distribution.

> So I guess adding a debug
> option without needing additional level would suffice for now. I shall
> rename it as CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC and include all
> periodic events like statistics, register R/Ws etc under this debug.

Yes it could work.
But it would be nice to have a consistent log management across drivers.