Re: [PATCH net] net/smc: use the correct ndev to find pnetid by pnetid table

[Halil Pasic <pasic@linux.ibm.com>]

On Wed, 8 Jan 2025 12:57:00 +0800
Guangguan Wang <guangguan.wang@linux.alibaba.com> wrote:

> > sorry for chiming in late. Wenjia is on vacation and Jan is out sick!
> > After some reading and thinking I could not figure out how 890a2cb4a966
> > ("net/smc: rework pnet table") is broken.  
> 
> Before commit 890a2cb4a966:
> smc_pnet_find_roce_resource
>     smc_pnet_find_roce_by_pnetid(ndev, ...) /* lookup via hardware-defined pnetid */
>         smc_pnetid_by_dev_port(base_ndev, ...)
>     smc_pnet_find_roce_by_table(ndev, ...) /* lookup via SMC PNET table */
>     {
>         ...
>         list_for_each_entry(pnetelem, &smc_pnettable.pnetlist, list) {
>                 if (ndev == pnetelem->ndev) { /* notice here, it was ndev to matching pnetid element in pnet table */
>         ...
>     }
> 
> After commit 890a2cb4a966:
> smc_pnet_find_roce_resource
>     smc_pnet_find_roce_by_pnetid
>     {
>         ...
>         base_ndev = pnet_find_base_ndev(ndev); /* rename the variable name to base_ndev for better understanding */
>         smc_pnetid_by_dev_port(base_ndev, ...)
>         smc_pnet_find_ndev_pnetid_by_table(base_ndev, ...)
>         {
>                 ...
>                 list_for_each_entry(pnetelem, &smc_pnettable.pnetlist, list) {
>                 if (base_ndev == pnetelem->ndev) { /* notice here, it is base_ndev to matching pnetid element in pnet table */
>                 ...
>         }
> 
>     }
> 
> The commit 890a2cb4a966 has changed ndev to base_ndev when matching pnetid element in pnet table.
> But in the function smc_pnet_add_eth, the pnetid is attached to the ndev itself, not the base_ndev.
> smc_pnet_add_eth(...)
> {
>     ...
>     ndev = dev_get_by_name(net, eth_name);
>     ...
>         if (new_netdev) {
>             if (ndev) {
>                 new_pe->ndev = ndev;
>                 netdev_tracker_alloc(ndev, &new_pe->dev_tracker,
>                     GFP_ATOMIC);
>             }
>             list_add_tail(&new_pe->list, &pnettable->pnetlist);
>             mutex_unlock(&pnettable->lock);
>         } else {
>     ...
> }

I still not understand why do you think that 890a2cb4a966~1 is better
than 890a2cb4a966 even if things changed with 890a2cb4a966 which
I did not verify for myself but am willing to assume.

Is there some particular setup that you think would benefit from
you patch? I.e. going back to the 890a2cb4a966~1 behavior I suppose.

I think I showed a valid and practical setup that would break with your
patch as is. Do you agree with that statement?

Regards,
Halil