[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FC41C24E35F18A40888AACA1A36F3E418ADD6433@fmsmsx115.amr.corp.intel.com>
Date: Sun, 18 Jan 2015 23:26:03 +0000
From: "Nelson, Shannon" <shannon.nelson@...el.com>
To: Yuval Mintz <Yuval.Mintz@...gic.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
David Miller <davem@...emloft.net>
CC: netdev <netdev@...r.kernel.org>,
"nhorman@...hat.com" <nhorman@...hat.com>,
"sassmann@...hat.com" <sassmann@...hat.com>,
"jogreene@...hat.com" <jogreene@...hat.com>
Subject: RE: [net-next v2 13/15] i40e: limit WoL and link settings to
partition 1
> From: Yuval Mintz [mailto:Yuval.Mintz@...gic.com]
> Sent: Saturday, January 17, 2015 10:10 PM
>
> >From: Shannon Nelson <shannon.nelson@...el.com>
>
> >When in multi-function mode, e.g. Dell's NPAR, only partition 1
> >of each MAC is allowed to set WoL, speed, and flow control.
>
> Isn't it problematic? I mean, in bnx2x we address ~same issue -
> but due to symmetry we prevent ALL interfaces from changing
> the link configuration.
Yes, this multi-function hardware port makes for "interesting opportunities" in hardware configuration. In our case, our requirements are to still allow for configuration of the hardware port. This is not unlike how a PF controls the physical port for its VF devices.
>
> How can user be aware of this 'private' behavior? via system logs?
> documentation?
In this case, note that we have added a log message that says these are dependent on the initial partition of the port for setting control. Also, the particular vendor using the device in this configuration will supply and support the user documentation.
>
> How does it interact with Physical Device Assignment of the first
> partition?
I'm not sure I understand this question, but I'll answer a different question: these multifunction ports show up as additional PCI functions, again, not unlike VF devices.
>
> Cheers,
> Yuval
sln
--
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
Powered by blists - more mailing lists