From: bharath paulraj <bharathpaul@gmail.com>
To: dev@dpdk.org
Cc: "Paulraj, Bharath" <bpaulraj@idirect.net>
Subject: Reg: Link Bonding of VFs and PF admin down
Date: Wed, 29 Mar 2023 12:27:16 +0530 [thread overview]
Message-ID: <CACfjA+mxao7A0Mo31S-TPE3kTRp6AtabZc+c5e5rf+WoWER8rA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1595 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, 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
[-- Attachment #2: Type: text/html, Size: 2232 bytes --]
next reply other threads:[~2023-03-29 6:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 6:57 bharath paulraj [this message]
2023-03-29 15:31 ` Stephen Hemminger
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=CACfjA+mxao7A0Mo31S-TPE3kTRp6AtabZc+c5e5rf+WoWER8rA@mail.gmail.com \
--to=bharathpaul@gmail.com \
--cc=bpaulraj@idirect.net \
--cc=dev@dpdk.org \
/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).