From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DC7622F3B4 for ; Wed, 15 Jan 2025 05:07:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736917663; cv=none; b=peYb1Ltlb0kdBxBVwXUM28i5bJ4TklglRPVwpL3zGfKREEFt++UQoYOBZfQBvYUrpP9BM6bi8LDkI/uLHGkJ1kzTj+jrIy6qpQnQIlI59QOh6HZsfILndw9MGuKt5n9IkQW9hfBm8lPhX0ODtxGQwp1pBa+5h4R53VMtPCw7QhQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736917663; c=relaxed/simple; bh=t4dXpTZmsRI2k2NZ4xiQUhN5dBPeJttIl5lhtigwHU8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ko0ykkN1hkZofWitJid9NxC4EsxQTNzzv5PTeX4hLAjtMTREFhQsNbE5e8OcVFnLnU1xsGZ1yaHg8kl7cvBIkzvqCw6MuUXDeDI+ImYwf/rahi5kowUmBaYGttOYM8dsUEEADQgqDnMqmI8gfg6adhjzqBfnSgjIFOciT/SM040= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com; spf=pass smtp.mailfrom=daynix.com; dkim=pass (2048-bit key) header.d=daynix-com.20230601.gappssmtp.com header.i=@daynix-com.20230601.gappssmtp.com header.b=ojNFcQ6q; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=daynix.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=daynix-com.20230601.gappssmtp.com header.i=@daynix-com.20230601.gappssmtp.com header.b="ojNFcQ6q" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-21670dce0a7so136432905ad.1 for ; Tue, 14 Jan 2025 21:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20230601.gappssmtp.com; s=20230601; t=1736917660; x=1737522460; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tJj2ax30G5cYMMuz85Qw6SCJDIZ/bbwOrDlSPLFGRgM=; b=ojNFcQ6qbQMsuh63BrZPD2cg5u7/AjaUXt9B7ekVeZhZM8dOXf3eAAuYd+TBljvKwK JtNVSsZSxxxJMsHDenuRv66Q+3LiW/CEFkGmFZ15GfcB1tGh258PdjinToYMY6fN5CT9 yLK/AIBtJTJJwU1XATwHLqPmqX6dv8V9mBOPQ6Rx1Sfri9vVUE/+dgN+cKHNzxg2ivhk m7ysgpWjGkfKAPQDfwx20th4mSNaYEPeGZwe/pPtPrlYgMFWu6FprvmzyPayoSWQys1k 2nGX8N5IF/6m1UIIXjlIlqdAOoj5xaQRHCPESiDfRHfQYqYL7WKNb6iJHI4t1rnWxhjb XD/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736917660; x=1737522460; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tJj2ax30G5cYMMuz85Qw6SCJDIZ/bbwOrDlSPLFGRgM=; b=byiKWtMVnwODmmM6lBlmyn+qmwtfOlF9mZ0S8R19So8F831t424t7YTKlBB5wgkac7 tB73mCkXje6ejU8VXUM0Foul3Osd5sMEKE2AflsGo3AuQvbbHgwU2MXEsbLa2u9br/ns ehAyaDaE12VsgaWZbUi/ymtJ2S7ikMpt7KoepaTk4HqNrxW+7TraU2ehpD1mK61q+7Ih tRD3WGjY/wJdSSwy8r8PW0OZ+8zy+OUhM0mhkf9LrJa4EJ0wQ/KqmVFY6BWhGIB873od uavPIshGo971Gy4+xmfpi485F8lfX3S7IiGUHmz9g9l9nJWY3DL+peyviyfnAYFv+FHR bNjw== X-Forwarded-Encrypted: i=1; AJvYcCWcQUfvX5B47nbuGsPw4SFBCa3rm1jIavATFQFfBkW96sSLrUut25bUnlrIGf/db5IcbiDas8Ejh8fhZrU=@vger.kernel.org X-Gm-Message-State: AOJu0Yyh9OFNoqdhIdfmdqKNbTyPlMTCCs4fNbxq0y0wZj+P84yHL5vo Q3VpZeU2Riem4eWEdOwa8tItvIhlcVwFdi3Yqk6wPGz2J4fXwZK9T67jgtqM1b0= X-Gm-Gg: ASbGncunOShyI7VCl+dU5iqGDF1KeUKLMiOGTrhjibXGztB3SamPZ05IRkXlEWLWmqP 5Z1XyMscfOh3/d/m2bs5SR6fdEQU0Rn2Mn8ZCdshLeP42fnnS+VYjxWTggsl34piFuDSTPT/nfx kzwQf1tzITe8I7YrxRBLTdq7ucPLUFnZG6pj+Rk84NlK+24By76D0y5sYlLfDoNTXYqrDLmsxQ6 iT0AiZb3sCtIgfGcNbVL1/wL6EYY9Ou8C8ai06zbK2LOKk08k+4Z+73ewFQpZwksR8= X-Google-Smtp-Source: AGHT+IH85/A6RLxL+2rEhiloGI8TMEvrvGtTvROtv7Pjqakmsz8YgZ7ly7fq+kIggy8KHNzrf4rkjg== X-Received: by 2002:a17:902:ea0a:b0:216:3083:d03d with SMTP id d9443c01a7336-21a83ffc447mr470885135ad.44.1736917659024; Tue, 14 Jan 2025 21:07:39 -0800 (PST) Received: from [157.82.203.37] ([157.82.203.37]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21a9f10e41csm73994625ad.11.2025.01.14.21.07.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jan 2025 21:07:38 -0800 (PST) Message-ID: Date: Wed, 15 Jan 2025 14:07:32 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] tun: Set num_buffers for virtio 1.0 To: Jason Wang Cc: "Michael S. Tsirkin" , Jonathan Corbet , Willem de Bruijn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Xuan Zhuo , Shuah Khan , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kselftest@vger.kernel.org, Yuri Benditovich , Andrew Melnychenko , Stephen Hemminger , gur.stavi@huawei.com, devel@daynix.com References: <20250109-tun-v2-0-388d7d5a287a@daynix.com> <20250109-tun-v2-3-388d7d5a287a@daynix.com> <20250110052246-mutt-send-email-mst@kernel.org> <2e015ee6-8a3b-43fb-b119-e1921139c74b@daynix.com> Content-Language: en-US From: Akihiko Odaki In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025/01/13 12:04, Jason Wang wrote: > On Fri, Jan 10, 2025 at 7:12 PM Akihiko Odaki wrote: >> >> On 2025/01/10 19:23, Michael S. Tsirkin wrote: >>> On Fri, Jan 10, 2025 at 11:27:13AM +0800, Jason Wang wrote: >>>> On Thu, Jan 9, 2025 at 2:59 PM Akihiko Odaki wrote: >>>>> >>>>> The specification says the device MUST set num_buffers to 1 if >>>>> VIRTIO_NET_F_MRG_RXBUF has not been negotiated. >>>> >>>> Have we agreed on how to fix the spec or not? >>>> >>>> As I replied in the spec patch, if we just remove this "MUST", it >>>> looks like we are all fine? >>>> >>>> Thanks >>> >>> We should replace MUST with SHOULD but it is not all fine, >>> ignoring SHOULD is a quality of implementation issue. >>> > > So is this something that the driver should notice? > >> >> Should we really replace it? It would mean that a driver conformant with >> the current specification may not be compatible with a device conformant >> with the future specification. > > I don't get this. We are talking about devices and we want to relax so > it should compatibile. The problem is: 1) On the device side, the num_buffers can be left uninitialized due to bugs 2) On the driver side, the specification allows assuming the num_buffers is set to one. Relaxing the device requirement will replace "due to bugs" with "according to the specification" in 1). It still contradicts with 2) so does not fix compatibility. Instead, we should make the driver requirement stricter to change 2). That is what "[PATCH v3] virtio-net: Ignore num_buffers when unused" does: https://lore.kernel.org/r/20250110-reserved-v3-1-2ade0a5d2090@daynix.com > >> >> We are going to fix all implementations known to buggy (QEMU and Linux) >> anyway so I think it's just fine to leave that part of specification as is. > > I don't think we can fix it all. It essentially only requires storing 16 bits. There are details we need to work out, but it should be possible to fix. Regards, Akihiko Odaki