Re: [Xen-devel] [PATCH net-next v4 2/5] xen-netback: add support for IPv6 checksum offload from guest

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 16 October 2013 17:12
> To: Paul Durrant
> Cc: David Vrabel; Wei Liu; netdev@xxxxxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH net-next v4 2/5] xen-netback: add support
> for IPv6 checksum offload from guest
> 
> On Mon, 2013-10-14 at 13:34 +0100, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: David Vrabel
> > > Sent: 14 October 2013 13:19
> > > To: Wei Liu
> > > Cc: Paul Durrant; netdev@xxxxxxxxxxxxxxx; Ian Campbell; David Vrabel;
> xen-
> > > devel@xxxxxxxxxxxxx
> > > Subject: Re: [Xen-devel] [PATCH net-next v4 2/5] xen-netback: add
> support
> > > for IPv6 checksum offload from guest
> > >
> > > On 14/10/13 11:55, Wei Liu wrote:
> > > > On Mon, Oct 14, 2013 at 11:49:20AM +0100, Paul Durrant wrote:
> > > >>> -----Original Message-----
> > > >>> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> > > >>> Sent: 14 October 2013 11:43
> > > >>> To: Paul Durrant
> > > >>> Cc: xen-devel@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; Wei Liu; David
> > > Vrabel;
> > > >>> Ian Campbell
> > > >>> Subject: Re: [PATCH net-next v4 2/5] xen-netback: add support for
> IPv6
> > > >>> checksum offload from guest
> > > >>>
> > > >>> On Fri, Oct 11, 2013 at 04:06:19PM +0100, Paul Durrant wrote:
> > > >>> [...]
> > > >>>> -/*
> > > >>>> - * This is the amount of packet we copy rather than map, so that
> the
> > > >>>> - * guest can't fiddle with the contents of the headers while we do
> > > >>>> - * packet processing on them (netfilter, routing, etc).
> > > >>>> +/* This is a miniumum size for the linear area to avoid lots of
> > > >>>> + * calls to __pskb_pull_tail() as we set up checksum offsets.
> > > >>>>   */
> > > >>>
> > > >>> You seem to forget to explain why 128 is chosen. :-)
> > > >>
> > > >> Is that not sufficient explanation? What sort of thing are you looking
> for?
> > > >>
> > > >
> > > >>From the second version of this patch, we had a conversation.
> > > >
> > > >> Where does 128 come from?
> > > >>
> > > >
> > > > "It's just an arbitrary power of 2 that was chosen because it seems to
> > > > cover most likely v6 headers and all v4 headers."
> > > >
> > > > So something like: "We choose 128 which is likely to cover most V6
> > > > headers and all V4 headers" would be sufficeint.
> > >
> > > Is "most IPv6 headers" actually good enough?  Don't we need to ensure
> > > netback copies all IP headers?
> > >
> >
> > It will do if checksum offload is in use, but perhaps the pull as far
> > as the transport header needs to be done anyway? I'm unsure of the
> > expectations of other code.
> 
> I've always been under the impression that transport headers needed
> pulling up too, for the benefit of netfilter perhaps?
> 
> AIUI the frags should be pure "payload". I may be wrong about that
> though...
> 

I don't believe there is actually any upper bound on IPv6 header size so coming 
up with a static value would be hard. Do all h/w drivers really have to parse 
headers (assuming they're driving dumb h/w that doesn't do header payload 
split)?

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel