From: "Keller, Jacob E" <jacob.e.keller@intel.com>
To: "Jakub Kicinski" <kuba@kernel.org>, "Íñigo Huguet" <ihuguet@redhat.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Ivan Vecera <ivecera@redhat.com>,
Edward Harold Cree <ecree@xilinx.com>,
"Dinan Gunawardena" <dinang@xilinx.com>,
Pablo Cascon <pabloc@xilinx.com>
Subject: RE: Correct interpretation of VF link-state=auto
Date: Fri, 18 Jun 2021 19:10:00 +0000 [thread overview]
Message-ID: <9a0836b2f5ed487bb7d9c03a4b17222f@intel.com> (raw)
In-Reply-To: <20210618093506.245a4186@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Friday, June 18, 2021 9:35 AM
> To: Íñigo Huguet <ihuguet@redhat.com>
> Cc: netdev@vger.kernel.org; Ivan Vecera <ivecera@redhat.com>; Edward Harold
> Cree <ecree@xilinx.com>; Dinan Gunawardena <dinang@xilinx.com>; Pablo
> Cascon <pabloc@xilinx.com>
> Subject: Re: Correct interpretation of VF link-state=auto
>
> On Tue, 15 Jun 2021 12:34:00 +0200 Íñigo Huguet wrote:
> > Hi,
> >
> > Regarding link-state attribute for a VF, 'man ip-link' says:
> > state auto|enable|disable - set the virtual link state as seen by the
> > specified VF. Setting to auto means a reflection of the PF link state,
> > enable lets the VF to communicate with other VFs on this host even if
> > the PF link state is down, disable causes the HW to drop any packets
> > sent by the VF.
> >
> > However, I've seen that different interpretations are made about that
> > explanation, especially about "auto" configuration. It is not clear if
> > it should follow PF "physical link status" or PF "administrative link
> > status". With the latter, `ip set PF down` would put the VF down too,
> > but with the former you'd have to disconnect the physical port.
>
> Like all legacy SR-IOV networking the correct thing to do here is clear
> as mud. I'd go for the link status of the PF netdev. If the netdev
> cannot pass traffic (either for administrative or physical link reasons)
> then VFs shouldn't talk either. But as I said, every vendor will have their
> own interpretation, and different users may expect different things...
I like this interpretation too.. but I agree that it's unfortunately confusing and each vendor has done something different.. :(
next prev parent reply other threads:[~2021-06-18 19:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 10:34 Correct interpretation of VF link-state=auto Íñigo Huguet
2021-06-18 15:21 ` Íñigo Huguet
2021-06-18 16:35 ` Jakub Kicinski
2021-06-18 19:10 ` Keller, Jacob E [this message]
2021-06-21 15:12 ` Íñigo Huguet
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=9a0836b2f5ed487bb7d9c03a4b17222f@intel.com \
--to=jacob.e.keller@intel.com \
--cc=dinang@xilinx.com \
--cc=ecree@xilinx.com \
--cc=ihuguet@redhat.com \
--cc=ivecera@redhat.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabloc@xilinx.com \
/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).