From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5BA32C4332F for ; Thu, 2 Nov 2023 09:10:38 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyThy-0004gD-4f; Thu, 02 Nov 2023 05:09:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyThw-0004fq-9s for qemu-devel@nongnu.org; Thu, 02 Nov 2023 05:09:44 -0400 Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qyThu-0003Zx-3m for qemu-devel@nongnu.org; Thu, 02 Nov 2023 05:09:43 -0400 Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2c54c8934abso10064201fa.0 for ; Thu, 02 Nov 2023 02:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20230601.gappssmtp.com; s=20230601; t=1698916180; x=1699520980; darn=nongnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U2nWwmmtAy6EWIJ0uFwVcUBxmCZA/kFzcbNcHasMqjc=; b=gUwHgDzr3HGKxfyxWk72ZNuMDQtjQxV8ccZrsVOEq7cz+3TujQsg5E6Q5jAz3GlZYD mv6und6oXKPnEqOb+uLLy+JFxrfglIEU2WKi2rSiRndPSXTZWALZHG0wkedb3Q8dtH3o jkvCPAhr4XtQmBOt3KV3EpL9zAHp71Dgb1+jQO8s3eXb7RfDAkAMDE2xAIP1fHL0CPlf 7pWXN1E0J7Ck70v6eQqmjPNCbcWNiByzD5LJiWGagtySXA+GJgnGM2vOzuSbrZr5hHZe CWvhxyAEDlrMncPGgsgeVCI5MfWZt5ZPBtXz0UzWDFQeJb1hluvIUL4IIoToqWKnjOy7 DA+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698916180; x=1699520980; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U2nWwmmtAy6EWIJ0uFwVcUBxmCZA/kFzcbNcHasMqjc=; b=ICGWLVRNi7fLbdiJw6c38dW61Ed4p4wIXa9JGvZQrk/LorWGDAUzDLjiUP15DRsXBM ICgUo1pxw01wbicraSBTAfaV9DS28+LWn6L9T161Q2lgMjN9sSoF8SFnC87A8vZezLmY MNm9VSZOhrzRJ+Ryixsai9RI0W1J9y80Y9Z7T3hAk2bbmyotbaQ+NFvoWPGRwALmBLKW ICwj5HT6T8kVOlisKkh5sje8NDqrteoK7sPhh19OWx0XJ66sKHg9SwCjV6DhKY+8p9rL dPU2rHELa/Eg8soSijFD07+jmdXEhtd6Z6gXcYccgXzRlB//b/LmHGz6bybEoAN+vWI4 4h8w== X-Gm-Message-State: AOJu0Yw+PCry/MRk/wjuiXwfPcJKFYUin88RwlFEaU6ly11byVAh8T3A P7Knoo1o7H3TqhPhDBOYAbYwaYSIuntgPl2ZZA3QCg== X-Google-Smtp-Source: AGHT+IH6w0NQLfqB/M8sxZ36l0dZO6Jr5oqw59Gcu9aEVwTAS7m0EnN7DZcYYYFIxTs4K2citw4a72eWhmOpm1lsX4I= X-Received: by 2002:a2e:a7d2:0:b0:2b9:4b2e:5420 with SMTP id x18-20020a2ea7d2000000b002b94b2e5420mr17076947ljp.52.1698916179766; Thu, 02 Nov 2023 02:09:39 -0700 (PDT) MIME-Version: 1.0 References: <20231030051356.33123-1-akihiko.odaki@daynix.com> <20231030051356.33123-12-akihiko.odaki@daynix.com> <58fb3b75-dd69-4715-a8ec-4c3df3b7e4c5@daynix.com> <8880b6f9-f556-46f7-a191-eeec0fe208b0@daynix.com> <20231101023805-mutt-send-email-mst@kernel.org> <39a02a4c-f8fa-437c-892f-caca84b8d85d@daynix.com> <20231101050838-mutt-send-email-mst@kernel.org> In-Reply-To: From: Yuri Benditovich Date: Thu, 2 Nov 2023 11:09:27 +0200 Message-ID: Subject: Re: [PATCH v6 11/21] virtio-net: Return an error when vhost cannot enable RSS To: Akihiko Odaki Cc: "Michael S. Tsirkin" , Jason Wang , qemu-devel@nongnu.org, Andrew Melnychenko Content-Type: multipart/alternative; boundary="000000000000660170060927bf3d" Received-SPF: none client-ip=2a00:1450:4864:20::234; envelope-from=yuri.benditovich@daynix.com; helo=mail-lj1-x234.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --000000000000660170060927bf3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Probably we mix two different patches in this discussion. Focusing on the patch in the e-mail header: IMO it is not acceptable to fail QEMU run for one feature that we can't make active when we silently drop all other features in such a case. On Wed, Nov 1, 2023 at 11:15=E2=80=AFAM Akihiko Odaki wrote: > On 2023/11/01 18:09, Michael S. Tsirkin wrote: > > On Wed, Nov 01, 2023 at 05:35:50PM +0900, Akihiko Odaki wrote: > >> On 2023/11/01 15:38, Michael S. Tsirkin wrote: > >>> On Wed, Nov 01, 2023 at 01:50:00PM +0900, Akihiko Odaki wrote: > >>>> We had another discussion regarding migration for patch "virtio-net: > Do not > >>>> clear VIRTIO_NET_F_HASH_REPORT". It does change the runtime behavior > so we > >>>> need to take migration into account. I still think the patch does no= t > >>>> require a compatibility flag since it only exposes a new feature and > does > >>>> not prevent migrating from old QEMU that exposes less features. It > instead > >>>> fixes the case where migrating between hosts with different tap > feature > >>>> sets. > >>> > >>> When in doubt, add a compat flag. > >> > >> Personally I'm confident about the migration compatibility with patch > >> "virtio-net: Do not clear VIRTIO_NET_F_HASH_REPORT". virtio-net alread= y > does > >> the same thing when the tap implementation on the destination implemen= ts > >> virtio-net header support while the counterpart of the source does not= . > > > > Trust me there's been so many times where we were very sure and > > problems come up later. Just don't enable new functionality for > > old machine types, problem solved. Why is this hard? > > I see. I'll add a compatibility flag for VIRTIO_NET_F_HASH_REPORT > exposure; it should be quite easy. > --000000000000660170060927bf3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Probably we mix two different patches in this discussion.<= div>
Focusing on the patch in the e-mail header:

IMO it is not acceptable to fail QEMU run for one feature that we can= 9;t make active when we silently drop all other features in such a case.

On Wed, Nov 1, 2023 at 11:15=E2=80=AFAM Akihiko Odaki <akihiko.odaki@daynix.com> wrote= :
On 2023/11/01 = 18:09, Michael S. Tsirkin wrote:
> On Wed, Nov 01, 2023 at 05:35:50PM +0900, Akihiko Odaki wrote:
>> On 2023/11/01 15:38, Michael S. Tsirkin wrote:
>>> On Wed, Nov 01, 2023 at 01:50:00PM +0900, Akihiko Odaki wrote:=
>>>> We had another discussion regarding migration for patch &q= uot;virtio-net: Do not
>>>> clear VIRTIO_NET_F_HASH_REPORT". It does change the r= untime behavior so we
>>>> need to take migration into account. I still think the pat= ch does not
>>>> require a compatibility flag since it only exposes a new f= eature and does
>>>> not prevent migrating from old QEMU that exposes less feat= ures. It instead
>>>> fixes the case where migrating between hosts with differen= t tap feature
>>>> sets.
>>>
>>> When in doubt, add a compat flag.
>>
>> Personally I'm confident about the migration compatibility wit= h patch
>> "virtio-net: Do not clear VIRTIO_NET_F_HASH_REPORT". vir= tio-net already does
>> the same thing when the tap implementation on the destination impl= ements
>> virtio-net header support while the counterpart of the source does= not.
>
> Trust me there's been so many times where we were very sure and > problems come up later. Just don't enable new functionality for > old machine types, problem solved. Why is this hard?

I see. I'll add a compatibility flag for VIRTIO_NET_F_HASH_REPORT
exposure; it should be quite easy.
--000000000000660170060927bf3d--