> On Apr 15, 2021, at 2:51 AM, Laszlo Ersek <ler...@redhat.com> wrote:
>
> On 04/15/21 06:01, Ethin Probst wrote:
>> Hi Mike and Andrew,
>>
>> Thanks for your responses. I'm looking at the VirtIO block device now
>> but will certainly have a look at the others as well. We'll also need
>> to define a completely new protocol for audio, as well, as no existing
>> protocol will fit the bill. The generic protocol proposed by Andrew
>> might work, though I was thinking of a couple modifications: primarily
>> that the audio interface will most likely be asynchronous in nature.
>
> EFI_SIMPLE_NETWORK_PROTOCOL is a good design for a request queueing API.
> (One limitation that I could mention here is that it does not permit the
> queueing of the exact same buffer (= bus adress) multiple times at the
> same time, but that's not a grave limitation in practice.) For audio
> output inspiration, you could excise the "admin" type member functions,
> just focus on the queueing (also ignore Rx, only focus on Tx).
>
> And then I suggest reading "OvmfPkg/VirtioNetDxe/TechNotes.txt", which
> explains how EFI_SIMPLE_NETWORK_PROTOCOL is implemented for virtio-net.
> It's the most complex of the virtio drivers in OvmfPkg (regarding virtio
> exchanges), exactly because it needs to deal with bidirectional async
> transfer. You can ignore the Rx direction and just look at Tx.
>
> VirtioLib contains several utility functions. A subset of those
> functions is only useful to the simpler (synchronous) virtio drivers,
> such as virtio-blk, virtio-scsi, ..., that implement request-response
> patterns. Because virtio-net is asynchronous (it does real queueing,
> down from the EFI protocol interface), some of the request-response
> helper functions in VirtioLib do not apply.
>
> virtio-net is still used with polling; what's important to know is that
> it's not the driver itself that performs the repeated checking. The SNP
> protocol specifies three members that relate to polling; in all three
> cases, the polling is driven from outside of the driver.
>
> Tx polling is performed via EFI_SIMPLE_NETWORK.GetStatus(), it is called
> repeatedly by whatever agent is using SNP.
>
> Rx polling is performed either via EFI_SIMPLE_NETWORK.Receive() (called
> repeatedly by whatever agent is using SNP), or via the "WaitForPacket"
> event. The latter is still polling, only the loop is iternal the
> WaitForEvent() boot service. Anyway, Rx should be OK to ignore for now.
>
Laszlo,
In the audio case I think the driver can do its own polling so we don’t need to
copy the networking stack from that point of view, but as you point out it is a
good example of the VirtIo magic.
Also thanks for the more detailed pointers.
Thanks,
Andrew Fish
> Thanks
> Laszlo
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74133): https://edk2.groups.io/g/devel/message/74133
Mute This Topic: https://groups.io/mt/81710286/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
