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, 20 May 2013 23:06:20 +0300
From:	Or Gerlitz <or.gerlitz@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	David Miller <davem@...emloft.net>
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:
> 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).  But then that's going to confuse people too.  I don't think we can win...

>>> Perhaps the default should also be specified?

So can we make progress in steps here... e.g deal with the question
whether the PF exposes one or two netdevices in a future thread and
add now code supporting an admin ability to control VF link state (I
suggest for the default, e.g when no config directive was applied to
be "auto" means follow the PF link state, as was suggested here)? if
we agree on that, do we want new ndo_set_vf_ call or introducr
ndo_set_vf_config call which whose param will be further extended each
time we add new feature to control/configure?

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