Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Jul 2015 18:01:21 -0700
From:      Colin Percival <cperciva@freebsd.org>
To:        Kristof Provost <kp@FreeBSD.org>
Cc:        Mark Felder <feld@FreeBSD.org>, freebsd-xen@freebsd.org, gnn@freebsd.org
Subject:   Re: Networking under Xen
Message-ID:  <55B582E1.5070803@freebsd.org>
In-Reply-To: <20150726131642.GC2484@vega.codepro.be>
References:  <4E7B7075-4E0D-4EA7-9F5D-6D252CFBD487@gmail.com> <1436890526.3162974.323521249.6B73E6E2@webmail.messagingengine.com> <55A55AE8.4090101@freebsd.org> <1436901780.3211878.323698017.360F8D73@webmail.messagingengine.com> <20F2398D-ECDF-4CF4-966D-18C894779C4C@FreeBSD.org> <55A611B1.6000000@freebsd.org> <20150726131642.GC2484@vega.codepro.be>

next in thread | previous in thread | raw e-mail | index | archive | help
On 07/26/15 06:16, Kristof Provost wrote:
> On 2015-07-15 00:54:25 (-0700), Colin Percival <cperciva@freebsd.org> wrote:
>> In my tests, deleting these lines from pf_ioctl.c
>> 3570	/* We need a proper CSUM befor we start (s. OpenBSD ip_output) */
>> [...]
>> unbreaks pf+TSO on EC2 instances.  I'm not entirely sure why these lines
>> are there in the first place, which is why I didn't want to simply go in
>> and remove them -- but it may be that wrapping those lines in something
>> like "if ((csum_flags & CSUM_TSO) == 0)" would solve the problem without
>> breaking anything else.
>
> I think the reason for this checksum calculation is that pf sometimes
> modifies the packet, so it also updates the checksum.

Aha, this is exactly the sort of thing I was worried about.  I'm glad you
understand this stuff better than me.

> It doesn't work on Xen TSO interfaces because (I assume) it expects to
> get the pseudo header checksum, not the full checksum.
> It's not entirely clear to my why it's not broken on my hardware (which
> claims TSO support), but perhaps Xen is more picky than actual hardware.

I'm not 100% certain about this, but I don't think Xen is doing anything
with the checksum; rather, everything is being passed through to the
underlying hardware, and some NICs are pickier than others.

I'll refrain from commenting on your plans for fixing this since, as I
mentioned above, you understand how pf and the network stack work far better
than I do. :-)

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55B582E1.5070803>