From: Anil Madhavapeddy <anil@recoil.org>
To: Balraj Singh <balrajsingh@ieee.org>, xen-devel@lists.xenproject.org
Cc: Mirage List <cl-mirage@lists.cam.ac.uk>
Subject: Re: Question about TCP checksum offload in Xen
Date: Thu, 5 Dec 2013 11:29:53 +0000 [thread overview]
Message-ID: <20131205112952.GF14792@dark.recoil.org> (raw)
In-Reply-To: <CANeYhgE44vTfP8mGQ5nvd8gyBbV_uLiTOgpdUmAYzeW4_KHpMw@mail.gmail.com>
On Tue, Dec 03, 2013 at 01:00:23PM +0000, Balraj Singh wrote:
> Hi,
>
> I'm working on verifying TCP checksums on incoming packets in Mirage, but
> I've run into a bit of a problem.
>
> If TCP checksum offload is turned on on a virtual interface (this is the
> default), and if the TCP connection is local to the machine, it looks like
> Xen does not calculate the checksum at all. This may be valid because Xen
> may be providing a stronger guarantee, but it means that incoming packets
> don't have a valid checksum in the header. This then means that in Mirage
> we can't just have checksum verification turned on all the time. This
> would have been the safe fall back option and detecting that checksum
> offload is on, and then not duplicating the verification in Mirage would
> have been an optimisation. But it looks like this is not an option. Now I
> need to know for every incoming packet whether checksum verification should
> be done or not. It should ideally be for every packet since chksum offload
> can be turned off and on on the VIF and existing tcp connections should
> continue. If not every packet, I need to get a notification or efficiently
> detect right away that the setting is changed on the VIF.
This is a question that seems to keep coming up even for Linux and
Windows, as the combination of local<->local VMs vs local<->off-host and
the checksum offload is quite confusing.
CCing xen-devel: is the appropriate behaviour for a guest VM that wants to
use checksum offloading in all situations documented anywhere?
--
Anil Madhavapeddy http://anil.recoil.org
next parent reply other threads:[~2013-12-05 11:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANeYhgE44vTfP8mGQ5nvd8gyBbV_uLiTOgpdUmAYzeW4_KHpMw@mail.gmail.com>
2013-12-05 11:29 ` Anil Madhavapeddy [this message]
2013-12-05 11:39 ` Question about TCP checksum offload in Xen Ian Campbell
2013-12-05 11:45 ` Richard Mortier
2013-12-05 11:52 ` Ian Campbell
2013-12-05 12:47 ` Paul Durrant
2013-12-05 12:55 ` Richard Mortier
2013-12-05 13:33 ` Balraj Singh
2013-12-05 13:42 ` Paul Durrant
2013-12-05 11:47 ` Paul Durrant
2013-12-05 12:37 ` John Haxby
2013-12-05 12:56 ` Balraj Singh
2013-12-05 15:19 ` John Haxby
2013-12-05 13:15 ` Jon Crowcroft
2013-12-05 13:43 ` Balraj Singh
2013-12-05 21:08 ` James Harper
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=20131205112952.GF14792@dark.recoil.org \
--to=anil@recoil.org \
--cc=balrajsingh@ieee.org \
--cc=cl-mirage@lists.cam.ac.uk \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.