From: Stephen Hemminger <stephen@networkplumber.org>
To: bharath paulraj <bharathpaul@gmail.com>
Cc: dev@dpdk.org, "Paulraj, Bharath" <bpaulraj@idirect.net>
Subject: Re: Reg: Link Bonding of VFs and PF admin down
Date: Wed, 29 Mar 2023 08:31:26 -0700 [thread overview]
Message-ID: <20230329083126.59c302f3@hermes.local> (raw)
In-Reply-To: <CACfjA+mxao7A0Mo31S-TPE3kTRp6AtabZc+c5e5rf+WoWER8rA@mail.gmail.com>
On Wed, 29 Mar 2023 12:27:16 +0530
bharath paulraj <bharathpaul@gmail.com> wrote:
> 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.
Link state is controlled by Linux kernel driver, the DPDK driver
is just reflecting information from the kernel. Talk to the kernel
maintainers and/or Redhat.
prev parent reply other threads:[~2023-03-29 15:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 6:57 Reg: Link Bonding of VFs and PF admin down bharath paulraj
2023-03-29 15:31 ` Stephen Hemminger [this message]
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=20230329083126.59c302f3@hermes.local \
--to=stephen@networkplumber.org \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.