On 10/26/2023 3:45 PM, Florian Fainelli wrote:
> In preparation for iterating over RXNFC rules for a different purpose,
> factor the generic code that already does that by allowing a callback to
> be specified. The body of ethtool_get_max_rxnfc_channel() now accepts a
> callback as an argument and is renamed to __ethtool_for_each_rxnfc().
>
> Signed-off-by: Florian Fainelli <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
On 10/26/2023 3:45 PM, Florian Fainelli wrote:
> A driver implementing WAKE_FILTER must first install at least one rule
> with RX_CLS_FLOW_WAKE for WAKE_FILTER to be effective. Iterate over
> RXNFC rules to validate that condition while trying to enable
> WAKE_FILTER.
>
Makes sense to enforce this.
Reviewed-by: Jacob Keller <[email protected]>
On 10/26/2023 3:45 PM, Florian Fainelli wrote:
> +EXPORT_SYMBOL(phy_ethtool_set_rxnfc);
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 3cc52826f18e..03e7c6352aef 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -1077,6 +1077,10 @@ struct phy_driver {
> int (*get_sqi)(struct phy_device *dev);
> /** @get_sqi_max: Get the maximum signal quality indication */
> int (*get_sqi_max)(struct phy_device *dev);
> + /* Used for WAKE_FILTER programming only */
Any particular reason this comment is required? I don't see it enforced
above so I'm curious.
> + int (*get_rxnfc)(struct phy_device *dev,
> + struct ethtool_rxnfc *nfc, u32 *rule_locs);
> + int (*set_rxnfc)(struct phy_device *dev, struct ethtool_rxnfc *nfc);
>
> /* PLCA RS interface */
> /** @get_plca_cfg: Return the current PLCA configuration */
> @@ -1989,6 +1993,10 @@ int phy_ethtool_set_plca_cfg(struct phy_device *phydev,
> struct netlink_ext_ack *extack);
> int phy_ethtool_get_plca_status(struct phy_device *phydev,
> struct phy_plca_status *plca_st);
> +int phy_ethtool_get_rxnfc(struct phy_device *phydev,
> + struct ethtool_rxnfc *nfc, u32 *rule_locs);
> +int phy_ethtool_set_rxnfc(struct phy_device *phydev,
> + struct ethtool_rxnfc *nfc);
>
> int __phy_hwtstamp_get(struct phy_device *phydev,
> struct kernel_hwtstamp_config *config);
On 10/26/2023 3:45 PM, Florian Fainelli wrote:
> Since the PHY is capable of matching any arbitrary Ethernet MAC
> destination as a programmable wake-up pattern, add support for doing
> that using the WAKE_FILTER and ethtool::rxnfc API. For instance, in
> order to wake-up from the Ethernet MAC address corresponding to the IPv4
> multicast IP address of 224.0.0.251 (e.g.: multicast DNS), one could do:
>
> ethtool -N eth0 flow-type ether dst 01:00:5e:00:00:fb loc 0 action -2
> ethtool -n eth0
> Total 1 rules
>
> Filter: 0
> Flow Type: Raw Ethernet
> Src MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF
> Dest MAC addr: 01:00:5E:00:00:FB mask: 00:00:00:00:00:00
> Ethertype: 0x0 mask: 0xFFFF
> Action: Wake-on-LAN
> ethtool -s eth0 wol f
>
> Signed-off-by: Florian Fainelli <[email protected]>
> ---
Reviewed-by: Jacob Keller <[email protected]>
On 10/26/2023 3:45 PM, Florian Fainelli wrote:
> Determine whether the PHY can support waking up from the user programmed
> network filter, and if it can utilize it.
>
Here, you're passing through to phy_ethtool_set_rxnfc, basically
allowing the lower device to program the wakeup filter if its supported. Ok.
This almost feels like it would belong generally in the higher level
ethtool code rather than in the driver?
Thanks,
Jake
On 10/26/23 16:20, Jacob Keller wrote:
>
>
> On 10/26/2023 3:45 PM, Florian Fainelli wrote:
>> +EXPORT_SYMBOL(phy_ethtool_set_rxnfc);
>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>> index 3cc52826f18e..03e7c6352aef 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -1077,6 +1077,10 @@ struct phy_driver {
>> int (*get_sqi)(struct phy_device *dev);
>> /** @get_sqi_max: Get the maximum signal quality indication */
>> int (*get_sqi_max)(struct phy_device *dev);
>> + /* Used for WAKE_FILTER programming only */
>
> Any particular reason this comment is required? I don't see it enforced
> above so I'm curious.
The comment is not required, though I put it in there to help readers
understand that this is purely for use by Wake-on-LAN, since unlike a
MACs, PHYs are not capable of redirecting certain flows to certain
queues, too low in the packet processing that there is not a notion of a
queue at that point (FIFO yes, but not queue as in what the networking
stack wants to use).
--
Florian
On 10/26/23 16:23, Jacob Keller wrote:
>
>
> On 10/26/2023 3:45 PM, Florian Fainelli wrote:
>> Determine whether the PHY can support waking up from the user programmed
>> network filter, and if it can utilize it.
>>
>
> Here, you're passing through to phy_ethtool_set_rxnfc, basically
> allowing the lower device to program the wakeup filter if its supported. Ok.
>
> This almost feels like it would belong generally in the higher level
> ethtool code rather than in the driver?
Agreed, as Doug just pointed out to me, there is still an open question
about reconciling the PHY and the MAC RXNFC spaces into a single
ethtool_rxnfc structure.
An ideal goal is to have zero modifications to neither the MAC or the
PHY drivers such that they can both work in their own spaces as if they
were alone, or combined.
I suppose that if we get the number of supported rules from the MAC
first, and then get the supported number of rules from the PHY next, we
could do something like this:
rule index
| 0|
| .| -> MAC rules
|15|
|16| -> PHY rule
and each of the MAC or the PHY {get,set}_rxnfc() operate within a base
rule number which is relative to their own space. So the MAC driver
would continue to care about its (max..first) - base (0) range, and the
PHY would care about (max..first) - base (16).
Though then the issue is discoverability, how do you know which rule
location is backed by which hardware block. We could create an
intermediate and inert rule at index 16 for instance that acts as a
delimiter?
Or we could create yet another RX_CLS_LOC_* value that is "special" and
can denote whether of the MAC or the PHY we should be targeting
whichever is supported, but that does not usually lend itself to being
logically ORed with the existing RX_CLS_LOC_* values. WDYT?
pw-bot: cr
--
Florian
On Thu, 26 Oct 2023 15:45:07 -0700 Florian Fainelli wrote:
> Ethernet MAC drivers supporting Wake-on-LAN using programmable filters
> (WAKE_FILTER) typically configure such programmable filters using the
> ethtool::set_rxnfc API and with a sepcial RX_CLS_FLOW_WAKE to indicate
> the filter is also wake-up capable.
Should we explicitly check for WAKE? WAKE, and DISC are probably the
only values that make sense for PHY nfc?
On 10/26/2023 4:52 PM, Florian Fainelli wrote:
> On 10/26/23 16:23, Jacob Keller wrote:
>>
>>
>> On 10/26/2023 3:45 PM, Florian Fainelli wrote:
>>> Determine whether the PHY can support waking up from the user programmed
>>> network filter, and if it can utilize it.
>>>
>>
>> Here, you're passing through to phy_ethtool_set_rxnfc, basically
>> allowing the lower device to program the wakeup filter if its supported. Ok.
>>
>> This almost feels like it would belong generally in the higher level
>> ethtool code rather than in the driver?
>
> Agreed, as Doug just pointed out to me, there is still an open question
> about reconciling the PHY and the MAC RXNFC spaces into a single
> ethtool_rxnfc structure.
>
> An ideal goal is to have zero modifications to neither the MAC or the
> PHY drivers such that they can both work in their own spaces as if they
> were alone, or combined.
>
> I suppose that if we get the number of supported rules from the MAC
> first, and then get the supported number of rules from the PHY next, we
> could do something like this:
>
> rule index
> | 0|
> | .| -> MAC rules
> |15|
> |16| -> PHY rule
>
> and each of the MAC or the PHY {get,set}_rxnfc() operate within a base
> rule number which is relative to their own space. So the MAC driver
> would continue to care about its (max..first) - base (0) range, and the
> PHY would care about (max..first) - base (16).
>
> Though then the issue is discoverability, how do you know which rule
> location is backed by which hardware block. We could create an
> intermediate and inert rule at index 16 for instance that acts as a
> delimiter?
>
> Or we could create yet another RX_CLS_LOC_* value that is "special" and
> can denote whether of the MAC or the PHY we should be targeting
> whichever is supported, but that does not usually lend itself to being
> logically ORed with the existing RX_CLS_LOC_* values. WDYT?
>
> pw-bot: cr
Ah, yea there is a lot of complexity to consider here.
I'm not entirely sure what we should do here. What about extending with
another attribute entirely instead of another bit in RX_CLS_LOC?
On 10/26/2023 4:32 PM, Florian Fainelli wrote:
> On 10/26/23 16:20, Jacob Keller wrote:
>>
>>
>> On 10/26/2023 3:45 PM, Florian Fainelli wrote:
>>> +EXPORT_SYMBOL(phy_ethtool_set_rxnfc);
>>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>>> index 3cc52826f18e..03e7c6352aef 100644
>>> --- a/include/linux/phy.h
>>> +++ b/include/linux/phy.h
>>> @@ -1077,6 +1077,10 @@ struct phy_driver {
>>> int (*get_sqi)(struct phy_device *dev);
>>> /** @get_sqi_max: Get the maximum signal quality indication */
>>> int (*get_sqi_max)(struct phy_device *dev);
>>> + /* Used for WAKE_FILTER programming only */
>>
>> Any particular reason this comment is required? I don't see it enforced
>> above so I'm curious.
>
> The comment is not required, though I put it in there to help readers
> understand that this is purely for use by Wake-on-LAN, since unlike a
> MACs, PHYs are not capable of redirecting certain flows to certain
> queues, too low in the packet processing that there is not a notion of a
> queue at that point (FIFO yes, but not queue as in what the networking
> stack wants to use).
Ah, right that makes sense. Thanks for the clarification.
Perhaps we could enforce that in the interface so that if something does
try to pass a different kind of filter to the phy_rxnfc it would fail or
complain somehow? Because that seems like it would be a programming mistake.
I guess with the current implementation you effectively rely on
returning -EOPNOTSUP for non-wake filters since the driver forwards the
filter to the PHY to check whether it can support it.
Thanks,
Jake
On 10/27/23 09:55, Jacob Keller wrote:
>
>
> On 10/26/2023 4:52 PM, Florian Fainelli wrote:
>> On 10/26/23 16:23, Jacob Keller wrote:
>>>
>>>
>>> On 10/26/2023 3:45 PM, Florian Fainelli wrote:
>>>> Determine whether the PHY can support waking up from the user programmed
>>>> network filter, and if it can utilize it.
>>>>
>>>
>>> Here, you're passing through to phy_ethtool_set_rxnfc, basically
>>> allowing the lower device to program the wakeup filter if its supported. Ok.
>>>
>>> This almost feels like it would belong generally in the higher level
>>> ethtool code rather than in the driver?
>>
>> Agreed, as Doug just pointed out to me, there is still an open question
>> about reconciling the PHY and the MAC RXNFC spaces into a single
>> ethtool_rxnfc structure.
>>
>> An ideal goal is to have zero modifications to neither the MAC or the
>> PHY drivers such that they can both work in their own spaces as if they
>> were alone, or combined.
>>
>> I suppose that if we get the number of supported rules from the MAC
>> first, and then get the supported number of rules from the PHY next, we
>> could do something like this:
>>
>> rule index
>> | 0|
>> | .| -> MAC rules
>> |15|
>> |16| -> PHY rule
>>
>> and each of the MAC or the PHY {get,set}_rxnfc() operate within a base
>> rule number which is relative to their own space. So the MAC driver
>> would continue to care about its (max..first) - base (0) range, and the
>> PHY would care about (max..first) - base (16).
>>
>> Though then the issue is discoverability, how do you know which rule
>> location is backed by which hardware block. We could create an
>> intermediate and inert rule at index 16 for instance that acts as a
>> delimiter?
>>
>> Or we could create yet another RX_CLS_LOC_* value that is "special" and
>> can denote whether of the MAC or the PHY we should be targeting
>> whichever is supported, but that does not usually lend itself to being
>> logically ORed with the existing RX_CLS_LOC_* values. WDYT?
>>
>> pw-bot: cr
>
> Ah, yea there is a lot of complexity to consider here.
Yes this is only the tip of iceberg! Here is hopefully a better
description of our particular system where this is being requested (the
fact there is a single one also makes me question the entire effort, but
anyway). We have 2 distinct system sleep modes:
- akin to ACPI S2 where the Ethernet PHY and MAC remain enabled and both
can be used for Wake-on-LAN filtering, with the MAC being more capable
than the PHY. System power consumption is just around 500mW at the wall.
In that case it would make sense to leverage the MAC's capability
because it is better and would lead to fewer false wake-ups
- akin to ACPI S3 where the Ethernet PHY only remains enabled, the MAC
is powered off (as is most of the SoC), but we have limited Wake-on-LAN
capability in the form of network filter as we can only match on a
custom MAC DA + mask. System power consumption is closer to 350mW at the
wall.
My users are not really willing to use the broad WAKE_MCAST because they
want to match specifically on mDNS over IPv4 (or IPv6), so they prefer
to program an exact match to limit the amount of false wake-ups.
Arguably there will already be quite a lot in home network due to
phones, IoT devices, and whatnot.
From an user perspective they would know which system standby state is
being entered so one could imagine that ahead of entry, we could
configure either the MAC, or the PHY when targeting S2, or just the PHY
when targeting S3. This implies that we can selectively target one
entity, or the other.
For the current time being, and knowing the use case of my users,
directing all of the Wake-on-LAN configuration towards the PHY would be
enough IMHO, even if that means we stop leveraging the MAC capabilities,
hence this patch series.
>
> I'm not entirely sure what we should do here. What about extending with
> another attribute entirely instead of another bit in RX_CLS_LOC?
Yes possibly, or we just target different objects, right now we have
visibility into the MACs via the net_device, it seems like we ought to
be able to target some ethtool APIs towards PHY objects, which currently
have no netlink representation. There is on-going work to bridge that gap:
https://lore.kernel.org/netdev/[email protected]/T/
but I am not sure we will reach an agreement any time soon. Maybe I can
convince my masters to wait for that to land and use WAKE_MCAST in the
meantime.
I would not necessary want to invent a new set of ethtool commands and
kernel APIs such that we could do the below examples, though maybe this
is not incompatible with the work being done by Maxime:
# Target the Ethernet MAC
ethtool -N eth0 flow-type ether dst 01:00:5e:00:00:fb loc 0 action -2 #
Assumes MAC by default
ethtool -N eth0 flow-type ether dst 01:00:5e:00:00:fb loc 0 action -2
target mac
# Target the Ethernet PHY, if capable
ethtool -N eth0 flow-type ether dst 01:00:5e:00:00:fb loc 0 action -2
target phy
# Enable WAKE_FILTER at the MAC level
ethtool -s eth0 wol f # assumes MAC by default
ethtool -s eth0 wol f target mac
# Enable WAKE_FILTER at the PHY level, if capable
ethtool -s eth0 wol f target phy
though maybe this is the much needed addition to ethtool so we can be
more selective.
After a bunch of candies on Tuesday I might reach a state of trance and
figure which way to proceed :D
--
Florian
On 10/27/2023 10:15 AM, Florian Fainelli wrote:
> On 10/27/23 09:55, Jacob Keller wrote:
>>
>>
>> On 10/26/2023 4:52 PM, Florian Fainelli wrote:
>>> On 10/26/23 16:23, Jacob Keller wrote:
>>>>
>>>>
>>>> On 10/26/2023 3:45 PM, Florian Fainelli wrote:
>>>>> Determine whether the PHY can support waking up from the user programmed
>>>>> network filter, and if it can utilize it.
>>>>>
>>>>
>>>> Here, you're passing through to phy_ethtool_set_rxnfc, basically
>>>> allowing the lower device to program the wakeup filter if its supported. Ok.
>>>>
>>>> This almost feels like it would belong generally in the higher level
>>>> ethtool code rather than in the driver?
>>>
>>> Agreed, as Doug just pointed out to me, there is still an open question
>>> about reconciling the PHY and the MAC RXNFC spaces into a single
>>> ethtool_rxnfc structure.
>>>
>>> An ideal goal is to have zero modifications to neither the MAC or the
>>> PHY drivers such that they can both work in their own spaces as if they
>>> were alone, or combined.
>>>
>>> I suppose that if we get the number of supported rules from the MAC
>>> first, and then get the supported number of rules from the PHY next, we
>>> could do something like this:
>>>
>>> rule index
>>> | 0|
>>> | .| -> MAC rules
>>> |15|
>>> |16| -> PHY rule
>>>
>>> and each of the MAC or the PHY {get,set}_rxnfc() operate within a base
>>> rule number which is relative to their own space. So the MAC driver
>>> would continue to care about its (max..first) - base (0) range, and the
>>> PHY would care about (max..first) - base (16).
>>>
>>> Though then the issue is discoverability, how do you know which rule
>>> location is backed by which hardware block. We could create an
>>> intermediate and inert rule at index 16 for instance that acts as a
>>> delimiter?
>>>
>>> Or we could create yet another RX_CLS_LOC_* value that is "special" and
>>> can denote whether of the MAC or the PHY we should be targeting
>>> whichever is supported, but that does not usually lend itself to being
>>> logically ORed with the existing RX_CLS_LOC_* values. WDYT?
>>>
>>> pw-bot: cr
>>
>> Ah, yea there is a lot of complexity to consider here.
>
> Yes this is only the tip of iceberg! Here is hopefully a better
> description of our particular system where this is being requested (the
> fact there is a single one also makes me question the entire effort, but
> anyway). We have 2 distinct system sleep modes:
>
> - akin to ACPI S2 where the Ethernet PHY and MAC remain enabled and both
> can be used for Wake-on-LAN filtering, with the MAC being more capable
> than the PHY. System power consumption is just around 500mW at the wall.
> In that case it would make sense to leverage the MAC's capability
> because it is better and would lead to fewer false wake-ups
>
> - akin to ACPI S3 where the Ethernet PHY only remains enabled, the MAC
> is powered off (as is most of the SoC), but we have limited Wake-on-LAN
> capability in the form of network filter as we can only match on a
> custom MAC DA + mask. System power consumption is closer to 350mW at the
> wall.
>
> My users are not really willing to use the broad WAKE_MCAST because they
> want to match specifically on mDNS over IPv4 (or IPv6), so they prefer
> to program an exact match to limit the amount of false wake-ups.
> Arguably there will already be quite a lot in home network due to
> phones, IoT devices, and whatnot.
>
> From an user perspective they would know which system standby state is
> being entered so one could imagine that ahead of entry, we could
> configure either the MAC, or the PHY when targeting S2, or just the PHY
> when targeting S3. This implies that we can selectively target one
> entity, or the other.
>
> For the current time being, and knowing the use case of my users,
> directing all of the Wake-on-LAN configuration towards the PHY would be
> enough IMHO, even if that means we stop leveraging the MAC capabilities,
> hence this patch series.
>
Right.
>>
>> I'm not entirely sure what we should do here. What about extending with
>> another attribute entirely instead of another bit in RX_CLS_LOC?
>
> Yes possibly, or we just target different objects, right now we have
> visibility into the MACs via the net_device, it seems like we ought to
> be able to target some ethtool APIs towards PHY objects, which currently
> have no netlink representation. There is on-going work to bridge that gap:
>
> https://lore.kernel.org/netdev/[email protected]/T/
>
> but I am not sure we will reach an agreement any time soon. Maybe I can
> convince my masters to wait for that to land and use WAKE_MCAST in the
> meantime.
>
Sure, but this obviously costs a potentially significant amount of extra
power, and it would be better to avoid that.
> I would not necessary want to invent a new set of ethtool commands and
> kernel APIs such that we could do the below examples, though maybe this
> is not incompatible with the work being done by Maxime:
>
> # Target the Ethernet MAC
> ethtool -N eth0 flow-type ether dst 01:00:5e:00:00:fb loc 0 action -2 #
> Assumes MAC by default
> ethtool -N eth0 flow-type ether dst 01:00:5e:00:00:fb loc 0 action -2
> target mac
>
> # Target the Ethernet PHY, if capable
> ethtool -N eth0 flow-type ether dst 01:00:5e:00:00:fb loc 0 action -2
> target phy
>
> # Enable WAKE_FILTER at the MAC level
> ethtool -s eth0 wol f # assumes MAC by default
> ethtool -s eth0 wol f target mac
>
> # Enable WAKE_FILTER at the PHY level, if capable
> ethtool -s eth0 wol f target phy
>
> though maybe this is the much needed addition to ethtool so we can be
> more selective.
>
> After a bunch of candies on Tuesday I might reach a state of trance and
> figure which way to proceed :D
It does seem like an acceptable compromise here, and perhaps being
driver specific is ok, since this does depend a lot on the individual
device support, thus broadly applying this across all drivers could be
problematic.
I like the idea of being able to more precisely target the rules so that
its clear to userspace what is being done... but I also understand the
challenge of wanting to deliver what feels like a small win and being
asked to do something much larger.
> It does seem like an acceptable compromise here, and perhaps being
> driver specific is ok, since this does depend a lot on the individual
> device support, thus broadly applying this across all drivers could be
> problematic.
The Marvell PHYs have a similar capability. Its actually more feature
rich. It allows upto 8 matches, each being of up to 128 bytes, and you
can enable/disable each byte within the 128 bytes. This would in fact
be better for Florian's use case, since it could match deeper into the
frame and reduce the false positive. But its a Marvell device...
My real point is, other hardware does have similar capabilities. Its
unclear if anybody else will ever actually need it, but we should try
to avoid a one device solution.
Andrew