On Thu, Dec 6, 2018 at 2:37 AM Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > > 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?
We only store a magic packet WoL bit in the NVRAM for basic power up WoL setting. I doubt that people will store the entire n-tuple WoL pattern in NVRAM for basic power up WoL. The whole idea is to have a basic method to wake up the machine after power up with Vaux. If the cable is connected, the NIC will autoneg to some lower speed that Vaux can support. I think we've been supporting this since the tg3 days.
