[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH v3] virtio-spec: Introduce new Receive-Segment-Coalescing feature for guest
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]