[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |