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 21:37:11 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Or Gerlitz <or.gerlitz@...il.com>
CC:	John Fastabend <john.r.fastabend@...el.com>,
	David Miller <davem@...emloft.net>,
	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 Mon, 2013-05-20 at 23:06 +0300, Or Gerlitz wrote:
> 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

Definitely, I don't want to derail your proposal.

> 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)?

I think that's a sensible default.

> 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?

The risk I see with extensible operations (and which has occurred with
many ethtool operations) is that drivers may quietly ignore the elements
they don't implement.  So either (1) add yet another specific operation
or (2) define a general VF setter, require drivers to set some flags
that indicate which VF attributes are settable, and check the flags in
rtnetlink.c before calling into the driver.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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