[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v3] virtio_net: support split header
On Tue, 14 Jun 2022 16:51:58 +0800, Jason Wang <jasowang@redhat.com> wrote: > On Mon, Jun 6, 2022 at 8:11 PM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote: > > > > The purpose of this feature is to split the header and the payload of > > the packet. > > > > | receive buffer | > > | 0th descriptor | 1th descriptor | > > | virtnet hdr | mac | ip hdr | tcp hdr|<-- hold -->| payload | > > > > We can use a buffer plus a separate page when allocating the receive > > buffer. In this way, we can ensure that all payloads can be > > independently in a page, which is very beneficial for the zerocopy > > implemented by the upper layer. > > > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> > > --- > > > > 1. Fix some syntax issues > > 2. Fix some terminology issues > > 3. It is not unified with ip alignment, so ip alignment is not included > > 4. Make it clear that the device must support four types, in the case of > > successful negotiation. > > > > conformance.tex | 2 ++ > > content.tex | 82 +++++++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 84 insertions(+) > > > > diff --git a/conformance.tex b/conformance.tex > > index 663e7c3..6f561fb 100644 > > --- a/conformance.tex > > +++ b/conformance.tex > > @@ -149,6 +149,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets} > > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode} > > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration / Setting Offloads State} > > \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) } > > +\item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Split Header} > > \end{itemize} > > > > \conformance{\subsection}{Block Driver Conformance}\label{sec:Conformance / Driver Conformance / Block Driver Conformance} > > @@ -411,6 +412,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets} > > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending} > > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode} > > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing} > > +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Split Header} > > \end{itemize} > > > > \conformance{\subsection}{Block Device Conformance}\label{sec:Conformance / Device Conformance / Block Device Conformance} > > diff --git a/content.tex b/content.tex > > index 7508dd1..a5a29d2 100644 > > --- a/content.tex > > +++ b/content.tex > > @@ -3084,6 +3084,9 @@ \subsection{Feature bits}\label{sec:Device Types / Network Device / Feature bits > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control > > channel. > > > > +\item[VIRTIO_NET_F_SPLIT_HEADER (55)] Device supports to split the protocol > > + header and the payload. > > + > > \item[VIRTIO_NET_F_HOST_USO (56)] Device can receive USO packets. Unlike UFO > > (fragmenting the packet) the USO splits large UDP packet > > to several segments when each of these smaller packets has UDP header. > > @@ -3131,6 +3134,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ. > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NET_F_HOST_TSO6. > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ. > > +\item[VIRTIO_NET_F_SPLIT_HEADER] Requires VIRTIO_NET_F_CTRL_VQ. > > \end{description} > > > > \subsubsection{Legacy Interface: Feature bits}\label{sec:Device Types / Network Device / Feature bits / Legacy Interface: Feature bits} > > @@ -3362,6 +3366,7 @@ \subsection{Device Operation}\label{sec:Device Types / Network Device / Device O > > #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 > > #define VIRTIO_NET_HDR_F_DATA_VALID 2 > > #define VIRTIO_NET_HDR_F_RSC_INFO 4 > > +#define VIRTIO_NET_HDR_F_SPLIT_HEADER 8 > > u8 flags; > > #define VIRTIO_NET_HDR_GSO_NONE 0 > > #define VIRTIO_NET_HDR_GSO_TCPV4 1 > > @@ -4463,6 +4468,83 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi > > according to the native endian of the guest rather than > > (necessarily when not using the legacy interface) little-endian. > > > > +\paragraph{Split Header}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Split Header} > > + > > +If the VIRTIO_NET_F_SPLIT_HEADER feature is negotiated, > > +the device supports to split the protocol header and the payload. > > +The protocol header and the payload will be separated into different > > +descriptors. > > + > > +\subparagraph{Split Header}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Split Header / Setting Split Header} > > + > > +To configure the split header, the following layout structure and definitions > > +are used: > > + > > +\begin{lstlisting} > > +struct virtio_net_split_header_config { > > +#define VIRTIO_NET_SPLIT_HEADER_TYPE_TCP4 1 > > +#define VIRTIO_NET_SPLIT_HEADER_TYPE_TCP6 2 > > +#define VIRTIO_NET_SPLIT_HEADER_TYPE_UDP4 4 > > +#define VIRTIO_NET_SPLIT_HEADER_TYPE_UDP6 8 > > + le64 type; > > +}; > > + > > +#define VIRTIO_NET_CTRL_SPLIT_HEADER 6 > > + #define VIRTIO_NET_CTRL_SPLIT_HEADER_SET 0 > > +\end{lstlisting} > > + > > +The class VIRTIO_NET_CTRL_SPLIT_HEADER has one command: > > +VIRTIO_NET_CTRL_SPLIT_HEADER_SET applies the new split header configuration. > > + > > +The driver can enable or disable the split header by setting or clearing > > +corresponding bits in \field{type}. > > + > > +The protocol header contains all headers before level 4 payload. > > So if the split header means only for level 4 we need to clarify it in > the above feature definition. > > Or is it worthwhile to leave space to split at level 3? (E.g modern > NICs can do splitting at various layer, l2/l3 and inner) Should support splitting at various layer. It's my expression problem. > > > For ip > > +fragmented packets, except for the first fragment, the protocol header only > > +contains all headers before level 3 payload. > > Does it mean the device needs to track the fragment ID and only do > this for the L4 protocol that is set via > VIRTIO_NET_CTRL_SPLIT_HEADER_SET? > > This looks complicates the design of the device and it doesn't help > too much since most segmentations are smaller than page size I agree. So I think it should not be supported for split ip fragmented packets > > > + > > +\devicenormative{\subparagraph}{Setting Split Header}{Device Types / Network Device / Device Operation / Control Virtqueue / Split Header} > > + > > +Split header MUST be disabled upon device reset. > > + > > +If VIRTIO_NET_F_SPLIT_HEADER is negotiated, the device MUST support > > +VIRTIO_NET_SPLIT_HEADER_TYPE_TCP4, VIRTIO_NET_SPLIT_HEADER_TYPE_TCP6, > > +VIRTIO_NET_SPLIT_HEADER_TYPE_UDP4, VIRTIO_NET_SPLIT_HEADER_TYPE_UDP6. > > + > > +A device MUST NOT perform split header in the following cases: > > +\begin{itemize} > > + \item device does not recognize the protocol of the packet. > > + \item \field{type} does not include the protocol of the packet. > > + \item the buffer consists of only one descriptor. > > + \item the virtio net header and the protocol header exceeds the size > > + of the first descriptor. > > + \item If VIRTIO_NET_F_MRG_RXBUF is not negotiated and the size of the > > + payload exceeds the size of the buffer chain starting from the 2nd > > I think it's a "descriptor chain" instead of a buffer chain, since we > can't use the buffer chain if MRG_RXBUF is not negotiated. Will fix. > > > + descriptor. > > +\end{itemize} > > + > > +If the header is split by the device, the \field{flags} of structure > > +virtio_net_hdr MUST contains VIRTIO_NET_HDR_F_SPLIT_HEADER. The protocol header > > s/contains/contain/ Will fix. > > > +MUST be on the buffer specified by the first descriptor, following the virtio > > +net header. The payload MUST starts from the buffer of the second descriptor. > > s/starts/start/, I think we can remove "the buffer of" otherwise it > may be confusing. Will fix. > > > +The device MUST set \field{hdr_len} of structure virtio_net_hdr to the length of > > +the protocol header. > > + > > +If the header is split by the device, VIRTIO_NET_F_MRG_RXBUF is negotiated, > > +and the receive packet is spread over multiple buffers, when the device uses a > > +buffer other than the first, if the buffer consists of multiple descriptors, the > > +device MUST skip the buffer of the first descriptor, > > skip the first descriptor of the buffer actually? Will fix. Thanks. > > > because the buffer of the > > +first descriptor is used to carry the protocol header. > > + > > +\drivernormative{\subparagraph}{Setting Split Header}{Device Types / Network Device / Device Operation / Control Virtqueue / Split Header} > > + > > +If VIRTIO_NET_HDR_F_SPLIT_HEADER bit in \field{flags} is set, the driver MUST > > +trust \field{hdr_len}. > > + > > +If the split header is enabled, the buffers submitted to receiveq by the > > +driver SHOULD at least be composed of two descriptors. The buffer specified by > > +the first descriptor SHOULD be able to accommodate the virtio net header and the > > +protocol header. > > Thanks > > > > > \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device > > Types / Network Device / Legacy Interface: Framing Requirements} > > -- > > 2.31.0 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]