From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E9DA34285E; Wed, 29 Mar 2023 08:57:30 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C856E40F18; Wed, 29 Mar 2023 08:57:30 +0200 (CEST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by mails.dpdk.org (Postfix) with ESMTP id E836340EE7 for ; Wed, 29 Mar 2023 08:57:28 +0200 (CEST) Received: by mail-ed1-f46.google.com with SMTP id i5so59438333eda.0 for ; Tue, 28 Mar 2023 23:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680073048; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=n6injmp5PH0/FLOcXhvzZ0tSYCxOvCVyugW5kciMeRI=; b=mMkHE1ji/4KfKzKWksPqgJzuePB1gVcnzkSHx7YQqi0hT0+m7jWZFNW6pK1dNYA1/7 gwhX5Egy8DxU9jq+YIIdoGvhAm2j+fSOGkLAfYJzjo9VchwFU92pnf0CyujDXwNPj+3i PbHra6T38ZI7xKpUSMtv+w9IBHkXU85jYKNDtfwzcPZsMuaiJednFVV0Jg3tFc1h2g63 H6VIPp46xHHqFDggjv+l4et9X65AZsethc4ttr7XGqLy7njN2cM2VLWnXCKSsLzFJh2+ X/83B7KshphMRa18jQMneXZMDuGgRqQqJVI22+iluYLplPkDNIVj7YStEHHibYvsk0ox ueXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680073048; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=n6injmp5PH0/FLOcXhvzZ0tSYCxOvCVyugW5kciMeRI=; b=w0AZmSUBAVQBoqS4O9i3dwFLKScZnFnzmMWjamq5Ox/VosgBVpolHRPtcTPQahUytx 01EvxMXgdc1G7hBbHlRFo96oVQ2PzpCz6NU9qUEAfoaihyaKUaRQYgOZkLMFIhUN/dEP /ZQ1lENgcepBPHQCDEHvhCW5Kl+bwbol1t6VZYUcDd7QSlF28+sxX3ZLfBdMl2fGe0M8 HCAHyOD8Ko+O0XhQ8TbBoFCn4V/HVmjCtHUZ70EVLr11077LBFY+lnCgLp+J2R1n5YoC 5DlaMIsGq5hlDWikaEIj8NzUal/Iq11EZHJt0oSz/02ULTpu7npUNMgTPhQ6bisfmEXX d/8Q== X-Gm-Message-State: AAQBX9f2wAUkRCZodKR8SOx9RSkPZJHqYdfxmGzzP9XzcyO6S8cox8oC mw+O/6B2bz2BIJCRUWmCJxeM92c9Xcs2jWipyOJ93KaA0qA= X-Google-Smtp-Source: AKy350Yh2KV/f7Xzggu4hBjHatfMZuwji97H+FYwfgGcmZJzxRLJLHQruYTLLNWCLGbRK6rtbv2rILbgrmRJZlDnS/0= X-Received: by 2002:a50:f69e:0:b0:4fc:8749:cd77 with SMTP id d30-20020a50f69e000000b004fc8749cd77mr9229593edn.3.1680073048092; Tue, 28 Mar 2023 23:57:28 -0700 (PDT) MIME-Version: 1.0 From: bharath paulraj Date: Wed, 29 Mar 2023 12:27:16 +0530 Message-ID: Subject: Reg: Link Bonding of VFs and PF admin down To: dev@dpdk.org Cc: "Paulraj, Bharath" Content-Type: multipart/alternative; boundary="0000000000003a72ad05f8047d86" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000003a72ad05f8047d86 Content-Type: text/plain; charset="UTF-8" Hello Team, I have two X710 NICs in the hypervisor and created the VFs on those NICs. PF is managed by the Linux kernel, while the VF is managed by DPDK. I am using the "test-pmd" application to test the bonding functionality, especially ACTIVE-BACKUP mode. I have created the bond interface and added the slaves in such a way that the one VFs from each of the PF is added to the bond interface. The goal is to achieve uninterrupted traffic flow even when one of the PF is down. As part of my testing, I made one of the PF admin down using the command "ip link set down". Even after waiting for a few minutes, the link status is not propagated to the VF, and the link bonding still takes the PF which is down as the primary slave and tries to send the packet out of that interface. While debugging I found out that the link status of VF is still up. Is this the expected behaviour? As per the link: https://www.intel.in/content/www/in/en/support/articles/000036776/ethernet-products.html it is the expected behaviour. It may work well if the use case is VF-to-VF communication. But if the use case is to communicate to the other system - (Switch/Routers), then this behaviour will break the link bonding functionality, as the peer's interface would be operationally down, once the PF is made admin down. My use case: PF is managed by Linux kernel is connected to the external Router, VF is added to the VM, and the DPDK application is supposed to send/read the packet from the VF. DPDK version used: DPDK-22.11.1 OS: centos-7 Let me know your thoughts. -- Regards, Bharath --0000000000003a72ad05f8047d86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Team,

I hav= e two X710 NICs=20 in the hypervisor and created the VFs on those NICs. PF is managed by=20 the Linux kernel, while the VF is managed by DPDK. I am using the=20 "test-pmd" application to test the bonding functionality, especia= lly=20 ACTIVE-BACKUP mode.
I have created the bond interface and=20 added the slaves in such a way that the one VFs from each of the PF is=20 added to the bond interface. The goal is to achieve uninterrupted=20 traffic flow even when one of the PF is down.
As part of my=20 testing, I made one of the PF admin down using the command "ip link se= t=20 <interface> down". Even after waiting for a few minutes, the lin= k=20 status is not propagated to the VF, and the link bonding still takes the PF which is down as the primary slave and tries to send the packet out=20 of that interface.

While=20 debugging I found out that the link status of VF is still up. Is this=20 the expected behaviour? As per the link:=20 https://www.intel.in/content/www/in/en/support/ar= ticles/000036776/ethernet-products.html it is the expected behaviour. It may work well if the use case is=20 VF-to-VF communication. But if the use case is to communicate to the=20 other system - (Switch/Routers), then this behaviour will break the link bonding functionality, as the peer's interface would be operationally = down, once the PF is made admin down.


My=20 use case: =C2=A0PF is managed by Linux kernel is connected to the external= =20 Router, VF is added to the VM, and the DPDK application is supposed to=20 send/read the packet from the VF.

DPDK version use= d: DPDK-22.11.1
OS: centos-7
<= br aria-hidden=3D"true">
Let me know your thoughts.


--
Regards,
Bharath
--0000000000003a72ad05f8047d86--