From: "Paulraj, Bharath" <bpaulraj@idirect.net>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: "Kumar, Rohit" <rokumar@idirect.net>,
"Eyrich, Michael" <meyr@idirect.net>
Subject: Link Bonding of VFs and PF admin down
Date: Tue, 28 Mar 2023 08:51:54 +0000 [thread overview]
Message-ID: <SN7PR22MB402752FC1DA530B115A80DA2DC889@SN7PR22MB4027.namprd22.prod.outlook.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]
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 <interface> 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.
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.
Let me know your thoughts.
Thanks,
Bharath
This electronic message and any files transmitted with it contains information from ST Engineering iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender.
[-- Attachment #2: Type: text/html, Size: 2541 bytes --]
reply other threads:[~2023-03-28 14:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SN7PR22MB402752FC1DA530B115A80DA2DC889@SN7PR22MB4027.namprd22.prod.outlook.com \
--to=bpaulraj@idirect.net \
--cc=dev@dpdk.org \
--cc=meyr@idirect.net \
--cc=rokumar@idirect.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).