From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"david.edmondson@oracle.com" <david.edmondson@oracle.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"sburla@marvell.com" <sburla@marvell.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
Yishai Hadas <yishaih@nvidia.com>,
Maor Gottlieb <maorg@nvidia.com>,
Shahaf Shuler <shahafs@nvidia.com>
Subject: [virtio-dev] Re: [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access
Date: Thu, 6 Jul 2023 16:28:31 -0400 [thread overview]
Message-ID: <20230706162505-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB5481AF3000FFDBA2CBA5D7ADDC2CA@PH0PR12MB5481.namprd12.prod.outlook.com>
On Thu, Jul 06, 2023 at 08:21:13PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > 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
next prev parent reply other threads:[~2023-07-06 20:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-06 4:17 [virtio-dev] [PATCH v10 0/4] admin: Access legacy registers using admin commands Parav Pandit
2023-07-06 4:17 ` [virtio-dev] [PATCH v10 1/4] admin: Split opcode table rows with a line Parav Pandit
2023-07-06 4:17 ` [virtio-dev] [PATCH v10 2/4] admin: Fix section numbering Parav Pandit
2023-07-06 13:39 ` [virtio-dev] " Cornelia Huck
2023-07-06 4:17 ` [virtio-dev] [PATCH v10 3/4] admin: Add group member legacy register access commands Parav Pandit
2023-07-06 16:12 ` [virtio-dev] " Cornelia Huck
2023-07-06 16:16 ` [virtio-dev] " Parav Pandit
2023-07-06 4:17 ` [virtio-dev] [PATCH v10 4/4] transport-pci: Introduce group legacy group member config region access Parav Pandit
2023-07-06 16:28 ` [virtio-dev] " Cornelia Huck
2023-07-06 16:33 ` [virtio-dev] " Parav Pandit
2023-07-06 16:42 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 16:58 ` [virtio-dev] " Parav Pandit
2023-07-06 17:33 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 17:47 ` [virtio-dev] " Parav Pandit
2023-07-06 18:06 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 18:16 ` [virtio-dev] " Parav Pandit
2023-07-06 18:48 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 18:53 ` [virtio-dev] " Parav Pandit
2023-07-06 18:56 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 19:00 ` [virtio-dev] " Parav Pandit
2023-07-06 19:42 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 20:21 ` [virtio-dev] " Parav Pandit
2023-07-06 20:28 ` Michael S. Tsirkin [this message]
2023-07-06 20:35 ` Parav Pandit
2023-07-06 20:41 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 20:43 ` [virtio-dev] " Parav Pandit
2023-07-07 8:12 ` [virtio-dev] Re: [virtio-comment] " Cornelia Huck
2023-07-07 8:32 ` Michael S. Tsirkin
2023-07-06 17:38 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 16:47 ` [virtio-dev] " Cornelia Huck
2023-07-06 16:52 ` Parav Pandit
2023-07-06 16:39 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 16:45 ` [virtio-dev] " Parav Pandit
2023-07-06 16:50 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 16:54 ` [virtio-dev] " Parav Pandit
2023-07-06 19:00 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 19:07 ` [virtio-dev] RE: [virtio-comment] " Parav Pandit
2023-07-06 19:59 ` [virtio-dev] " Michael S. Tsirkin
2023-07-06 20:28 ` [virtio-dev] " Parav Pandit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230706162505-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=david.edmondson@oracle.com \
--cc=jasowang@redhat.com \
--cc=maorg@nvidia.com \
--cc=parav@nvidia.com \
--cc=sburla@marvell.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox