From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696605522; x=1697210322; darn=redhat.com; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:from:to:cc:subject:date :message-id:reply-to; bh=2hJEOZpwkHmVtNYt07ls/jHKrkkiG4vDwfVuupARRP8=; b=MmcbhVN8STU9hZsTZulutJlZC2ScyHD0vGxFqsbQ4vdegzLgY6g/G0YmS9BAS/7VH2 Hz7J8dBXmuJ9OhwQcFuTHQHN+s9ldlJIhx8cUZmenvfY3n6WGsH3jpDJ/Yh7IcZcsfSA ttK3YaviKmsFmJxtjtKQkfer/2BG5r8GzXMo0gO5bvUXrxlw6+1O6xklt7fra7yPKx9b O/5frdMFzyO31VR7aAr87fXq1ROfdXklerkQ/hWjT3A9vAmDHQw99UPtAWtAGV5sFaz3 L2b6xJQJBCGtngpfX2S/tNEMpgsVG70cO6un2OVLEHz9jLYScM3Qgvl1lei3WAhb77PJ sSfg== References: <20231004125904.110781-1-hreitz@redhat.com> <20231004125904.110781-2-hreitz@redhat.com> <20231005170852.GB1342722@fedora> <20231005131352-mutt-send-email-mst@kernel.org> <00272da3-0a48-5544-6ba8-5dfde00be241@redhat.com> <20231006043518-mutt-send-email-mst@kernel.org> <20231006051802-mutt-send-email-mst@kernel.org> <20231006055229-mutt-send-email-mst@kernel.org> From: Alex =?utf-8?Q?Benn=C3=A9e?= Date: Fri, 06 Oct 2023 16:17:34 +0100 In-reply-to: Message-ID: <87il7jg4oe.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Virtio-fs] (no subject) List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hanna Czenczek Cc: "Michael S. Tsirkin" , virtio-fs@redhat.com, Eugenio =?utf-8?Q?P=C3=A9rez?= , Anton Kuchin , Yajun Wu , qemu-devel@nongnu.org Hanna Czenczek writes: > On 06.10.23 12:34, Michael S. Tsirkin wrote: >> On Fri, Oct 06, 2023 at 11:47:55AM +0200, Hanna Czenczek wrote: >>> On 06.10.23 11:26, Michael S. Tsirkin wrote: >>>> On Fri, Oct 06, 2023 at 11:15:55AM +0200, Hanna Czenczek wrote: >>>>> On 06.10.23 10:45, Michael S. Tsirkin wrote: >>>>>> On Fri, Oct 06, 2023 at 09:48:14AM +0200, Hanna Czenczek wrote: >>>>>>> On 05.10.23 19:15, Michael S. Tsirkin wrote: >>>>>>>> On Thu, Oct 05, 2023 at 01:08:52PM -0400, Stefan Hajnoczi wrote: >>>>>>>>> On Wed, Oct 04, 2023 at 02:58:57PM +0200, Hanna Czenczek wrote: >>> What I=E2=80=99m saying is, 923b8921d21 introduced SET_STATUS calls tha= t broke all >>> devices that would implement them as per virtio spec, and even today it= =E2=80=99s >>> broken for stateful devices.=C2=A0 The mentioned performance issue is l= ikely >>> real, but we can=E2=80=99t address it by making up SET_STATUS calls tha= t are wrong. >>> >>> I concede that I didn=E2=80=99t think about DRIVER_OK.=C2=A0 Personally= , I would do all >>> final configuration that would happen upon a DRIVER_OK once the first v= ring >>> is started (i.e. receives a kick).=C2=A0 That has the added benefit of = being >>> asynchronous because it doesn=E2=80=99t block any vhost-user messages (= which are >>> synchronous, and thus block downtime). >>> >>> Hanna >> >> For better or worse kick is per ring. It's out of spec to start rings >> that were not kicked but I guess you could do configuration ... >> Seems somewhat asymmetrical though. > > I meant to take the first ring being started as the signal to do the > global configuration, i.e. not do this once per vring, but once > globally. > >> Let's wait until next week, hopefully Yajun Wu will answer. > > I mean, personally I don=E2=80=99t really care about the whole SET_STATUS > thing.=C2=A0 It=E2=80=99s clear that it=E2=80=99s broken for stateful dev= ices.=C2=A0 The fact > that it took until 6f8be29ec17d to fix it for just any device that > would implement it according to spec to me is a strong indication that > nobody does implement it according to spec, and is currently only used > to signal to some specific back-end that all rings have been set up > and should be configured in a single block. I'm certainly using [GS]ET_STATUS for the proposed F_TRANSPORT extensions where everything is off-loaded to the vhost-user backend. --=20 Alex Benn=C3=A9e Virtualisation Tech Lead @ Linaro