[PATCH] net: ethernet: ti: cpsw_ale: optimize cpsw_ale_restore()

[PATCH] net: ethernet: ti: cpsw_ale: optimize cpsw_ale_restore()

[Roger Quadros]

If an entry was FREE then we don't have to restore it.

Signed-off-by: Roger Quadros <rogerq@kernel.org>
---

Patch depends on
https://lore.kernel.org/netdev/20221104132310.31577-3-rogerq@kernel.org/T/

 drivers/net/ethernet/ti/cpsw_ale.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
index 0c5e783e574c..41bcf34a22f8 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -1452,12 +1452,15 @@ void cpsw_ale_dump(struct cpsw_ale *ale, u32 *data)
 	}
 }
 
+/* ALE table should be cleared (ALE_CLEAR) before cpsw_ale_restore() */
 void cpsw_ale_restore(struct cpsw_ale *ale, u32 *data)
 {
-	int i;
+	int i, type;
 
 	for (i = 0; i < ale->params.ale_entries; i++) {
-		cpsw_ale_write(ale, i, data);
+		type = cpsw_ale_get_entry_type(data);
+		if (type != ALE_TYPE_FREE)
+			cpsw_ale_write(ale, i, data);
 		data += ALE_ENTRY_WORDS;
 	}
 }
-- 
2.17.1

Re: [PATCH] net: ethernet: ti: cpsw_ale: optimize cpsw_ale_restore()

[Jakub Kicinski]

On Tue,  8 Nov 2022 15:56:43 +0200 Roger Quadros wrote:
> If an entry was FREE then we don't have to restore it.

Motivation? Does it make the restore faster?

> Signed-off-by: Roger Quadros <rogerq@kernel.org>
> ---
> 
> Patch depends on
> https://lore.kernel.org/netdev/20221104132310.31577-3-rogerq@kernel.org/T/
> 
>  drivers/net/ethernet/ti/cpsw_ale.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
> index 0c5e783e574c..41bcf34a22f8 100644
> --- a/drivers/net/ethernet/ti/cpsw_ale.c
> +++ b/drivers/net/ethernet/ti/cpsw_ale.c
> @@ -1452,12 +1452,15 @@ void cpsw_ale_dump(struct cpsw_ale *ale, u32 *data)
>  	}
>  }
>  
> +/* ALE table should be cleared (ALE_CLEAR) before cpsw_ale_restore() */

Maybe my tree is old but I see we clear only if there is a netdev that
needs to be opened but then always call ale_restore(). Is that okay?

I'd also s/should/must/ 

>  void cpsw_ale_restore(struct cpsw_ale *ale, u32 *data)
>  {
> -	int i;
> +	int i, type;
>  
>  	for (i = 0; i < ale->params.ale_entries; i++) {
> -		cpsw_ale_write(ale, i, data);
> +		type = cpsw_ale_get_entry_type(data);
> +		if (type != ALE_TYPE_FREE)
> +			cpsw_ale_write(ale, i, data);
>  		data += ALE_ENTRY_WORDS;
>  	}
>  }

Re: [PATCH] net: ethernet: ti: cpsw_ale: optimize cpsw_ale_restore()

[Roger Quadros]

On 10/11/2022 05:19, Jakub Kicinski wrote:
> On Tue,  8 Nov 2022 15:56:43 +0200 Roger Quadros wrote:
>> If an entry was FREE then we don't have to restore it.
> 
> Motivation? Does it make the restore faster?

Yes, since this would be called during system suspend/resume path.
I will update the commit message to mention this.

> 
>> Signed-off-by: Roger Quadros <rogerq@kernel.org>
>> ---
>>
>> Patch depends on
>> https://lore.kernel.org/netdev/20221104132310.31577-3-rogerq@kernel.org/T/
>>
>>  drivers/net/ethernet/ti/cpsw_ale.c | 7 +++++--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
>> index 0c5e783e574c..41bcf34a22f8 100644
>> --- a/drivers/net/ethernet/ti/cpsw_ale.c
>> +++ b/drivers/net/ethernet/ti/cpsw_ale.c
>> @@ -1452,12 +1452,15 @@ void cpsw_ale_dump(struct cpsw_ale *ale, u32 *data)
>>  	}
>>  }
>>  
>> +/* ALE table should be cleared (ALE_CLEAR) before cpsw_ale_restore() */
> 
> Maybe my tree is old but I see we clear only if there is a netdev that

This patch depends on this series
https://lore.kernel.org/netdev/20221104132310.31577-3-rogerq@kernel.org/T/

> needs to be opened but then always call ale_restore(). Is that okay?

If netdev is closed and opened ale_restore() is not called.
ale_restore() is only called during system suspend/resume path
since CPSW-ALE might have lost context during suspend and we want to restore
all valid ALE entries.

I have a question here. How should ageable entries be treated in this case?

> 
> I'd also s/should/must/ 

OK, will fix.

> 
>>  void cpsw_ale_restore(struct cpsw_ale *ale, u32 *data)
>>  {
>> -	int i;
>> +	int i, type;
>>  
>>  	for (i = 0; i < ale->params.ale_entries; i++) {
>> -		cpsw_ale_write(ale, i, data);
>> +		type = cpsw_ale_get_entry_type(data);
>> +		if (type != ALE_TYPE_FREE)
>> +			cpsw_ale_write(ale, i, data);
>>  		data += ALE_ENTRY_WORDS;
>>  	}
>>  }
> 

cheers,
-roger

Re: [PATCH] net: ethernet: ti: cpsw_ale: optimize cpsw_ale_restore()

[Jakub Kicinski]

On Thu, 10 Nov 2022 11:39:47 +0200 Roger Quadros wrote:
> > Maybe my tree is old but I see we clear only if there is a netdev that  
> 
> This patch depends on this series
> https://lore.kernel.org/netdev/20221104132310.31577-3-rogerq@kernel.org/T/

I do have those in my tree.

> > needs to be opened but then always call ale_restore(). Is that okay?  
> 
> If netdev is closed and opened ale_restore() is not called.
> ale_restore() is only called during system suspend/resume path
> since CPSW-ALE might have lost context during suspend and we want to restore
> all valid ALE entries.

Ack, what I'm referring to is the contents of am65_cpsw_nuss_resume().

I'm guessing that ALE_CLEAR is expected to be triggered by
cpsw_ale_start().

Assuming above is true and that ALE_CLEAR comes from cpsw_ale_start(),
the call stack is:

 cpsw_ale_start()
 am65_cpsw_nuss_common_open()
 am65_cpsw_nuss_ndo_slave_open()
 am65_cpsw_nuss_resume()

but resume() only calls ndo_slave_open under certain conditions:

        for (i = 0; i < common->port_num; i++) {                                  
                if (netif_running(ndev)) {                                      
                        rtnl_lock();                                            
                        ret = am65_cpsw_nuss_ndo_slave_open(ndev);    

Is there another path? Or perhaps there's nothing to restore 
if all netdevs are down?

> I have a question here. How should ageable entries be treated in this case?

Ah, no idea :) Let's me add experts to To:

Re: [PATCH] net: ethernet: ti: cpsw_ale: optimize cpsw_ale_restore()

[Roger Quadros]

Hi Jakub,

On 10/11/2022 22:32, Jakub Kicinski wrote:
> On Thu, 10 Nov 2022 11:39:47 +0200 Roger Quadros wrote:
>>> Maybe my tree is old but I see we clear only if there is a netdev that  
>>
>> This patch depends on this series
>> https://lore.kernel.org/netdev/20221104132310.31577-3-rogerq@kernel.org/T/
> 
> I do have those in my tree.
> 
>>> needs to be opened but then always call ale_restore(). Is that okay?  
>>
>> If netdev is closed and opened ale_restore() is not called.
>> ale_restore() is only called during system suspend/resume path
>> since CPSW-ALE might have lost context during suspend and we want to restore
>> all valid ALE entries.
> 
> Ack, what I'm referring to is the contents of am65_cpsw_nuss_resume().
> 
> I'm guessing that ALE_CLEAR is expected to be triggered by
> cpsw_ale_start().
> 
> Assuming above is true and that ALE_CLEAR comes from cpsw_ale_start(),
> the call stack is:
> 
>  cpsw_ale_start()
>  am65_cpsw_nuss_common_open()
>  am65_cpsw_nuss_ndo_slave_open()
>  am65_cpsw_nuss_resume()
> 
> but resume() only calls ndo_slave_open under certain conditions:
> 
>         for (i = 0; i < common->port_num; i++) {                                  
>                 if (netif_running(ndev)) {                                      
>                         rtnl_lock();                                            
>                         ret = am65_cpsw_nuss_ndo_slave_open(ndev);    
> 
> Is there another path? Or perhaps there's nothing to restore 
> if all netdevs are down?

I see your point now. We are missing a ALE_CLEAR if all interfaces were
down during suspend/resume.
In this case the call to cpsw_ale_restore() is pointless as ALE will be
cleared again when one of the interfaces is brought up.

I'll revise the patch to call cpsw_ale_restore only if any interface
was running.

> 
>> I have a question here. How should ageable entries be treated in this case?
> 
> Ah, no idea :) Let's me add experts to To:

Thanks.

cheers,
-roger

Re: [PATCH] net: ethernet: ti: cpsw_ale: optimize cpsw_ale_restore()

[Vladimir Oltean]

On Thu, Nov 10, 2022 at 12:32:49PM -0800, Jakub Kicinski wrote:
> > I have a question here. How should ageable entries be treated in this case?
> 
> Ah, no idea :) Let's me add experts to To:

Not a real expert, but if suspend/resume loses the Ethernet link,
I expect that no dynamically learned entries are preserved across
a link loss event.

In DSA for example, we only keep ageable entries in hardware as long as
the port STP state, plus BR_LEARNING port flag, are compatible with
having such FDB entries. Otherwise, any transition to such a state
flushes the ageable FDB entries.

A link loss generates a bridge port transition to the DISABLED state,
which DSA uses to generate a SWITCHDEV_FDB_FLUSH_TO_BRIDGE event.

I'm not sure if it would even be possible to accurately do the right
thing and update the ageing timer of the FDB entries with the amount of
time that the system was suspended.

Re: [PATCH] net: ethernet: ti: cpsw_ale: optimize cpsw_ale_restore()

[Roger Quadros]

On 11/11/2022 14:03, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 12:32:49PM -0800, Jakub Kicinski wrote:
>>> I have a question here. How should ageable entries be treated in this case?
>>
>> Ah, no idea :) Let's me add experts to To:
> 
> Not a real expert, but if suspend/resume loses the Ethernet link,
> I expect that no dynamically learned entries are preserved across
> a link loss event.

Understood. We loose the link in this particular case.

> 
> In DSA for example, we only keep ageable entries in hardware as long as
> the port STP state, plus BR_LEARNING port flag, are compatible with
> having such FDB entries. Otherwise, any transition to such a state
> flushes the ageable FDB entries.
> 
> A link loss generates a bridge port transition to the DISABLED state,
> which DSA uses to generate a SWITCHDEV_FDB_FLUSH_TO_BRIDGE event.
> 
> I'm not sure if it would even be possible to accurately do the right
> thing and update the ageing timer of the FDB entries with the amount of
> time that the system was suspended.

In that case I'll leave the entries as they are and let the Switch logic
deal with the stale entries. They should eventually get flushed out.

cheers,
-roger