Re: [virtio-dev] [PATCH v3] virtio-spec: Introduce new Receive-Segment-Coalescing feature for guest

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 22, 2016 at 02:31:51AM +0800, Wei Xu wrote:
> Hi TCers,
> Just finished a new version based on feedback from v2, please help review
> it, thanks a lot.

looks good overall. some questions below.

> Changelog:
> v2->v3:
> -- Revise flag definition for RSC4/6 to start from 5, add a 'RESERVED'
> definition for already used number '2' which stands for historical
> meaning of 'VIRTIO_NET_HDR_GSO_TCPV4_ECN'.
> -- Add prefix 'rsc_' to new fields in virtio_net_hdr.
> -- Drop wrong legacy part.
> -- Revise maximum payload size for coalesced packets, also revise max
> ip payload from 65536 to 65535 for TSO4/6/UFO.
> -- Add default value of new fields member as zero for original packets.
> -- Drop redundant hint in 'hdr_len' for RSC header size, both
> send/receive should use the same header after the feature was
> acknowledged.
> 
> v1->v2:
> Feature 22 should not be used by device, replacing it with 41 and 42 for
> VIRTIO_NET_GUEST_RSC4 and VIRTIO_NET_GUEST_RSC6.
> 
> Index: content.tex
> ===================================================================
> --- content.tex	(revision 569)
> +++ content.tex	(working copy)
> @@ -3086,6 +3086,11 @@
> 
>  \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control
>      channel.
> +
> +\item[VIRTIO_NET_F_GUEST_RSC4 (41)] Driver can receive coalesced IPv4 tcp
> packets.
> +
> +\item[VIRTIO_NET_F_GUEST_RSC6 (42)] Driver can receive coalesced IPv6 tcp
> packets.
> +
>  \end{description}
> 
>  \subsubsection{Feature bit requirements}\label{sec:Device Types / Network
> Device / Feature bits / Feature bit requirements}
> @@ -3247,8 +3252,12 @@
>          u8 flags;
>  #define VIRTIO_NET_HDR_GSO_NONE        0
>  #define VIRTIO_NET_HDR_GSO_TCPV4       1
> +#define VIRTIO_NET_HDR_RESERVED        2
>  #define VIRTIO_NET_HDR_GSO_UDP         3
>  #define VIRTIO_NET_HDR_GSO_TCPV6       4
> +#define VIRTIO_NET_HDR_RSC_NONE        5
> +#define VIRTIO_NET_HDR_RSC_TCPV4       6
> +#define VIRTIO_NET_HDR_RSC_TCPV6       7
>  #define VIRTIO_NET_HDR_GSO_ECN      0x80
>          u8 gso_type;
>          le16 hdr_len;
> @@ -3256,6 +3265,9 @@
>          le16 csum_start;
>          le16 csum_offset;
>          le16 num_buffers;
> +        le16 rsc_pkts;
> +        le16 rsc_size;
> +        le16 rsc_dup_acks;
>  };
>  \end{lstlisting}
> 
> @@ -3446,11 +3458,27 @@
> 
>  If the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6 or
>  VIRTIO_NET_F_GUEST_UFO features are used, the maximum incoming packet
> -will be to 65550 bytes long (the maximum size of a
> +will be to 65549 bytes long (the maximum size of a
>  TCP or UDP packet, plus the 14 byte ethernet header), otherwise
>  1514 bytes.  The 12-byte struct virtio_net_hdr is prepended to this,
> -making for 65562 or 1526 bytes.
> +making for 65561 or 1526 bytes.
> 
> +If the VIRTIO_NET_F_GUEST_RSC4 feature is used, the maximum incoming
> +packet will be up to 65551 bytes long (the maximum size of an ip packet
> +as 65535-byte, plus the 14-byte ethernet header, and even more 2-byte
> +for a vlan packet), otherwise 1514 bytes, the 18-byte struct
> +virtio_net_hdr is prepended to this, making for 65569 or 1532 bytes.
> +
> +If the VIRTIO_NET_F_GUEST_RSC6 feature is used, since there is no
> +length limitation for IPv6 extension header, so it depends on the scenario,
> +but this feature bypasses all IPv6 packets with any extension header,
> +thus for a regular IPv6 packet, the maximum incoming packet will be
> +up to 65591-byte long (the maximum size of an IPv6 PDU as 65535-byte,
> +plus the 40-byte standard IPv6 header, and a 14-byte ethernet header,
> +and even more 2-byte for a vlan packet), otherwise 1514 bytes, the
> +18-byte struct virtio_net_hdr is prepended to this, making for 65609
> +or 1532 bytes.
> +

I would rather not touch this section at all for now.

Is this mess strictly required for RSC to pass WHQL?
Can't device just limit itself to e.g. 65549 with RSC 4 and 6,
avoid coalescing if it would be exceeded?


>  \drivernormative{\paragraph}{Setting Up Receive Buffers}{Device Types /
> Network Device / Device Operation / Setting Up Receive Buffers}
> 
>  \begin{itemize}
> @@ -3514,6 +3542,23 @@
>    set: if so, device has validated the packet checksum.
>    In case of multiple encapsulated protocols, one level of checksums
>    has been validated.
> +
> +\item If one or both VIRTIO_NET_F_GUEST_RSC4, RSC6 were negotiated,
> +  but it is an original packet which didn't coalesce any packet,
> +  then the \field{flags} should be set to VIRTIO_NET_HDR_RSC_NONE.
> +
> +\item If one or both VIRTIO_NET_F_GUEST_RSC4, RSC6 options were negotiated,
> +  and \field{flags} is either RSC4 or RSC6, then \field{rsc_pkts} indicates
> +  how many packets are coalesced into this packet, otherwise it should be
> zero.
> +
> +\item If one or both VIRTIO_NET_F_GUEST_RSC4, RSC6 options were negotiated,
> +  and \field{flags} is either RSC4 or RSC6, then \field{rsc_size} indicates
> +  the real packet size after coalesced, otherwise it should be zero.

Is this not always same as buffer size minus the virtio net header?

> +
> +\item If one or both VIRTIO_NET_F_GUEST_RSC4, RSC6 options were negotiated,
> +  and \field{flags} is either RSC4 or RSC6, then \field{rsc_dup_acks}
> indicates
> +  how many duplicated ack packets are coalesced into this packet, otherwise
> +  it should be zero.
>  \end{enumerate}
> 
>  Additionally, VIRTIO_NET_F_GUEST_CSUM, TSO4, TSO6, UDP and ECN