From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 9798098647D for ; Thu, 17 Feb 2022 12:31:34 +0000 (UTC) From: "Loghin, Laura" Date: Thu, 17 Feb 2022 12:31:20 +0000 Message-ID: <1645101080313.3853@amazon.com> MIME-Version: 1.0 Subject: [virtio-comment] vsock: define a maximum size for the packet data Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_16451010803133853amazoncom_" To: "virtio-comment@lists.oasis-open.org" List-ID: --_000_16451010803133853amazoncom_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello, Would it be possible to define a maximum size for the packet data in the sp= ec (for example the one from the Linux driver [1])? We are working on a vso= ck packet implementation in rust-vmm [2], and we would like to check for so= me sort of limit for the data packet, without using the limit from a specific driver implementation. We want to d= o 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 w= here 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_vs= ock.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 R= omania. Registration number J22/2621/2005. --_000_16451010803133853amazoncom_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

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 t= o do this so that the driver is not allowed to reserve huge chunks of memor= y. VMMs might want to reject packets that have bigger data arrays. This lim= it could probably be defined in the VMM as well, and then propagated/checked where it is needed, but it wo= uld 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://g= ithub.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 R= omania. Registration number J22/2621/2005.

--_000_16451010803133853amazoncom_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id DC73F98647D for ; Thu, 17 Feb 2022 12:55:15 +0000 (UTC) Date: Thu, 17 Feb 2022 13:55:06 +0100 From: Stefano Garzarella Message-ID: <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> References: <1645101080313.3853@amazon.com> MIME-Version: 1.0 In-Reply-To: <1645101080313.3853@amazon.com> Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline To: "Loghin, Laura" Cc: "virtio-comment@lists.oasis-open.org" List-ID: 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 6C8C298638B for ; Tue, 22 Feb 2022 08:18:22 +0000 (UTC) References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> From: Arseniy Krasnov Message-ID: <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> Date: Tue, 22 Feb 2022 11:18:09 +0300 MIME-Version: 1.0 In-Reply-To: <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable To: Stefano Garzarella , "Loghin, Laura" Cc: "virtio-comment@lists.oasis-open.org" List-ID: 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 t= o do this so that the driver is not allowed to reserve huge chunks of memor= y. VMMs might want to reject packets that have bigger data arrays.=C2=A0 Th= is 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 l= evel. >> > > Yep, I think it is possible, but maybe to limit the memory used in the gu= est, 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 allocat= ed with this size from config? And also both peers must negotiate this valu= e(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, obvio= usly 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-l= ists > 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-lis= ts Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id CE21898638E for ; Tue, 22 Feb 2022 08:46:46 +0000 (UTC) From: "Loghin, Laura" Date: Tue, 22 Feb 2022 08:46:29 +0000 Message-ID: <1645519589258.8467@amazon.com> References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat>,<0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> In-Reply-To: <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> MIME-Version: 1.0 Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Arseniy Krasnov , Stefano Garzarella Cc: "virtio-comment@lists.oasis-open.org" List-ID: 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 it= s descriptor (this is another thing that I think should be explicitly menti= oned in the spec even though it's pretty obvious; there is no mention at th= is 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 devi= ce code that this is indeed happening. Laura ________________________________________ From: virtio-comment@lists.oasis-open.org on behalf of Arseniy Krasnov 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 t= he packet data CAUTION: This email originated from outside of the organization. Do not cli= ck 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 t= o do this so that the driver is not allowed to reserve huge chunks of memor= y. VMMs might want to reject packets that have bigger data arrays. This li= mit could probably be defined in the VMM as well, and then propagated/check= ed 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 gu= est, 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 allocat= ed with this size from config? And also both peers must negotiate this valu= e(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, obvio= usly 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-l= ists > 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-lis= ts 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 R= omania. Registration number J22/2621/2005. This publicly archived list offers a means to provide input to the=0D OASIS Virtual I/O Device (VIRTIO) TC.=0D =0D In order to verify user consent to the Feedback License terms and=0D to minimize spam in the list archive, subscription is required=0D before posting.=0D =0D Subscribe: virtio-comment-subscribe@lists.oasis-open.org=0D Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org=0D List help: virtio-comment-help@lists.oasis-open.org=0D List archive: https://lists.oasis-open.org/archives/virtio-comment/=0D Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf= =0D List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lis= ts=0D Committee: https://www.oasis-open.org/committees/virtio/=0D Join OASIS: https://www.oasis-open.org/join/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 58D709863B5 for ; Tue, 22 Feb 2022 09:20:27 +0000 (UTC) References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> <1645519589258.8467@amazon.com> From: Arseniy Krasnov Message-ID: <7ce12c17-a25e-379d-23df-38015dc2d86e@gmail.com> Date: Tue, 22 Feb 2022 12:20:20 +0300 MIME-Version: 1.0 In-Reply-To: <1645519589258.8467@amazon.com> Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US To: "Loghin, Laura" , Stefano Garzarella Cc: "virtio-comment@lists.oasis-open.org" List-ID: 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 on behalf of Arseniy Krasnov > 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id E14B3986413 for ; Wed, 23 Feb 2022 08:57:32 +0000 (UTC) Date: Wed, 23 Feb 2022 09:57:25 +0100 From: Stefano Garzarella Message-ID: <20220223085725.22vwp72qo7m6noq7@sgarzare-redhat> References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> <1645519589258.8467@amazon.com> MIME-Version: 1.0 In-Reply-To: <1645519589258.8467@amazon.com> Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline To: "Loghin, Laura" Cc: Arseniy Krasnov , "virtio-comment@lists.oasis-open.org" List-ID: 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id C48D5986416 for ; Wed, 23 Feb 2022 13:39:09 +0000 (UTC) From: "Loghin, Laura" Date: Wed, 23 Feb 2022 13:38:57 +0000 Message-ID: <1645623537015.64403@amazon.com> References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> <1645519589258.8467@amazon.com>,<20220223085725.22vwp72qo7m6noq7@sgarzare-redhat> In-Reply-To: <20220223085725.22vwp72qo7m6noq7@sgarzare-redhat> MIME-Version: 1.0 Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Stefano Garzarella Cc: Arseniy Krasnov , "virtio-comment@lists.oasis-open.org" List-ID: 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 on behalf of Stefano Garzarella 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 t= he packet data CAUTION: This email originated from outside of the organization. Do not cli= ck 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-lis= ts 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 R= omania. Registration number J22/2621/2005. This publicly archived list offers a means to provide input to the=0D OASIS Virtual I/O Device (VIRTIO) TC.=0D =0D In order to verify user consent to the Feedback License terms and=0D to minimize spam in the list archive, subscription is required=0D before posting.=0D =0D Subscribe: virtio-comment-subscribe@lists.oasis-open.org=0D Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org=0D List help: virtio-comment-help@lists.oasis-open.org=0D List archive: https://lists.oasis-open.org/archives/virtio-comment/=0D Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf= =0D List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lis= ts=0D Committee: https://www.oasis-open.org/committees/virtio/=0D Join OASIS: https://www.oasis-open.org/join/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id D00DE9863D4 for ; Tue, 22 Mar 2022 09:58:05 +0000 (UTC) From: "Loghin, Laura" Date: Tue, 22 Mar 2022 09:57:59 +0000 Message-ID: <1647943078836.86626@amazon.com> References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> <1645519589258.8467@amazon.com>,<20220223085725.22vwp72qo7m6noq7@sgarzare-redhat>,<1645623537015.64403@amazon.com> In-Reply-To: <1645623537015.64403@amazon.com> MIME-Version: 1.0 Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Stefano Garzarella Cc: Arseniy Krasnov , "virtio-comment@lists.oasis-open.org" List-ID: Hi, Sorry for the super late reply! I just sent the patch for the `len` descrip= tion [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 wou= ld 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.ht= ml =20 ________________________________________ 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 t= he 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 on behalf of Stefano Garzarella 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 t= he packet data CAUTION: This email originated from outside of the organization. Do not cli= ck 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-lis= ts 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 R= omania. Registration number J22/2621/2005. This publicly archived list offers a means to provide input to the=0D OASIS Virtual I/O Device (VIRTIO) TC.=0D =0D In order to verify user consent to the Feedback License terms and=0D to minimize spam in the list archive, subscription is required=0D before posting.=0D =0D Subscribe: virtio-comment-subscribe@lists.oasis-open.org=0D Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org=0D List help: virtio-comment-help@lists.oasis-open.org=0D List archive: https://lists.oasis-open.org/archives/virtio-comment/=0D Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf= =0D List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lis= ts=0D Committee: https://www.oasis-open.org/committees/virtio/=0D Join OASIS: https://www.oasis-open.org/join/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 654BC986269 for ; Mon, 28 Mar 2022 11:14:56 +0000 (UTC) MIME-Version: 1.0 References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> <1645519589258.8467@amazon.com> <20220223085725.22vwp72qo7m6noq7@sgarzare-redhat> <1645623537015.64403@amazon.com> <1647943078836.86626@amazon.com> In-Reply-To: <1647943078836.86626@amazon.com> From: Stefano Garzarella Date: Mon, 28 Mar 2022 13:14:40 +0200 Message-ID: Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Type: text/plain; charset="UTF-8" To: "Loghin, Laura" Cc: Arseniy Krasnov , "virtio-comment@lists.oasis-open.org" List-ID: On Tue, Mar 22, 2022 at 10:58 AM Loghin, Laura 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id A5206986281 for ; Mon, 4 Apr 2022 13:55:49 +0000 (UTC) Message-ID: <29c47acc-b9fe-2787-3fae-52e666a54955@amazon.com> Date: Mon, 4 Apr 2022 16:55:24 +0300 MIME-Version: 1.0 References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> <1645519589258.8467@amazon.com> <20220223085725.22vwp72qo7m6noq7@sgarzare-redhat> <1645623537015.64403@amazon.com> <1647943078836.86626@amazon.com> From: Laura Loghin In-Reply-To: Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Type: multipart/alternative; boundary="------------QHiGTdjYlNj0UtrtXxPv4BKp" Content-Language: en-US To: Stefano Garzarella Cc: Arseniy Krasnov , "virtio-comment@lists.oasis-open.org" List-ID: --------------QHiGTdjYlNj0UtrtXxPv4BKp MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: base64 T24gMy8yOC8yMiAxNDoxNCwgU3RlZmFubyBHYXJ6YXJlbGxhIHdyb3RlOgo+IENBVVRJT046IFRo aXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8g bm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSBjYW4gY29uZmly bSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuCj4KPgo+Cj4gT24gVHVl LCBNYXIgMjIsIDIwMjIgYXQgMTA6NTggQU0gTG9naGluLCBMYXVyYTxsYXVyYWxnQGFtYXpvbi5j b20+ICB3cm90ZToKPj4gSGksCj4+Cj4+IFNvcnJ5IGZvciB0aGUgc3VwZXIgbGF0ZSByZXBseSEg SSBqdXN0IHNlbnQgdGhlIHBhdGNoIGZvciB0aGUgYGxlbmAgZGVzY3JpcHRpb24gWzFdLgo+Pgo+ PiBSZWdhcmRpbmcgdGhlIG1heCBzaXplIGZvciB0aGUgcGFja2V0IGRhdGEsIHRoZSBwcm9wb3Nh bCBmb3IgYWRkaW5nIGEgZmllbGQgaW4gdGhlIGNvbmZpZyBzcGFjZSBzb3VuZHMgZ29vZCB0byBt ZS4gV2hhdCB3b3VsZCBiZSBzb21lIG5leHQgc3RlcHMgaGVyZT8gU2hvdWxkIEkgc2VuZCBhIHBh dGNoIGZvciB0aGlzIG9uZSBhcyB3ZWxsPwo+IFllcywgcGxlYXNlLgo+Cj4+ICBGcm9tIHdoYXQg SSB1bmRlcnN0YW5kLCB3ZSB3b3VsZCBkZWZpbmUgYSBuZXcgZmVhdHVyZSBmb3IgdGhlIG1heCBz aXplLCBhbmQKPj4gYWRkIGEgbmV3IGZpZWxkIGluIHRoZSBjb25maWcgc3BhY2UuIERpZCBJIG1p c3VuZGVyc3RhbmQgaXQ/Cj4gVGhhdCdzIHdoYXQgSSB3b3VsZCBkbyA6LSkKPiBXaGVuIHRoZSBm ZWF0dXJlIGlzIG5lZ290aWF0ZWQsIHRoZW4gdGhlIGRyaXZlciBzaG91bGQgbm90IHNlbmQKPiBw YWNrZXRzIGFuZCBhbGxvY2F0ZSBSWCBidWZmZXJzIGxhcmdlciB0aGFuIHRoYXQgc2l6ZS4KPgo+ IFRoYW5rcywKPiBTdGVmYW5vCj4KSGksCgpJIGp1c3Qgc2VudCBhIHBhdGNoIGZvciB0aGUgbWF4 IHNpemUgY29uZmlnIGZpZWxkOmh0dHBzOi8vbGlzdHMub2FzaXMtb3Blbi5vcmcvYXJjaGl2ZXMv dmlydGlvLWNvbW1lbnQvMjAyMjA0L21zZzAwMDEwLmh0bWwuCkl0IG1vc3RseSBmb2xsb3dzIHRo ZSBzcGVjIGZvcm1hdCBmb3IgTVRVLiBGb3IgdGhlIG1heCB2YWx1ZSBJIHVzZWQgZm9yIG5vdyB0 aGUgb25lIGRlZmluZWQgaW4gbGludXgsIGJ1dCBzaG91bGQgd2UgYWN0dWFsbHkgZ28gd2l0aCBh IGhpZ2hlciBvbmU/CgpUaGFuayB5b3UsCkxhdXJhCgoKCgpBbWF6b24gRGV2ZWxvcG1lbnQgQ2Vu dGVyIChSb21hbmlhKSBTLlIuTC4gcmVnaXN0ZXJlZCBvZmZpY2U6IDI3QSBTZi4gTGF6YXIgU3Ry ZWV0LCBVQkM1LCBmbG9vciAyLCBJYXNpLCBJYXNpIENvdW50eSwgNzAwMDQ1LCBSb21hbmlhLiBS ZWdpc3RlcmVkIGluIFJvbWFuaWEuIFJlZ2lzdHJhdGlvbiBudW1iZXIgSjIyLzI2MjEvMjAwNS4K --------------QHiGTdjYlNj0UtrtXxPv4BKp MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRl bnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPGRp diBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAzLzI4LzIyIDE0OjE0LCBTdGVmYW5vIEdhcnph cmVsbGEKICAgICAgd3JvdGU6PGJyPgogICAgPC9kaXY+CiAgICA8YmxvY2txdW90ZSB0eXBlPSJj aXRlIgpjaXRlPSJtaWQ6Q0FHeFUyRjVtM1pUVjhGQlZNX1RxNXdWMXNXeFVCanhtc2RhLUJjakNW ZjdFRmN5LURBQG1haWwuZ21haWwuY29tIj4KICAgICAgPHByZSBjbGFzcz0ibW96LXF1b3RlLXBy ZSIgd3JhcD0iIj5DQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9m IHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRz IHVubGVzcyB5b3UgY2FuIGNvbmZpcm0gdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBp cyBzYWZlLgoKCgpPbiBUdWUsIE1hciAyMiwgMjAyMiBhdCAxMDo1OCBBTSBMb2doaW4sIExhdXJh IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpsYXVyYWxnQGFt YXpvbi5jb20iPiZsdDtsYXVyYWxnQGFtYXpvbi5jb20mZ3Q7PC9hPiB3cm90ZToKPC9wcmU+CiAg ICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICAgIDxwcmUgY2xhc3M9Im1vei1xdW90 ZS1wcmUiIHdyYXA9IiI+CkhpLAoKU29ycnkgZm9yIHRoZSBzdXBlciBsYXRlIHJlcGx5ISBJIGp1 c3Qgc2VudCB0aGUgcGF0Y2ggZm9yIHRoZSBgbGVuYCBkZXNjcmlwdGlvbiBbMV0uCgpSZWdhcmRp bmcgdGhlIG1heCBzaXplIGZvciB0aGUgcGFja2V0IGRhdGEsIHRoZSBwcm9wb3NhbCBmb3IgYWRk aW5nIGEgZmllbGQgaW4gdGhlIGNvbmZpZyBzcGFjZSBzb3VuZHMgZ29vZCB0byBtZS4gV2hhdCB3 b3VsZCBiZSBzb21lIG5leHQgc3RlcHMgaGVyZT8gU2hvdWxkIEkgc2VuZCBhIHBhdGNoIGZvciB0 aGlzIG9uZSBhcyB3ZWxsPwo8L3ByZT4KICAgICAgPC9ibG9ja3F1b3RlPgogICAgICA8cHJlIGNs YXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPgpZZXMsIHBsZWFzZS4KCjwvcHJlPgogICAgICA8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICA8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJl IiB3cmFwPSIiPkZyb20gd2hhdCBJIHVuZGVyc3RhbmQsIHdlIHdvdWxkIGRlZmluZSBhIG5ldyBm ZWF0dXJlIGZvciB0aGUgbWF4IHNpemUsIGFuZAphZGQgYSBuZXcgZmllbGQgaW4gdGhlIGNvbmZp ZyBzcGFjZS4gRGlkIEkgbWlzdW5kZXJzdGFuZCBpdD8KPC9wcmU+CiAgICAgIDwvYmxvY2txdW90 ZT4KICAgICAgPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4KVGhhdCdzIHdoYXQg SSB3b3VsZCBkbyA6LSkKV2hlbiB0aGUgZmVhdHVyZSBpcyBuZWdvdGlhdGVkLCB0aGVuIHRoZSBk cml2ZXIgc2hvdWxkIG5vdCBzZW5kCnBhY2tldHMgYW5kIGFsbG9jYXRlIFJYIGJ1ZmZlcnMgbGFy Z2VyIHRoYW4gdGhhdCBzaXplLgoKVGhhbmtzLApTdGVmYW5vCgo8L3ByZT4KICAgIDwvYmxvY2tx dW90ZT4KICAgIDxwcmU+CkhpLAoKSSBqdXN0IHNlbnQgYSBwYXRjaCBmb3IgdGhlIG1heCBzaXpl IGNvbmZpZyBmaWVsZDogPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0 cHM6Ly9saXN0cy5vYXNpcy1vcGVuLm9yZy9hcmNoaXZlcy92aXJ0aW8tY29tbWVudC8yMDIyMDQv bXNnMDAwMTAuaHRtbCI+aHR0cHM6Ly9saXN0cy5vYXNpcy1vcGVuLm9yZy9hcmNoaXZlcy92aXJ0 aW8tY29tbWVudC8yMDIyMDQvbXNnMDAwMTAuaHRtbDwvYT4uIApJdCBtb3N0bHkgZm9sbG93cyB0 aGUgc3BlYyBmb3JtYXQgZm9yIE1UVS4gRm9yIHRoZSBtYXggdmFsdWUgSSB1c2VkIGZvciBub3cg dGhlIG9uZSBkZWZpbmVkIGluIGxpbnV4LCBidXQgc2hvdWxkIHdlIGFjdHVhbGx5IGdvIHdpdGgg YSBoaWdoZXIgb25lPwoKVGhhbmsgeW91LApMYXVyYQo8L3ByZT4KICAgIDxwPjxicj4KICAgIDwv cD4KICA8cD48L3A+Cgo8cD48YnI+CkFtYXpvbiBEZXZlbG9wbWVudCBDZW50ZXIgKFJvbWFuaWEp IFMuUi5MLiByZWdpc3RlcmVkIG9mZmljZTogMjdBIFNmLiBMYXphciBTdHJlZXQsIFVCQzUsIGZs b29yIDIsIElhc2ksIElhc2kgQ291bnR5LCA3MDAwNDUsIFJvbWFuaWEuIFJlZ2lzdGVyZWQgaW4g Um9tYW5pYS4gUmVnaXN0cmF0aW9uIG51bWJlciBKMjIvMjYyMS8yMDA1LjwvcD4KPC9ib2R5Pgo8 L2h0bWw+Cg== --------------QHiGTdjYlNj0UtrtXxPv4BKp-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 6C3D79864DC for ; Wed, 6 Apr 2022 07:42:20 +0000 (UTC) MIME-Version: 1.0 References: <1645101080313.3853@amazon.com> <20220217125506.icgvndy3v66cyhxy@sgarzare-redhat> <0420e5d6-60f0-be57-ec6a-e88127174cda@gmail.com> <1645519589258.8467@amazon.com> <20220223085725.22vwp72qo7m6noq7@sgarzare-redhat> <1645623537015.64403@amazon.com> <1647943078836.86626@amazon.com> <29c47acc-b9fe-2787-3fae-52e666a54955@amazon.com> In-Reply-To: <29c47acc-b9fe-2787-3fae-52e666a54955@amazon.com> From: Stefano Garzarella Date: Wed, 6 Apr 2022 09:42:00 +0200 Message-ID: Subject: Re: [virtio-comment] vsock: define a maximum size for the packet data Content-Type: text/plain; charset="UTF-8" To: Laura Loghin Cc: Arseniy Krasnov , "virtio-comment@lists.oasis-open.org" List-ID: On Mon, Apr 4, 2022 at 3:55 PM Laura Loghin 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 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/