[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.