lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a0836b2f5ed487bb7d9c03a4b17222f@intel.com>
Date:   Fri, 18 Jun 2021 19:10:00 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Íñigo Huguet <ihuguet@...hat.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Ivan Vecera <ivecera@...hat.com>,
        Edward Harold Cree <ecree@...inx.com>,
        "Dinan Gunawardena" <dinang@...inx.com>,
        Pablo Cascon <pabloc@...inx.com>
Subject: RE: Correct interpretation of VF link-state=auto



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, June 18, 2021 9:35 AM
> To: Íñigo Huguet <ihuguet@...hat.com>
> Cc: netdev@...r.kernel.org; Ivan Vecera <ivecera@...hat.com>; Edward Harold
> Cree <ecree@...inx.com>; Dinan Gunawardena <dinang@...inx.com>; Pablo
> Cascon <pabloc@...inx.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.. :(

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ