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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Fri, 2010-12-03 at 10:52 +0000, Jan Beulich wrote:
> Ian, Jeremy,
> 
> knowing pretty little about networking, it nevertheless seems to me
> that the different placement of skb_checksum_setup() (in the receive
> paths of pv-ops vs in various transmit paths in legacy) poses a
> compatibility problem (nothing done on either side if sending from
> pv-ops to legacy, and done on both ends when sending from legacy
> to pv-ops). Am I overlooking something here?

Possibly confusion due to the backwards naming convention in netback?

The pvops dom0 side calls skb_checksum_setup in net_tx_submit which
(counter-intuitively) is the function which receives the skb from the
guest and passes it up to the dom0 network stack (i.e. it handles guest
tx).

Since we call skb_checksum_setup on the ingress path all skbs in the
domain 0 network stack always have their checksum fields correctly
initialised and there is never anything to be done when transmitting
transmitting out the other side, either to another domU or to a physical
device, and therefore it doesn't matter which kernel the domU is
running.

On legacy dom0 skb_checksum_setup is called on the generic transmit
path, so skbs in the domain 0 network stack can have uninitialised
checksum fields but this is always fixed up before passing back down to
either netback (called the rx path in netback parlance) or a physical
device. This can (and has) caused trouble in the past where networking
subsystems are interested in the checksum fields before egress, e.g. we
needed to do fixup in various netfilter code paths etc.

Ian.


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