* [virtio-comment] vsock: define a maximum size for the packet data
@ 2022-02-17 12:31 Loghin, Laura
2022-02-17 12:55 ` Stefano Garzarella
0 siblings, 1 reply; 11+ messages in thread
From: Loghin, Laura @ 2022-02-17 12:31 UTC (permalink / raw)
To: virtio-comment
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
Hello,
Would it be possible to define a maximum size for the packet data in the spec (for example the one from the Linux driver [1])? We are working on a vsock packet implementation in rust-vmm [2], and we would like to check for some sort of limit for the data packet,
without using the limit from a specific driver implementation. We want to do this so that the driver is not allowed to reserve huge chunks of memory. VMMs might want to reject packets that have bigger data arrays. This limit could probably be defined in the VMM as well, and then propagated/checked where it is needed, but it would be nicer to have one at the spec level.
Thanks,
Laura
[1] https://elixir.bootlin.com/linux/v4.9.12/source/include/linux/virtio_vsock.h#L14
[2] https://github.com/rust-vmm/vm-virtio/pull/131
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
[-- Attachment #2: Type: text/html, Size: 1669 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-02-17 12:31 [virtio-comment] vsock: define a maximum size for the packet data Loghin, Laura
@ 2022-02-17 12:55 ` Stefano Garzarella
2022-02-22 8:18 ` Arseniy Krasnov
0 siblings, 1 reply; 11+ messages in thread
From: Stefano Garzarella @ 2022-02-17 12:55 UTC (permalink / raw)
To: Loghin, Laura; +Cc: virtio-comment
On Thu, Feb 17, 2022 at 12:31:20PM +0000, Loghin, Laura wrote:
>Hello,
>
>Would it be possible to define a maximum size for the packet data in
>the spec (for example the one from the Linux driver [1])? We are
>working on a vsock packet implementation in rust-vmm [2], and we would
>like to check for some sort of limit for the data packet,
>
>without using the limit from a specific driver implementation. We want
>to do this so that the driver is not allowed to reserve huge chunks of
>memory. VMMs might want to reject packets that have bigger data arrays.
>This limit could probably be defined in the VMM as well, and then
>propagated/checked where it is needed, but it would be nicer to have
>one at the spec level.
>
Yep, I think it is possible, but maybe to limit the memory used in the
guest, it would be better to add a field in the configuration space to
define the maximum packet size (like MTU for virtio-net) for each
device.
At that point we can also add a maximum that seems reasonable. For now I
think the theoretical maximum is 4GB since the len field is on 32bit,
obviously not a real limit :-)
Thanks,
Stefano
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-02-17 12:55 ` Stefano Garzarella
@ 2022-02-22 8:18 ` Arseniy Krasnov
2022-02-22 8:46 ` Loghin, Laura
0 siblings, 1 reply; 11+ messages in thread
From: Arseniy Krasnov @ 2022-02-22 8:18 UTC (permalink / raw)
To: Stefano Garzarella, Loghin, Laura; +Cc: virtio-comment
Hello
On 17.02.2022 15:55, Stefano Garzarella wrote:
> On Thu, Feb 17, 2022 at 12:31:20PM +0000, Loghin, Laura wrote:
>> Hello,
>>
>> Would it be possible to define a maximum size for the packet data in the spec (for example the one from the Linux driver [1])? We are working on a vsock packet implementation in rust-vmm [2], and we would like to check for some sort of limit for the data packet,
>>
>> without using the limit from a specific driver implementation. We want to do this so that the driver is not allowed to reserve huge chunks of memory. VMMs might want to reject packets that have bigger data arrays. This limit could probably be defined in the VMM as well, and then propagated/checked where it is needed, but it would be nicer to have one at the spec level.
>>
>
> Yep, I think it is possible, but maybe to limit the memory used in the guest, it would be better to add a field in the configuration space to define the maximum packet size (like MTU for virtio-net) for each device.
>
So, rely on current implementation, virtio vsock rx buffers will be allocated with this size from config? And also both peers must negotiate this value(like credit size), to avoid packets drop?
Thank You
> At that point we can also add a maximum that seems reasonable. For now I think the theoretical maximum is 4GB since the len field is on 32bit, obviously not a real limit :-)
>
> Thanks,
> Stefano
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-02-22 8:18 ` Arseniy Krasnov
@ 2022-02-22 8:46 ` Loghin, Laura
2022-02-22 9:20 ` Arseniy Krasnov
2022-02-23 8:57 ` Stefano Garzarella
0 siblings, 2 replies; 11+ messages in thread
From: Loghin, Laura @ 2022-02-22 8:46 UTC (permalink / raw)
To: Arseniy Krasnov, Stefano Garzarella; +Cc: virtio-comment
Hello,
I was thinking that this limit would be used on the TX path (because on the RX, the device is considered to be trusted it will add a shorter buffer). The size of the TX buffer would still be the one from the header or from its descriptor (this is another thing that I think should be explicitly mentioned in the spec even though it's pretty obvious; there is no mention at this moment about what `len` is). The driver would be "forced" by that limit to not send bigger buffers, but we can have like a double-check in the device code that this is indeed happening.
Laura
________________________________________
From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-open.org> on behalf of Arseniy Krasnov <oxffffaa@gmail.com>
Sent: Tuesday, February 22, 2022 10:18 AM
To: Stefano Garzarella; Loghin, Laura
Cc: virtio-comment@lists.oasis-open.org
Subject: RE: [EXTERNAL] [virtio-comment] vsock: define a maximum size for the packet data
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Hello
On 17.02.2022 15:55, Stefano Garzarella wrote:
> On Thu, Feb 17, 2022 at 12:31:20PM +0000, Loghin, Laura wrote:
>> Hello,
>>
>> Would it be possible to define a maximum size for the packet data in the spec (for example the one from the Linux driver [1])? We are working on a vsock packet implementation in rust-vmm [2], and we would like to check for some sort of limit for the data packet,
>>
>> without using the limit from a specific driver implementation. We want to do this so that the driver is not allowed to reserve huge chunks of memory. VMMs might want to reject packets that have bigger data arrays. This limit could probably be defined in the VMM as well, and then propagated/checked where it is needed, but it would be nicer to have one at the spec level.
>>
>
> Yep, I think it is possible, but maybe to limit the memory used in the guest, it would be better to add a field in the configuration space to define the maximum packet size (like MTU for virtio-net) for each device.
>
So, rely on current implementation, virtio vsock rx buffers will be allocated with this size from config? And also both peers must negotiate this value(like credit size), to avoid packets drop?
Thank You
> At that point we can also add a maximum that seems reasonable. For now I think the theoretical maximum is 4GB since the len field is on 32bit, obviously not a real limit :-)
>
> Thanks,
> Stefano
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-02-22 8:46 ` Loghin, Laura
@ 2022-02-22 9:20 ` Arseniy Krasnov
2022-02-23 8:57 ` Stefano Garzarella
1 sibling, 0 replies; 11+ messages in thread
From: Arseniy Krasnov @ 2022-02-22 9:20 UTC (permalink / raw)
To: Loghin, Laura, Stefano Garzarella; +Cc: virtio-comment
On 22.02.2022 11:46, Loghin, Laura wrote:
> Hello,
>
> I was thinking that this limit would be used on the TX path (because on the RX, the device is considered to be trusted it will add a shorter buffer). The size of the TX buffer would still be the one from the header or from its descriptor (this is another thing that I think should be explicitly mentioned in the spec even though it's pretty obvious; there is no mention at this moment about what `len` is). The driver would be "forced" by that limit to not send bigger buffers, but we can have like a double-check in the device code that this is indeed happening.
I see, this will be new check in 'virtio_transport_alloc_pkt()' when it calls kmalloc() for packet buffer?
>
> Laura
>
> ________________________________________
> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-open.org> on behalf of Arseniy Krasnov <oxffffaa@gmail.com>
> Sent: Tuesday, February 22, 2022 10:18 AM
> To: Stefano Garzarella; Loghin, Laura
> Cc: virtio-comment@lists.oasis-open.org
> Subject: RE: [EXTERNAL] [virtio-comment] vsock: define a maximum size for the packet data
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> Hello
>
> On 17.02.2022 15:55, Stefano Garzarella wrote:
>> On Thu, Feb 17, 2022 at 12:31:20PM +0000, Loghin, Laura wrote:
>>> Hello,
>>>
>>> Would it be possible to define a maximum size for the packet data in the spec (for example the one from the Linux driver [1])? We are working on a vsock packet implementation in rust-vmm [2], and we would like to check for some sort of limit for the data packet,
>>>
>>> without using the limit from a specific driver implementation. We want to do this so that the driver is not allowed to reserve huge chunks of memory. VMMs might want to reject packets that have bigger data arrays. This limit could probably be defined in the VMM as well, and then propagated/checked where it is needed, but it would be nicer to have one at the spec level.
>>>
>> Yep, I think it is possible, but maybe to limit the memory used in the guest, it would be better to add a field in the configuration space to define the maximum packet size (like MTU for virtio-net) for each device.
>>
> So, rely on current implementation, virtio vsock rx buffers will be allocated with this size from config? And also both peers must negotiate this value(like credit size), to avoid packets drop?
>
>
> Thank You
>
>> At that point we can also add a maximum that seems reasonable. For now I think the theoretical maximum is 4GB since the len field is on 32bit, obviously not a real limit :-)
>>
>> Thanks,
>> Stefano
>>
>>
>> This publicly archived list offers a means to provide input to the
>> OASIS Virtual I/O Device (VIRTIO) TC.
>>
>> In order to verify user consent to the Feedback License terms and
>> to minimize spam in the list archive, subscription is required
>> before posting.
>>
>> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
>> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
>> List help: virtio-comment-help@lists.oasis-open.org
>> List archive: https://lists.oasis-open.org/archives/virtio-comment/
>> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
>> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
>> Committee: https://www.oasis-open.org/committees/virtio/
>> Join OASIS: https://www.oasis-open.org/join/
>>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>
>
>
>
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
>
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-02-22 8:46 ` Loghin, Laura
2022-02-22 9:20 ` Arseniy Krasnov
@ 2022-02-23 8:57 ` Stefano Garzarella
2022-02-23 13:38 ` Loghin, Laura
1 sibling, 1 reply; 11+ messages in thread
From: Stefano Garzarella @ 2022-02-23 8:57 UTC (permalink / raw)
To: Loghin, Laura; +Cc: Arseniy Krasnov, virtio-comment
On Tue, Feb 22, 2022 at 08:46:29AM +0000, Loghin, Laura wrote:
>
>Hello,
>
>I was thinking that this limit would be used on the TX path (because on
>the RX, the device is considered to be trusted it will add a shorter
>buffer). The size of the TX buffer would still be the one from the
>header or from its descriptor (this is another thing that I think
>should be explicitly mentioned in the spec even though it's pretty
>obvious; there is no mention at this moment about what `len` is). The
The size of the TX buffers should be the one from the descriptor. (Now
we are using 2 buffers, one for the header and one for the payload, but
it is an implementation details).
Then the `len` field in the header contains the amount of bytes used for
the payload. So the buffer could be bigger then (hdr + payload).
For TX in the current implementation it never happens because of the way
the Linux driver is written, but for RX it happens just this, because
the driver allocates the buffer and the device can use only a part of
it.
However I agree that we could describe the `len` field better in the
specs, also because it's currently not really described.
If you want to send a patch, that would be great!
Thanks,
Stefano
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-02-23 8:57 ` Stefano Garzarella
@ 2022-02-23 13:38 ` Loghin, Laura
2022-03-22 9:57 ` Loghin, Laura
0 siblings, 1 reply; 11+ messages in thread
From: Loghin, Laura @ 2022-02-23 13:38 UTC (permalink / raw)
To: Stefano Garzarella; +Cc: Arseniy Krasnov, virtio-comment
Hello,
Yes I'll send a patch next week, these days I'll be on vacation.
Thank you,
Laura
________________________________________
From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-open.org> on behalf of Stefano Garzarella <sgarzare@redhat.com>
Sent: Wednesday, February 23, 2022 10:57 AM
To: Loghin, Laura
Cc: Arseniy Krasnov; virtio-comment@lists.oasis-open.org
Subject: RE: [EXTERNAL] [virtio-comment] vsock: define a maximum size for the packet data
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On Tue, Feb 22, 2022 at 08:46:29AM +0000, Loghin, Laura wrote:
>
>Hello,
>
>I was thinking that this limit would be used on the TX path (because on
>the RX, the device is considered to be trusted it will add a shorter
>buffer). The size of the TX buffer would still be the one from the
>header or from its descriptor (this is another thing that I think
>should be explicitly mentioned in the spec even though it's pretty
>obvious; there is no mention at this moment about what `len` is). The
The size of the TX buffers should be the one from the descriptor. (Now
we are using 2 buffers, one for the header and one for the payload, but
it is an implementation details).
Then the `len` field in the header contains the amount of bytes used for
the payload. So the buffer could be bigger then (hdr + payload).
For TX in the current implementation it never happens because of the way
the Linux driver is written, but for RX it happens just this, because
the driver allocates the buffer and the device can use only a part of
it.
However I agree that we could describe the `len` field better in the
specs, also because it's currently not really described.
If you want to send a patch, that would be great!
Thanks,
Stefano
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-02-23 13:38 ` Loghin, Laura
@ 2022-03-22 9:57 ` Loghin, Laura
2022-03-28 11:14 ` Stefano Garzarella
0 siblings, 1 reply; 11+ messages in thread
From: Loghin, Laura @ 2022-03-22 9:57 UTC (permalink / raw)
To: Stefano Garzarella; +Cc: Arseniy Krasnov, virtio-comment
Hi,
Sorry for the super late reply! I just sent the patch for the `len` description [1].
Regarding the max size for the packet data, the proposal for adding a field in the config space sounds good to me. What would be some next steps here? Should I send a patch for this one as well? From what I understand, we would define a new feature for the max size, and
add a new field in the config space. Did I misunderstand it?
Thanks,
Laura
[1] https://lists.oasis-open.org/archives/virtio-comment/202203/msg00073.html
________________________________________
From: Loghin, Laura
Sent: Wednesday, February 23, 2022 3:38 PM
To: Stefano Garzarella
Cc: Arseniy Krasnov; virtio-comment@lists.oasis-open.org
Subject: Re: [EXTERNAL] [virtio-comment] vsock: define a maximum size for the packet data
Hello,
Yes I'll send a patch next week, these days I'll be on vacation.
Thank you,
Laura
________________________________________
From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-open.org> on behalf of Stefano Garzarella <sgarzare@redhat.com>
Sent: Wednesday, February 23, 2022 10:57 AM
To: Loghin, Laura
Cc: Arseniy Krasnov; virtio-comment@lists.oasis-open.org
Subject: RE: [EXTERNAL] [virtio-comment] vsock: define a maximum size for the packet data
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On Tue, Feb 22, 2022 at 08:46:29AM +0000, Loghin, Laura wrote:
>
>Hello,
>
>I was thinking that this limit would be used on the TX path (because on
>the RX, the device is considered to be trusted it will add a shorter
>buffer). The size of the TX buffer would still be the one from the
>header or from its descriptor (this is another thing that I think
>should be explicitly mentioned in the spec even though it's pretty
>obvious; there is no mention at this moment about what `len` is). The
The size of the TX buffers should be the one from the descriptor. (Now
we are using 2 buffers, one for the header and one for the payload, but
it is an implementation details).
Then the `len` field in the header contains the amount of bytes used for
the payload. So the buffer could be bigger then (hdr + payload).
For TX in the current implementation it never happens because of the way
the Linux driver is written, but for RX it happens just this, because
the driver allocates the buffer and the device can use only a part of
it.
However I agree that we could describe the `len` field better in the
specs, also because it's currently not really described.
If you want to send a patch, that would be great!
Thanks,
Stefano
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-03-22 9:57 ` Loghin, Laura
@ 2022-03-28 11:14 ` Stefano Garzarella
2022-04-04 13:55 ` Laura Loghin
0 siblings, 1 reply; 11+ messages in thread
From: Stefano Garzarella @ 2022-03-28 11:14 UTC (permalink / raw)
To: Loghin, Laura; +Cc: Arseniy Krasnov, virtio-comment
On Tue, Mar 22, 2022 at 10:58 AM Loghin, Laura <lauralg@amazon.com> wrote:
>
> Hi,
>
> Sorry for the super late reply! I just sent the patch for the `len` description [1].
>
> Regarding the max size for the packet data, the proposal for adding a field in the config space sounds good to me. What would be some next steps here? Should I send a patch for this one as well?
Yes, please.
> From what I understand, we would define a new feature for the max size, and
> add a new field in the config space. Did I misunderstand it?
That's what I would do :-)
When the feature is negotiated, then the driver should not send
packets and allocate RX buffers larger than that size.
Thanks,
Stefano
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-03-28 11:14 ` Stefano Garzarella
@ 2022-04-04 13:55 ` Laura Loghin
2022-04-06 7:42 ` Stefano Garzarella
0 siblings, 1 reply; 11+ messages in thread
From: Laura Loghin @ 2022-04-04 13:55 UTC (permalink / raw)
To: Stefano Garzarella; +Cc: Arseniy Krasnov, virtio-comment
[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]
On 3/28/22 14:14, Stefano Garzarella wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Tue, Mar 22, 2022 at 10:58 AM Loghin, Laura<lauralg@amazon.com> wrote:
>> Hi,
>>
>> Sorry for the super late reply! I just sent the patch for the `len` description [1].
>>
>> Regarding the max size for the packet data, the proposal for adding a field in the config space sounds good to me. What would be some next steps here? Should I send a patch for this one as well?
> Yes, please.
>
>> From what I understand, we would define a new feature for the max size, and
>> add a new field in the config space. Did I misunderstand it?
> That's what I would do :-)
> When the feature is negotiated, then the driver should not send
> packets and allocate RX buffers larger than that size.
>
> Thanks,
> Stefano
>
Hi,
I just sent a patch for the max size config field:https://lists.oasis-open.org/archives/virtio-comment/202204/msg00010.html.
It mostly follows the spec format for MTU. For the max value I used for now the one defined in linux, but should we actually go with a higher one?
Thank you,
Laura
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
[-- Attachment #2: Type: text/html, Size: 2287 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [virtio-comment] vsock: define a maximum size for the packet data
2022-04-04 13:55 ` Laura Loghin
@ 2022-04-06 7:42 ` Stefano Garzarella
0 siblings, 0 replies; 11+ messages in thread
From: Stefano Garzarella @ 2022-04-06 7:42 UTC (permalink / raw)
To: Laura Loghin; +Cc: Arseniy Krasnov, virtio-comment
On Mon, Apr 4, 2022 at 3:55 PM Laura Loghin <lauralg@amazon.com> wrote:
>
> On 3/28/22 14:14, Stefano Garzarella wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Tue, Mar 22, 2022 at 10:58 AM Loghin, Laura <lauralg@amazon.com> wrote:
>
> Hi,
>
> Sorry for the super late reply! I just sent the patch for the `len` description [1].
>
> Regarding the max size for the packet data, the proposal for adding a field in the config space sounds good to me. What would be some next steps here? Should I send a patch for this one as well?
>
> Yes, please.
>
> From what I understand, we would define a new feature for the max size, and
> add a new field in the config space. Did I misunderstand it?
>
> That's what I would do :-)
> When the feature is negotiated, then the driver should not send
> packets and allocate RX buffers larger than that size.
>
> Thanks,
> Stefano
>
> Hi,
>
> I just sent a patch for the max size config field: https://lists.oasis-open.org/archives/virtio-comment/202204/msg00010.html.
Great! I'll review in the next few days.
> It mostly follows the spec format for MTU. For the max value I used for now the one defined in linux, but should we actually go with a higher one?
Maybe yes, but having the same default value as the current one maybe
simplifies the driver/device for backward compatibility?
Let's discuss it on the patch.
Thanks,
Stefano
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-04-06 7:42 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-17 12:31 [virtio-comment] vsock: define a maximum size for the packet data Loghin, Laura
2022-02-17 12:55 ` Stefano Garzarella
2022-02-22 8:18 ` Arseniy Krasnov
2022-02-22 8:46 ` Loghin, Laura
2022-02-22 9:20 ` Arseniy Krasnov
2022-02-23 8:57 ` Stefano Garzarella
2022-02-23 13:38 ` Loghin, Laura
2022-03-22 9:57 ` Loghin, Laura
2022-03-28 11:14 ` Stefano Garzarella
2022-04-04 13:55 ` Laura Loghin
2022-04-06 7:42 ` Stefano Garzarella
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.