netdev - Re: [PATCH RFC 0/2] Control VF link state

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]

Date:	Mon, 13 May 2013 00:48:22 +0300
From:	Or Gerlitz <or.gerlitz@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	Or Gerlitz <ogerlitz@...lanox.com>, netdev@...r.kernel.org,
	amirv@...lanox.com, ronye@...lanox.com
Subject: Re: [PATCH RFC 0/2] Control VF link state

On Fri, May 10, 2013 at 3:34 AM, Ben Hutchings
<bhutchings@...arflare.com> wrote:
> On Fri, 2013-05-10 at 02:17 +0300, Or Gerlitz wrote:
> > On Thu, May 9, 2013 at 6:24 PM, Ben Hutchings <bhutchings@...arflare.com> wrote:
> > >
> > > On Wed, 2013-05-08 at 16:45 +0300, Or Gerlitz wrote:
> > > > Here's a suggestion for API and implementation that lets the admin to
> > > > configure
> > > > the link state of the VF / SRIOV eSwitch vPORT. Basically, it has three
> > > > states
> > > >
> > > > Auto -        the VF link state will reflect the PF link state
> > > >
> > > > Enable - VF link stat will be always up, traffic from VF to VF can
> > > >        work even if PF link is down.
> > >
> > > It seems like it would be useful to implement these two options on the PF as well.
> >
> > You mean that PF <--> VF communication on the same node can be made to
> > work even when the physical link is down? this is a bit problematic to
> > model/implement I think. Generally speaking it makes things easier to
> > grasp if PF is considered to be the uplink of the eSwitch whos link is
> > 1:1 as the physical link, but need to think that a bit more.
>
> Yeah.  In some ways it could be better for a PF driver to create two net
> devices, one which acts as a vswitch port and one which bypasses it (if possible).

That's interesting approach, any rough thoughts what you think it would by us?

> But then that's going to confuse people too.  I don't think we can win...
>
> > > Perhaps the default should also be specified?
> >
> > mmm, not sure if we can require/enforce the same default for all drivers.
>
> I know. :-/  But arbitrary differences between drivers are no fun for sysadmins.

yes, basically, on a production cloud environment, I would say that
before a vport (VF) interface
is configured, e.g ndo_set_vf_yyy is applied for it, we would want the
VF link to be down, but for non
production environments it could be problematic to have down/disabled
as the default... not sure, maybe
the default should be auto and for smart env they would set it to down
before the VF is probed on the VM?

Or.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html