On Wed, 8 Jan 2025 12:57:00 +0800
Guangguan Wang <guangguan.wang@xxxxxxxxxxxxxxxxx> 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
