From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [PATCH RFC (resend) net-next 0/6] virtio-net: Add support for virtio-net header extensions Date: Tue, 18 Apr 2017 11:01:02 +0800 Message-ID: <0d9216af-e3db-e06b-f70d-d77f519c3fd4@redhat.com> References: <1492274298-17362-1-git-send-email-vyasevic@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: virtualization@lists.linux-foundation.org, virtio-dev@lists.oasis-open.org, mst@redhat.com, maxime.coquelin@redhat.com, Vladislav Yasevich To: Vladislav Yasevich , netdev@vger.kernel.org Return-path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <1492274298-17362-1-git-send-email-vyasevic@redhat.com> List-Id: netdev.vger.kernel.org On 2017年04月16日 00:38, Vladislav Yasevich wrote: > Curreclty virtion net header is fixed size and adding things to it is rather > difficult to do. This series attempt to add the infrastructure as well as some > extensions that try to resolve some deficiencies we currently have. > > First, vnet header only has space for 16 flags. This may not be enough > in the future. The extensions will provide space for 32 possbile extension > flags and 32 possible extensions. These flags will be carried in the > first pseudo extension header, the presense of which will be determined by > the flag in the virtio net header. > > The extensions themselves will immidiately follow the extension header itself. > They will be added to the packet in the same order as they appear in the > extension flags. No padding is placed between the extensions and any > extensions negotiated, but not used need by a given packet will convert to > trailing padding. Do we need a explicit padding (e.g an extension) which could be controlled by each side? > > For example: > | vnet mrg hdr | ext hdr | ext 1 | ext 2 | ext 5 | .. pad .. | packet data | Just some rough thoughts: - Is this better to use TLV instead of bitmap here? One advantage of TLV is that the length is not limited by the length of bitmap. - For 1.1, do we really want something like vnet header? AFAIK, it was not used by modern NICs, is this better to pack all meta-data into descriptor itself? This may need a some changes in tun/macvtap, but looks more PCIE friendly. Thanks > > Extensions proposed in this series are: > - IPv6 fragment id extension > * Currently, the guest generated fragment id is discarded and the host > generates an IPv6 fragment id if the packet has to be fragmented. The > code attempts to add time based perturbation to id generation to make > it harder to guess the next fragment id to be used. However, doing this > on the host may result is less perturbation (due to differnet timing) > and might make id guessing easier. Ideally, the ids generated by the > guest should be used. One could also argue that we a "violating" the > IPv6 protocol in the if the _strict_ interpretation of the spec. > > - VLAN header acceleration > * Currently virtio doesn't not do vlan header acceleration and instead > uses software tagging. One of the first things that the host will do is > strip the vlan header out. When passing the packet the a guest the > vlan header is re-inserted in to the packet. We can skip all that work > if we can pass the vlan data in accelearted format. Then the host will > not do any extra work. However, so far, this yeilded a very small > perf bump (only ~1%). I am still looking into this. > > - UDP tunnel offload > * Similar to vlan acceleration, with this extension we can pass additional > data to host for support GSO with udp tunnel and possible other > encapsulations. This yeilds a significant perfromance improvement > (still testing remote checksum code). > > An addition extension that is unfinished (due to still testing for any > side-effects) is checksum passthrough to support drivers that set > CHECKSUM_COMPLETE. This would eliminate the need for guests to compute > the software checksum. > > This series only takes care of virtio net. I have addition patches for the > host side (vhost and tap/macvtap as well as qemu), but wanted to get feedback > on the general approach first. > > Vladislav Yasevich (6): > virtio-net: Remove the use the padded vnet_header structure > virtio-net: make header length handling uniform > virtio_net: Add basic skeleton for handling vnet header extensions. > virtio-net: Add support for IPv6 fragment id vnet header extension. > virtio-net: Add support for vlan acceleration vnet header extension. > virtio-net: Add support for UDP tunnel offload and extension. > > drivers/net/virtio_net.c | 132 +++++++++++++++++++++++++++++++++------- > include/linux/skbuff.h | 5 ++ > include/linux/virtio_net.h | 91 ++++++++++++++++++++++++++- > include/uapi/linux/virtio_net.h | 38 ++++++++++++ > 4 files changed, 242 insertions(+), 24 deletions(-) >