On 7/19/2024 10:20 PM, Stephen Hemminger wrote: > On Fri, 19 Jul 2024 21:39:04 +0100 > Ferruh Yigit <ferruh.yi...@amd.com> wrote: > >>> --- a/drivers/net/netvsc/hn_vf.c >>> +++ b/drivers/net/netvsc/hn_vf.c >>> @@ -264,7 +264,7 @@ int hn_vf_add(struct rte_eth_dev *dev, struct hn_data >>> *hv) >>> goto exit; >>> } >>> >>> - ret = hn_vf_mtu_set(dev, dev->data->mtu); >>> + ret = rte_eth_dev_set_mtu(port, dev->data->mtu); >>> >> >> As 'rte_eth_dev_set_mtu()' calls 'hn_vf_mtu_set()' in the call chain, >> won't it cause same problem? > > The port is the vf so it will call the set_mtu on the VF not the netvsc > device so it is not in the call chain. >
ack >> >> Does it help to make unlocked version of 'hn_vf_mtu_set()': >> ``` >> _hn_vf_mtu_set() >> // set mtu without lock >> >> hn_vf_mtu_set() >> lock() >> _hn_vf_mtu_set() >> unlock() >> ``` > > That was original proposal, but using rte_eth_dev_set_mtu() on the VF > port has more error checking.
