Hi, > -----Original Message----- > From: Shani Peretz <[email protected]> > Sent: Thursday, February 6, 2025 8:09 AM > To: [email protected] > Cc: [email protected]; Shani Peretz <[email protected]>; > Parav Pandit <[email protected]>; Xueming Li <[email protected]>; > Nipun Gupta <[email protected]>; Nikhil Agarwal > <[email protected]>; Hemant Agrawal <[email protected]>; > Sachin Saxena <[email protected]>; Xu, Rosen <[email protected]>; > Chenbo Xia <[email protected]>; Tomasz Duszynski > <[email protected]>; Chengwen Feng > <[email protected]>; Long Li <[email protected]>; Wei Hu > <[email protected]>; Richardson, Bruce <[email protected]>; > Laatz, Kevin <[email protected]>; Tyler Retzlaff > <[email protected]>; Jan Blunck <[email protected]> > Subject: [PATCH v5 2/4] lib: fix comparison between devices > > DPDK supports multiple formats for specifying buses, (such as "0000:08:00.0" > and "08:00.0" for PCI). > This flexibility can lead to inconsistencies when using one format while > running testpmd, then attempts to use the other format in a later command, > resulting in a failure. > > The issue arises from the find_device function, which compares the user- > provided string directly with the device->name in the rte_device structure. > If we want to accurately compare these names, we'll need to bring both > sides to the same representation by invoking the parse function on the user > input. > > The proposed solution is to utilize the parse function implemented by each > bus. When comparing names, we will call parse on the supplied string as well > as on the device name itself and compare the results. > As part of the change the parse function will now return the size of the > parsed address. > > This will allow consistent comparisons between different representations of > same devices. > > In addition, fixed vdev test to use the rte_cmp_dev_name function instead > of the custom one. > > Fixes: a3ee360f4440 ("eal: add hotplug add/remove device") > > Signed-off-by: Shani Peretz <[email protected]>
Reviewed-by: Rosen Xu <[email protected]>
