From: Jason Wang <jasowang@redhat.com>
To: Vitaly Mireyno <vmireyno@marvell.com>,
"virtio-networking@redhat.com" <virtio-networking@redhat.com>,
Virtio-Dev <virtio-dev@lists.oasis-open.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, Ariel Elior <aelior@marvell.com>
Subject: [virtio-dev] Re: [Virtio-networking] Doorbell mapping of vDPA
Date: Fri, 17 Apr 2020 12:15:06 +0800 [thread overview]
Message-ID: <5c682a37-04cc-e96f-e593-ec932caefbc7@redhat.com> (raw)
In-Reply-To: <BN6PR1801MB2067FCCE45316C25E5EB82F7C5DA0@BN6PR1801MB2067.namprd18.prod.outlook.com>
On 2020/4/14 下午9:12, Vitaly Mireyno wrote:
>> -----Original Message-----
>> From: virtio-networking-bounces@redhat.com <virtio-networking-bounces@redhat.com> On Behalf
>> Of Jason Wang
>> Sent: Tuesday, 7 April, 2020 10:56
>> To: virtio-networking@redhat.com; Virtio-Dev <virtio-dev@lists.oasis-open.org>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Subject: [Virtio-networking] Doorbell mapping of vDPA
>>
>> ----------------------------------------------------------------------
>> Hi all:
>>
>> To get native performance of VF, we need to map doorbell to guest to avoid unnecessary vmexit. In
>> order to do this, we will launch qemu with page-per-vq=on. This means the each doorbell register
>> should be located at the beginning of 4K page and does not share the page with other registers. Then
>> vDPA framework can safely map it into the guest physical address (GPA) range defined by qemu. It
>> could be either
>>
>> 1) a single doorbell register that is used by all virtqueues
>>
>> or
>>
>> 2) several different per-vq doorbell registers
>>
>> If you decide to implement a virtio-pci register layout, need to make sure for notification structure
>> (4.1.4.4 of virtio spec):
>>
>> For each virtqueue, the result
>> ofcap.offset+queue_notify_off*notify_off_multiplier is PAGE_SIZE (e.g
>> 4K) alignment, and the doorbeel does not share the page with other registers.
>>
>> And it would be better if queue_notify_off, notify_off_multiplier can be changed via firmware for
>> extra flexibility.
>>
> In some cases, these conditions could not be met for a virtio-net hardware device over PCI transport.
> queue_notify and notify_off_multiplier could not always be fully controlled by the firmware. There could be hardware limitations on flexibility degree of these parameters.
> Specifically, the limitations I'm thinking of are:
> * queue_notify_off>0 and notify_off_multiplier>0
> * Several doorbell registers of several virtqueues share the same page (but don't share the page with other registers).
>
> Can this be supported in vDPA with direct doorbell mapping?
I think this could be supported, we can introduce the API to:
1) let qemu to mmap() the notification pages to userspace
2) let qemu query the location of each notification registers, and
decide whether or not it could be modeled by the transport. E.g in your
case, if the transport is virtio-pci, it can be supported.
Thanks
>
> Thanks
>
>> Please check and make sure your hardware have such ability and feel free to ask if you have questions
>> (offline if necessary).
>>
>> Thanks
>>
>>
>>
>>
>>
>> _______________________________________________
>> Virtio-networking mailing list
>> Virtio-networking@redhat.com
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_virtio-
>> 2Dnetworking&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=lDHJ2FW52oJ3lqqsArgFRdcevq01tbLQAw
>> 4A_NO7xgI&m=pddgVCz-
>> orGTuUXATJ4Dmi7vAXatG9w47AmULNC3V9A&s=5mfYWbLCjcZO8FcwDqgAc5bjE-H-
>> 4p5TBkRZqP3uMsQ&e=
---------------------------------------------------------------------
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:[~2020-04-17 4:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BN6PR1801MB2067FCCE45316C25E5EB82F7C5DA0@BN6PR1801MB2067.namprd18.prod.outlook.com>
2020-04-14 16:20 ` [virtio-dev] Re: [Virtio-networking] Doorbell mapping of vDPA Michael S. Tsirkin
2020-04-17 4:19 ` Jason Wang
2020-04-17 4:22 ` Jason Wang
2020-04-17 6:39 ` Michael S. Tsirkin
2020-04-17 9:31 ` Jason Wang
2020-04-17 9:37 ` Michael S. Tsirkin
2020-04-17 9:59 ` Jason Wang
2020-04-17 10:06 ` Michael S. Tsirkin
2020-04-17 10:25 ` Jason Wang
2020-04-17 11:00 ` Michael S. Tsirkin
2020-04-20 2:03 ` Jason Wang
2020-04-20 5:33 ` Jason Wang
2020-04-17 6:37 ` Michael S. Tsirkin
2020-04-17 9:29 ` Jason Wang
2020-04-17 9:34 ` Michael S. Tsirkin
2020-04-17 4:15 ` Jason Wang [this message]
[not found] <BN6PR1801MB206742E4081B5E9D957A4FF1C5D90@BN6PR1801MB2067.namprd18.prod.outlook.com>
2020-04-17 8:25 ` Michael S. Tsirkin
[not found] <BN6PR1801MB206788CAF85BBE191D52BF33C5D90@BN6PR1801MB2067.namprd18.prod.outlook.com>
2020-04-17 9:30 ` Michael S. Tsirkin
[not found] <BN6PR1801MB2067D788CCD354CE6DE0CF52C5D90@BN6PR1801MB2067.namprd18.prod.outlook.com>
2020-04-17 13:17 ` Michael S. Tsirkin
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=5c682a37-04cc-e96f-e593-ec932caefbc7@redhat.com \
--to=jasowang@redhat.com \
--cc=aelior@marvell.com \
--cc=mst@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtio-networking@redhat.com \
--cc=vmireyno@marvell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.