From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 492DD45658; Fri, 19 Jul 2024 23:21:05 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9E73B42799; Fri, 19 Jul 2024 23:21:04 +0200 (CEST) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by mails.dpdk.org (Postfix) with ESMTP id 367CC4026B for ; Fri, 19 Jul 2024 23:21:02 +0200 (CEST) Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-70af3d9169bso1016829b3a.1 for ; Fri, 19 Jul 2024 14:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1721424061; x=1722028861; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=/4RKemHQg8c/2r+IvtvLOMIOig2j3yNztYdK2hXxG4k=; b=z/RQNBrj7uJeDDqaG4YfV+7POgpHkOVNT1jXoL/yJLTDmfp/QX5yAHSAKzLj1Ubemk 0sYYymLMvStZhJyMQ71cKtoVzkuh9vnwXOjVAPMFdJ0rydmFcK8HAsXc/xH6CutQazT8 e78Tl3uPytQr+Iq/2o7iUpdBfdugzviIeq/jaOChvmIpu6PcvVZAuaCfgl7lPQ++HTvC zJqYCHr/aW0OcxIdQbqEVAgZnQY1ur4ULzh9ugXyrwEm5BcfmEPBgvpC0sDDZrM1Usrc lam+aXS3Mp3v8v+Vsyo8LnDlSo15ioqhyBoDkehSvZX7XcUobLwTgrz4l7AVq+WHKFap e1+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721424061; x=1722028861; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/4RKemHQg8c/2r+IvtvLOMIOig2j3yNztYdK2hXxG4k=; b=Cg5DV2OEL4cHChvK08lFNqX2JN0d5vxkAxnkIxgPbIVf3zZMaxgq7n6k6zVundZQKv TFZQOdqveWgGOpc91gJ9Ej1iUz0qDdo3dS8z1lk3cHDBrzMstq2bnOqGZZRzj8lHVMvn KTR9ve/4dzpRrZuzYGoWvJVSc6CfAluR9r7JgTpfwaDPhH55ZxTo+qYfvj1EB6eBqqA4 qahMQOncfjbJ5Qxg1QdLEUSImbeUiCUN6bJd80JLz8EnO+DXBJYe9GRFp2ByFJfVYRQI HF1K3/obf1oq0W7u9jmuwfU6E7EgZCVVXIQJ0SymrV0oYmSXhNP+9jf7hGlRibru09jw ALLg== X-Forwarded-Encrypted: i=1; AJvYcCXmPfJBd1VvXMYaxmLCOliCG+9j5qJpV0TfUAtjXqD2UWQ1l8s8vIWLbOqfBq8A4IwUX35KRdP0ECV8+80= X-Gm-Message-State: AOJu0YzQDVEyYkdDMIuso35rPCMWjyUJCkhkI63ytNietDgWdaZWTyHn N6ujg02oJODVC/OE7H+ZWzkfweaNgWK/XXLaZbCgo4PYjSWtpn5SEHr6ZFPcC3w= X-Google-Smtp-Source: AGHT+IGlx/GUiO7uMIC7zQ0gWUx5ZtVxqhILOft7Zg4avcGkAEvLfpx/nhgONIBbMcmBzTuvmqDLhQ== X-Received: by 2002:a05:6a20:ba07:b0:1bd:28b9:6f88 with SMTP id adf61e73a8af0-1c4228d7a21mr1342626637.24.1721424061229; Fri, 19 Jul 2024 14:21:01 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70cff59cb7dsm1675359b3a.144.2024.07.19.14.21.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jul 2024 14:21:01 -0700 (PDT) Date: Fri, 19 Jul 2024 14:20:59 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: longli@linuxonhyperv.com, Andrew Rybchenko , Wei Hu , dev@dpdk.org, stable@dpdk.org, Long Li Subject: Re: [PATCH] net/netvsc: use rte_eth_dev_set_mtu to set VF MTU Message-ID: <20240719142059.5f3e6cf6@hermes.local> In-Reply-To: <9c0c9e2e-3179-419e-9f0c-bd24984ee45f@amd.com> References: <1721331316-8821-1-git-send-email-longli@linuxonhyperv.com> <9c0c9e2e-3179-419e-9f0c-bd24984ee45f@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, 19 Jul 2024 21:39:04 +0100 Ferruh Yigit 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. > > 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.