[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: [virtio-dev] [PATCH v3] virtio-spec: Introduce new Receive-Segment-Coalescing feature for guest
On 2016年06月23日 02:25, Michael S. Tsirkin wrote:
Sorry for missed this comment, this field is used to indicate something similar with 'gso_size' for TSO4/6, after checked out the spec again, i think this is useless for rsc, it also can be calculated out by the guest, will remove it in next version.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 ECNThis 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]