On Fri, 10 Jan 2025 13:43:44 +0800 Guangguan Wang <guangguan.wang@xxxxxxxxxxxxxxxxx> wrote: > > I think I showed a valid and practical setup that would break with your > > patch as is. Do you agree with that statement? > Did you mean > " > Now for something like a bond of two OSA > interfaces, I would expect the two legs of the bond to probably have a > "HW PNETID", but the netdev representing the bond itself won't have one > unless the Linux admin defines a software PNETID, which is work, and > can't have a HW PNETID because it is a software construct within Linux. > Breaking for example an active-backup bond setup where the legs have > HW PNETIDs and the admin did not bother to specify a PNETID for the bond > is not acceptable. > " ? > If the legs have HW pnetids, add pnetid to bond netdev will fail as > smc_pnet_add_eth will check whether the base_ndev already have HW pnetid. > > If the legs without HW pnetids, and admin add pnetids to legs through smc_pnet. > Yes, my patch will break the setup. What Paolo suggests(both checking ndev and > base_ndev, and replace || by && )can help compatible with the setup. I'm glad we agree on that part. Things are much more acceptable if we are doing both base and ndev. Nevertheless I would like to understand your problem better, and talk about it to my team. I will also ask some questions in another email. That said having things work differently if there is a HW PNETID on the base, and different if there is none is IMHO wonky and again asymmetric. Imagine the following you have your nice little setup with a PNETID on a non-leaf and a base_ndev that has no PNETID. Then your HW admin configures a PNETID to your base_ndev, a different one. Suddenly your ndev PNETID is ignored for reasons not obvious to you. Yes it is similar to having a software PNETID on the base_ndev and getting it overruled by a HW PNETID, but much less obvious IMHO. I also think a software PNETID of the base should probably take precedence over over the software pnetid of ndev. Regards, Halil
