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 756E245658 for ; Fri, 19 Jul 2024 23:21:04 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6F97340DD5; Fri, 19 Jul 2024 23:21:04 +0200 (CEST) Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by mails.dpdk.org (Postfix) with ESMTP id 3B57C40DD5 for ; Fri, 19 Jul 2024 23:21:02 +0200 (CEST) Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-76cb5b6b3e4so1653149a12.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=fXEBj6YcP0I8AmH81Hl7zSJPzoPRvqrEERkth4AdFisCSn+JCA9uul6mh3gneXMUMh fLZJ4ItIaYYH1B4V/a8D/Us7ngakhbD+5xVH/JqhfzrXlCnsP8ONMG4UTv3GtacFaMIE 15U6qr0QLfsDBa6UhIDoDGs27LsvDPk3W+C7GG3So3Bkpb41JBB1c2QygXb2R35WWZMp u97gygi6v0daiAwq77kASoHFPv8vSBV3BOIo5aUGtnKDf/EWDwXSvtYhnqlGhigsVjxM rrjjzKDmSEz31dnHY5+vBmNDdRygRpJBAuYKEOd5/qjPw63jzDmxJS2Ehty6kG/GCTGl nCaw== X-Forwarded-Encrypted: i=1; AJvYcCWEWWz9xusKyn1YFTMZ6vfMpI0yenPPiEnLP9VuyYuwhumu/5JFoS1rgxVJc5plCqYSYZqblhoFAyCrTZ1iH+U= X-Gm-Message-State: AOJu0YwIooiB+8fzNXGbqs54oQFOAS9x7nwvXz9ruXaqVkYT8c9/gUFh xk1yD19HhwjCAmC3R2KmT2G2klRz5/oesg+8h15q8K2iu4aGyniE6mhX5psF3aI= 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: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-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.