On Thu, 6 Dec 2018 00:57:05 -0800, Michael Chan wrote: > On Wed, Dec 5, 2018 at 11:11 PM Jakub Kicinski wrote: > > > > On Wed, 5 Dec 2018 22:41:43 -0800, Michael Chan wrote: > > > > > > It will be in the BIOS only for a LOM, I think. For a NIC, it should > > > be in the NIC's NVRAM. > > > > This is all vague. Could you please clearly state the use case. > > > Well, the WoL setting's use case should be quite simple, right? If > the card's NVRAM WoL setting is ON, when you plug the card in a slot > that has Vaux power, it will assert PME# when a magic packet is > received. Again, the WoL setting in this context is similar to other > power up settings such as PCIe Gen2 or Gen3.
If there was some configuration of PME# involved, maybe, but basic networking configuration has its APIs already. > Let's say the power up setting is ON and it boots up to Linux for the > first time after receiving a magic packet. The Linux user can then > run ethtool -s to set the driver's non persistent WoL setting. It can > be the same as the NVRAM's power up setting, or different. Ethtool > may support additional WoL packet types that the power up setting does > not support. Let's say the Linux user sets the ethtool WoL setting to > OFF and shuts down the system. That card now will not wake up the > system. But if there is a power failure and power comes back on > later, the card will lose the ethtool setting and go back to the power > up WoL setting, which is ON in this example. So in your example there is a machine with a 25/40/100G NIC that doesn't have any remote BMC control, and connected to a L2 network where a magic packet can be received. In my experience machines are either low end/embedded and they just boot on power on fully (to Linux), or they are proper machines which support IPMI etc. If you could illuminate the use case some more I'd really appreciate that. In your hypothetical scenario you still have to get the link up, so if we apply this patch a logical extension would be to add all ethtool link settings as devlink parameters as well. Florian recently added an option to wake based on a packet that matched an n-tuple filter. If your use case is legit, doing the same thing with n-tuple filters instead of Magic Packets is very much legit, too. So we will poke n-tuple filters via devlink params?
