WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: skb_checksum_setup() placement in pv-ops vs. legacy kern

On Tue, 2010-12-07 at 12:24 +0000, Jan Beulich wrote:
> >>> On 03.12.10 at 14:18, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > The setup which is done in skb_checksum_setup is internal to the guest's
> > skb data structure and doesn't cross the pv interface boundary. The
> > fields which it sets up are just offsets to the checksum field in the
> > packet, it doesn't actually manipulate the content of the packet or
> > impact what goes into the ring until/unless the guest does TSO or
> > something similar in which case the kernel needs to make sure the fields
> > are setup first.
> 
> Okay, that makes it much easier to change the behavior then.
> 
> What I'm then not understanding is who the consumer of this
> data is,

The physical NIC driver can use it as part of setting up its descriptors
fo transmit with TSO. I think the software TSO/GSO egress paths use it
too in skb_checksum_help().

> and why it wasn't done the receive path way from the
> beginning. Were there issues with the no longer used loopback
> driver? Or did kernel networking infrastructure change (if so,
> it'd be nice to know when and what)?

I don't really know the answer to this, it's a little before my time.

Perhaps it was simply a desire to defer work as long as possible in the
hopes that it won't be necessary for some reason? e.g. the skb gets
dropped and not delivered. Doesn't seem terribly compelling to me --
perhaps someone else remembers that far back.

A bunch of stuff relating the CHECKSUM_* changed at some point after
2.6.18 but I don't know if that had any impact on this aspect of things.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel