RE: [EXT] [virtio] [PATCH requirements 7/7] net-features: Add header data split requirements

[Satananda Burla <sburla@marvell.com>]

Hi Parav

> -----Original Message-----
> From: virtio@lists.oasis-open.org <virtio@lists.oasis-open.org> On
> Behalf Of Parav Pandit
> Sent: Sunday, July 23, 2023 8:34 PM
> To: virtio-comment@lists.oasis-open.org
> Cc: shahafs@nvidia.com; hengqi@linux.alibaba.com; virtio@lists.oasis-
> open.org; Parav Pandit <parav@nvidia.com>
> Subject: [EXT] [virtio] [PATCH requirements 7/7] net-features: Add
> header data split requirements
> 
> External Email
> 
> ----------------------------------------------------------------------
> Add header data split requirements for the receive packets.
> 
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>  net-workstream/features-1.4.md | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/net-workstream/features-1.4.md b/net-workstream/features-
> 1.4.md
> index 37820b6..a64e356 100644
> --- a/net-workstream/features-1.4.md
> +++ b/net-workstream/features-1.4.md
> @@ -11,6 +11,7 @@ together is desired while updating the virtio net
> interface.
>  3. Virtqueue notification coalescing re-arming support
>  4  Virtqueue receive flow filters (RFF)
>  5. Device timestamp for tx and rx packets
> +6. Header data split for the receive virtqueue
> 
>  # 3. Requirements
>  ## 3.1 Device counters
> @@ -306,3 +307,15 @@ struct virtio_net_rff_delete {
>     point of reception from the network.
>  3. The device should provide a receive packet timestamp in a single DMA
>     transaction along with the rest of the receive completion fields.
> +
> +## 3.6 Header data split for the receive virtqueue
> +1. The device should be able to DMA the packet header and data to two
> different
> +   memory locations, this enables driver and networking stack to
> perform zero
> +   copy to application buffer(s).
> +2. The driver should be able to configure maximum header buffer size
> per
> +   virtqueue.
> +3. The header buffer to be in a physically contiguous memory per
> virtqueue
> +4. The device should be able to indicate header data split in the
> receive
> +   completion.
The device should also be able to indicate the size of the header that
has been placed in the header buffer. 
> +5. The device should be able to zero pad the header buffer when the
> received
> +   header is shorter than cpu cache line size.
I am not sure why this is needed. The driver would anyway need the size
of header that was placed in the header buffer to be indicated by the
device and would not consume beyond that.
> --
> 2.26.2
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-
> 2Dopen.org_apps_org_workgroup_portal_my-
> 5Fworkgroups.php&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=NHDPsfcAYlN2z-
> NXHHG4WB09qqS0voo_nf6_kGS625A&m=8mCmsaqsETpHBYC1cSO251gJSPqA8d8Tv5mTc3Av
> 0hL0J7SuDkUgA4w2WQFUq-pD&s=4CzAmGWykUmjgHgWM2C2-
> S4tknBE2erM7pTbXK10r7M&e=