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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Fri, 2010-12-03 at 11:51 +0000, Jan Beulich wrote:
> >>> On 03.12.10 at 12:12, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > 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?
> 
> No - note that I wrote it specifically this way in the original mail.
> 
> > 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.
> 
> Yes, I can see the benefit of doing it the pv-ops way. The question is
> what happens for a transmission from pv-ops (frontend or backend -
> nothing done in the transmit path) to legacy (again frontend or
> backend - nothing done in the receive path).

You mean a packet flowing pvops-domU -> pvops-dom0 -> legacy?

In this case the dom0 kernel does the necessary setup at (*) in the
pvops-domU -> (*) pvops-dom0 hop so there is nothing to do on the
pvops-dom0 (*) ->legacy hop.

If the legacy kernel forwards the packet further it will have to do the
setup on its egress path, this is the same if dom0 is pvops or legacy.

> Secondary question was whether the duplicated effort on transmission the 
> other way around
> may be a (performance) issue.

You mean the legacy (*) -> (*) pvops-dom0 -> pvops-domU case?

In that case the setup is done at the two (*)'s but it is not really
"duplicated" as such since it is in the context of two separate skbs. if
the dom0 was legacy then the second one would still happen but on the
egress path.

I have a feeling I'm not understanding what your concern is correctly.
If the above isn't what you mean can you give an example of the path of
the packet and when the setup is (not) occurring.

Ian.


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