[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1370437077.4021.15.camel@deadeye.wl.decadent.org.uk>
Date: Wed, 5 Jun 2013 13:57:57 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Tom Parkin <tparkin@...alix.com>
CC: <netdev@...r.kernel.org>, <jchapman@...alix.com>
Subject: Re: [PATCH] l2tp: avoid checksum offload for fragmented packets
On Wed, 2013-06-05 at 10:41 +0100, Tom Parkin wrote:
> On Mon, Jun 03, 2013 at 03:44:12PM +0100, Ben Hutchings wrote:
> > On Mon, 2013-06-03 at 08:49 +0100, Tom Parkin wrote:
> > > Hardware offload for UDP datagram checksum calculation doesn't work with
> > > fragmented IP packets -- the device will note the fragmentation and leave the
> > > UDP checksum well alone.
> > >
> > > As such, if we expect the L2TP packet to be fragmented by the IP layer we need
> > > to perform the UDP checksum ourselves in software (ref: net/ipv4/udp.c).
> > >
> > > This change modifies the L2TP xmit path to fallback to software checksum
> > > calculation if the L2TP packet + IP header exceeds the tunnel device MTU.
> > [...]
> >
> > Surely this should be done in the IP stack when fragmenting, not in any
> > particular client?
> >
>
> Hmm, that's a good question.
>
> I'm not sure it makes sense to push this down into the IP layer, though. Since
> it's the UDP checksum we're calculating, it seems reasonable to handle it at
> the UDP layer (which is where L2TP sits when using UDP encapsulation).
TCP, UDP and similar checksums can be handled generically, e.g. if
dev_hard_start_xmit() finds the device doesn't actually do checksum
offload then it calls skb_checksum_help() to fill it in. I was thinking
that since the IP layer makes the decision to fragment then it should
also be responsible for filling in the checksum before doing so. Why
should the transport layer protocol have to guess?
> If you're worried about reproducing similar code in both UDP and L2TP
> I can see where you're coming from, but since UDP uses corking and
> L2TP doesn't the data transmit path is quite dissimilar. We could
> probably do some work to share the code, but it doesn't seem worth it
> for the amount of sharing we'd be able to achieve.
OK, so long as you've thought about the options.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists