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 ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (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 32B61EB64DD for ; Thu, 6 Jul 2023 20:28:42 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 93FAA2AD7A for ; Thu, 6 Jul 2023 20:28:41 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 81C3C986816 for ; Thu, 6 Jul 2023 20:28:41 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 6F4969867F9; Thu, 6 Jul 2023 20:28:41 +0000 (UTC) Mailing-List: contact virtio-dev-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 59127986800 for ; Thu, 6 Jul 2023 20:28:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-MC-Unique: IagfMn4zNlClVqxNhKkQvw-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688675316; x=1691267316; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NUyaMi950aL/hHkWdSq+JGXYXS6LA6Ax3X1Mex+ekmM=; b=beN3mmKn163wSpKP2UU89O6/RsV5jR4ZUqt6k3LCJQ/hyGIqvgmxhO2C2cl7WFahjo /gCpcZOEDu0SueKzvqNoXvXsWZAUOOsOL2DiYUfc3xl8h2iV9sskpqGnyjJ6M7QSKWbA 0XW00C3EEQLLl69jzspgKQmbrfVl+RWsOrm35Zh++AeDg+21eNYJbOq/pxGoRKxRPbq4 XmISGimN+lI6RcmX67B/9DWQ9BA6XoqwbVXVhZq1VGKQIFtgkhi6+9qeptQsekcUfxwI bUVUHYGlOyV14inE2SeeOPyUkhOZhwSFdlvUf02uKOxBPhPsZDtg+Ak6PwxxKccTHKfa ROEw== X-Gm-Message-State: ABy/qLZ70od7OvJlA4O80USmKlGkqREzCWyq1y5oLmYwcv5mPk0PbWKq pXzYA6Am7/zD0tihIDXIyH3yIQYOOe/btBCZYghQkMk8IMBartHBt2beEiRYXCH+zhAQ9JO5QKv dfkQWRnl86KMY2vH3P0KCyF7Xc8XZ X-Received: by 2002:adf:d08a:0:b0:314:3b68:eac6 with SMTP id y10-20020adfd08a000000b003143b68eac6mr2221323wrh.12.1688675316560; Thu, 06 Jul 2023 13:28:36 -0700 (PDT) X-Google-Smtp-Source: APBJJlGmJJfRhv9uUINk9T7sbB4LgIWN7drQrUZu+o31rIObUwMHQgxIX3VUxRkIVdinecSYmTebhg== X-Received: by 2002:adf:d08a:0:b0:314:3b68:eac6 with SMTP id y10-20020adfd08a000000b003143b68eac6mr2221308wrh.12.1688675316255; Thu, 06 Jul 2023 13:28:36 -0700 (PDT) Date: Thu, 6 Jul 2023 16:28:31 -0400 From: "Michael S. Tsirkin" To: Parav Pandit Cc: Cornelia Huck , "virtio-comment@lists.oasis-open.org" , "david.edmondson@oracle.com" , "virtio-dev@lists.oasis-open.org" , "sburla@marvell.com" , "jasowang@redhat.com" , Yishai Hadas , Maor Gottlieb , Shahaf Shuler Message-ID: <20230706162505-mutt-send-email-mst@kernel.org> References: <20230706132638-mutt-send-email-mst@kernel.org> <20230706135858-mutt-send-email-mst@kernel.org> <20230706144427-mutt-send-email-mst@kernel.org> <20230706145538-mutt-send-email-mst@kernel.org> <20230706154002-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access On Thu, Jul 06, 2023 at 08:21:13PM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin > > Sent: Thursday, July 6, 2023 3:43 PM > > > > > As the order is there anyway, why not just prescribe entries are used in > > order? > > > > > > I don't see any value in defining any order. It is an array of entries not a priority > > list. > > > > I think we are losing out. For example I can see how access through member > > would be preferable for ordering reasons. > > However device might still allow access through PF for cases where driver can't > > access VF. > > > So a driver can choose say I prefer order over accessibility over VF, so it choose PF. > Device doesn't have the knowledge anyway whether driver can/cannot access the VF. > So, device's preference vs driver's preference may be different. The driver has a final decision. Let's make it a SHOULD and then if driver knows best then it has the choice? > > But I don't see any configs where leaving this to the driver's discretion is > > preferable. If you see one let me know. > > In doesn't need to be config. > It is the environment that chooses which is preferred by the driver. > For example preference of accessibility over ordering. what does accessibility mean exactly? I definitely see OSes where owner driver can't access a member. So in that case naturally driver will skip the entry for member even if it's first. maybe there are configs where member access is possible but is very slow e.g. with lots of indirect function calls? OK fine, but then it will be up to the driver to test and make damn sure the benefits outweight the costs. IOW it's a hint for the driver. If you like you can say it explicitly even. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org