[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH net-next v4 2/5] xen-netback: add support for IPv6 checksum offload from guest
> -----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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |