OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] [RFC PATCH v2] virtio-rtc: Add device specification.


On 18.10.23 18:24, Parav Pandit wrote:
> 
> 
>> From: Peter Hilber <peter.hilber@opensynergy.com>
>> Sent: Wednesday, October 18, 2023 9:44 PM
>>
>> On 18.10.23 07:36, Parav Pandit wrote:
>>>
>>>>>>>>>> With "unclear responsibility" I meant to refer to the
>>>>>>>>>> responsibility for drafting a spec extension for virtio-net,
>>>>>>>>>
>>>>>>>>> You can count me to draft the virtio-net spec for responsibility.
>>>>>>>>> I am sure others would join as there is common interest across
>>>>>>>>> multiple device
>>>>>>>> implementors to support it.
>>>>>>>>> We know at least 4 stake holders have interests in it in
>>>>>>>>> virtio-net (Alibaba,
>>>>>>>> google, marvell, nvidia).
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK, thank you for the information.
>>>>>>>>
>>>>>>>> I think the arguments on how to have the RTC spec interact with
>>>>>>>> the net device are now on the table. Maybe the discussion could
>>>>>>>> continue on a draft spec extension for the net device?
>>>>>>>>
>>>>>>> I didnât follow the comment.
>>>>>>> My suggestion is lets draft the spec _now_ that covers rtc
>>>>>>> functionality as part
>>>>>> of virtio-net device and as independent rtc device.
>>>>>>> And if that requires me to work and draft the net part for you, I
>>>>>>> am here to
>>>>>> draft it.
>>>>>>>
>>>>>>> Would it work for you?
>>>>>>>
>>>>>>
>>>>>> Of course, work on the net part could also start now.
>>>>>>
>>>>>> I would prefer if the net part could be discussed as a dedicated
>>>>>> patch, on top of the patch(es) introducing the RTC device (and
>>>>>> referring to
>>>> those).
>>>>>>
>>>>> It will be separate patch (or patches) in device-type/net/description.tex.
>>>>> It should be part of same patch series as rtc and net so both
>>>>> devices agree
>>>> and reserve necessary opcode ranges etc to utilize same infra.
>>>>>
>>>>
>>>> I plan to send out RTC spec RFC v3, which should contain all the
>>>> agreed changes from the v2 discussion, in November. Maybe the net
>>>> related changes could then be put on top of that (and become part of a
>> common RFC v4)?
>>>>
>>> Sure, we can possibly converge before posting v3 itself so that v4 does not
>> require rewrite due to net.
>>> This can be done by drafting v3 in such a way that it fits the v4 scenario.
>>
>> AFAIU the only interoperability issue which was brought up in this discussion so
>> far, for which there was no explicit agreement on resolution, is how to
>> encapsulate RTC messages in the net controlq.
>>
>> For this I propose to encapsulate the RTC requests resp. responses in the net
>> controlq pseudo-fields command-specific-data resp.
>> command-specific-result. (command-specific-result is being introduced through
>> [1].)
>>
>> This handles natural alignment of the payload in a way which is compatible with
>>
>> - existing virtio-net controlq commands (including those being introduced
>>   by [1]), and
>>
>> - with the standalone virtio-rtc messages.
> 
> I will need to re-read the rtc v2, but the generic approach I had in mind is to take the ctrl vq opcode being common between net and rtc.
> And follow the net's cvq command response format (donât recall if fullfils rtc or not).
> And thatâs it. Rtc and net gets both same command, same response.
> Net will have feature bit to indicate this functionality exists, for rtc it is implicit as its being and rtc device.
>  

But that would force virtio-rtc to use the not padded request/reply headers
which the virtio-net controlq has, implying dedicated descriptors for
class/command and ack to still have natural alignment in
command-specific-data and command-specific-result.

	struct virtio_net_ctrl {
		u8 class;
		u8 command;
		u8 command-specific-data[];
		u8 ack;
		u8 command-specific-result[];
	};

To me, this looks like a net legacy issue, so it should be addressed in net
by encapsulating the aligned RTC request/response.

Thanks for your feedback,

Peter

>> [1] https://lore.kernel.org/virtio-comment/20231009013135.55890-1-
>> xuanzhuo@linux.alibaba.com/#iZ31device-types:net:description.tex


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]