From: Vladislav Yasevich <vyasevich@gmail.com>
To: netdev@vger.kernel.org
Cc: virtio-dev@lists.oasis-open.org, mst@redhat.com,
virtualization@lists.linux-foundation.org,
maxime.coquelin@redhat.com
Subject: [PATCH RFC (resend) net-next 0/6] virtio-net: Add support for virtio-net header extensions
Date: Sat, 15 Apr 2017 12:38:12 -0400 [thread overview]
Message-ID: <1492274298-17362-1-git-send-email-vyasevic@redhat.com> (raw)
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.
For example:
| vnet mrg hdr | ext hdr | ext 1 | ext 2 | ext 5 | .. pad .. | packet data |
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(-)
--
2.7.4
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: Add support for UDP tunnel offload and extension.
drivers/net/virtio_net.c | 121 ++++++++++++++++++++++++++++++++++------
include/linux/skbuff.h | 5 ++
include/linux/virtio_net.h | 91 +++++++++++++++++++++++++++++-
include/uapi/linux/virtio_net.h | 38 +++++++++++++
4 files changed, 236 insertions(+), 19 deletions(-)
--
2.7.4
next reply other threads:[~2017-04-15 16:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-15 16:38 Vladislav Yasevich [this message]
2017-04-15 16:38 ` [PATCH RFC (resend) net-next 1/6] virtio-net: Remove the use the padded vnet_header structure Vladislav Yasevich
2017-04-15 16:38 ` [PATCH RFC (resend) net-next 2/6] virtio-net: make header length handling uniform Vladislav Yasevich
2017-04-15 16:38 ` [PATCH RFC (resend) net-next 3/6] virtio_net: Add basic skeleton for handling vnet header extensions Vladislav Yasevich
2017-04-18 2:52 ` Jason Wang
2017-04-15 16:38 ` [PATCH RFC (resend) net-next 4/6] virtio-net: Add support for IPv6 fragment id vnet header extension Vladislav Yasevich
2017-04-15 16:38 ` [PATCH RFC (resend) net-next 5/6] virtio-net: Add support for vlan acceleration " Vladislav Yasevich
2017-04-16 0:28 ` Michael S. Tsirkin
2017-04-18 2:54 ` Jason Wang
2017-04-15 16:38 ` [PATCH RFC (resend) net-next 6/6] virtio: Add support for UDP tunnel offload and extension Vladislav Yasevich
2017-04-18 3:01 ` [PATCH RFC (resend) net-next 0/6] virtio-net: Add support for virtio-net header extensions Jason Wang
2017-04-20 15:34 ` Vlad Yasevich
2017-04-21 4:05 ` Jason Wang
2017-04-21 13:08 ` Vlad Yasevich
2017-04-24 3:22 ` Jason Wang
2017-04-24 17:04 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1492274298-17362-1-git-send-email-vyasevic@redhat.com \
--to=vyasevich@gmail.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).