OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[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:
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?
Agree, just added this section based on TSO4/6, looks this section doesn't help a lot, will drop it.


  \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

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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]