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 1678BA04F5 for ; Thu, 5 Dec 2019 01:30:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 526441BE84; Thu, 5 Dec 2019 01:30:26 +0100 (CET) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by dpdk.org (Postfix) with ESMTP id EBD771BE82 for ; Thu, 5 Dec 2019 01:30:24 +0100 (CET) Received: by mail-wm1-f45.google.com with SMTP id f129so1766554wmf.2 for ; Wed, 04 Dec 2019 16:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xlBAhM3zLtNKGm6vosTAmmr3LcjBCp+Zkp3LC9E5CHg=; b=EAzS49d7cIuUMDiv4d7bIj0kfkoJFBigm70fmEHnjlE8zRCGZSHZIQFbk+YAyB5+Ba gYirierebjqwX9geaWXQyTXqioQXLM45cvN2U906uA8pcHIJm3IHxJr8vR12fl/X7xGC ngBVFD2QApZkiqb5t2By/ZDkVTtbN0wqUn4FtgfIAogt4cvpirx8W1VUVvo1GGDJs8CO Bcuy1FtC6DA2aqB3lsbJfpQkt3Txhgx6YBO+w/v0SWaYS2t8X+UXhSIQHybCWMb253PC 12ZYb2f9gRt5IAdYabXjegnYLx2gE0WRwTyNPNVj/4N+lqU49JjccjuzjK0smf9wmTYN JJMQ== 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; bh=xlBAhM3zLtNKGm6vosTAmmr3LcjBCp+Zkp3LC9E5CHg=; b=GVJf2/BcC5j0QL5G/7zBSw7PgqUqedXu5RXng99BmWW7C5ZLJK+8xZSYKS6eCnAgLE nS7u1kRhHzf8hkAVKHY1vX6OFmxJG/b8qkPIiS7XQaAg8U6VyRRQGwRMWiHIEZO0hhHA dfY7z/RfGPlBgSnKOeNH7x9rUfV7KtZ0+VVId1NsZ7JxO1puhVTDu/TW6V5TTHk4qUPr v/9WXbdIJcHDfcJjF6sxcvkmDF9zAOFxxKKI000W8PbaGvvf7zTTaZpckajjRkEG9Jov qgWnJ8GJPxhHWtoWzmm6CsBXehz3kjmHJ2FsdC4P0GvLlfBU/15HQtU6PW30/LD0a7bx jibw== X-Gm-Message-State: APjAAAUsE3pkfcHdXWOtOy9xBWr2knQQKQuHcIyKoWTh/J+QZOfs2sqy NHK5TzTEKTm2BIJvxhEgJsKNmc7hnyZzacLq3A== X-Google-Smtp-Source: APXvYqyJ37HKD2q2Z7fS8SvmI8Dbk0KnjAogBplIPcyZD4F1UQJinBsGNGxFdpX4i8/Nm7XbSj2pY8TEKKAmTFTGBjw= X-Received: by 2002:a1c:9602:: with SMTP id y2mr2159303wmd.23.1575505824465; Wed, 04 Dec 2019 16:30:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Laurent Dumont Date: Wed, 4 Dec 2019 19:30:12 -0500 Message-ID: To: "Greg O'Rawe" Cc: "users@dpdk.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Failover not working on X520 NIC with ixgbevf driver X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" These look okay to me. Sorry, I don't think I saw the same behavior :( On Tue, Dec 3, 2019 at 5:27 AM Greg O'Rawe wrote: > Hi, > > > > Thanks for the reply. > > > > Here are the settings on the hypervisor =E2=80=93 the link-state is =E2= =80=9Cauto=E2=80=9D: > > > > ip link show ens1f1 > > 172: ens1f1: mtu 1500 qdisc mq master > ovs-system state UP mode DEFAULT group default qlen 1000 > > link/ether 90:e2:ba:49:b2:29 brd ff:ff:ff:ff:ff:ff > > vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 3 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 4 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 5 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 6 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 7 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 8 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 9 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trus= t > on, query_rss off > > vf 10 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, > trust on, query_rss off > > vf 11 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, > trust on, query_rss off > > vf 12 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, > trust on, query_rss off > > vf 13 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, > trust on, query_rss off > > vf 14 MAC fa:16:3e:db:90:5a, vlan 412, spoof checking on, link-state > auto, trust on, query_rss off > > vf 15 MAC fa:16:3e:bd:72:64, vlan 411, spoof checking on, link-state > auto, trust on, query_rss off > > > > Thanks > > Greg > > > > > > *From:* Laurent Dumont > *Sent:* 30 November 2019 15:55 > *To:* Greg O'Rawe > *Cc:* users@dpdk.org > *Subject:* Re: [dpdk-users] Failover not working on X520 NIC with ixgbevf > driver > > > > Can you show the VF settings on the hypervisor? "ip link show > $SRIOV_INTERFACE_NAME"? > > > > We saw similar issue with X710 where the physical state wasn't properly > passed from the actual PF to the VM VF. That meant that failover could no= t > happen since the VM thought the link was still active. We had to change t= he > "link-state" parameter on the two VF used by the VM. > > > > That said, it was without VPP but a VM with DPDK enabled. > > > > On Thu, Nov 28, 2019 at 6:52 PM Greg O'Rawe wrote: > > I have the following setup: > > * Virtual environment with Openstack with Intel X520 NIC > > * Hypervisor using ixgbe driver > > * Virtual machine using ixgbevf driver (version 4.6.1) on Red Hat > Linux 7.6 running VPP and DPDK 17.11.4 > > * VM interfaces are bonded in active-standby mode on ingress and > egress > In normal state everything is fine, the bond interfaces are operational. > However when one of the physical interfaces on the hypervisor is brought > down then failover to the standby does not work. > > The second interface in each bond does become primary but original primar= y > is still reported as UP by VPP. The device stats reported by VPP change t= o > around maximum values and traffic no longer works through the bond > interfaces: > > Name Idx Link Hardware > BondEthernet0 5 up Slave-Idx: 1 2 > Ethernet address fa:16:3e:20:2c:ae > Ethernet Bonding > carrier up full duplex speed 1000 mtu 1500 > Mode 1 > rx queues 1, rx desc 1024, tx queues 1, tx desc 4096 > cpu socket 0 > > tx frames ok 8589934243 > tx bytes ok 137438924646 > rx frames ok 8589849574 > rx bytes ok 137433171720 > extended stats: > rx good packets 8589849574 > tx good packets 8589934243 > rx good bytes 137433171720 > tx good bytes 137438924646 > > BondEthernet1 6 up Slave-Idx: 3 4 > Ethernet address fa:16:3e:f2:3c:af > Ethernet Bonding > carrier up full duplex speed 1000 mtu 1500 > Mode 1 > rx queues 1, rx desc 1024, tx queues 1, tx desc 4096 > cpu socket 0 > > tx frames ok 8589934273 > tx bytes ok 137438926918 > rx frames ok 8589849579 > rx bytes ok 137433172132 > extended stats: > rx good packets 8589849579 > tx good packets 8589934273 > rx good bytes 137433172132 > tx good bytes 137438926918 > > device_0/6/0 1 slave device_0/6/0 > Ethernet address fa:16:3e:20:2c:ae > Intel 82599 VF > carrier up full duplex speed 1000 mtu 1500 > Slave UP > Slave State StandBy > rx queues 1, rx desc 1024, tx queues 1, tx desc 4096 > cpu socket 0 > > tx frames ok 4294966950 > tx bytes ok 68719448136 > rx frames ok 4294882284 > rx bytes ok 68713695344 > > device_0/7/0 2 slave device_0/7/0 > Ethernet address fa:16:3e:20:2c:ae > Intel 82599 VF > carrier up full duplex speed 1000 mtu 1500 > Slave UP > Slave State Primary > rx queues 1, rx desc 1024, tx queues 1, tx desc 4096 > cpu socket 0 > > tx frames ok 4294967293 > tx bytes ok 68719476510 > rx frames ok 4294967290 > rx bytes ok 68719476376 > > device_0/8/0 3 slave device_0/8/0 > Ethernet address fa:16:3e:f2:3c:af > Intel 82599 VF > carrier up full duplex speed 1000 mtu 1500 > Slave UP > Slave State StandBy > rx queues 1, rx desc 1024, tx queues 1, tx desc 4096 > cpu socket 0 > > tx frames ok 4294966980 > tx bytes ok 68719450408 > rx frames ok 4294882289 > rx bytes ok 68713695756 > > device_0/9/0 4 slave device_0/9/0 > Ethernet address fa:16:3e:f2:3c:af > Intel 82599 VF > carrier up full duplex speed 1000 mtu 1500 > Slave UP > Slave State Primary > rx queues 1, rx desc 1024, tx queues 1, tx desc 4096 > cpu socket 0 > > tx frames ok 4294967293 > tx bytes ok 68719476510 > rx frames ok 4294967290 > rx bytes ok 68719476376 > > There are no specific errors reported in the /var/log/messages files on > either the VM or the hypervisor machines. > > Any ideas on this issue? Is there a configuration problem, or possibly a > change in a later DPDK version which might be relevant? > > Thanks > > Greg O'Rawe > > > > > This message, including attachments, is CONFIDENTIAL. It may also be > privileged or otherwise protected by law. If you received this email by > mistake please let us know by reply and then delete it from your system; > you should not copy it or disclose its contents to anyone. All messages > sent to and from Enea may be monitored to ensure compliance with internal > policies and to protect our business. Emails are not secure and cannot be > guaranteed to be error free as they can be intercepted, a mended, lost or > destroyed, or contain viruses. The sender therefore does not accept > liability for any errors or omissions in the contents of this message, > which arise as a result of email transmission. Anyone who communicates wi= th > us by email accepts these risks. > > > This message, including attachments, is CONFIDENTIAL. It may also be > privileged or otherwise protected by law. If you received this email by > mistake please let us know by reply and then delete it from your system; > you should not copy it or disclose its contents to anyone. All messages > sent to and from Enea may be monitored to ensure compliance with internal > policies and to protect our business. Emails are not secure and cannot be > guaranteed to be error free as they can be intercepted, a mended, lost or > destroyed, or contain viruses. The sender therefore does not accept > liability for any errors or omissions in the contents of this message, > which arise as a result of email transmission. Anyone who communicates wi= th > us by email accepts these risks. >